HTTPS原理探讨（二）

TLS/SSL握手过程

握手与密钥协商过程

基于RSA握手和密钥交换的客户端验证服务器为示例详解握手过程。

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 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

---

会话缓存握手过程

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗(具体分析在后文)，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) 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

---

重建连接

重建连接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) 客户端和服务器开始新的重建连接的过程。

---

密钥计算

上节提到了两个明文传输的随机数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用于数据的完整性校验；

---

数据加密通信过程

(a) 对应用层数据进行分片成合适的block;
(b) 为分片数据编号，防止重放攻击；
(c) 使用协商的压缩算法压缩数据；
(d) 计算MAC值和压缩数据组成传输数据；
(e) 使用client encryption key加密数据，发送给服务器server；
(f) server收到数据之后使用client encrytion key解密，校验数据，解压缩数据，重新组装。
注：MAC值的计算包括两个Hash值：client Mac key和Hash(编号、包类型、长度、压缩数据)。

---

抓包分析

关于抓包不再详细分析，按照前面的分析，基本的情况都能够匹配，根据平常定位问题的过程，个人提些认为需要注意的地方：
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 ticket是扩展协议部分，存在该字段说明协议支持sesssion ticket，否则不支持，存在且值为空，说明之前未建立并缓存连接，存在且值不为空，说明有缓存连接。
4.server_hello
根据TLS version字段能够推测出服务器支持的协议的最高版本，版本不同可能造成握手失败；
基于cipher_suite信息判断出服务器优先支持的加密协议；
5.ceritficate
服务器配置并返回的证书链，根据证书信息并于服务器配置文件对比，判断请求与期望是否一致，如果不一致，是否返回的默认证书。
6.alert
告警信息alert会说明建立连接失败的原因即告警类型，对于定位问题非常重要。

---

HTTPS性能与优化

HTTPS性能损耗

前文讨论了HTTPS原理与优势：身份验证、信息加密与完整性校验等，且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价，HTTPS协议的性能损耗主要体现如下：
1.增加延时
分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2RTT，利用会话缓存从而复用连接，延时也至少1RTT。
2.消耗较多的CPU资源
除数据传输之外，HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据)；压测TS8机型的单核CPU：对称加密算法AES-CBC-256吞吐量600Mbps，非对称RSA私钥解密200次/s。不考虑其它软件层面的开销，10G网卡为对称加密需要消耗CPU约17核，24核CPU最多接入HTTPS连接4800；
静态节点当前10G网卡的TS8机型的HTTP单机接入能力约为10w/s，如果将所有的HTTP连接变为HTTPS连接，则明显RSA的解密最先成为瓶颈。因此，RSA的解密能力是当前困扰HTTPS接入的主要难题。

---

HTTPS接入优化

1.CDN接入
HTTPS增加的延时主要是传输延时RTT，RTT的特点是节点越近延时越小，CDN天然离用户最近，因此选择使用CDN作为HTTPS接入的入口，将能够极大减少接入延时。CDN节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少HTTPS带来的延时。
2.会话缓存
虽然前文提到HTTPS即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化；同时，基于会话缓存建立的HTTPS连接不需要服务器使用RSA私钥解密获取Pre-master信息，可以省去CPU的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。
3.硬件加速
为接入服务器安装专用的SSL硬件加速卡，作用类似GPU，释放CPU，能够具有更高的HTTPS接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。
4.远程解密
本地接入消耗过多的CPU资源，浪费了网卡和硬盘等资源，考虑将最消耗CPU资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择CPU负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是CDN用于大规模HTTPS接入的解决方案之一。
5.SPDY/HTTP2
前面的方法分别从减少传输延时和单机负载的方法提高HTTPS接入性能，但是方法都基于不改变HTTP协议的基础上提出的优化方法，SPDY/HTTP2利用TLS/SSL带来的优势，通过修改协议的方法来提升HTTPS的性能，提高下载速度等。

参考链接：
http://segmentfault.com/a/119...
http://www.fenesky.com/blog/2...
https://technet.microsoft.com...
https://www.ietf.org/rfc/rfc2...