2023年7月3日发(作者：)

TLS握⼿过程及wireshark抓包分析TLS握⼿过程及wireshark抓包分析的发展1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。1996年，SSL 3.0版问世，得到⼤规模应⽤。1999年，互联⽹标准化组织ISOC接替NetScape公司，发布了SSL的升级版 1.0版。2006年和2008年，TLS进⾏了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的。基本运⾏过程SSL/TLS协议的基本思路是采⽤，也就是说，客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密⽂后，⽤⾃⼰的私钥解密。2.1 基本过程（1） 客户端向服务器端索要并验证公钥。（2） 双⽅协商⽣成"对话密钥"。（3） 双⽅采⽤"对话密钥"进⾏加密通信。2.2 详细运⾏过程2.2.1客户端发出请求（ClientHello）客户端主要发送以下信息：（1） ⽀持的协议版本，⽐如TLS 1.0版。（2） ⼀个客户端⽣成的随机数，稍后⽤于⽣成"对话密钥"。（3） ⽀持的加密⽅法，⽐如RSA公钥加密。（4） ⽀持的压缩⽅法。需要注意的是，在开始请求的时候，客户端是不包括服务器的域名。这限制了⽬标服务器只能有⼀个⽹站，为了解决这个问题，引⼊了Server Name Indication拓展，允许客户端请求时包含域名，每个域名对应⼀本证书。上图是wireshark抓包中client hello的内容，接下来描述下client hello所携带的内容2：客户端⾸次发起TLS握⼿时会使⽤最低版本的TLS1.03：表⽰客户端所⽀持TLS的最⾼版本，为TLS1.24：随机数，客户端在请求时随机⽣成，⽤于⽣成会话密钥5：为提⾼加解密效率，设置Session ID6：所⽀持的加解密套件，具体的使⽤⽅式可在官⽅⽂档中查看8：为实现同服务器多个⽹站所加⼊的拓展，⽤于区别请求，便于发放证书这⾥提到了Session ID，因为我们在认证时使⽤了⾮对称加密，⾮对称加密在提升安全性的同时，需要耗费更多的时间。由于"对话密钥"是对称加密，所以运算速度⾮常快，⽽服务器公钥只⽤于加密"对话密钥"本⾝，这样就减少了加密运算的消耗时间。2.2.2 服务器回应（SeverHello）当服务器接收到客户端的请求时，需要根据客户端提供的信息来给出回应，回应包含以下内容：（1） 确认使⽤的加密通信协议版本，⽐如TLS 1.0版本。如果浏览器与服务器⽀持的版本不⼀致，服务器关闭加密通信。（2） ⼀个服务器⽣成的随机数，稍后⽤于⽣成"对话密钥"。（3） 确认使⽤的加密⽅法，⽐如RSA公钥加密。（4） 服务器证书。除去上⾯必要的信息，服务器还可以验证客户端的⾝份，还可以加⼊⼀项请求客户端的证书，这样的场景常见于⾦融⾏业，给⽤户发放USB密钥，俗称”⽹银“，⾥⾯就包含客户端的证书。这⾥⾯需要提到⼀个⽐较重要的拓展，application_layer_protocol_negotiation (ALPN)，因为当前的通信协议有很多，包括http1.x，http2，spdy，quic等，ALPN就⽤来确定通信时使⽤的协议，以下是ALPN的协商客户端在client hello时，向服务器发送客户带所⽀持的所有通信协议，如上图，此时客户端就⽀持http2和http1.1，当服务器收到clienthello后，解析到报⽂中这个字段，会检查⾃⼰服务器⽀持什么协议，按优先级由⾼到低匹配，匹配成功后在server hello中携带⽬标协议，当客户端收到这个字段时，在之后的通信中都将使⽤该协议进⾏通信。以上时Server hello的内容1：server hello回包使⽤的时TLS1.22：协商了之后所⽤的TLS版本，为TLS1.23：随机⽣成的数，⽤于⽣成消息密钥4：Session ID5：协商好未来加解密所使⽤的加解密套件7：协商好未来通信的应⽤层协议，为http22.2.3服务端发送证书等信息进⾏验证服务端在这个过程中发送了⾃⼰的证书，客户端验证证书的有效性，包括启⽤时间、过期时间、CA中⼼是否可信、证书链是否可信、证书是否被吊销、证书包含的域名是否是当前正在访问的域名，验证成功后，客户端通过包含在证书中的公钥，将计算出来的随机数⽤公钥进⾏加密，发送给服务端在本次请求中，还会完成⼀个数据的发送，server key change，这个内容是可选的，只有当加密算法是DH算法时才需要传输该参数接着是server hello done1：证书部分，当前的阶段是证书验证2：证书内容，⾥⾯包含了证书的所有相关信息，包含过期时间、CA中⼼、公钥等3：DH相关参数的传输阶段4：DH相关参数5：server hello done2.2.4客户端进⾏参数验证，通信前的最后⼀次对端验证客户端从证书中取出公钥，并⽣成随机数，然后⽤server的公钥进⾏加密，⽣成PreMaster。⽣成后，将加密结果发送到server，server⽤⾃⼰的私钥进⾏解密，获得第三个随机数。之后发送⼀条通知，客户端通知服务端之后的通信就使⽤之前协商的密钥进⾏加密。然后使⽤之前协商的密钥，将⾃⼰之前发送过的所有数据、⾃⼰收到的所有数据进⾏摘要，因为摘要所⽤到的密钥是之前协商的密钥，如果在server端对该消息进⾏解密失败，则证明密钥协商失败。这⾥还有⼀个⽐较重要的点，这是整个握⼿过程中第⼀个经过对称加密的报⽂，在解密过程中，如果解密失败，则证明密钥协商错误，如果解密后发现与⾃⼰⼿中的信息不符，也证明握⼿失败（为什么，因为此时摘要的内容是⾃⼰收到的和发送的信息，这些信息在对端⼿中也是拥有的，如果解密后信息不符合，则证明在之前的传输过程中数据被篡改了，也证明之前的握⼿过程失败了）。2.2.5 服务端进⾏参数验证服务端也是重复上⼀个过程，将⾃⼰收到的数据和发出的数据使⽤协商的密钥进⾏摘要，然后将摘要信息发送给客户端，⽤来证明协商密钥的正确性和传输数据的正确性，解密成功后证明密钥正确，数据完整证明没有被篡改⾃此，TLS的握⼿就结束了。总结和反思对于TLS的握⼿过程，笔者之前也不是⾮常懂，只知道每个阶段需要完成什么内容，通过抓包，按照抓包内容进⾏分析，明⽩了每个阶段所⽤到的算法，但是笔者对加密算法不是很精通，所以在DH等阶段⽆法理解椭圆圆锥的具体算法，后续会给出引⽤，读者有兴趣可以⾃⼰再研究下。本⽂引⽤SSL/TLS协议运⾏机制的概述：SSL / TLS ⼯作原理和详细握⼿过程：抓包解析：TLS1.2连接过程：SSL/TLS 链接的建⽴/握⼿：