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 ）：

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 有两个缺点：

1. 须要消耗服务端内存来存储 session 内容。
2. 目前的开源软件包括 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

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

查看OSCP验证服务器地址：

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

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

请求 OSCP 证书

1 2 3 4

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

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

1 2 3

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” ，没问题后就能够直接保存下来证书文件，完整的命令以下：

1 2 3 4

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 中配置变成了这样子：

1 2 3 4

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

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

1	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证书。

总结：（所有优化参数）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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