为什么同样是使用了SSL证书，有些网站评分很低有些却很高?几天前，一位朋友问我：都说用SSL Labs这个工具测试SSL安全性，为什么有些安全实力很强的大厂家评分也很低?我认为这个问题应该从两方面来看：

1)国内用户终端情况复杂，很多时候降低SSL安全配置是为了兼容更多用户;

2)确实有一些大厂家的SSL配置很不专业，尤其是配置了一些明显不该使用的CipherSuite。

我之前写的《正确使用HTTPS加密协议经验分享(一)》，主要介绍HTTPS加密协议如何与一些新出的安全规范配合使用，面向的是现代浏览器。而今天这篇文章，更多的是介绍启用HTTPS过程中在老旧浏览器下可能遇到的问题，以及如何取舍。

SSL版本选择

TLS(Transport Layer Security，传输层安全)的前身是SSL(Secure Sockets Layer，安全套接字层)，它最初的几个版本(SSL 1.0、SSL 2.0、SSL 3.0)由网景公司开发，从3.1 开始被IETF 标准化并改名，发展至今已经有TLS 1.0、TLS 1.1、TLS 1.2 三个版本。TLS 1.3 改动会比较大，目前还在草案阶段。

SSL 1.0 从未公开过，而SSL 2.0 和 SSL 3.0 都存在安全问题，不推荐使用。Nginx 从1.9.1 开始默认只支持TLS 的三个版本，以下是Nginx 官方文档中对ssl_protocols 配置的说明：

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];

Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Context: http, server

Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters work only when the OpenSSL library of version 1.0.1 or higher is used.

但不幸的是，IE 6 默认只支持SSLv2 和SSLv3(来源)，也就是说HTTPS 网站要支持IE 6，就必须启用SSLv3。仅这一项就会导致SSL Labs 给出的评分降为C。

加密套件选择

加密套件(CipherSuite)，是在SSL 握手中需要协商的很重要的一个参数。客户端会在Client Hello 中带上它所支持的CipherSuite 列表，服务端会从中选定一个并通过Server Hello 返回。如果客户端支持的CipherSuite 列表与服务端配置的CipherSuite 列表没有交集，会导致无法完成协商，握手失败。

CipherSuite 包含多种技术，例如认证算法(Authentication)、加密算法(Encryption)、消息认证码算法(Message Authentication Code，简称为 MAC)、密钥交换算法(Key Exchange)和密钥衍生算法(Key Derivation Function)。

SSL 的CipherSuite 协商机制具有良好的扩展性，每个CipherSuite 都需要在IANA 注册，并被分配两个字节的标志。全部CipherSuite 可以在IANA 的TLS Cipher Suite Registry 页面查看。

OpenSSL库支持的全部CipherSuite 可以通过以下命令查看：

openssl ciphers -V | column -t

0xCC,0x14 - ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDH  Au=ECDSA  Enc=ChaCha20-Poly1305  Mac=AEAD

... ...

0xCC,0x14 是CipherSuite 的编号，在SSL 握手中会用到。ECDHE-ECDSA-CHACHA20-POLY1305 是它的名称，之后几部分分别表示：用于TLSv1.2，使用ECDH 做密钥交换，使用ECDSA 做认证，使用ChaCha20-Poly1305 做对称加密，由于ChaCha20-Poly1305 是一种AEAD 模式，不需要MAC 算法，所以MAC 列显示为AEAD。

要了解CipherSuite 的更多内容，可以阅读这篇长文《TLS 协议分析与现代加密通信协议设计》。总之，在配置CipherSuite 时，请务必参考权威文档，如：Mozilla的推荐配置、CloudFlare使用的配置。

以上Mozilla 文档中的「Old backward compatibility」配置，以及CloudFlare 的配置，都可以很好的兼容老旧浏览器，包括Windows XP / IE6。

之前见到某个大厂家居然支持包含EXPORT 的CipherSuite，这些套件在上世纪由于美国出口限制而被弱化过，已被攻破，实在没有理由再使用。

SNI 扩展

我们知道，在Nginx 中可以通过指定不同的server_name来配置多个站点。HTTP/1.1 协议请求头中的Host 字段可以标识出当前请求属于哪个站点。但是对于HTTPS 网站来说，要想发送HTTP 数据，必须等待SSL 握手完成，而在握手阶段服务端就必须提供网站证书。对于在同一个IP 部署不同HTTPS 站点，并且还使用了不同证书的情况下，服务端怎么知道该发送哪个证书?

Server Name Indication，简称为SNI，是TLS 的一个扩展，为解决这个问题应运而生。有了SNI，服务端可以通过Client Hello 中的SNI 扩展拿到用户要访问网站的Server Name，进而发送与之匹配的证书，顺利完成SSL 握手。

Nginx在很早之前就支持了SNI，可以通过nginx -V 来验证。以下是我的验证结果：

./nginx -V

nginx version: nginx/1.9.9

built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

built with OpenSSL 1.0.2e-dev xx ‍ xxxx

TLS SNI support enabled

configure arguments: --with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

然而，并不是所有浏览器都支持SNI，以下是常见浏览器支持SNI 的最低版本：

可以看到，现在还有一定用户量的Windows XP IE6~8、Android 2.x Webview 都不支持SNI。如果要避免在这些浏览器中出现证书错误，只能将使用不同证书的HTTPS 站点部署在不同IP 上，最简单的做法是分开部署到不同机器上。

另外，包含 SAN(Subject Alternative Name)的证书能同时支持多个域名，也可以用于解决这个问题。

证书选择

HTTPS 网站需要通过CA 取得合法证书，证书通过数字签名技术确保第三方无法伪造。证书的简单原理如下：

· 根据版本号、序列号、签名算法标识、发行者名称、有效期、证书主体名、证书主体公钥信息、发行商唯一标识、主体唯一标识、扩展生成 TBSCertificate(To Be Signed Certificate，待签名证书)信息;

· 签发数字签名：使用HASH 函数对TBSCertificate 计算得到消息摘要，用CA 的私钥对消息摘要进行加密，得到签名;

· 校验数字签名：使用相同的HASH 函数对TBSCertificate 计算得到消息摘要，与使用CA 公钥解密签名得到内容相比较;

使用SHA-1 做为HASH 函数的证书被称之为SHA-1 证书，由于目前已经找到SHA-1 的碰撞条件，将证书换成使用更安全的SHA-2 做为 HASH 函数的SHA-2 证书被提上日程。

实际上，微软已经宣称自2017年1 月1 日起，将全面停止对SHA-1 证书的支持。届时在最新版本的Windows 系统中，SHA-1 证书将不被信任。

而根据Chrome 官方博客的文章，使用SHA-1 证书且证书有效期在2016 年1月1号至2016 年12 月31号之间的站点会被给予「安全的，但存在漏洞」的提示，也就是地址栏的小锁不再是绿色的，并且会有一个黄色小三角。而使用SHA-1 证书且证书有效期超过2017 年 1月1号的站点会被给予「不安全」的红色警告，小锁上直接显示一个红色的叉。参考：微软谷歌Mozilla 三大浏览器2016放弃对SHA-1证书支持

然而，并不是所有的终端都支持SHA-2 证书，服务端不支持还好办，浏览器只能依赖于用户升级了。下面是常见浏览器支持SHA-2 证书的最低版本：

可以看到，如果要照顾没有打XP SP3 补丁的IE6 用户，只能继续使用SHA-1 证书。

在我之前的文章中，还提到过ECC 证书，这种新型的证书支持度更差，这里略过不提，有兴趣的同学可以点这里查看。

是否可以针对不同浏览器启用不同证书呢?理论上服务端可以根据客户端Client Hello 中的 Cipher Suites 特征以及是否支持SNI 的特征来分配不同证书。现在有一些网站利用IE on Windows XP 不支持SNI 这个特性，配置使用SHA-1 证书的Default Server 给它们用。

本文先写这么多，很多策略都需要根据自己网站的用户来决定，例如我的博客基本没有IE8- 用户，理所当然可以禁用SSLv3。如果你的产品还有很多使用老旧浏览器的用户，那就必须为这些用户做兼容方案了。一种方案是：只把主域安全级别配低，将XP 上IE 用户的HTTPS 请求直接重定向到HTTP 版本，这样其它域名可以使用高安全级别的配置，运维起来比较方便。

相关阅读：

如何正确使用HTTPS加密协议经验分享(一)

如何正确使用HTTPS加密协议经验分享(三)

文章来源：https://imququ.com/post/sth-about-switch-to-https-2.html

沃通CA为广大用户提供安全可信,性价比高的EV SSL证书,OV SSL证书,IV SSL证书以及免费SSL证书,欢迎申请体验!申请地址：http://www.wosign.com