菜单

有关启用 HTTPS 的片段经历分享(二)

2019年1月20日 - 金沙前端

有关启用 HTTPS 的一些经验分享(二)

2015/12/24 · 基本功技术 ·
金沙国际,HTTP,
HTTPS

原文出处:
imququ(@屈光宇)   

小说目录

几天前,一位情人问我:都说推荐用 Qualys SSL
Labs 这些工具测试 SSL
安全性,为何有些安全实力很强的大厂家评分也很低?我以为这一个问题应有从两方面来看:1)国内用户终端意况复杂,很多时候降落
SSL 安全安排是为着同盟更加多用户;2)确实有部分大厂家的 SSL
配置很不僧不俗,尤其是布署了有的明显不应该使用的 CipherSuite。

自身从前写的《关于启用 HTTPS
的局地经历分享(一)》,主要介绍 HTTPS
怎么样与一些新出的吕梁专业同盟使用,面向的是当代浏览器。而前天那篇文章,更多的是介绍启用
HTTPS 进程中在老旧浏览器下可能碰着的题材,以及如何挑选。

几天前,一位朋友问我:都说推荐用 Qualys SSL
Labs 这么些工具测试 SSL
安全性,为啥有些安全实力很强的大厂家评分也很低?我以为那么些题材应该从两下面来看:

什么样针对老旧浏览器设置 HTTPS 策略

几天前,一位情人问我:都说推荐用 Qualys SSL Labs 那一个工具测试 SSL
安全性,为啥有些安全实力很强的大厂家评分也很低?我认为这么些问题应有从两方面来看:

  1. 国内用户终端情形复杂,很多时候降落 SSL 安全布局是为着同盟更加多用户;
  2. 实在有局地大厂家的 SSL 配置很不三不四,越发是计划了有的明了不应当使用的
    CipherSuite。

自己事先写的《关于启用 HTTPS 的有些经验分享(一)》,首要介绍 HTTPS
咋样与部分新出的安全标准合营使用,面向的是当代浏览器。而前几天那篇小说,更加多的是介绍启用
HTTPS 进度中在老旧浏览器下可能碰到的题目,以及哪些抉择。

金沙国际 1

 

在近年几年里,我写了很多关于 HTTPS 和 HTTP/2
的小说,涵盖了证书申请、Nginx
编译及布置、性能优化等成套。在这么些作品的评介中,不少读者提出了丰裕多彩的题材,我的信箱也每每接到类似的邮件。本文用来罗列其中有代表性、且我晓得解决方案的题材。

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。

  1. 境内用户终端情形复杂,很多时候降落 SSL 安全配置是为着协作更加多用户;
  2. 确实有一些大厂家的 SSL 配置很不正规,尤其是安顿了部鲜明确不应该使用的
    CipherSuite。

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 … …

1
2
3
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,那么些套件在上世纪由于美利哥出口限制而被弱化过,已被攻占,实在没有理由再利用。

自己从前写的《至于启用 HTTPS
的局地经历分享(一)》,紧要介绍
HTTPS
如何与局地新出的平安标准合营使用,面向的是当代浏览器。而明天那篇文章,更多的是介绍启用
HTTPS 进程中在老旧浏览器下或者遇见的问题,以及哪些挑选。

加密套件选拔

加密套件(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 可以经过以下命令查看:

  1. openssl ciphers -V | column -t
  2. 0xCC,0x14- ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305Mac=AEAD
  3. ......

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,那几个套件在上世纪由于美利坚联邦合众国讲话限制而被削弱过,已被夺回,实在没有理由再使用。

 

实在,碰到任何有关陈设 HTTPS 或 HTTP/2 的题目,都推荐先用 Qualys SSL
Labs’s SSL Server
Test 跑个测试,大多数问题都能被诊断出来。

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 XXX xxxx TLS SNI
support enabled configure arguments: –with-openssl=../openssl
–with-http_ssl_module –with-http_v2_module

1
2
3
4
5
6
./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 XXX xxxx
TLS SNI support enabled
configure arguments: –with-openssl=../openssl –with-http_ssl_module –with-http_v2_module

只是,并不是装有浏览器都辅助 SNI,以下是大规模浏览器协助 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

只要要防止在不辅助 SNI 的浏览器中冒出证书错误,只好将应用不一致证书的
HTTPS 站点布局在不相同 IP 上,最简便的做法是分离安插到分歧机器上。

金沙国际 2

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 来验证。以下是本人的求证结果:

  1. ./nginx -V
  2. nginx version: nginx/1.9.9
  3. built by gcc4.8.4(Ubuntu4.8.4-2ubuntu1~14.04)
  4. built withOpenSSL1.0.2e-dev xx XXX xxxx
  5. TLS SNI support enabled
  6. configure arguments:--with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

可是,并不是怀有浏览器都援救 SNI,以下是广大浏览器辅助 SNI 的最低版本:

浏览器 最低版本
Chrome Vista+ 全支持;XP 需要 Chrome 6+;OSX 10.5.7+ 且 Chrome 5+
Firefox 2.0+
Internet Explorer 7+ (需要 Vista+)
Safari 3+ (需要 OS X 10.5.6+)
Mobile Safari iOS 4.0+
Android Webview 3.0+

可以见见,现在还有一定用户量的 Windows XP IE6~8、Android 2.x Webview
都不援救 SNI。假如要幸免在这几个浏览器中出现证书错误,只好将拔取差距证书的
HTTPS 站点布局在不一样 IP 上,最简易的做法是分别计划到分化机器上。

 

报名 Let’s Encrypt 证书时,一贯不可以验证通过

那类问题一般是因为 Let’s Encrypt
不可能访问你的服务器,推荐尝试 acme.sh 的 DNS
验证方式,一般都能化解。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图