优化HTTPS
一、性能损耗分析
性能损耗主要从两方面着手
- TLS协议握手过程
- 握手后的对称加密报文传输
针对握手后的对称加密报文传输,主流的AES、ChaCha20性能都是不错的,所以这个好解决。
那么我们就来分析TLS握手过程中的性能分析
- ECDHE密钥协商算法,握手过程中客户端和服务端都要临时生成椭圆曲线公私钥
- 客户端验证证书,要访问CA
- 双方都要计算对称加密密钥
二、硬件优化
主要是选择AES-NI特性的CPU,这款CPU能在指令级别优化了AES算法,加速数据加密解密传输过程。
三、软件优化
软件升级到最新版本,使用新特性。
三、协议优化
密钥算法优化
- ECDHE密钥交换:选择x25519曲线
- 对称加密算法:选用AES_128_GCM
TLS升级
把TLS1.2升级成TLS1.3,TLS1.3把Hello和公钥交换这两个消息合并成了一个消息,减少了一次握手。
对于密钥加密算法,废除了不支持前向安全性的RSA和DH算法,只支持ECDHE算法
四、证书优化
证书传输优化
对于服务器的证书应该选择椭圆曲线证书,而不是RSA证书,因为在相同安全强度下,ECC密钥长度比RSA短的多
证书验证优化
客户端用CA公钥解密证书,用签名算法验证证书完整性,以及访问CA确保证书有效性。
CRL(证书吊销列表)
这个列表是由 CA 定期更新,列表内容都是被撤销信任的 证书序号,如果服务器的证书在此列表,就认为证书已经失效,不在的话,则认为证书是有效的。
CRL存在的问题
- 实时性较差:CRL列表由CA维护,定期更新。
- 下载速度慢:随着吊销证书的增多,列表会越来越大,下载的速度就会越慢。
OCSP(在线证书状态协议)
它的工作方式是向CA发送查询请求,让CA返回证书的有效状态。
OCSP存在的问题
- 网络状态不好或CA服务器繁忙,也会导致校验证书环节时延变大
OCSP Stapling
服务器向CA 周期性地查询证书状态,获得⼀个带有时间戳和签名的响应结果并缓存它。
当有客户端发起连接请求时,服务器会把这个响应结果在 TLS 握⼿过程中发给客户端。由于有签名的存在, 服务器无法篡改,因此客户端就能得知证书是否已被吊销了,这样客户端就不需要再去查询。
五、会话复用
通过把首次TLS握手协商的对称加密密钥缓存起来,等到下次需要建立HTTPS连接的时候,直接复用这个密钥,来减少TLS握手的性能损耗。
SessionID
SessionID的工作原理是,客户端和服务器首次TLS 握手连接后,双方会在内存缓存会话密钥,并用唯⼀的SessionID来标识,SessionID和会话密钥相当于 key-value 的关系。
当客户端再次连接时,hello消息里会带上SessionID,服务器收到后就会从内存找,如果找到就直接用该会话密钥恢复会话状态,跳过其余的过程,只用⼀个消息往返就可以建立安全通信。当然为了安全性,内存中的会话密钥会定期失效。
缺点
- 随着客户端的增多,服务器的内存压力也会变得越大
- 现在网站服务⼀般是由多台服务器通过负载均衡提供服务的,客户端再次连接不一定会命中上次访问过的服务器,于是还要走完整的TLS握手过程
Session Ticket
服务器不再缓存每个客户端的会话密钥,而是把缓存的工作交给了客户端,类似于HTTP的Cookie。
客户端与服务器首次建立连接时,服务器会加密会话密钥作为 Ticket 发给客户端,交给客户端缓存该Ticket。客户端再次连接服务器时,客户端会发送 Ticket,服务器解密后就可以获取上⼀次的会话密钥,然后验证有效期, 如果没问题,就可以恢复会话了,开始加密通信。
重连时,客户端会把Ticket和HTTP 请求⼀同发送给服务端,这种方式叫Pre-shared Key。
SessionID和SessionTicket的缺点
SessionID和Session Ticket 都不具备前向安全性,因为⼀旦加密会话密钥的密钥被破解或者服务器泄漏会话密钥,前面劫持的通信密文都会被破解。
重放攻击
重放攻击的危险之处在于,如果中间⼈截获了某个客户端的Session ID或 Session Ticket 以及 POST报文,而一般POST 请求会改变数据库的数据,中间人就可以利用此截获的报文,不断向服务器发送该报恩,这样就会导致数据库的数据被中间人改变了,而客户是不知情的。
应对重放攻击可以给会话密钥设定⼀个合理的过期时间。