HTTPS 站中的几大难题
性能,包括:
- HTTPS需要多次握手,因此网络耗时变长,用户从HTTP跳转到HTTPS需要一些时间;
- HTTPS要做RSA校验,这会影响到设备性能;
- 所有CDN节点要支持HTTPS,而且需要有极其复杂的解决方案来面对DDoS的挑战。
其次,兼容性及周边,如:
- 页面里所有嵌入的资源都要改成HTTPS的,这些资源可能会来自不同的部门甚至不同的公司,包括图片、视频、表单等等,否则浏览器就会报警。
如何解决
- 采用了统一接入层的架构,并配备管控平台。这样的设计解决了很多问题,比如证书分散且落地不安全、软件版本难以维护、配置过多、难以标准和自动化、VIP 过多等;
- 以域名收敛的方式减少建连;
- 采用 HSTS 技术去掉 80 到 443 的 302 跳转;
- 通过 Session 复用来提高建连速度和降低服务器压力;
- 对证书链进行优化以减少证书的传输量;
- 摒弃传统的 RSA 算法,转而使用了最新的 ECDH 密钥交换算法,极大地提升了服务端的性能。
关注安全与兼容性
- 采用了双证书模式,即SHA-1和SHA-256,最大限度地保证安全和兼容性;
- 使用的是兼容性最宽泛的 OV 证书,全面支持单域名、多域名和泛域名,满足多种浏览器访问,保证最好的用户体验,当然代价也是费用较为昂贵;
- 引入泛域名 SAN 证书。
其次是一篇关于 Nginx 中 SSL 性能优化的文章《Nginx SSL 性能优化》。
密钥交换算法
常见的密钥交换算法有 RSA,ECDHE,DH,DHE 等算法。它们的特性如下:
- RSA:算法实现简单,诞生于 1977 年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是 2048 位)来保证安全强度,很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
- DH:diffie-hellman 密钥交换算法,诞生时间比较早(1977 年),但是 1999 年才公开。缺点是比较消耗 CPU 性能。
- ECDHE:使用椭圆曲线(ECC)的 DH 算法,优点是能用较小的素数(256 位)实现 RSA 相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。
- ECDH:不支持 PFS,安全性低,同时无法实现 false start。
- DHE:不支持 ECC。非常消耗 CPU 资源 。
建议优先支持 RSA 和 ECDH_RSA 密钥交换算法。原因是:
- ECDHE 支持 ECC 加速,计算速度更快。支持 PFS,更加安全。支持 false start,用户访问速度更快。
- 目前还有至少 20% 以上的客户端不支持 ECDHE,我们推荐使用 RSA 而不是 DH 或者 DHE,因为 DH 系列算法非常消耗 CPU(相当于要做两次 RSA 计算)。
更改其配置如下(参照 Nginx Performance Tuning for SSL( http://dojo.techsamurais.com/?p=1384 ):
1
2
3
4
5
|
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
|
或者
1
|
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:!ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:!RC4-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!EDH:!kEDH:!PSK:!SRP:!kECDH;
|
(禁用了RC4,sha1,MD5等算法)
辅助加速
启用SPDY
SPDY 是 Google 推出的优化 HTTP 传输效率的协议( https://www.chromium.org/spdy ), 它基本上沿用了 HTTP 协议的语义, 但是通过使用帧控制实现了多个特性,显著提升了 HTTP 协议的传输效率。
SPDY 最大的特性就是多路复用,能将多个 HTTP 请求在同一个连接上一起发出去,不像目前的 HTTP 协议一样,只能串行地逐个发送请求。
可以在编译Nginx带上参数 –with-http_spdy_module 支持 SPDY 协议,然后可在配置中启用:
1
|
listen 443 ssl spdy;
|
检测是否使用SPDY的网址( https://spdycheck.org/ )
HSTS
HSTS(HTTP Strict Transport Security)。服务端返回一个 HSTS 的 http header,浏览器获取到 HSTS 头部之后,在一段时间内,不管用户输入 www.baidu.com 还是 http://www.baidu.com ,都会默认将请求内部跳转成 https://www.baidu.com;
将下述行添加到你的 HTTPS 配置的 server 块中:
1
|
add_header Strict-Transport-Security "max-age=31536000";
|
Session cache
Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存,则直接使用已有的 session 信息提前完成握手,称为简化握手。
Session cache 有两个缺点:
- 需要消耗服务端内存来存储 session 内容。
- 目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存,不支持多机间分布式缓存,对于百度或者其他大型互联网公司而言,单机 session cache 几乎没有作用。
Session cache 也有一个非常大的优点:session id 是 TLS 协议的标准字段,市面上的浏览器全部都支持 session cache。
1
2
|
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 20m;
|
参照 Nginx 的官方文档 1MB 内存大约可以存储 4000 个 session,按例配置 20M 大约可以存储 80000。根据需求合理设置。
Ocsp stapling
Ocs