HTTPS performacne tips

June 3, 2018

相对HTTP，影响HTTPS性能的因素包括以下几个方面。

TLS协议开销

TLS协议采用主从式架构模型，用于在两个应用程序间通过网络创建起安全的连接，防止在交换数据时受到窃听及篡改。

TLS协议的优势是与高层的应用层协议（如HTTP、FTP、Telnet等）无耦合。应用层协议能透明地运行在TLS协议之上，由TLS协议进行创建加密通道需要的协商和认证。应用层协议传送的数据在通过TLS协议时都会被加密，从而保证通信的私密性。

TLS握手

The SSL or TLS handshake enables the SSL or TLS client and server to establish the secret keys with which they communicate.

  1. TCL client send "client hello" to TLS server. include:
    • cryptographic information such as the SSL or TLS version
    • the CipherSuites supported by the client
    • a random byte string that is used in subsequent computations
    • data compression methods supported by the client
  2. The TLS server responds with a "server hello" message that contains:
    • the CipherSuite chosen by the server from the list provided by the client.
    • the session ID.
    • another random byte string.
    • The server also sends its digital certificate.
    • If the server requires a digital certificate for client authentication, the server sends a "client certificate request" that includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).
  3. The TLS client verifies the server's digital certificate. For more information, see How SSL and TLS provide identification, authentication, confidentiality, and integrity.
  4. The TLS client sends the random byte string (also called pre-master-secret) that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key.
  5. (optional)If the TLS server sent a "client certificate request", the client sends a random byte string encrypted with the client's private key, together with the client's digital certificate, or a "no digital certificate alert". This alert is only a warning, but with some implementations the handshake fails if client authentication is mandatory.
  6. The SSL or TLS server verifies the client's certificate. For more information, see How SSL and TLS provide identification, authentication, confidentiality, and integrity.
  7. The SSL or TLS client sends the server a "finished" message, which is encrypted with the secret key, indicating that the client part of the handshake is complete. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
  8. The SSL or TLS server sends the client a "finished" message, which is encrypted with the secret key, indicating that the server part of the handshake is complete.
  9. For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.

可见，相比http，client和server至少增加了2个来回的交互。

对于长连接的使用场景影响还好，因为handshake只影响到了session建立的过程，对于后面的数据交互无影响，但对于端链接的场景冲击会相对较大，每次请求都会多了2个来回的交互。

交换数据加解密

TLS连接建立后，CS间采用secret key来加密交换数据。对称加密会对服务端的性能造成一些压力。

注意secret key的生成依赖上面提到的三个随机数，原因如下

ssl3_send_client_key_exchange是openssl中客户端确定密钥的函数，同时也发送了“一部分”数据给服务器，这一部分数据就是所谓的pre_master，不管是客户端还是服务器都根据对端传过来的pre_master和自己计算出来的另一部分数据来生成最终的对称密钥，生成过程中需要hello消息中的随机数，这样生成的密钥才不会每次都一样。由于ssl协议中dh份额来源于证书，而证书又是静态的，因此十分有必要引入一种随机因素来保证通过静态证书导出的密钥份额协商出来的密钥的随机性。同时这也是pre_master的意义，那就是随机，对于rsa密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥，但是对于dh，包括ecdh算法(不考虑匿名dh和瞬时dh)，就只有hello消息中的两个随机数因子了。

pre master的存在在于ssl协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

CA验证

(未完)

See all postsSee all posts