HTTPS 安全配置

协议版本选择

SSL2.0 早就被证明是不安全的协议了，统计发现目前已经没有客户端支持 SSL2.0，所以可以放心地在服务端禁用 SSL2.0 协议。
2014 年爆发了 POODLE 攻击，SSL3.0 因此被证明是不安全的。但是统计发现依然有 0.5% 的流量只支持 SSL3.0。所以只能有选择地支持 SSL3.0。
TLS1.1 及 1.2 目前为止没有发现安全漏洞，建议优先支持。

加密套件选择

加密套件包含四个部分：

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

2. 证书签名算法。由于部分浏览器及操作系统不支持 ECDSA 签名，目前默认都是使用 RSA 签名，其中 SHA1 签名已经不再安全，chrome 及微软 2016 年开始不再支持 SHA1 签名的证书 (http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。

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

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

HTTPS 防攻击

防止协议降级攻击

降级攻击一般包括两种：加密套件降级攻击 (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，就不会接受比服务端最高协议版本低的协议。

防止重新协商攻击

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

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

2. 重协商过程中不断发起完全握手请求，触发服务端进行高强度计算并引发服务拒绝。 对于重协商，最直接的保护手段就是禁止客户端主动重协商，当然出于特殊场景的需求，应该允许服务端主动发起重协商。