Skip to content

Latest commit

 

History

History
38 lines (25 loc) · 2.25 KB

File metadata and controls

38 lines (25 loc) · 2.25 KB

P19 考虑下面对于某 SSL 会话的一部分的 Wireshake 的输出。

a. Wireshake 分组 112 是由客户还是服务器发出的?

b. 服务器的 IP 地址和端口号是什么?

c. 假定没有丢包和重传,由客户发送的下一个 TCP 报文段的序号将是什么?

d. Wireshake 分组 112 包含了多少个 SSL 记录?

e. 分组 112 包含了一个主密钥或者加密的主密钥吗?或者两者都不是?

f. 假定握手类型字段是 1 字节并且每个长度字段是 3 字节,主密钥(或加密的主密钥)的第一个和最后一个字节的值是什么?

g. 客户加密的握手报文考虑了多少 SSL 记录?

h. 服务器加密的握手报文考虑了多少 SSL 记录?

  • a.

    • 客户端
  • b.

    • 服务器的 IP 和端口号是 216.75.194.220:443
  • c.

    • 假定没有丢包和重传,下一个 TCP 报文段的序号是 283
  • d.

    • 3 个 SSL 记录项
  • e.

    • 分组 112 包含一个用服务器公钥加密的主密钥 Pre-Master-Key。
  • f.

    • 第一个字节是 bc,最后一个字节是 29

P20 8.6.1 节中表明,不使用序号,Trudy (一名中间人) 能够在一个 SSL 会话中通过互换 TCP 报文段实施破坏。Trudy 能够通过删除一个 TCP 报文段做某种类似的事情吗?在该删除攻击中,她需要做什么才能成功?它将具有什么影响?

  • 如果通过删除 TCP 报文段来搞破坏,那么她必须修改 TCP 中的序号和确认好来保证不会引发 TCP 重传机制。这样的话 Bob 将会在不知情的情况下收到不完整的 SSL 握手报文 (而 TCP 报文段是连续的,因此序号和确认号被修改了)。

P21 假定 Alice 和 Bob 通过一个 SSL 会话通信。假定一个没有任何共享密钥的攻击者,在某分组流中插入一个假冒的 TCP 报文段,该报文段具有正确的 TCP 校验和及序号(以及正确的 IP 地址和端口号)。在接收侧 SSL 将接受该假冒分组并传递载荷给接收应用程序吗?为什么?

  • 不会,因为 SSL 记录项中使用接收方和发送方分别维护的序号进行了 MAC 的计算,所以该分组在完整性校验中无法通过。