BLOG
Enjoy when you can, and endure when you must.
MAR 27, 2016/平台与系统运维
HTTPS 站点的性能优化

最近比较多的了解了一下关于 SSL 与性能优化相关的知识,收集了以下两篇文章作为记录并做了部分或全部转载。

如需转载此文,请注明原作者。

第一篇是在阿里云上发现的文章《淘宝全站 HTTPS 百万页面改造技术细节大起底》,其中提到了以下几个方面:

HTTPS 站中的几大难题

性能,包括:

  1. HTTPS需要多次握手,因此网络耗时变长,用户从HTTP跳转到HTTPS需要一些时间;
  2. HTTPS要做RSA校验,这会影响到设备性能;
  3. 所有CDN节点要支持HTTPS,而且需要有极其复杂的解决方案来面对DDoS的挑战。

其次,兼容性及周边,如:

  1. 页面里所有嵌入的资源都要改成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 ):

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;

或者

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 协议,然后可在配置中启用:

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 块中:

add_header Strict-Transport-Security "max-age=31536000";

Session cache

Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存,则直接使用已有的 session 信息提前完成握手,称为简化握手。

Session cache 有两个缺点:

  1. 需要消耗服务端内存来存储 session 内容。
  2. 目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存,不支持多机间分布式缓存,对于百度或者其他大型互联网公司而言,单机 session cache 几乎没有作用。

Session cache 也有一个非常大的优点:session id 是 TLS 协议的标准字段,市面上的浏览器全部都支持 session cache。

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 20m;

参照 Nginx 的官方文档 1MB 内存大约可以存储 4000 个 session,按例配置 20M 大约可以存储 80000。根据需求合理设置。

Ocsp stapling

Ocsp 全称在线证书状态检查协议 (rfc6960),用来向 CA 站点查询证书状态,比如是否撤销。通常情况下,浏览器使用 OCSP 协议发起查询请求,CA 返回证书状态内容,然后浏览器接受证书是否可信的状态。 将证书保存下来,浏览器请求时候直接通过自己的服务器发送回去,防止验证服务器出问题,还能加快访问速度。

查看OSCP验证服务器地址:

openssl x509 -in 1_test.qupeiyin.net_bundle.crt  -text

在输出的文字中找到 OCSP - URI: ,后面的 URL 就是 OSCP 的验证服务器地址。

请求 OSCP 证书

openssl ocsp -noverify \
-issuer /certificate-path/trustchain.crt \
-cert /certificate-path/trustchain.crt \
-url http://ocsp1.wosign.com/ca6/server1

不出意外会收到如下的结果

trustchain.crt: good        
    This Update: Oct 18 17:59:10 2014 GMT        
    Next Update: Oct 18 23:59:10 2014 GMT

如果出现 403 错误,那就需要在 Header 请求头加上域名参数如 -header “HOST” “ocsp2.globalsign.com” ,没问题后就可以直接保存下来证书文件,完整的命令如下:

openssl
ocsp -noverify  -issuer 1_root_bundle.crt
-cert 1_root_bundle.crt -url http://ocsp1.wosign.com/ca6/server1  -header "HOST"
"ocsp1.wosign.com" -text -respout ./stapling_file.ocsp

将保存下来的 stapling_file.ocsp 证书添加到 nginx 的配置中,如下,Nginx 中配置变成了这样子:

ssl_stapling on;
ssl_stapling_verify on;
ssl_stapling_file /stapling_file.ocsp;
ssl_trusted_certificate /certificate-path/trustchain.crt;

这样子重启 Nginx 后就会生效,可以使用下面的命令测试生效结果:

echo QUIT | openssl s_client -connect blog.alphatr.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

看到 OCSP Response Status: successful 这样的字样就是成功了。

ocsp证书有效期很短,大概不到一个月,所以过段时间要更新 ocsp 证书,不然还是会验证失败。需要用脚本定时更新OCSP证书。

总结:(全部优化参数)

ssl on;
ssl_certificate /data/www/ssl/ssl.crt;
ssl_certificate_key /data/www/ssl/ssl.key;
ssl_trusted_certificate /data/www/ssl/trustchain.crt;
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_stapling on;
ssl_stapling_verify on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
add_header Strict-Transport-Security "max-age=31536000";
resolver 223.5.5.5 223.6.6.6 valid=300s;
resolver_timeout 10s;
error_page 497 https://$host$request_uri;

参数详解:

ssl on  开启SSL

ssl_certificate  对应单张证书

ssl_certificate_key  对应私钥

ssl_trusted_certificate  对应信任链(即Startcom SSL或者Positive SSL中需要附加到单张证书后面的那两张证书,可以独立出来)

ssl_protocols  支持的SSL协议标准(nginx默认参数为:ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;)

ssl_ciphers  (nginx默认参数为:ssl_ciphers HIGH:!aNULL:!MD5;)

ssl_prefer_server_ciphers On;  指定服务器密码算法在优先于客户端密码算法时,使用SSLv3和TLS协议。

error_page 497 https://$host$request_uri;  通过497错误将http转跳到https

COMMENTS
LEAVE COMMNT