HTTPS如何优化

HTTPS如何优化

学习资源 小林coding 2022.4.3

HTTPS 提高了安全性 也带来了性能的消耗

HTTPS 比 HTTP 多出了TLS协议握手的过程 为了通过非对称加密握手协商或者交换出对称加密密钥 时间最长可以花费掉两RTT 接着后续传输的应用数据 都得使用对称加密密钥来加密/解密

分析性能损耗

两个环节：

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

第一环节： TLS协议握手过程增加了网络延时 （最长2RTT）

握手过程的一些步骤也会产生性能损耗

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

硬件优化

HTTPS协议是计算密集型 不是IO密集型 应该将提升方向至CPU

支持 AES-NI 特性的CPU 在指令级别 优化了AES算法 加速传输

软件优化

• 软件升级
• 协议优化

Linux内核

OpenSSL

协议优化

对密钥交换过程进行优化

密钥交换算法优化

TLS1.2 如果使用RSA密钥交换算法 需要四次握手 2RTT 而且不具备前向安全性

尽量选用 ECDHE密钥交换算法代替RSA算法

客户端可以在TLS协议的三次握手后 发送加密的应用数据

将TLS握手的2RTT减少到1RTT 安全性高

ECDHE算法中 尽量选择x25519曲线 目前最快的椭圆曲线

如果安全性不是特别高的要求 可以选用 AES_128_GCM 对称加密算法

TLS升级

将TLS1.2->TLS1.3 TLS1.3大幅度减少了握手的步骤 完成TLS握手只需要1RTT 安全性更高

TLS1.3将Hello和公钥交换合并成一个消息

TLS1.3只支持ECDHE算法

证书优化

• 证书传输
• 证书验证

证书传输优化

服务器证书应该选择ECDSA（椭圆曲线）证书 不是RSA证书

在相同安全强度下 ECC密钥长度更小

证书验证优化

客户端在验证证书时 会走证书链逐级验证

• 用CA公钥解密证书
• 用签名验证算法 验证证书的完整性
• 下载CRL OCSP 保证证书有效性

CRL

CRL 证书吊销列表 由CA定期更新

列表内容是被撤销信任的证书序号 服务器证书在此列表说明证书失效

• CRL由CA维护 定期更新 实时性差
• 吊销证书增多 列表变大 下载速度慢

OCSP

在线证书状态协议

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

• 网络状态
• CA服务器繁忙程度

OCSP stapling

解决网络开销 原理：服务器向CA周期性地查询证书状态 获得一个带有时间戳和签名的响应结果并缓存

会话复用

TLS握手 -> 协商出会话密钥 对称加密密钥 如果把首次TLS握手协商的对称加密密钥缓存 下次连接时复用 减少损耗

• Session ID
• Session Ticket

Session ID

客户端和服务器首次TLS握手连接之后 双方会在内存缓存会话密钥 并且使用唯一的Session ID 来表示

客户端再次连接 -> 携带Session ID->服务器寻找 -> 为了安全性 内存中会话密钥会定期失效

缺点：

• 服务器保存每一个客户端的会话密钥 压力大
• 目前的网站服务多台服务器使用 负载均衡提供服务 客户端再次连接不一定会命中上次访问的服务器 还需要再次握手

Session Ticket

服务器不再缓存每个客户端的密钥 把缓存的工作交给客户端

客户端与服务器首次建立连接时 服务器会加密会话密钥作为Ticket 发给客户端

交给客户端缓存该Ticket

• 确保每台服务器加密会话密钥的密钥是一致的
• 不具备前向安全性
• 应对重放攻击困难

如何避免重放攻击 -> 对会话密钥设定一个合理的过期时间

Pre-shared Key

Session ID 和 Session Ticket 方式都需要在 1 RTT才能恢复会话

TLS1.3 重连只需要 0 RTT

重连时会把 Ticket和 HTTP请求一同发给服务器

也有重放攻击的风险

总结

硬件优化 -> CPU 支持 AES-NI特性

软件优化 -> 内核 软件

协议优化 -> 尽量走ECDHE算法 TLS1.3

证书优化 -> 选择ECDSA证书 开启OCSP Stapling

服务器周期性向CA查询状态缓存

重连HTTPS-> 会话重用 TLS1.3最快