SSL（Secure Sockets Layer）安全套接层协议详解

---

SSL简介

SSL(Secure Sockets Layer 安全套接层)协议,及其继任者TLS（Transport Layer Security传输层安全）协议，是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密，用于保障网络数据传输安全，利用数据加密技术，确保数据在网络传输过程中不会被截取及窃听。SSL协议已成为全球化标准，所有主要的浏览器和WEB服务器程序都支持SSL协议，可通过安装SSL证书激活SSL协议。

SSL 证书就是遵守 SSL协议的服务器数字证书，由受信任的证书颁发机构（CA机构），验证服务器身份后颁发，部署在服务器上，具有网站身份验证和加密传输双重功能。

SSL历史发展

1.诞生

Netscape（网景通信公司）在1994年创建了SSL协议的原始范本，但是第一个SSL版本由于在创建时使用了弱加密的方式，因而被业界广泛质疑，所以从未公开发布。Netscape在1995年修订了规范，并发布了一个大幅改进的版本——SSL 2.0协议。SSL 2.0版本相较于之前的版本有很大的改进，但仍然存在不少漏洞。

2.更名

在1996年，由Netscape和Paul Kocher共同设计的版本SSL 3.0协议发布。SSL 3.0协议获得互联网广泛认可和支持，并将其重命名为传输层安全（TLS）协议。
TLS协议的第一个版本（RFC 2246）于1999年1月发布，但是该版本实际上就是SSL 3.0协议的适度改进版。

3.发展

2006年4月，IETF发布TLS 1.1版本（RFC4346），包含一些小的安全改进。2008年8月，TLS 1.2版本（RFC5246）发布，移除了老旧加密套件，增强了协议的安全性，TLS 1.2协议是目前主流的TLS协议版本。

2018年3月，TLS 1.3协议正式批准问世，成为了新一代TLS协议版本。TLS 1.3版本历经长达4年28次草案修改，是迄今为止改动最大的一次，既能提高互联网用户的访问速度，又能增强安全性，大大提升HTTPS连接的速度性能，用户的使用体验度得到明显的提升。

SSL协议结构

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：

SSL记录协议（SSL RecordProtocol）：是通过将数据流分割成一系列的片段并加以传输来工作的，其中的每个片段都单独进行保护和传输。在传输数据片段之前，需要计算数据的MAC以保证数据的完整性。数据片段和MAC一起被加密并与头信息组成记录，记录是实际传输的内容。

SSL握手协议（SSL HandshakeProtocol）：SSL握手协议指在SSL协议中，客户端和服务器首先通过握手过程来获得密钥，此后在记录集协议中使用这个密钥来加密客户端和服务器间的通信信息。握手过程首先采用非对称加密的方法来交换信息，使得服务器获得客户端提供的对称加密的密钥(pre_master_secret)，然后服务器和客户端使用这个pre_master_secret来产生会话密钥。

SSL修改密文协议（SSL Change Cipher Spec Protocol）：是使用SSL记录协议服务的SSL高层协议的3个特定协议之一，也是其中最简单的一个。协议由单个消息组成，该只包含一个值为1的单个字节。该消息的唯一作用就是使未决状态复制为当前状态，更新用于当前连接的密码组。为了保障SSL传输过程的安全性，双方应该每隔一段时间改变加密规范。

SSL警告协议：亦称SSL告警协议、SSL报警协议，是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常，就需要给对方发送一条警示消息通告。

SSL协议实际上是SSL握手协议、SSL修改密文协议、SSL警告协议和SSL记录协议组成的一个协议族。

SSL协议结构详解

SSL记录协议为SSL连接提供两种服务：机密性和报文完整性。

在SSL协议中，所有的传输数据都被封装在记录中。记录是由记录头和记录数据（长度不为0）组成的。所有的SSL通信都使用SSL记录层，记录协议封装上层的握手协议、报警协议、修改密文协议。SSL记录协议包括记录头和记录数据格式的规定。

SSL记录协议定义了要传输数据的格式，它位于一些可靠的传输协议之上（如TCP），用于各种更高层协议的封装。主要完成分组和组合、压缩和解压缩，以及消息认证和加密等。

SSL警告协议

SSL报警协议是用来为对等实体传递SSL的相关警告。如果在通信过程中某一方发现任何异常,就需要给对方发送一条警示消息通告。警示消息有两种：

1.Fatal错误,如传递数据过程中发现错误的MAC,双方就需要立即中断会话,同时消除自己缓冲区相应的会话记录。

2.Warning消息,这种情况,通信双方通常都只是记录日志,而对通信过程不造成任何影响。SSL握手协议可以使得服务器和客户能够相互鉴别对方,协商具体的加密算法和MAC算法以及保密密钥,用来保护在SSL记录中发送的数据。

SSL修改密文协议

为了保障SSL传输过程的安全性,客户端和服务器双方应该每隔一段时间改变加密规范。所以有了SSL修改密文协议。SSL修改密文协议是3个高层的特定协议之一,也是其中最简单的一个。在客服端和服务器完成握手协议之后,它需要向对方发送相关消息(该消息只包含一个值为1的单字节)，通知对方随后的数据将用刚刚协商的密码规范算法和关联的密钥处理，并负责协调本方模块按照协商的算法和密钥工作。

SSL握手协议

SSL握手协议被封装在记录协议中，该协议允许服务器与客户机在应用程序传输和接收数据之前互相认证、协商加密算法和密钥。在初次建立SSL连接时，服务器与客户机交换一系列消息。
信息包含以下作用：
1.认证服务器

• 允许客户机与服务器选择双方都支持的密码算法
• 可选择的服务器认证客户
• 使用公钥加密技术生成共享密钥

2.建立加密
SSL握手协议报文头包括三个字段：
类型（1字节）：该字段指明使用的SSL握手协议报文类型。
长度（3字节）：以字节为单位的报文长度。
内容（≥1字节）：使用的报文的有关参数。

SSL原理

在用SSL进行通信之前，首先要使用SSL的Handshake协议在通信两端握手，协商数据传输中要用到的相关安全参数（如加密算法、共享密钥、产生密钥所要的材料等），并对对端的身份进行验证。

SSL第一阶段

Handshake phase（握手阶段）
客户端首先发送ClientHello消息到服务端，服务端收到ClientHello消息后，再发送ServerHello消息回应客户端。

• 协商加密算法

• 认证服务器

• 建立用于加密和MAC（Message Authentication Code）用的密钥
  
  ClientHello
  握手第一步是客户端向服务端发送 Client Hello 消息，这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件（Support Ciphers）和 SSL Version 等信息。
  
  ClientHello中涉及到的消息具体如下：

• 客户端版本

  按优先级列出客户端支持的协议版本，首选客户端希望支持的最新协议版本。

• 客户端随机数Random

• 会话ID（Session id）

  如果客户端第一次连接到服务器，那么这个字段就会保持为空。上图中该字段为空，说明这是第一次连接到服务器。

  如果该字段不为空，说明以前是与服务器有连接的，在此期间，服务器将使用Session ID映射对称密钥，并将Session ID存储在客户端浏览器中，为映射设置一个时间限。如果浏览器将来连接到同一台服务器（在时间到期之前），它将发送Session ID，服务器将对映射的Session ID进行验证，并使用以前用过的对称密钥来恢复Session，这种情况下不需要完全握手。也叫作SSL会话恢复。后面会有介绍。

• 加密套件：

  客户端会给服务器发送自己已经知道的密码套件列表，这是由客户按优先级排列的，但完全由服务器来决定发送与否。TLS中使用的密码套件有一种标准格式。上面的报文中，客户端发送了74套加密套件。服务端会从中选出一种来作为双方共同的加密套件。

• 压缩方法：

  为了减少带宽，可以进行压缩。但从成功攻击TLS的事例中来看，其中使用压缩时的攻击可以捕获到用HTTP头发送的参数，这个攻击可以劫持Cookie，这个漏洞我们称为CRIME。从TLS 1.3开始，协议就禁用了TLS压缩。

• 扩展包：

  其他参数（如服务器名称，填充，支持的签名算法等）可以作为扩展名使用。
  这些是客户端问候的一部分，如果已收到客户端问候，接下来就是服务器的确认，服务器将发送服务器问候。

ServerHello
收到客户端问候之后服务器必须发送服务器问候信息，服务器会检查指定诸如TLS版本和算法的客户端问候的条件，如果服务器接受并支持所有条件，它将发送其证书以及其他详细信息，否则，服务器将发送握手失败消息。

如果接受，第二步是服务端向客户端发送 Server Hello 消息，这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件，这个套件决定了后续加密和生成摘要时具体使用哪些算法，另外还会生成一份随机数 Random2。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

ServerHello中涉及到的具体参数：

• 服务器版本Version：

  服务器会选择客户端支持的最新版本。

• 服务器随机数Random：

  服务器和客户端都会生成32字节的随机数。用来创建加密密钥。

• 加密套件：

  服务器会从客户端发送的加密套件列表中选出一个加密套件。

• 会话ID（Session ID）：

  服务器将约定的Session参数存储在TLS缓存中，并生成与其对应的Session id。它与Server Hello一起发送到客户端。客户端可以写入约定的参数到此Session id，并给定到期时间。客户端将在Client Hello中包含此id。如果客户端在此到期时间之前再次连接到服务器，则服务器可以检查与Session id对应的缓存参数，并重用它们而无需完全握手。这非常有用，因为服务器和客户端都可以节省大量的计算成本。

  在涉及亚马逊和谷歌等流量巨大的应用程序时，这种方法存在缺点。每天都有数百万人连接到服务器，服务器必须使用Session密钥保留所有Session参数的TLS缓存。这是一个巨大的开销。

  为了解决这个问题，在扩展包里加入了Session Tickets, 在这里，客户端可以在client hello中指定它是否支持Session Ticket。然后，服务器将创建一个新的会话票证(Session Ticket)，并使用只有服务器知道的经过私钥加密的Session参数。它将存储在客户端上，因此所有Session数据仅存储在客户端计算机上，但Ticket仍然是安全的，因为该密钥只有服务器知道。

  此数据可以作为名为Session Ticket的扩展包含在Client Hello中。

• 压缩算法：

  如果支持，服务器将同意客户端的首选压缩方法。

• 扩展包

这个阶段之后，客户端服务端知道了下列内容：

1.SSL版本
2.密钥交换、信息验证和加密算法
3.压缩方法
4.有关密钥生成的两个随机数。

SSL第二阶段

Secure data transfer phase（安全的数据传输阶段）
在已经建立的SSL连接里安全的传输数据。

服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：

1.证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
2.服务器密钥交换（可选）：这里视密钥交换算法而定
3.证书请求：服务端可能会要求客户自身进行验证。
4.服务器握手完成：第二阶段的结束，第三阶段开始的信号

Certificate消息
第一次建立必须要有证书
一般情况下，除了会话恢复时不需要发送该消息，在SSL握手的全流程中，都需要包含该消息。消息包含一个X.509证书，证书中包含公钥，发给客户端用来验证签名或在密钥交换的时候给消息加密。

这一步是服务端将自己的证书下发给客户端，让客户端验证自己的身份，客户端验证通过后取出证书中的公钥。

Server Key Exchange
根据之前在ClientHello消息中包含的CipherSuite信息，决定了密钥交换方式（例如RSA或者DH），因此在Server Key Exchange消息中便会包含完成密钥交换所需的一系列参数。

Certificate Request
可以是单向的身份认证，也可以双向认证
这一步是可选的，如果在对安全性要求高的常见可能用到。服务器用来验证客户端。服务器端发出Certificate Request消息，要求客户端发他自己的证书过来进行验证。该消息中包含服务器端支持的证书类型（RSA、DSA、ECDSA等）和服务器端所信任的所有证书发行机构的CA列表，客户端会用这些信息来筛选证书。
Server Hello Done
该消息表示服务器已经将所有信息发送完毕，接下来等待客户端的消息。

SSL第三阶段

客户端收到服务器发送的一系列消息并解析后，将本端相应的消息发送给服务器。

客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：

1.证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。
2.客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。
3.证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。

Certificate
如果在第二阶段服务器端要求发送客户端证书，客户端便会在该阶段将自己的证书发送过去。服务器端在之前发送的Certificate Request消息中包含了服务器端所支持的证书类型和CA列表，因此客户端会在自己的证书中选择满足这两个条件的第一个证书发送过去。若客户端没有证书，则发送一个no_certificate警告。
Client Key exchange
根据之前从服务器端收到的随机数，按照不同的密钥交换算法，算出一个pre-master，发送给服务器，服务器端收到pre-master算出main master。而客户端当然也能自己通过pre-master算出main master。如此以来双方就算出了对称密钥。

如果是RSA算法，会生成一个48字节的随机数，然后用server的公钥加密后再放入报文中。如果是DH算法，这是发送的就是客户端的DH参数，之后服务器和客户端根据DH算法，各自计算出相同的pre-master secret.

本消息在给服务器发送的过程中，使用了服务器的公钥加密。服务器用自己的私钥解密后才能得到pre-master key.（向服务器证明自己的确持有客户端证书私钥。）
Certificate verify
只有在客户端发送了自己证书到服务器端，这个消息才需要发送。其中包含一个签名，对从第一条消息以来的所有握手消息的HMAC值（用master_secret）进行签名。

SSL第四阶段

完成握手协议，建立SSL连接。

客户机启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。

建立起一个安全的连接，客户端发送一个Change Cipher Spec消息，并且把协商得到的CipherSuite拷贝到当前连接的状态之中。然后，客户端用新的算法、密钥参数发送一个Finished消息，这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值，对客户端整个握手过程的消息进行校验。服务器同样发送Change Cipher Spec消息和Finished消息。握手过程完成，客户端和服务器可以交换应用层数据进行通信。

ChangeCipherSpec
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送（ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了）。

Clinet Finished
客户端握手结束通知, 表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验（使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。）
Server Finished
服务端握手结束通知。

1.使用私钥解密加密的Pre-master数据，基于之前(Client Hello 和 Server Hello)交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
2.计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
3.发送一个 ChangeCipherSpec（告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了）
4.服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。

会话恢复

会话恢复是指只要客户端和服务器已经通信过一次，它们就可以通过会话恢复的方式来跳过整个握手阶段而直接进行数据传输。SSL采用会话恢复的方式来减少SSL握手过程中造成的巨大开销。此功能从之前的13步减少到6步，大大减少了开销。

两种会话机制

• 会话标识 session ID
  由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;
• 会话记录 session ticket
  需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通

信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
二者对比，主要是保存协商信息的位置与方式不同，类似与 http 中的 session 与 cookie。二者都存在的情况下，(nginx 实现)优先使用 session_ticket。

恢复过程
如果服务器和客户端之间曾经建立过连接，服务器会在握手成功后返回一个session ID，并保存对应的参数在服务器中。如果客户端和服务器需要再次连接，则需要在Client hello消息中携带记录的信息，返回给服务器。服务器根据收的到的Session ID检索缓存记录，如果有缓存，则返回一个Change Cipher Spec消息和Finished消息，如果没有缓存则正常进行握手。如果客户端能够验证通过服务器加密数据，则同样回复一个Change Cipher Spec消息和Finished消息。服务器验证通过则握手建立成功，开始进行正常的加密数据通信。

---

参考

【1】SSL协议详解——薄荷加冰心有多冷：http://t.csdn.cn/cxsTz
【2】SSL协议原理详解——曹世宏的博客：http://t.csdn.cn/OTNPk
【3】ssl——360百科：https://baike.so.com/doc/1076182-1138848.html