HTTPS-如何优化？

目录

• HTTP 与 HTTPS
• HTTPS 如何优化？
  • 会话复用
    • Session ID
    • Session Ticket
    • Pre-shared Key
• 总结
• 参考

相关阅读推荐：

• HTTPS-各种加密方式
• 计算机网络汇总

HTTP 与 HTTPS

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。

HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。

这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，

HTTPS 如何优化？

这里着重介绍会话复用这个模块。

会话复用

TLS 握⼿的⽬的就是为了协商出会话密钥，如果我们把⾸次 TLS 握⼿协商的对称加密密钥缓存起来，

待下次需要建⽴ HTTPS 连接时，直接「复⽤」这个密钥，不就减少 TLS 握⼿的性能损耗了吗？

这种⽅式就是会话复⽤（TLS session resumption），会话复⽤分两种：

• 第⼀种叫 Session ID；
• 第⼆种叫 Session Ticket；

Session ID

Session ID 的⼯作原理是，客户端和服务器⾸次 TLS 握⼿连接后，双⽅会在内存缓存会话密钥，

并⽤唯⼀的Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系。

当客户端再次连接时，hello 消息⾥会带上 Session ID，服务器收到后就会从内存找，

如果找到就直接⽤该会话密钥恢复会话状态，跳过其余的过程，只⽤⼀个消息往返就可以建⽴安全通信。

当然为了安全性，内存中的会话密钥会定期失效。

---

缺点：

服务器必须保持每⼀个客户端的会话密钥，随着客户端的增多，服务器的内存压⼒也会越⼤。

现在⽹站服务⼀般是由多台服务器通过负载均衡提供服务的，

客户端再次连接不⼀定会命中上次访问过的服务器，于是还要⾛完整的 TLS 握⼿过程；

Session Ticket

服务器不再缓存每个客户端的会话密钥，⽽是把缓存的⼯作交给了客户端，类似于 HTTP 的 Cookie。

客户端与服务器⾸次建⽴连接时，服务器会加密「会话密钥」作为 Ticket 发给客户端，交给客户端缓存该Ticket。

客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上⼀次的会话密钥，

然后验证有效期，如果没问题，就可以恢复会话了，开始加密通信。

---

对于集群服务器的话，要确保每台服务器加密 「会话密钥」的密钥是⼀致的，

这样客户端携带 Ticket 访问任意⼀台服务器时，都能恢复会话。

Session ID 和 Session Ticket 都不具备前向安全性，

因为⼀旦加密「会话密钥」的密钥被破解或者服务器泄漏「会话密钥」，前⾯劫持的通信密⽂都会被破解。

为了避免重放攻击的⽅式就是需要对会话密钥设定⼀个合理的过期时间。

Pre-shared Key

前⾯的 Session ID 和 Session Ticket ⽅式都需要在 1 RTT 才能恢复会话。

对于重连 TLS1.3 只需要 0 RTT，原理和 Ticket 类似，只不过在重连时，

客户端会把 Ticket和 HTTP 请求⼀同发送给服务端，这种⽅式叫 Pre-shared Key。

同样的，Pre-shared Key 也有重放攻击的危险。

总结

对于硬件优化的⽅向，因为 HTTPS 是属于计算密集型，应该选择计算⼒更强的 CPU，

⽽且最好选择⽀持 AES-NI特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应⽤数据的加解密。

---

对于软件优化的⽅向，如果可以，把软件升级成较新的版本。

---

对于协议优化的⽅向：

• 密钥交换算法应该选择 ECDHE 算法，⽽不⽤ RSA 算法，

  因为 ECDHE 算法具备前向安全性，⽽且客户端可以在第三次握⼿之后，就发送加密应⽤数据，节省了 1 RTT。

• 将 TSL1.2 升级 TSL1.3，因为 TSL1.3 的握⼿过程只需要 1 RTT，⽽且安全性更强。

---

对于证书优化的⽅向：

• 服务器应该选⽤ ECDSA 证书，⽽⾮ RSA 证书，因为在相同安全级别下，ECC 的密钥⻓度⽐ RSA 短很多，这样可以提⾼证书传输的效率；

• 服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样TLS 握⼿的时候就不⽤再访问 CA 服务器，减少了⽹络通信的开销，提⾼了证书验证的效率；

对于重连 HTTPS 时，我们可以使⽤⼀些技术让客户端和服务端使⽤上⼀次 HTTPS 连接使⽤的会话密钥，直接恢
复会话，⽽不⽤再重新⾛完整的 TLS 握⼿过程。

常⻅的会话重⽤技术有 Session ID 和 Session Ticket，⽤了会话重⽤技术，当再次重连 HTTPS 时，只需要 1 RTT
就可以恢复会话。对于 TLS1.3 使⽤ Pre-shared Key 会话重⽤技术，只需要 0 RTT 就可以恢复会话。

这些会话重⽤技术虽然好⽤，但是存在⼀定的安全⻛险，它们不仅不具备前向安全，⽽且有重放攻击的⻛险，所以
应当对会话密钥设定⼀个合理的过期时间。

参考

• https://medium.com/faun/http-2-spdy-and-http-3-quic-bae7d9a3d484
• https://developers.google.com/web/fundamentals/performance/http2?hl=zh-cn
• https://blog.cloudflare.com/http3-the-past-present-and-future/
• 图解网络