SSL握手的目的

第一，客户端与服务器需要就一组用于保护数据的算法达成一致。

第二，它们需要确立一组由那些算法所使用的加密密钥。

第三，握手还可以选择对客户端进行认证。

SSL 握手概述

（1）客户端将它所支持的算法列表连同一个密钥产生过程用作输入的随机数发送给服务器。

（2）服务器根据从列表的内容中选择一种加密算法，并将其连同一份包含服务器公用密钥的证书发回给客户端。该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个作为密钥产生过程部分输入的随机数。

（3）客户端对服务器的证书进行验证，并抽取服务器的公用密钥。然后，再产生一个称做pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密。最后，客户端将加密后的信息发送给服务器。

（4）客户端与服务器端根据pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和MAC 密钥。

（5）客户端将所有握手消息的MAC 值发送给服务器。

（6）服务器将所有握手消息的MAC 值发送给客户端。

那么，该过程达到了怎样的效果呢？

还记得我们的两个目标是什么吗？

第一个目标，就一组算法达成一致。确立一组加密密钥。第一和第二步实现了第一个目标。客户端告诉服务器它所支持的算法，而服务器选择其中的一种算法。当客户端收到了服务器在第二步所发的消息时，它也会知道这种算法，所以双方现在就都知道要使用什么算法了。

第二个目标，确立一组加密密钥是通过第二和第三步来实现的。在第2 步服务器向客户端提供其证书，这样就可以允许客户端给服务器传送密码。经过第3 步后，客户端与服务器端就都知道了pre_master_secret。客户端知道pre_master_secret 是因为这是它产生的，而服务器则是通过解密而得到pre_master_secret 的。注意，第3步是握手过程中的关键一步。所有要被保护的数据都依赖于pre_master_secret的安全。

原理非常简单：客户端使用服务器的公用密钥（从证书中抽取的）来加密共享密钥，而服务器使用其私用密钥对共享密钥进行解密。握手的剩余步骤主要用于确保这种交换过程的安全进行。然后在第4步，客户端与服务器分别使用相同的密钥导出函数（key derivationfunction，KDF）来产生master_secret，最后再次通过KDF 使用master_secret来产生加密密钥。

第 5 与第6 步用以防止握手本身遭受篡改。设想一个攻击者想要控制客户端与服务器所使用的算法。客户端提供多种算法的情况相当常见，某些强度弱而某些强度强，以便能够与仅支持弱强度算法的服务器进行通信。攻击者可以删除客户端在第1步所提供的所有高强度算法，于是就迫使服务器选择一种弱强度的算法。第5步与第6 步的MAC交换就能阻止这种攻击，因为客户端的MAC 是根据原始消息计算得出的，而服务器的MAC是根据攻击者修改过的消息计算得出的，这样经过检查就会发现不匹配。由于客户端与服务器所提供的随机数为密钥产生过程的输入，所以握手不会受到重放攻击的影响。这些消息是首个在新的加密算法与密钥下加密的消息。

因此，在此过程结束时，客户端与服务器已就使用的加密算法达成一致，并拥有了一组与那些算法一起使用的密钥。更重要的是，它们可以确信攻击者没有干扰握手过程，所以磋商过程反映了双方的真实意图。

握手消息

SSL 握手消息

第 1 步对应一条单一的握手消息，ClientHello。

第 2 步对应一系列SSL 握手消息，服务器发送的第一条件消息为ServerHello，其中包含了它所选择的算法，接着再在Certificate 消息中发送其证书。最后，服务器发送ServerHelloDone 消息以表示这一握手阶段的完成。需要ServerHelloDone 的原因是一些更为复杂的握手变种还要在Certificate 之后发送其他一些消息。当客户端接收到ServerHelloDone消息时，它就知道不会再有其他类似的消息过来了，于是就可以继续它这一方的握手。

第3步对应ClientKeyExchange 消息。

第5与第6 步对应Finished 消息。该消息是第一条使用刚刚磋商过的算法加以保护的消息。为了防止握手过程遭到篡改，该消息的内容是前一阶段所有握手消息的MAC值。然而，由于Finished 消息是以磋商好的算法加以保护的，所以也要与新磋商的MAC密钥一起计算消息本身的MAC 值。

对于想深入了解SSL协议的朋友，我向大家推荐《SSL与TLS.pdf》。

下载地址：

《SSL与TLS.pdf》