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