你知道HTTPS如何优化吗？

• 一、性能损耗分析
• 二、硬件优化
• 三、软件优化
• 三、协议优化
• • 密钥算法优化
  • TLS升级
• 四、证书优化
• • 证书传输优化
  • 证书验证优化
  • CRL（证书吊销列表）
  • OCSP（在线证书状态协议）
  • OCSP Stapling
• 五、会话复用
• • SessionID
  • Session Ticket
  • SessionID和SessionTicket的缺点
  • 重放攻击

性能损耗主要从两方面着手

• TLS协议握手过程
• 握手后的对称加密报文传输

针对握手后的对称加密报文传输，主流的AES、ChaCha20性能都是不错的，所以这个好解决。
那么我们就来分析TLS握手过程中的性能分析

• ECDHE密钥协商算法，握手过程中客户端和服务端都要临时生成椭圆曲线公私钥
• 客户端验证证书，要访问CA
• 双方都要计算对称加密密钥

主要是选择AES-NI特性的CPU，这款CPU能在指令级别优化了AES算法，加速数据加密解密传输过程。

软件升级到最新版本，使用新特性。

• ECDHE密钥交换：选择x25519曲线
• 对称加密算法：选用AES_128_GCM

把TLS1.2升级成TLS1.3，TLS1.3把Hello和公钥交换这两个消息合并成了一个消息，减少了一次握手。
对于密钥加密算法，废除了不支持前向安全性的RSA和DH算法，只支持ECDHE算法

对于服务器的证书应该选择椭圆曲线证书，而不是RSA证书，因为在相同安全强度下，ECC密钥长度比RSA短的多

客户端用CA公钥解密证书，用签名算法验证证书完整性，以及访问CA确保证书有效性。

这个列表是由 CA 定期更新，列表内容都是被撤销信任的 证书序号，如果服务器的证书在此列表，就认为证书已经失效，不在的话，则认为证书是有效的。
CRL存在的问题

• 实时性较差：CRL列表由CA维护，定期更新。
• 下载速度慢：随着吊销证书的增多，列表会越来越大，下载的速度就会越慢。

它的工作方式是向CA发送查询请求，让CA返回证书的有效状态。
OCSP存在的问题

• 网络状态不好或CA服务器繁忙，也会导致校验证书环节时延变大

服务器向CA 周期性地查询证书状态，获得⼀个带有时间戳和签名的响应结果并缓存它。
当有客户端发起连接请求时，服务器会把这个响应结果在 TLS 握⼿过程中发给客户端。由于有签名的存在， 服务器无法篡改，因此客户端就能得知证书是否已被吊销了，这样客户端就不需要再去查询。

通过把首次TLS握手协商的对称加密密钥缓存起来，等到下次需要建立HTTPS连接的时候，直接复用这个密钥，来减少TLS握手的性能损耗。

SessionID的工作原理是，客户端和服务器首次TLS 握手连接后，双方会在内存缓存会话密钥，并用唯⼀的SessionID来标识，SessionID和会话密钥相当于 key-value 的关系。
当客户端再次连接时，hello消息里会带上SessionID，服务器收到后就会从内存找，如果找到就直接用该会话密钥恢复会话状态，跳过其余的过程，只用⼀个消息往返就可以建立安全通信。当然为了安全性，内存中的会话密钥会定期失效。
缺点

• 随着客户端的增多，服务器的内存压力也会变得越大
• 现在网站服务⼀般是由多台服务器通过负载均衡提供服务的，客户端再次连接不一定会命中上次访问过的服务器，于是还要走完整的TLS握手过程

服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给了客户端，类似于HTTP的cookie。
客户端与服务器首次建立连接时，服务器会加密会话密钥作为 Ticket 发给客户端，交给客户端缓存该Ticket。客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上⼀次的会话密钥，然后验证有效期， 如果没问题，就可以恢复会话了，开始加密通信。
重连时，客户端会把Ticket和HTTP 请求⼀同发送给服务端，这种方式叫Pre-shared Key。

SessionID和Session Ticket 都不具备前向安全性，因为⼀旦加密会话密钥的密钥被破解或者服务器泄漏会话密钥，前面劫持的通信密文都会被破解。

重放攻击的危险之处在于，如果中间⼈截获了某个客户端的Session ID或 Session Ticket 以及 POST报文，而一般POST 请求会改变数据库的数据，中间人就可以利用此截获的报文，不断向服务器发送该报恩，这样就会导致数据库的数据被中间人改变了，而客户是不知情的。

应对重放攻击可以给会话密钥设定⼀个合理的过期时间。