SSL/TLS 早已不是陌生的词汇，然而其原理及细则却不是太容易记住。本文将试图通过一些简单图示呈现其流程原理，希望读者有所收获。

一、相关版本

SSL全称为 Socket Security Layer，TLS全称为Transport Layer Security，这两者没有本质的区别，都是做的传输层之上的加密(介于传输层及应用层之间)。TLS是后续SSL版本分支的名称，花费长时间去争论两者的优劣没有意义。目前TLS最新版本为 TLS1.2(也称为SSL3.3)

二、SSL/TLS 解决的问题

信息被窃听(wiretap)，第三方随时随地获得通讯内容；

SSL/TLS 实现了传输信息的加密。

数据被篡改(tampering)，第三方可修改传输中的数据；

SSL/TLS 实现了数据签名及校验。

身份被冒充(pretending)，第三方可冒充通讯者身份传输数据；

SSL/TLS 采用了CA数字证书认证机制。

三、握手阶段

简单点说，SSL/TLS对于传输层的加密是通过动态密钥对数据进行加密实现的，而动态密钥则通过握手流程协商制定；为了保证动态密钥的安全性，其中免不了使用公钥加密算法(非对称)、数字证书签名等技术手段。

一个SSL/TLS 握手过程需要协商的信息包括：

1 协议的版本号；

2 加密算法，包括非对称加密算法、动态密钥算法；

3 数字证书，传输双方通过交换证书及签名校验对彼此进行鉴权；

4 动态密钥，传输数据过程使用该密钥进行对称加解密，该密钥通过非对称密钥进行加密传输。

四、流程解析

一个典型的SSL/TLS 握手流程包括双向认证，如下所示：

1. 客户端发出一个 client hello 消息，携带的信息包括：

所支持的SSL/TLS 版本列表；支持的与加密算法；所支持的数据压缩方法；随机数A;

2. 服务端响应一个 server hello 消息，携带的信息包括：

协商采用的SSL/TLS 版本号；会话ID；随机数B；服务端数字证书 serverCA；

由于双向认证需求，服务端需要对客户端进行认证，会同时发送一个 client certificate request，表示请求客户端的证书；

3. 客户端校验服务端的数字证书；校验通过之后发送随机数C，该随机数称为pre-master-key，使用数字证书中的公钥加密后发出；

由于服务端发起了 client certificate request，客户端使用私钥加密一个随机数 clientRandom随客户端的证书 clientCA一并发出；

4. 服务端校验客户端的证书，并成功将客户端加密的随机数clientRandom 解密；

根据 随机数A/随机数B/随机数C(pre-master-key) 产生动态密钥 master-key，加密一个finish 消息发至客户端；

5. 客户端根据 同样的随机数和算法 生成master-key，加密一个finish 消息发送至服务端；

6. 服务端和客户端分别解密成功，至此握手完成，之后的数据包均采用master-key进行加密传输。

五、要点解析

双向认证和单向认证

双向认证更好的解决了身份冒充问题，服务端提供证书的同时要求对客户端身份进行认证；然而在一些常见的应用场景下往往只有单向认证，如采用https网站只需要求客户端(浏览器)对服务端的证书进行认证。

在单向认证场景下，握手阶段2服务端不会发出 client certificate request，之后服务端也不需要校验客户端证书；

在双向认证场景下，客户端如果无法提供证书，会发出 no digital certificate alert 的警告信息，此时可能导致握手失败(根据服务端策略而定)；

随机数的使用

由于数字证书是静态的，因此要求使用随机因素来保证协商密钥的随机性；对于RSA 算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

之所以采用 pre-master-key 机制是因为SSL协议不信任每个主机都能产生完全随机的随机数，如果 pre-master-key 不随机，那么被猜出来的风险就很大，于是仅仅使用 pre-master-secret作为密钥不合适，需要引入新的随机因素，也就是同时结合hello消息中的双向随机数。

会话密钥重用

SSL/TLS握手过程比较繁琐，同时非对称加解密性能比对称密钥要差得多；如果每次重建连接时都需要进行一次握手会产生较大开销，因此有必要实现会话的重用以提高性能。

常用的方式包括：

SessionID(RFC 5246)，客户端和服务端同时维护一个会话ID和会话数据状态；重建连接时双方根据sessionID找到之前的会话密钥实现重用；

SessionTicket(RFC 5077)，由服务端根据会话状态生成一个加密的ticket，并将key也发给客户端保证两端都可以对其进行解密。该机制相较sessionID的方式更加轻量级，服务端不需要存储会话状态数据，可减轻一定压力。

证书的校验

1. 检查数字签名；

数字签名通过数字摘要算法生成并通过私钥加密传输，对端公钥解密；

2. CA链授权检查；

3. 证书过期及激活时间检查；

数字摘要的计算图示

关于Server Name Indication

在普通 SSL/TLS握手的过程中，客户端发送的信息之中不包括服务器的域名；因此理论上服务器只能包含一个域名，否则会分不清应该向客户端提供哪一个域名的数字证书。在后续TLS的版本中实现了SNI(Server Name Indication) 扩展，用于支持一台服务器主机需服务多个域名的场景。

由客户端请求时发送指定的域名，服务器据此选择相应证书完成握手。

六、参考文档

阮一峰_SSL/TLS协议运行机制的概述

An overview of the SSL or TLS handshake