使用wireshark分析TLSv2（详细）

 

握手阶段如上图所示，可分为5步（使用Diffie – Hellman算法）：

第一步，浏览器给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。

第二步，服务器确认双方使用的加密方法，使用的tls版本号和一个随机数。

第三部，并给出数字证书、以及一个服务器运行Diffie-Hellman算法生成的参数，比如pubkey。

第四部，浏览器获取服务器发来的pubkey，计算出另一个pubkey，发给服务器。

第五部，服务器发给浏览器一个session ticket。

下面，我们使用wireshark抓包验证上面的握手过程。

 

在浏览器中访问https://baidu.com, 使用ip.addr==119.75.217.109&& ssl来过滤TLS包。结果如下图所示。

图一

 

我的Chrome浏览器一开始就连续给服务器发送三个相同的“Client Hello”包，这三个包除了源端口和随机数不一样外，其他的部分都相同。（图三四五所示）为什么？后面我们会看到，最总这个connection只用了第一个“ClientHello”所建立的连接，也就是端口号为4188。所以，之所以这样做，很可能是为了避免超时重传从而影响用户体验。如下图所示：

图二

 

图三

 

图四

 

图五

 

浏览器发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。

 

2.Server Hello：服务器将其SSL版本号、加密设置参数以及其它一些必要信息发送给客户端，一个服务器生成的随机数（稍后用于生成“对话密钥”），确认使用的加密方法（如RSA公钥加密），如下图所示：

 

 

 

 

3.Certificate：服务器发一个证书给客户端，该证书用于向客户端确认服务器的身份。如果配置服务器的SSL需要验证服务器的身份，会发送该消息（多数电子商务应用都需要服务器端身份验证。服务器如果需要验证客户端的身份，那么服务器会发一个“Certificate Request”给浏览器，而在很多实现中，服务器一般不需要验证客户端的身份）。在这个Certificate包中，还告诉我们服务器和浏览器是通过Diffie-Hellman算法来生成最终的密钥（也就是Sessionkey），这个算法的具体介绍可以参考https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B。其中下图所示的pubkey是Diffie-Hellman算法中的一个参数，这个参数需要通过网络传给浏览器，即使它被截取也没有影响安全性。

 

 

浏览器收到服务器发来的Certificate包来之后，运行Diffie-Hellman算法生成一个pubkey，然后发送给服务器。通过这一步和上面Certificate两个步骤，服务器和浏览器分别交换了pubkey，这样他们就可以分别生成了一个一样的sessionkey（具体的实现过程可以参考Diffie-Hellman算法的实现），如果你还不是很理解这个算法，那么这里你只需要知道服务器和浏览器向对方发送了pubkey之后，双方就可以计算出相同的密钥了，并且这个过程没有安全问题。

 

完成上面的步骤，可以说TLS的握手阶段已经完成了，但是，服务器还会发送一个Session Ticket给浏览器。如下图所示，这个sessionticket包含了这个ticket的生命周期是两个小时（7200s）、它的id等等信息。这个sessionticket包有什么做用呢？握手阶段用来建立TLS连接。如果出于某种原因，对话中断，就需要重新握手。客户端只需发送一个服务器在上一次对话中发送过来的sessionticket。这个sessionticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到sessionticket以后，解密后就不必重新生成对话密钥了。就可以继续使用上一次的连接了。

 

 

通过上面的步骤，服务器和浏览器建立了安全的连接，下面便开始传数据了。如下图所示。我们可以看到，它使用的是http协议，数据被加密了。前面我们也提到，一开始浏览器直接发送了三个“ClientHello”包给服务器，而最终只使用了第一个成功建立起来的TLS（端口号为4188）传输数据。