3， Web server 到 TLS 计算集群之间的任务是异步的。即 web server 将待计算内容发送给加速集群后，依然可以继续处理其他请求，整个过程是异步非阻塞的。

　　4 HTTPS 安全配置

　　4.1 协议版本选择

　　SSL2.0 早就被证明是不安全的协议了，统计发现目前已经没有客户端支持 SSL2.0，所以可以放心地在服务端禁用 SSL2.0 协议。

　　2014 年爆发了 POODLE 攻击，SSL3.0 因此被证明是不安全的。但是统计发现依然有 0.5% 的流量只支持 SSL3.0。所以只能有选择地支持 SSL3.0。

　　TLS1.1 及 1.2 目前为止没有发现安全漏洞，建议优先支持。

　　4.2 加密套件选择

　　加密套件包含四个部分：

　　1， 非对称密钥交换算法。建议优先使用 ECDHE，禁用 DHE，次优先选择 RSA。

　　2， 证书签名算法。由于部分浏览器及操作系统不支持 ECDSA 签名，目前默认都是使用 RSA 签名，其中 SHA1 签名已经不再安全，chrome 及微软 2016 年开始不再支持 SHA1 签名的证书 ()。

　　3， 对称加解密算法。优先使用 AES-GCM 算法，针对 1.0 以上协议禁用 RC4（ rfc7465）。

　　4， 内容一致性校验算法。Md5 和 sha1 都已经不安全，建议使用 sha2 以上的安全哈希函数。

　　4.3 HTTPS 防攻击

　　4.3.1 防止协议降级攻击

　　降级攻击一般包括两种：加密套件降级攻击 (cipher suite rollback) 和协议降级攻击（version roll back）。降级攻击的原理就是攻击者伪造或者修改 client hello 消息，使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。

　　为了应对降级攻击，现在 server 端和浏览器之间都实现了 SCSV 功能，原理参考https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。

　　一句话解释就是如果客户端想要降级，必须发送 TLS_SCSV 的信号，服务器如果看到 TLS_SCSV，就不会接受比服务端最高协议版本低的协议。

　　4.3.2 防止重新协商攻击

　　重新协商（tls renegotiation）分为两种：加密套件重协商 (cipher suite renegotiation) 和协议重协商（protocol renegotiation）。

　　重新协商会有两个隐患：

　　1， 重协商后使用弱的安全算法。这样的后果就是传输内容很容易泄露。

　　2， 重协商过程中不断发起完全握手请求，触发服务端进行高强度计算并引发服务拒绝。

　　对于重协商，最直接的保护手段就是禁止客户端主动重协商，当然出于特殊场景的需求，应该允许服务端主动发起重协商。

　　5 结束语

　　HTTPS 的实践和优化涉及到了非常多的知识点，由于篇幅关系，本文对很多优化策略只是简单介绍了一下. 如果想要了解协议背后的原理，还是需要详细阅读 TLS 协议及 PKI 知识。对于大型站点来说，如果希望做到极致，HTTPS 的部署需要结合产品和基础设施的架构来进行详细的考虑，比起部署支持 HTTPS 的接入和对它的优化，在产品和运维层面上花费的功夫会更多。本系列的下一篇文章将进一步进行介绍。