章节导航：
HTTPS加密协议详解(一)：HTTPS基础知识
HTTPS加密协议详解(二)：TLS/SSL工作原理
HTTPS加密协议详解(三)：PKI 体系
HTTPS加密协议详解(四)：TLS/SSL握手过程
HTTPS加密协议详解(五)：HTTPS性能与优化
本文关键词:TLS/SSL握手过程
本文链接：http://www.wosign.com/FAQ/faq2016-0309-04.htm
1、握手与密钥协商过程
基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程。
(1).client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;
客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
随机数 random_C，用于后续的密钥的生成;
扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
(a) server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
(b)server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
(c) server_hello_done，通知客户端 server_hello 信息发送结束;
(3).证书校验
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
证书链的可信性 trusted certificate path，方法如前文所述;
证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
有效期 expiry date，证书是否在有效时间范围;
域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
(a) client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
(b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
enc_key=Fuc(random_C, random_S, Pre-Master)
(c) change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
(d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
(a) 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
(b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
(c) change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
(d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
(6).握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
(7).加密通信
开始使用协商密钥与算法进行加密通信。
注意：
(a) 服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证;
(b) 根据使用的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似;
(c) sever key exchange 的作用是 server certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送;
(d) change cipher spec 实际可用于通知对端改版当前使用的加密通信方式，当前没有深入解析;
(e) alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。
2、会话缓存握手过程
为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。
session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个 session ID 机器相关信息，占用服务器资源较多;
session ticket 需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
二者对比，主要是保存协商信息的位置与方式不同，类似与 http 中的 session 与 cookie。
二者都存在的情况下，(nginx 实现)优先使用 session_ticket。
握手过程如下图：
注意：虽然握手过程有1.5个来回，但是最后客户端向服务器发送的第一条应用数据不需要等待服务器返回的信息，因此握手延时是1*RTT。
(1).会话标识 session ID
(a) 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中;
(b) 如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器;
(c) 服务器根据收到的 session ID 检索缓存记录，如果没有检索到货缓存过期，则按照正常的握手过程进行;
(d) 如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用类似，encrypted_handshake_message 是到当前的通信参数与 master_secret的hash 值;
(f) 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
(g) 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
(2).会话记录 session ticket
(a) 如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存;
(b) 如果客户端再次需要和该服务器建立连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，一起发送给服务器;
(c) 服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;
(d) 如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;
(f)如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;
(g) 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
3、重建连接
重建连接 renegotiation 即放弃正在使用的 TLS 连接，从新进行身份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前 windows 2000 & XP 与 SSL 2.0不支持。
(1).服务器重建连接
服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下：
(a) 客户端和服务器之间建立了有效 TLS 连接并通信;
(b) 客户端访问受保护的信息;
(c) 服务器端返回 hello_request 信息;
(d) 客户端收到 hello_request 信息之后发送 client_hello 信息，开始重新建立连接。
(2).客户端重建连接
客户端重建连接一般是为了更新通信密钥。
(a) 客户端和服务器之间建立了有效 TLS 连接并通信;
(b) 客户端需要更新密钥，主动发出 client_hello 信息;
(c) 服务器端收到 client_hello 信息之后无法立即识别出该信息非应用数据，因此会提交给下一步处理，处理完之后会返回通知该信息为要求重建连接;
(d) 在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器;
(e) 服务器识别出重建连接请求之后，发送 server_hello 信息至客户端;
(f) 客户端也同样无法立即判断出该信息非应用数据，同样提交给下一步处理，处理之后会返回通知该信息为要求重建连接;
(g) 客户端和服务器开始新的重建连接的过程。
4、密钥计算
上节提到了两个明文传输的随机数 random_C 和 random_S 与通过加密在服务器和客户端之间交换的 Pre-master，三个参数作为密钥协商的基础。本节讨论说明密钥协商的基本计算过程以及通信过程中的密钥使用。
(1).计算 Key
涉及参数 random client 和 random server, Pre-master, Master secret, key material, 计算密钥时，服务器和客户端都具有这些基本信息，交换方式在上节中有说明，计算流程如下：
(a) 客户端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master;
(b) Pre-master 结合 random client 和 random server 两个随机数通过 PseudoRandomFunction(PRF)计算得到 Master secret;
(c) Master secret 结合 random client 和 random server 两个随机数通过迭代计算得到 Key material;
以下为一些重要的记录，可以解决部分爱深入研究朋友的疑惑，copy的材料，分享给大家：
(a) PreMaster secret 前两个字节是 TLS 的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在 Client Hello 阶段，客户端会发送一份加密套件列表和当前支持的 SSL/TLS 的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的 PreMaster 版本号跟之前 Client Hello 阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。(copy)
(b) 不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于 RSA 密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre master secret 就有可能被猜出来，那么仅适用 pre master secret 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
(2).密钥使用
Key 经过12轮迭代计算会获取到12个 hash 值，分组成为6个元素，列表如下：
(a) mac key、encryption key 和 IV 是一组加密元素，分别被客户端和服务器使用，但是这两组元素都被两边同时获取;
(b) 客户端使用 client 组元素加密数据，服务器使用 client 元素解密;服务器使用 server 元素加密，client 使用 server 元素解密;
(c) 双向通信的不同方向使用的密钥不同，破解通信至少需要破解两次;
(d) encryption key 用于对称加密数据;
(e) IV 作为很多加密算法的初始化向量使用，具体可以研究对称加密算法;
(f) Mac key 用于数据的完整性校验;
（3）.数据加密通信过程
(a) 对应用层数据进行分片成合适的 block;
(b) 为分片数据编号，防止重放攻击;
(c) 使用协商的压缩算法压缩数据;
(d) 计算 MAC 值和压缩数据组成传输数据;
(e) 使用 client encryption key 加密数据，发送给服务器 server;
(f) server 收到数据之后使用 client encrytion key 解密，校验数据，解压缩数据，重新组装。
注：MAC值的计算包括两个 Hash 值：client Mac key 和 Hash (编号、包类型、长度、压缩数据)。
5、抓包分析
关于抓包不再详细分析，按照前面的分析，基本的情况都能够匹配，根据平常定位问题的过程，个人提些认为需要注意的地方：
(1).抓包 HTTP 通信，能够清晰的看到通信的头部和信息的明文，但是 HTTPS 是加密通信，无法看到 HTTP 协议的相关头部和数据的明文信息，
(2).抓包 HTTPS 通信主要包括三个过程：TCP 建立连接、TLS 握手、TLS 加密通信，主要分析 HTTPS 通信的握手建立和状态等信息。
(3).client_hello
根据 version 信息能够知道客户端支持的最高的协议版本号，如果是 SSL 3.0 或 TLS 1.0 等低版本协议，非常注意可能因为版本低引起一些握手失败的情况;
根据 extension 字段中的 server_name 字段判断是否支持SNI，存在则支持，否则不支持，对于定位握手失败或证书返回错误非常有用;
会话标识 session ID 是标准协议部分，如果没有建立过连接则对应值为空，不为空则说明之前建立过对应的连接并缓存;
会话记录 session ticke t是扩展协议部分，存在该字段说明协议支持 sesssion ticket，否则不支持，存在且值为空，说明之前未建立并缓存连接，存在且值不为空，说明有缓存连接。
(4).server_hello
根据 TLS version 字段能够推测出服务器支持的协议的最高版本，版本不同可能造成握手失败;
基于 cipher_suite 信息判断出服务器优先支持的加密协议;
(5).ceritficate
服务器配置并返回的证书链，根据证书信息并于服务器配置文件对比，判断请求与期望是否一致，如果不一致，是否返回的默认证书。
(6).alert
告警信息 alert 会说明建立连接失败的原因即告警类型，对于定位问题非常重要。
传输层安全性协定（英语：Transport Layer Security，缩写作 TLS），及其前身安全套接层（Secure Sockets Layer，缩写作 SSL）是一种安全协议，目的是为网际网路通信，提供安全及数据完整性保障。网景公司（Netscape）在1994年推出首版网页浏览器，网景领航员时，推出HTTPS协定，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布第一版TLS标准文件。随后又公布RFC 5246 （2008年8月）与 RFC 6176 （2011年3月）。在浏览器、电子邮件、即时通讯、VoIP、网路传真等应用程式中，广泛支持这个协定。主要的网站，如Google、Facebook等也以这个协定来建立安全连线，传送资料。目前已成为互联网上保密通信的工业标准。
SSL包含记录层（Record Layer）和传输层，记录层协议确定传输层数据的封装格式。传输层安全协议使用X.509认证，之后利用非对称加密演算来对通讯方做身份认证，之后交换对称金钥作为会谈金钥（Session key）。这个会谈金钥是用来将通讯两方交换的资料做加密，保证两个应用间通信的保密性和可靠性，使客户与服务器应用之间的通信不被攻击者窃听。
目录
1 概论
2 发展历史
2.1 安全网络编程
2.2 SSL 1.0、2.0和3.0
2.3 TLS 1.0
2.4 TLS 1.1
2.5 TLS 1.2
2.6 TLS 1.3
3 算法
3.1 密钥交换和密钥协商
3.2 加密密码
3.3 数据完整性
4 过程
4.1 TLS
5 参考文献
6 外部链接
7 参见
概论
TLS协定采用主从式架构模型，用于在两个应用程式间透过网路建立起安全的连线，防止在交换资料时受到窃听及篡改。
TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行建立加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。
TLS协议是可选的，必须配置客户端和服务器才能使用。主要有两种方式实现这一目标：一个是使用统一的TLS协议通讯埠（例如：用于HTTPS的端口443）；另一个是客户端请求服务器连接到TLS时使用特定的协议机制（例如：邮件、新闻协议和STARTTLS）。一旦客户端和服务器都同意使用TLS协议，他们通过使用一个握手过程协商出一个有状态的连接以传输数据[1]。通过握手，客户端和服务器协商各种参数用于建立安全连接：
当客户端连接到支持TLS协议的服务器要求建立安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
服务器从该列表中决定加密和散列函数，并通知客户端。
服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
客户端确认其颁发的证书的有效性。
为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
利用随机数，双方生成用于加密和解密的对称密钥。这就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
发展历史
定义协议年份SSL 1.0未知SSL 2.01995SSL 3.01996TLS 1.01999TLS 1.12006TLS 1.22008TLS 1.32018
安全网络编程
早期的研究工作，为方便改造原有网络应用程序，在1993年已经有了相似的Berkeley套接字安全传输层API方法[2]。
SSL 1.0、2.0和3.0
SSL（Secure Sockets Layer）是网景公司（Netscape）设计的主要用于Web的安全传输协议，这种协议在Web上获得了广泛的应用[3]。
基础算法由作为网景公司的首席科学家塔希尔·盖莫尔（Taher Elgamal）编写，所以他被人称为“SSL之父”。[4][5]
2014年10月，Google发布在SSL 3.0中发现设计缺陷，建议禁用此一协议。攻击者可以向TLS发送虚假错误提示，然后将安全连接强行降级到过时且不安全的SSL 3.0，然后就可以利用其中的设计漏洞窃取敏感信息。Google在自己公司相关产品中陆续禁止回溯相容，强制使用TLS协议。Mozilla也在11月25日发布的Firefox 34中彻底禁用了SSL 3.0。微软同样发出了安全通告[6]。
1.0版本从未公开过，因为存在严重的安全漏洞。
2.0版本在1995年2月发布，但因为存在数个严重的安全漏洞而被3.0版本替代[7]。
3.0版本在1996年发布，是由网景工程师Paul Kocher、Phil Karlton和Alan Freier完全重新设计的。较新版本的SSL/TLS基于SSL 3.0。SSL 3.0作为历史文献IETF通过 RFC 6101 发表。
TLS 1.0
IETF将SSL标准化，即 RFC 2246 ，并将其称为TLS（Transport Layer Security）。从技术上讲，TLS 1.0与SSL 3.0的差异非常微小。但正如RFC所述"the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0"（本协议和SSL 3.0之间的差异并不是显著，却足以排除TLS 1.0和SSL 3.0之间的互操作性）。TLS 1.0包括可以降级到SSL 3.0的实现，这削弱了连接的安全性[8]:1–2。
TLS 1.1
TLS 1.1在 RFC 4346 中定义，于2006年4月发表[9]，它是TLS 1.0的更新。在此版本中的差异包括：
添加对CBC攻击的保护：
隐式IV被替换成一个显式的IV。
更改分组密码模式中的填充错误。
支持IANA登记的参数。[8]:2
TLS 1.2
TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：
可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
增强服务器和客户端指定Hash和签名算法的能力。
扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
添加TLS扩展定义和AES密码组合[8]:2。所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用的SSL 2.0以避免安全问题。
TLS 1.3
参见：来回通讯延迟
TLS 1.3在 RFC 8446 中定义，于2018年8月发表。[10]它基于更早的TLS 1.2规范，与TLS 1.2的主要区别包括：
将密钥协商和认证算法从密码套件中分离出来。
移除脆弱和较少使用的命名椭圆曲线支持（参见椭圆曲线密码学）。
移除MD5和SHA-224密码杂凑函数的支持。
请求数字签名，即便使用之前的配置。
集成HKDF和半短暂DH提议。
替换使用PSK和票据的恢复。
支持1-RTT握手并初步支持0-RTT。
通过在(EC)DH密钥协议期间使用临时密钥来保证完善的前向安全性。
放弃许多不安全或过时特性的支持，包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH密钥交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息，以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
集成会话散列的使用。
弃用记录层版本号和冻结数以改进向后兼容性。
将一些安全相关的算法细节从附录移动到标准，并将ClientKeyShare降级到附录。
添加带有Poly1305消息验证码的ChaCha20流加密。
添加Ed25519和Ed448数字签名算法。
添加x25519和x448密钥交换协议。
网络安全服务（NSS）是由Mozilla开发并由其网络浏览器Firefox使用的加密库，自2017年2月起便默认启用TLS 1.3。[11]随后TLS 1.3被添加到2017年3月发布的Firefox 52.0中，但它由于某些用户的兼容性问题，默认情况下禁用。[12]直到Firefox 60.0才正式默认启用。[13]
Google Chrome曾在2017年短时间将TLS 1.3设为默认，然而由于类似Blue Coat Systems等不兼容组件而被取消。[14]
wolfSSL在2017年5月发布的3.11.1版本中启用了TLS 1.3。[15] 作为第一款支持TLS 1.3部署，wolfSSL 3.11.1 支持 TLS 1.3 Draft 18（ 现已支持到Draft 28），[16]同时官方也发布了一系列关于TLS 1.2和TLS 1.3性能差距的博客。[17]
算法
主条目：密码套件
密钥交换和密钥协商
在客户端和服务器开始交换TLS所保护的加密信息之前，他们必须安全地交换或协定加密密钥和加密数据时要使用的密码。用于密钥交换的方法包括：使用RSA算法生成公钥和私钥（在TLS 握手协议中被称为TLS_RSA），Diffie-Hellman（在TLS握手协议中被称为TLS_DH），临时Diffie-Hellman（在TLS握手协议中被称为TLS_DHE），椭圆曲线迪菲-赫尔曼（在TLS握手协议中被称为TLS_ECDH），临时椭圆曲线Diffie-Hellman（在TLS握手协议中被称为TLS_ECDHE），匿名Diffie-Hellman（在TLS握手协议中被称为TLS_DH_anon）[18]和预共享密钥（在TLS握手协议中被称为TLS_PSK）。[19]
TLS_DH_anon和TLS_ECDH_anon的密钥协商协议不能验证服务器或用户，因为易受中间人攻击因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。
在交换过程中使用的公钥/私钥加密密钥的长度和在交换协议过程中使用的公钥证书也各不相同，因而提供的强健性的安全。2013年7月，Google宣布向其用户提供的TLS加密将不再使用1024位公钥并切换到2048位，以提高安全性。[20]
身份验证和密钥交换协议列表算法SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2TLS 1.3 （草案）状态RSA 是是是是是否在TLS 1.2的RFCs内定义DH-RSA否是是是是否DHE-RSA（具有前向安全性）否是是是是是ECDH-RSA否否是是是否ECDHE-RSA（具有前向安全性）否否是是是是DH-DSS 否是是是是否DHE-DSS（具有前向安全性）否是是是是否[21] ECDH-ECDSA 否否是是是否ECDHE-ECDSA（具有前向安全性）否否是是是是SRP 否否是是是 SRP-DSS 否否是是是 SRP-RSA 否否是是是 Kerberos 否否是是是 DH-ANON（不安全）否否是是是 ECDH-ANON（不安全）否否是是是 GOST R 34.10-94 / 34.10-2001[22] 否否是是是 RFC草案
加密密码
参见：块密码的工作模式 已知公开并可行的攻击方法列表 密码协议版本状态类型算法长度（位）SSL 2.0SSL 3.0 [n 1][n 2][n 3][n 4] TLS 1.0 [n 1][n 3] TLS 1.1 [n 1] TLS 1.2 [n 1] 块密码 AES GCM[23][n 5] 256, 128不适用不适用不适用不适用安全在TLS 1.2的RFCs中定义AES CCM[24][n 5] 不适用不适用不适用不适用安全AES CBC[n 6] 不适用不适用依赖于后期加入的措施安全安全Camellia GCM[25][n 5] 256, 128不适用不适用不适用不适用安全Camellia CBC[26][n 6] 不适用不适用依赖于后期加入的措施安全安全ARIA GCM[27][n 5] 256, 128不适用不适用不适用不适用安全ARIA CBC[27][n 6] 不适用不适用依赖于后期加入的措施安全安全SEED CBC[28][n 6] 128不适用不适用依赖于后期加入的措施安全安全3DES EDE CBC[n 6] 112
[n 7]
不安全不安全强度不足 依赖于后期加入的措施强度不足强度不足GOST 28147-89 CNT[22] 256不适用不适用安全安全安全RFC草案IDEA CBC[n 6][n 8] 128不安全不安全依赖于后期加入的措施安全不适用在TLS 1.2中已被移除DES CBC[n 6][n 8] 56不安全不安全不安全不安全不适用 40[n 9] 不安全不安全不安全不适用不适用在TLS 1.1及更高版本中被禁用RC2 CBC[n 6] 40[n 9] 不安全不安全不安全不适用不适用 流密码 RC4[n 10] 128不安全不安全不安全不安全不安全在TLS 1.2的RFCs中定义40[n 9] 不安全不安全不安全不适用不适用在TLS 1.1以后的版本中被禁用ChaCha20-Poly1305[32][n 5] 256不适用不适用不适用不适用安全RFC草案ChaCha20[33] 256不适用不适用安全安全安全不加密无[n 11] -不适用不安全不安全不安全不安全在TLS 1.2的RFCs中定义
标注
RFC 5746必须执行，修补重协商漏洞。
如果库实现修复RFC 5746中列出的问题将违反SSL 3.0规范，与TLS不同的是IETF无法更改SSL协议的设计。幸运的是，最新的库实现已经修复并忽略违反规范的问题。
除非服务器和客户端双方都已经修复，BEAST能攻击所有使用SSL 3.0和TLS 1.0的CBC数据块。
除非服务器和客户端双方都已经修复，POODLE能攻击所有使用SSL 3.0的CBC数据块。
AEAD密码（例如GCM和CCM模式）只能用于TLS 1.2。
如果库实现处理边缘计时器不严密，CBC密码可以通过Lucky 13被攻击。
虽然3DES的密钥长度是168位，但有效的安全强度只有112位，[29]而现在最低的安全要求是128位[30]。
IDEA和DES在TLS 1.2中已被移除[31]。
40位强度的密码组合是为了减少密钥长度，以遵守包含某些功能强大的加密算法的加密软件在出口方面的规定，这些弱密码组合在TLS 1.1及更高版本中已被禁用。
RC4攻击削弱了RC4在SSL/TLS中的使用。
只认证，不加密
数据完整性算法列表算法SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2TLS 1.3
（草案）状态HMAC-
MD5
是是是是是否在TLS 1.2的RFCs中定义HMAC-
SHA1
否是是是是否HMAC-
SHA256/384
否否否否是否AEAD否否否否是是GOST 28147-89 IMIT
[22]
否否是是是
RFC草案
GOST R 34.11-94[22]
否否是是是
双向证书认证的SSL握手过程。
发送一个“ClientHello”消息，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。
然后收到一个“ServerHello”消息，内容包括：确认使用的加密通信协议版本，比如TLS 1.0版本（如果浏览器与服务器支持的版本不一致，服务器关闭加密通信），一个服务器生成的随机数（稍后用于生成“对话密钥”），确认使用的加密方法（如RSA公钥加密），服务器证书。
当双方知道了连接参数，客户端与服务器交换证书（依靠被选择的公钥系统）。这些证书通常基于X.509，不过已有草案支持以OpenPGP为基础的证书。
服务器请求客户端公钥。客户端有证书即双向身份认证，没证书时随机生成公钥。
客户端与服务器通过公钥保密协商共同的主私钥（双方随机协商），这通过精心谨慎设计的伪随机数功能实现。结果可能使用Diffie-Hellman交换，或简化的公钥加密，双方各自用私钥解密。所有其他关键数据的加密均使用这个“主密钥”。数据传输中记录层（Record layer）用于封装更高层的HTTP等协议。记录层数据可以被随意压缩、加密，与消息验证码压缩在一起。每个记录层包都有一个Content-Type段用以记录更上层用的协议。
对等协商支援的密钥算法
基于非对称密钥的信息传输加密和身份认证、基于PKI证书的身份认证
基于对称密钥的数据传输保密
公钥私钥非对称密钥保密系统：RSA、Diffie-Hellman、DSA;
对称密钥保密系统：RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia；
单向散列函数：MD5、SHA1以及SHA256。
所有的记录层数据均被编号，用于消息验证码校验。
"SSL/TLS in Detail". Microsoft TechNet. Updated July 31, 2003.
Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and Simon S. Lam, SNP: An interface for secure network programming Proceedings USENIX Summer Technical Conference, June 1994
THE SSL PROTOCOL. Netscape Corporation. 2007. （原始内容存档于14 June 1997）.
Messmer, Ellen. Father of SSL, Dr. Taher Elgamal, Finds Fast-Moving IT Projects in the Middle East. Network World. [30 May 2014]. （原始内容存档于2014年5月31日）.
Greene, Tim. Father of SSL says despite attacks, the security linchpin has lots of life left. Network World. [30 May 2014]. （原始内容存档于2014年5月31日）.
POODLE: SSLv3 vulnerability (CVE-2014-3566). [21 October 2014].
Rescorla 2001
Polk, Tim; McKay, Terry; Chokhani, Santosh. Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (PDF). National Institute of Standards and Technology: 67. April 2014 [2014-05-07].
Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346. April 2006.
Joseph A. Salowey; Sean Turner; Christopher A. Wood. TLS 1.3. IETF. 2018-08-10 [2018-08-11] （英语）.
NSS 3.29 release notes. Mozilla Developer Network. February 2017. （原始内容存档于2017-02-22）.
Enable TLS 1.3 by default. Bugzilla@Mozilla. 16 October 2016 [10 October 2017].
Firefox — Notes (60.0). Mozilla. [2018-05-10] （美国英语）.
ProxySG, ASG and WSS will interrupt SSL connections when clients using TLS 1.3 access sites also using TLS 1.3. BlueTouch Online. 16 May 2017 [11 September 2017]. （原始内容存档于12 September 2017）.
wolfSSL TLS 1.3 BETA Release Now Available. info@wolfssl.com. 11 May 2017 [11 May 2017].
TLS 1.3 PROTOCOL SUPPORT. info@wolfssl.com.
TLS 1.3 Draft 28 Support in wolfSSL. info@wolfssl.com. 14 June 2018 [14 June 2018].
RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. Internet Engineering Task Force. [9 September 2013].
P. Eronen, Ed. RFC 4279: Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). Internet Engineering Task Force. [9 September 2013].
Gothard, Peter. Google updates SSL certificates to 2048-bit encryption. Computing. Incisive Media. [9 September 2013].
Sean Turner. Consensus: remove DSA from TLS 1.3. September 17, 2015. （原始内容存档于October 3, 2015）.
draft-chudov-cryptopro-cptls-04 - GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)
RFC 5288
RFC 6655
RFC 6367
RFC 5932, RFC 6367
RFC 6209
RFC 4162
NIST Special Publication 800-57 Recommendation for Key Management—Part 1: General (Revised) (PDF). 2007-03-08 [2014-07-03]. （原始内容 (PDF)存档于2014-06-06）.
Qualys SSL Labs. SSL/TLS Deployment Best Practices (PDF). [19 November 2013]. （原始内容 (PDF)存档于2013年12月5日）.
RFC 5469
draft-agl-tls-chacha20poly1305-04 - ChaCha20 and Poly1305 based Cipher Suites for TLS4, draft-mavrogiannopoulos-chacha-tls-03 - The ChaCha Stream Cipher for Transport Layer Security
draft-mavrogiannopoulos-chacha-tls-03 - The ChaCha Stream Cipher for Transport Layer Security
维基共享资源
中相关的多媒体资源：
SSL/TLS/WTLS原理
SSL配置指南
SSL状态检查、格式转换、漏洞扫描工具
网际网路协议套组应用层
BGP
DHCP
DNS
FTP
HTTP
IMAP
LDAP
MGCP
NNTP
NTP
POP
ONC/RPC
RTP
RTSP
RIP
SIP
SMTP
SNMP
SSH
Telnet
TLS／SSL
XMPP
更多...
传输层
TCP
UDP
DCCP
SCTP
RSVP
更多...
网路层
IP
IPv4
IPv6
ICMP
ICMPv6
ECN
IGMP
OSPF
IPsec
更多...
连结层
ARP
NDP
Tunnels
L2TP
PPP
MAC
Ethernet
DSL
ISDN
FDDI
更多...
查
论
编
SSL/TLS协议运行机制的概述
互联网的通信安全，建立在SSL/TLS协议之上。
本文简要介绍SSL/TLS协议的运行机制。文章的重点是设计思想和运行过程，不涉及具体的实现细节。如果想了解这方面的内容，请参阅RFC文档。
一、作用
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。
（1） 窃听风险（eavesdropping）：第三方可以获知通信内容。 （2） 篡改风险（tampering）：第三方可以修改通信内容。 （3） 冒充风险（pretending）：第三方可以冒充他人身份参与通信。
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
（1） 所有信息都是加密传播，第三方无法窃听。 （2） 具有校验机制，一旦被篡改，通信双方会立刻发现。 （3） 配备身份证书，防止身份被冒充。
互联网是开放环境，通信双方都是未知身份，这为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的攻击，这使得SSL/TLS协议变得异常复杂。
二、历史
互联网加密通信协议的历史，几乎与互联网一样长。
1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。 1996年，SSL 3.0版问世，得到大规模应用。 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。
目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。
TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
三、基本的运行过程
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
但是，这里有两个问题。
（1）如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
（2）公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
（1） 客户端向服务器端索要并验证公钥。 （2） 双方协商生成"对话密钥"。 （3） 双方采用"对话密钥"进行加密通信。
上面过程的前两步，又称为"握手阶段"（handshake）。
四、握手阶段的详细过程
"握手阶段"涉及四次通信，我们一个个来看。需要注意的是，"握手阶段"的所有通信都是明文的。
4.1 客户端发出请求（ClientHello）
首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1） 支持的协议版本，比如TLS 1.0版。 （2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。 （3） 支持的加密方法，比如RSA公钥加密。 （4） 支持的压缩方法。
这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
4.2 服务器回应（SeverHello）
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。 （2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。 （3） 确认使用的加密方法，比如RSA公钥加密。 （4） 服务器证书。
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
4.3 客户端回应
客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。 （2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。 （3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数，来生成"会话密钥"，dog250解释得很好：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
4.4 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。 （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。
五、参考链接
MicroSoft TechNet, SSL/TLS in Detail
Jeff Moser, The First Few Milliseconds of an HTTPS Connection
Wikipedia, Transport Layer Security
StackExchange, How does SSL work?
（完）
