面经学习-如何优化HTTPS

HTTPS如何优化

分析性能损耗

性能损耗的两个环节

1TLS握手过程

2握手后的对称加密报文传输

主要针对第一环节，有最长2RTT的延时

以及一些握手过程中的其他损耗

1. 对于 ECDHE 密钥协商算法，握手过程中会客户端和服务端都需要临时生成椭圆曲线公私钥
2. 客户端验证证书时，会访问 CA 获取 CRL 或者 OCSP，目的是验证服务器的证书是否有被吊销
3. 双方计算 Pre-Master，也就是对称加密密钥

硬件优化

支持 AES-NI 特性的 CPU

软件优化

软件升级和协议优化

协议优化

密钥交换算法优化

使用ECDHE替换RSA算法

选择x25519曲线

对称加密算法使用AES 128 GCM而非256来增加速度

TLS升级

TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 TLS 握手。

具体的做法是，客户端在 Client Hello 消息里带上了支持的椭圆曲线，以及这些椭圆曲线对应的公钥。对应的公钥。服务端收到后，选定一个椭圆曲线等参数，然后返回消息时，带上服务端这边的公钥。经过这 1 个 RTT，双方手上已经有生成会话密钥的材料了，于是客户端计算出会话密钥，就可以进行应用数据的加密传输了。

证书优化

两个方向，证书传输和证书验证

证书传输

减少证书的大小，选择椭圆曲线证书（ECDSA)而不是RSA证书，ECC的密钥更短

证书验证

证书验证需要走证书链逐级验证，造成开销

CRL，证书吊销列表

由CA维护，定期更新，内存被撤销的信任证书序号，如果存在，则认为证书失效

缺陷：1由CA维护，实时性差；2吊销证书增加则列表增大，下载速度变慢，拖慢验证速度

OCSP，在线证书状态协议

向CA发送查询请求，让CA返回证书有效状态

缺陷：1向CA查询看网络状态和CA服务器状态

OCSP Stapling

服务器向 CA 周期性地查询证书状态，获得一个带有时间戳和签名的响应结果并缓存它。

当有客户端发起连接请求时，服务器会把这个「响应结果」在 TLS 握手过程中发给客户端。由于有签名的存在，服务器无法篡改，因此客户端就能得知证书是否已被吊销了，这样客户端就不需要再去查询。

会话复用

TLS session resumption

缓存对称密钥留待下次复用

session id

客户端和服务器首次握手后，双方缓存会话密钥，并用sessionid来标识，再次链接时，客户端的hello中带上session id，服务器收到后直接查询内存，如果存在则恢复会话状态，只需要一个消息往返就可以建立安全通信，同时为了安全性要定期失效会话密钥

缺点：1，保存的session id 越多，服务器内存压力越大；2，多台服务器负载均衡，可能再次连接时不一定命中，还要再走一次TLS

Session Ticket

解决id的缺点，将缓存交给客户端，服务器不在缓存对话密钥。

首次链接时，服务器将加密后的对话密钥作为ticket交给客户端，客户端再次链接时，发送ticket，服务器解密后获取密钥，验证有效期

对于集群服务器要确保服务器的加密会话密钥的密钥是一致的。

缺点：1sessionid和ticket都不具备向前安全性，如果泄露了会话密钥则前面的消息全部泄露；2难以应对重放攻击

Pre-shared Key

原理和ticket类似，但是会将http请求和ticket一起发送给服务器