HTTPS优化——协议优化,证书优化,会话复用

HTTPS优化

相比于HTTP协议,HTTPS协议保证了安全性.因此对HTTPS的优化是非常必要的.

分析性能损耗

产生性能消耗的两个环节

1. TLS握手过程

   1. 握手过程中增加了网络延时(最多花费2RTT).
   2. ECDHE密钥协商算法,握手过程中客户端和服务器都需要临时生成椭圆曲线公私钥
   3. 客户端验证证书时,需要用CA公钥去解密身份证书
   4. 双方都需要计算pre-master,也就是对称加密密钥.

2. 握手后的对称加密报文传输:主要的是加密算法上的优化.但现在的技术已经可以让这一个环节的性能消耗变得非常小了

硬件优化

玩游戏最快战胜对方的方式就是[充钱].软件都是在硬件上跑的,想要提高软件的效率,最直接的方法就是提高硬件的质量. 因为HTTPS是计算密集型,所以主要提升的硬件应该是CPU.

软件优化

软件升级.但升级大量服务器花费的人力物力成本也是不容小觑的.因此软件优化的重心是协议优化

协议优化

密钥交换算法优化

用ECDHE算法代替RSA算法,既能提高安全性(前向安全),也能减少1个RTT(2RTT–>1RTT).

在选用ECDHE算法时,可以选择x25519椭圆曲线(速度最快),如果对性能要求不高,对称加密算法可以选择AES-128-GCM,它生成的会话密钥长度更短,速度更快.

TLS升级

将TLS从1.2升级为1.3

TLS1.2握手过程中,需要4次握手:Client Hello(1),Server Hello(2)协商出需要使用的加密算法,互换公钥(3,4),需要花费2个RTT;TLS1.3握手过程中,将hello和交换公钥进行了合并,只需要1个RTT.

TLS1.3握手过程:首先客户端在Client Hello消息里带上支持的椭圆曲线,基点以及自己根据支持椭圆曲线生成的公钥;服务器收到消息以后选取一条椭圆曲线,然后根据该椭圆曲线生成自己的公钥并发送给客户端.至此,客户端和服务器都具备了生成会话密钥的材料,于是客户端就可以开始利用会话密钥进行通信了.[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TcvkB7mQ-1661867275591)(C:\Users\qiu\AppData\Roaming\Typora\typora-user-images\1659310439221.png)]

除此之外,TLS1.3的密码套件列表进行了缩减,对于密钥交换算法,只支持ECDHE算法,对于对称加密和签名算法只支持最安全的几个.

证书优化

证书指的是服务器用以验证自身身份的身份证书

证书传输优化

通过减少证书的大小来提高证书传输的速度,因此选取椭圆曲线证书来代替RSA证书,因为椭圆曲线公钥的长度要远小于RSA公钥.

证书验证优化

客户端在验证服务器的身份证书时,为了验证证书是否被CA吊销,需要去访问CA,下载CRL或者OCSP数据来确认证书的有效性

CRL:CA维护的一张证书吊销的列表,当一张证书存在于CRL中时,说明该证书已被吊销,不可用.

CRL的问题:

1. 实时性差:因为CRL是CA定期更新的一张表,所以客户端在验证身份证书时,该证书可能当前并不存在于CRL中,但已经被CA吊销了.
2. 效率低:首先客户端必须访问CA,然后查询CRL,但随着吊销证书的增加,CRL表的增大,从CRL中查询出想要的结果的资源耗费是比较大的.

OCSP:在线证书状态协议.通过向CA发送查询请求,让CA返回证书的有效状态.

因为是实时查询,所以解决了CRL实时性差的问题,但查询的效率依旧不高.

OCSP Stapling:服务器定期向CA查询证书的状态并将带有时间戳(验证有效期)和签名(防治服务器篡改)的结果缓存到本地,这样客户端在验证证书是否被吊销时,服务器直接返回一个结果就可以.

会话复用

HTTP连接时会生成一个对称加密密钥,这个密钥每次连接都会生成.通过缓存首次HTTP连接生成的对称加密密钥,直接复用该密钥,减少TLS握手性能的损耗.

Session ID

客户端和服务器首次建立连接时生成的对称加密密钥会被缓存到本地,并用一个唯一映射该密钥的Session ID来标识.这样在之后的连接中,客户端只需要发送自己的Session ID给服务器,就可以直接开始通信.为了安全,缓存中的对称加密密钥会定期失效.

Session ID的缺点:

1. 服务器需要保存每个客户端的会话密钥,随着客户端的增多,服务器的内存压力会增大.
2. 当多台服务器负载均衡提供服务时,客户端发送的Session ID很难命中之前建立连接的服务器,也就是说,这次请求到达的服务器很有可能不存在该Session ID,因此还需要重新建立连接生成新的会话密钥.

Session Ticket

Session Ticket将任务交给了客户端,类似于HTTP的cookie.

客户端和服务器首次建立连接生成的会话密钥,服务器会对其加密生成Ticket发送给客户端,客户端再建立连接时发送该Ticket给服务器,服务器解密Ticket并验证其有效性,若有效,则用该会话密钥进行通信.

对于集群服务器而言,要保证每台服务器加密会话密钥是一致的,这样就会解决Session ID的第2个问题.

Session Ticket的缺点:不具备前向安全性,当会话密钥被破解后,之前的很多通信数据都会被破译.同时也很难应对重放攻击.

重放攻击:中间人在拿到Session ID/Ticket时,通过监听客户端和服务器之间的对话,能够冒充客户端与服务器进行重复的相同或类似的通信使服务器中的数据并不是客户端想要的结果

解决重放攻击的方式就是给会话密钥设置有效时间

Pre-shared Key

Session ID/Ticket都需要1RTT才能恢复会话,而Pre-shared Key可以实现0RTT .

原理和Ticker类似,只是在发送的时候将Ticket和请求一同发送给服务端,这种方式交Pre-shared Key.

使用会话重用是会可能受到重放攻击的,因此要给缓存的会话密钥一个有效期,或者只针对安全的HTTP请求,如Get使用会话重用,