摘要

1. HTTPS的性能损耗
2. 硬件优化
3. 软件优化
4. 证书优化
5. 会话复用

HTTPS的性能损耗

• 数据传输需要通过对称加密进行传输
• 对称加密密钥需要经历TLS握手才可获得
• 证书验证需要耗时

硬件优化

选择支持AES-NI特性的CPU，该CPU在指令级别优化了AES算法，加速了数据的加解密过程。

sort -u /proc/crypto | grep module | grep aes

在CPU支持AES-NI特性，我们的对称加密算法尽量选择AES，否则可以选择ChaCha20对称加密算法。

软件优化

软件上的优化分为：

• 软件升级
• 协议升级

软件升级

软件升级相比硬件升级可能会节省money，但是如果服务器数量庞大，软件升级也需要较大的人力和升级，软件升级主要包括以下：

• Linux内核升级
• OpenSSL升级

协议升级

• 密钥协商算法优化
• 对称加密算法优化
• TLS1.2升级为1.3

密钥协商算法优化

密钥协商算法尽量选取ECDHE算法，该算法相比RSA算法具有向前保密，且在第三次握手以后就可以发送数据，减少了一个RTT时间。

ECDHE算法在选择椭圆曲线时尽量选择X25519的曲线，该曲线是目前最快的曲线。

在Nginx上可以使用ssl_ecdh_curve 指令配置想使用的椭圆曲线，把优先使用的放在前面。

ssl_ecdh_curve X25519:prime256v1:secp384r1;

对称加密算法优化

对称加密算法在安全性要求不是很高的情况下尽量选择AES_128_GCM，因为AES_128_GCM相比于AES_256_GCM生成的速度更快，但密钥长度较短。

在Nginx上可以使用ssl_ciphers 指令配置想使用的密钥套件(非对称加密算法和对称加密算法)，比如：

ssl_ciphers ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA;

使用以下命令可以查看本地Open SSL的密码套件

openssl ciphers

TLS1.2升级为1.3

TLS1.3的握手简化为一个1RTT，大大减少了网络IO的耗时。

TLS1.3如何将握手减少到1个RTT

上图是TLS1.3整个握手的过程，从图中可以看出经历过1个RTT以后，我们的客户端和服务端就可以发送加密数据了（Application Data）。

Client Hello中包含一个key_share，key_share中是椭圆曲线类型及其对应的公钥，第一个是预留的空值，第二个是我们这里选择的x25519曲线类型对应的公钥

Server Hello会确认椭圆曲线的类型及参数，并且生成公钥通过key_share消息发送给客户端。

至此，客户端和服务端都拥有了生成对称密钥的所有信息，客户端和服务端经历过一个RTT以后便可进行加密数据传输。

TLS1.3废除了RSA和DH加密算法，只支持ECDHE算法。

证书优化

证书优化主要优化：

• 传输优化
• 验证优化

如何进行传输优化

服务器证书应该选择椭圆曲线(ECDSA)证书，相同安全强度下，ECDS证书相比RSA证书密钥更短，这样可以减少证书的大小，减小网络传输耗时。

证书验证优化

证书验证需要通过CA公钥解密证书以及使用签名算法验证证书的完整性，并且为了知道证书是否被CA吊销，需要再去访问CA来获取证书的有效性，这一步就产生了额外的网络开销。

CRL

CRL是证书吊销列表，列表定期由CA更新，如果服务器的证书在该列表中，证书则失效。

CRL的缺点：

• 定期刷新，实时性差，在未刷新期间该证书依然有效
• 列表不断增大，下载耗时增加，同时客户端遍历证书验证列表耗时也增加

OCSP

OCSP就是向CA发送查询请求，CA返回证书的有效状态。

OCSP的速度依赖CA服务器的状态和与CA服务器之间的网络状态，如果服务器响应慢或中间网络慢，都会导致证书验证变慢。

OCSP Stapling

OCSP Stapling就是服务器周期性的向CA查询证书状态，获得一个带有时间戳和签名的结果响应并且进行缓存。然后在客户端和服务端建立TLS连接时，服务器会把上面的响应结果发送给客户端。客户端通过该结果就可以知道证书是否被吊销，不需要再向CA发起网络请求。

会话复用

TLS握手是为了协商对称密钥，如果将密钥进行缓存，下次HTTPS连接建立时直接复用缓存的密钥即可减少TLS握手的消耗。

会话复用的形式有：

• Session Id
• Session Ticket
• Pre-shared Key

Session Id

Session Id是客户端段和服务端在完成TLS握手连接后，双方会各自缓存一份密钥，使用唯一标识Session Id作为key，会话对称密钥为value。

客户端在下次建立连接时会带上Session Id，服务器接到Session Id后会在内存中进行查找，如果可以找到跳过密钥协商环节，直接使用以前的会话密钥恢复会话进行数据加密传输。

为了安全性，会话密钥的缓存注意设置过期时间。

Session Id的缺点

• 客户端增多，服务器缓存的密钥会越来越多，吃掉过多内存
• 现在的服务端基本都是多台服务器部署，客户端在下次连接时如果连接的是一台从未访问过的服务器，还是需要TLS握手

Session Ticket

服务器不再缓存会话密钥，客户端和服务端首次建立连接时，服务器会加密会话密钥作为Ticket发送给客户端，客户端会缓存该Ticket。

客户端和再次连接服务器时，会发送次Ticket，服务器收到解密以后即可拿到会话密钥，然后验证有效期，如果有效就可以恢复会话进行加密通信。

Session Ticket在多台服务器下，需要保证生成的会话密钥一样，这样才可以在多服务器间恢复会话。

Session ID和Session Ticket

这两种方式虽然可以复用会话减少TLS握手，但是这两种方式都不具备向前保密，一旦会话密钥泄漏即可破解过往截获的密文。

因为密钥泄漏，密文可以被破解，因此很容易对服务器进行重放攻击，破坏数据库数据。

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

Pre-shared Key

Pre-shared Key是TLS1.3出现的优化方式，它的原理类似于Session Ticket，但Session Ticket需要1个RTT才能进行加密数据传输，但Pre-shared Key会在重连时将Ticket和HTTP请求一起发送给服务端，0个RTT即可加密传输数据。

Pre-shared Key的缺点和Session Ticket的缺点一样无法抵御重放攻击。