1、SSL概述 

安全套接层（Secure Socket Layer，SSL ）是一种在两台机器之间提供安全通道的协议。它具有保护传输数据以及识别通信机器的功能。安全通道是透明的，意思就是说它对传输的数据不加变更。客户与服务器之间的数据是经过加密的，一端写入的数据完全是另一端读取的内容。透明性使得几乎所有基于TCP 的协议稍加改动就可以在SSL 上运行，非常方便。

Netscape公司在推出第一个Web浏览器的同时，提出了SSL协议标准,目前已有3.0版本。SSL采用公开密钥技术。其目标是保证两个应用间通信的保密性和可靠性,可在服务器端和用户端同时实现支持。目前，利用公开密钥技术的SSL协议，已成为Internet上保密通讯的工业标准。安全套接层协议能使用户/服务器应用之间的通信不被攻击者窃听，并且始终对服务器进行认证，还可选择对用户进行认证。SSL协议要求建立在可靠的传输层协议(TCP)之上。SSL协议的优势在于它是与应用层协议独立无关的，高层的应用层协议(例如：HTTP，FTP，TELNET等)能透明地建立于SSL协议之上。SSL协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商及服务器认证工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

2、SSL的分层结构

SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：

图1 SSL协议分层

（1）上层为SSL握手协议（SSL handshake protocol）、SSL密码变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）；

SSL握手协议：是SSL协议非常重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。

SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。

SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。

（2）底层为SSL记录协议（SSL record protocol）。

SSL记录协议：主要负责对上层的数据（SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文）进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。

3、SSL握手过程

SSL 握手有三个目的。第一，客户端与服务器需要就一组用于保护数据的算法达成一致。第二，它们需要确立一组由那些算法所使用的加密密钥。第三，握手还可以选择对客户端进行认证。整个过程工作如下：

图2 SSL握手概述

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

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

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

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

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

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

在此过程结束时，客户端与服务器已就使用的加密算法达成一致，并拥有了一组与那些算法一起使用的密钥。

3.1 只验证服务器的SSL握手过程

只验证服务器的SSL是最常见的情况，如图3所示，只需要验证SSL服务器身份，不需要验证SSL客户端身份时，SSL的握手过程为：

（1）SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。

（2）SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。

（3）SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。

（4）SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。

（5）SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的pre_master_secret，并通过Client Key Exchange消息发送给SSL服务器。

（6）SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

（7）SSL客户端计算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

（8）同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

（9）SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到pre_master_secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

图3 只验证服务器的SSL握手过程

实际上，SSL客户端发送给SSL服务器的密钥不能直接用来加密数据或计算MAC值，该密钥是用来计算对称密钥和MAC密钥的信息，称为pre_master_secret。SSL客户端和SSL服务器利用pre_master_secret计算出相同的主密钥（master_secret），再利用master_secret生成用于对称密钥算法、MAC算法等的密钥。pre_master_secret是计算对称密钥、MAC算法密钥的关键。

3.2 验证服务器和客户端的SSL握手过程

SSL客户端的身份验证是可选的，由SSL服务器决定是否验证SSL客户端的身份。如图4中蓝色部分标识的内容所示，如果SSL服务器验证SSL客户端身份，则SSL服务器和SSL客户端除了交互上一节“只验证服务器的SSL握手过程”中的消息协商密钥和加密套件外，还需要进行以下操作：

(1) SSL服务器发送Certificate Request消息，请求SSL客户端将其证书发送给SSL服务器。

(2) SSL客户端通过Certificate消息将携带自己公钥的证书发送给SSL服务器。SSL服务器验证该证书的合法性。

(3)SSL客户端计算已交互的握手消息、主密钥的Hash值，利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSL服务器。

(4)SSL服务器计算已交互的握手消息、主密钥的Hash值，利用SSL客户端证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。如果二者相同，则SSL客户端身份验证成功。

图4 验证服务器和客户端的SSL握手过程

SSL对客户端进行加密认证的机制，这在服务器想要限制只有某些授权客户端才能存取的服务时非常有用，它可以使用客户端认证来做到这一点。这里的思想就是客户端使用其私用密钥对某些内容进行签名，这样就证明它拥有与数字证书对应的私用密钥。客户端认证是通过服务器给客户端发送一条CertificateRequest 消息来进行初始化的。而客户端通过发送一条 Certificate消息（与服务器用来传送其证书的消息一样）和一条CertificateVerify 消息予以应答。CertificateVerify 消息是一个使用与其传输的证书所关联的私用密钥来签名的字符串。户端认证总是由服务器进行初始化，不存在由客户端单方提出认证的机制。

4、SSL单向认证的简单实例

注意这里约定一下，{} 表示RSA加密后的内容，[ | ]表示用什么密钥和算法进行加密，后面的示例中都用这种表示方式，例如{你好，我是服务器}[私钥|RSA]  就表示用私钥对“你好，我是服务器”进行加密后的结果。

step1： “客户”向服务端发送一个通信请求

“客户”->“服务器”：你好

step2： “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息，私钥由“服务器”持有

“服务器”->“客户”：你好，我是服务器，这里是我的数字证书

step3： “客户”收到“服务器”的证书后，它会去验证这个数字证书到底是不是“服务器”的，数字证书有没有什么问题，数字证书如果检查没有问题，就说明数字证书中的公钥确实是“服务器”的。检查数字证书后，“客户”会发送一个随机的字符串给“服务器”用私钥去加密，服务器把加密的结果返回给“客户”，“客户”用公钥解密这个返回结果，如果解密结果与之前生成的随机字符串一致，那说明对方确实是私钥的持有者，或者说对方确实是“服务器”。

“客户”->“服务器”：向我证明你就是服务器，这是一个随机字符串

“服务器”->“客户”：{一个随机字符串}[私钥|RSA]

step4： 验证“服务器”的身份后，“客户”生成一个对称加密算法和密钥，用于后面的通信的加密和解密。这个对称加密算法和密钥，“客户”会用公钥加密后发送给“服务器”，别人截获了也没用，因为只有“服务器”手中有可以解密的私钥。这样，后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。

“服务器”->“客户”：{OK，已经收到你发来的对称加密算法和密钥！有什么可以帮到你的？}[密钥|对称加密算法]

“客户”->“服务器”：{我的帐号是aaa，密码是123，把我的余额的信息发给我看看}[密钥|对称加密算法]

“服务器”->“客户”：{你好，你的余额是100元}[密钥|对称加密算法]

…… //继续其它的通信

OPEN SSL提供了一套API用于实现上述认证过程，对于只对服务器进行认证的SSL握手，相对简单，客户端无需安装证书。对于需要对服务器和客户端都进行认证的SSL握手来说（相当于多了一个向服务器证明客户端是合法客户端的过程），客户端需要一个客户端证书和私钥，用于向服务器证明合法身份。

对于单向认证的SSL握手的服务器，服务器端有一个证书（里面有公钥等信息）、私钥；双向认证的SSL，服务器、客户端都有一个证书、私钥，证书由CA(Certificate Authority数字证书认证中心)提供。如果应用场景要求对客户来源做验证可以实现成双向认证，选择是单向认证还是双向认证，可在服务器端配置。