抓包分析TCP三次握手和四次挥手

抓包分析

实验主要两个内容：

1. TCP三次握手和四次挥手过程
2. 分析HTTPS的TLS握手过程

TCP三次握手

windows10下wireshark工具，浏览器访问47.93.242.17端口443，即HTTPS协议，源端口54407

• 过滤规则

  ip.dst ==47.93.242.17  or ip.src == 47.93.242.17
  

  过滤ip

  tcp.port == 80
  

  过滤端口，无论是源端口还是目的端口

• 三次握手过程

1. 第一次握手tcp报文段

   

   报文段分析：

   源端口：54407
   目的端口：443
   sequence number：229919303
   SYN标志为1
   窗口大小：64240
   校验和
   可选项
   时间戳
   

2. 第二次握手

   

   报文段分析：

   源端口：443
   目的端口：54407
   sequence number： 311700020
   ackonwledgment number： 229919304
   flags：SYN=1 ACK=1
   窗口大小：29200
   校验和
   可选项
   时间戳
   

3. 第三次握手

   

   报文段分析：

   源端口：54407
   目的端口：443
   sequence number： 229919304
   ackonwledgment number： 311700021
   flags：ACK=1
   窗口大小：513
   校验和
   可选项
   时间戳
   

4. **总结：**第一次握手客户端向服务端发送SYN报文段，其中包含了自己的seq=x；第二次握手服务端向客户端发送SYN+ACK报文段，其中seq=y，ack=x+1；第三次握手客户端向服务端发送ACK报文段，其中seq=x+1，ack=y+1.

TCP四次挥手

• 四次挥手

  

  这里惊奇的发现，四次挥手实际上只进行了三次，第二次和第三次合并了！

• 第一次挥手

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hb5o14s6-1645970090549)(
  )]

• 第二次、第三次挥手

  

• 第四次挥手

• 总结

  第一次挥手，客户端向服务端发送ACK+FIN报文段，包含了seq=x，ack=上一次发送ack；第二、三次挥手，服务端向客户端发送FIN+ACK报文段，包含了seq=y，ack=x+1；第四次挥手，客户端向服务端发送ACK报文段，seq=x+1，ack=y+1，客户端进入TIME_WAIT状态，服务端接收到ACK后CLOSE

• 三次挥手的原因

  因为Linux的延迟ACK机制？感觉不对

  实际原因是，服务端实现过程是，在接收到到客户端的断开连接请求之后，马上调用close，因此ACK和FIN合并了。

HTTPS过程分析

• TLS协议

  TLS协议本身可以分为上下两层：TLS握手层协议 TLS记录层协议

• TLS握手协议

  基于ECDHE（椭圆曲线diffie-hellman秘钥交换）

  

  1. 第一次握手 client hello 客户端发送client Random

     

  2. 第二次握手 server hello、Certificate、Server Key Exchange、Server Hello Done；服务端发送server random，服务端公钥

     

     

     

  3. 第三次握手client key exchange、 change cipher spec、 encryted Handshake Message客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端的身份就是没问题的。客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端。至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，但实际应用中，x 还不是最终的会话密钥。最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。

     然后发送[ Change Cipher Spec] 消息，告诉服务端后续改用对称算法加密通信。

     最后把之前发送的数据做一个摘要，再用新生成的对称密钥加密一下，让服务端做个验证，即[ Encrypted Handshake Message]

     

  4. 第四次握手发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。