简介

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
IETF后来在标准化SSL协议时，将其改为了TLS。很多人会混用SSL与TLS，但严格来说它们指代的协议版本不同（SSL3.0的升级版才是TLS1.0）。目前市面上所有的Https都是用的是TLS，而不是SSL。本文重在讲述TLS的概念和原理及其网络优化。

作用

TLS协议的目标是为信息传输提供三个基本的保证：加密、身份验证和数据完整性。这三种服务并不是必须的，可以根据具体的应用场景进行选择。
加密：混淆数据的机制。
身份验证：验证身份标识有效性的机制。
完整性：检测消息是否被篡改或伪造的机制。

SSL/TLS的应用

SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3协议等。

TLS协议的架构

TLS主要分为两层，底层的是TLS记录协议，主要负责使用对称密码对消息进行加密。
上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。

• 握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。
• 密码规格变更协议负责向通信对象传达变更密码方式的信号
• 警告协议负责在发生错误的时候将错误传达给对方
• 应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。

握手协议

TLS的握手阶段是发生在TCP握手之后。握手实际上是一种协商的过程，对协议所必需的一些参数进行协商。TLS握手过程分为四步，过程如下：

Client Hello

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的Master Secret。

Server Hello

上图中，从Server Hello到Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。
服务端在接收到客户端的Client Hello之后，服务端需要将自己的证书发送给客户端。这个证书是对于服务端的一种认证。例如，客户端收到了一个来自于称自己是www.alipay.com的数据，但是如何证明对方是合法的alipay支付宝呢？这就是证书的作用，支付宝的证书可以证明它是alipay，而不是财付通。证书是需要申请，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。另外，证书还有个有效期。
在服务端向客户端发送的证书中没有提供足够的信息的时候，还可以向客户端发送一个Server Key Exchange。
此外，对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出Cerficate Request消息，要求客户端发送证书对客户端的合法性进行验证。
跟客户端一样，服务端也需要产生一个随机数发送给客户端。客户端和服务端都需要使用这两个随机数来产生Master Secret。
最后服务端会发送一个Server Hello Done消息给客户端，表示Server Hello消息结束了。

Client Key Exchange

如果服务端需要对客户端进行验证，在客户端收到服务端的Server Hello消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。
在此之前的所有TLS握手信息都是明文传送的。在收到服务端的证书等信息之后，客户端会使用一些加密算法(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个Key叫PreMaster Secret，很多材料上也被称作PreMaster Key, 最终通过Master secret生成session secret， session secret就是用来对应用数据进行加解密的。PreMaster secret属于一个保密的Key，只要截获PreMaster secret，就可以通过之前明文传送的随机数，最终计算出session secret，所以PreMaster secret使用RSA非对称加密的方式，使用服务端传过来的公钥进行加密，然后传给服务端。
接着，客户端需要对服务端的证书进行检查，检查证书的完整性以及证书跟服务端域名是否吻合。
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件的状态，准备使用之前协商好的加密套件加密数据并传输了。
在ChangecipherSpec传输完毕之后，客户端会使用之前协商好的加密套件和session secret加密一段Finish的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

Server Finish

服务端在接收到客户端传过来的PreMaster加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成session secret，一切准备好之后，会给客户端发送一个ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和session secret加密数据了。之后，服务端也会使用session secret加密后一段Finish消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的session secret对数据进行加密传输了。

Secret Keys

上面的分析和讲解主要是为了突出握手的过程，所以PreMaster secret，Master secret，session secret都是一代而过，但是对于Https，SSL/TLS深入的理解和掌握，这些Secret Keys是非常重要的部分。所以，准备把这些Secret Keys抽出来单独分析和讲解。
我们先来看看这些Secret Keys的的生成过程以及作用流程图：

PreMaster secret

PreMaster secret是在客户端使用RSA或者Diffie-Hellman等加密算法生成的。它将用来跟服务端和客户端在Hello阶段产生的随机数结合在一起生成Master secret。在客户端使用服务单的公钥对PreMaster secret进行加密之后传送给服务端，服务端将使用私钥进行解密得到PreMaster secret。也就是说服务端和客户端都有一份相同的PreMaster secret和随机数。
PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

服务器名称指示

任意两个TCP端之间都可以建立加密的TLS隧道：客户端只需要知道对端的IP地址就可以建立连接，并执行TLS握手。但是，如果服务器需要部署多个独立的网站，每个与自己的TLS证书，但使用同一个IP地址 - 请问如何处理？为了解决上述问题，SNI（服务器名称指示）扩展被引入到TLS协议中，它允许客户端在握手开始指示他想要连接的主机名。服务器检查SNI主机名，选择适当的证书，并继续握手。
注：TLS + SNI工作流程和HTTP的Host头域宣告流程是相同的，客户端在头域中指示它要请求的Host：同一IP地址可能会部署许多不同domain，SNI和Host都是用来区分不同的Host或者Domain。

TLS会话恢复

完整的TLS握手需要额外延迟和计算，为所有需要安全通信的应用带来了严重的性能损耗。为了帮助减少一些性能损耗，TLS提供恢复机制，即多个连接之间共享相同的协商密钥数据。

会话标识符

“会话标识符”（RFC 5246）恢复机制在SSL 2.0中首次被引入，支持服务器端创建32字节的会话标识符，并将其作为“ServerHello”消息的一部分进行发送。在服务器内部，服务器保存一个会话ID和其对应的协商参数。对应地，客户端也同时存储会话ID信息，在后续的会话中，可以在“ClientHello”消息中携带session ID信息，告诉服务器客户端还记着session ID对应的密钥和加密算法等信息，并且可以重用这些信息。假设在客户端和服务器都能在它们各自的缓存中找到共享的会话ID参数，那么就可以缩减握手了。
借助会话标识符，我们能够减少一个完整的往返，以及用于协商的共享密钥的公钥加密算法开销。这让我们能快速的建立安全连接，而不损失安全性。然而，“会话标识符”机制的一个限制就是要求服务器为每个客户端创建和维护一个会话缓存。这会为服务器上带来几个问题，对于一些每天同时几万，甚至几百万的单独连接的服务器来说：由于缓存session ID所需要的内存消耗将非常大，同时还有session ID清除策略的问题。这对一些流量大的网站来说不是一个简单的任务，理想的情况下，使用一个共享的TLS会话缓存可以获得最佳性能。上述问题没有是不可能解决的，许多高流量的网站成功的使用了会话标识符。但是，对任何多服务主机的部署，会话标识符方案需要一些认真的思考和好的系统架构，以确保良好的的会话缓存。

会话记录单

由于在服务器访问量很大的情况下，缓存会话信息是一个很大的负担，为消除服务器需要维护每个客户端的会话状态缓存的要求，“Sesion Ticket”机制被引入--服务器端不再需要保存客户端的会话状态。如果客户端表明它支持Session Ticket，则在服务器完成TLS握手的最后一步中将包含一个“New Session Ticket”信息，这个信息包含一个加密通信所需要的信息，这些数据采用一个只有服务器知道的密钥进行加密。这个Session Ticket由客户端进行存储，并可以在随后的会话中添加到ClientHello消息的SessionTicket扩展中。因此，所有的会话信息只存储在客户端上，Session Ticket仍然是安全的，因为它是由只有服务器知道的密钥加密的。
会话标识符和会话记录单机制，通常分别被称为“会话缓存”和“无状态恢复”机制。无状态恢复的主要改进是消除服务器端的会话缓存，从而简化了部署，它要求客户在每一个新的会话开始时提供Session Ticket，直到Ticket过期。
注：在实际应用中，在一组负载平衡服务器中部署Session Ticket，也需要仔细考虑：所有的服务器都必须用相同的会话密钥，或者可能需要额外的机制，定期轮流在所有服务器上的共享密钥。

TLS记录协议

抓包

客户端发出请求（ClientHello)

客户端与服务端通过tcp三次握手建立tcp连接后，客户端首先向服务器发出建立加密通信的请求，发送ClientHello请求，从消息体结构看，tls/ssl是基于tcp连接之上，应用层之下的协议，封装的消息体内容如下:

(1) 此时握手协议(handshake protocol)的消息类型为:client hello
(2) 支持的TLS协议版本，比如TLS 1.0版。握手协议的版本为TLS 1.2
(3) 一个客户端生成的随机数，稍后用于生成"对话密钥"。
(4) 支持的加密套件，如Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
(5) 支持的压缩方法。
(6) 扩展属性如：服务器名称（例子中为baidu.com)，支持的签名算法等
2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

服务器响应（SeverHello）

从消息体中，可以看到服务器的响应包含以下内容：

(1) 确认使用的加密通信协议版本，这里确认使用tls1.2，而不是client hello中的tls1.0。响应握手协议消息 server hello。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
(2) 一个服务器生成的随机数，稍后用于生成"对话密钥"。
(3) 确认使用的加密套件,这里为rsa+aes128+sha256
(4) 压缩方法为空。
(5) 一些列扩展信息

服务端发送服务端电子证书（CA），密钥交换（server key exchange），及server hello done三个握手消息

客户端接收到server hello握手消息后，及时反馈ack消息。服务端接收客户端ack消息后，发送服务端电子证书，密钥交换，及server hello done三个握手消息

从封装内容看，包含两层ssl协议体信息，头一个为服务端证书，后面跟着公共密钥交换和hello done消息体，具体如下：

（1）详细的电子证书信息和CA认证机构信息
（2）密钥交换信息，包括DH算法计算出的pubkey公钥，电子签名的hash算法值
（3）server hello done消息体

客户端发送密钥交换信息（client key exchange）、编码改变协议消息(change cipher spec)

客户端发送ack消息给服务端，确认收到server hello done消息，然后发送客户端的密钥交换信息和修改密钥的协议消息

主要内容如下：

(1) 发送DH算法计算的pubkey，用于服务端计算生成解密私钥
(2) 发送编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 发送加密后的握手消息，一个随机数。该随机数用服务器公钥加密，防止被窃听
(4) 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。（可能在加密消息中，未确认）

客户端收到服务器所有响应消息后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥，即server key exchange消息中携带的pubkey值。然后，根据根据已经收到的三个随机数计算书加密密钥，对握手信息进行加密通信，然后向服务器发送上面抓包中三项信息内容。

服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。

（1）编码改变协议，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。