HTTPS优化与证书

时间 2019-11-10

标签 https 优化证书繁體版

原文原文链接

一、HTTPS性能优化

1.1 HTTPS性能损耗缘由

前文讨论了HTTPS原理与优点：身份验证、信息加密与完整性校验等，且未对TCP和HTTP协议作任何修改。但经过增长新协议以实现更安全的通讯必然须要付出代价，HTTPS协议的性能损耗主要体现以下：html

一、增长延时node

分析前面的握手过程，一次完整的握手至少须要两端依次来回两次通讯，至少增长延时2* RTT，利用会话缓存从而复用链接，延时也至少1* RTT*。nginx

二、消耗较多的CPU资源git

除数据传输以外，HTTPS通讯主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密须要消耗 CPU 约17核，24核CPU最多接入 HTTPS 链接 4800;github

静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，若是将全部的HTTP链接变为HTTPS链接，则明显RSA的解密最早成为瓶颈。所以，RSA的解密能力是当前困扰HTTPS接入的主要难题。web

1.2 HTTPS接入优化

一、CDN接入算法

HTTPS 增长的延时主要是传输延时 RTT，RTT 的特色是节点越近延时越小，CDN 自然离用户最近，所以选择使用 CDN 做为 HTTPS 接入的入口，将可以极大减小接入延时。CDN 节点经过和业务服务器维持长链接、会话复用和链路质量优化等可控方法，极大减小 HTTPS 带来的延时。apache

二、会话缓存小程序

虽然前文提到 HTTPS 即便采用会话缓存也要至少1*RTT的延时，可是至少延时已经减小为原来的一半，明显的延时优化;同时，基于会话缓存创建的 HTTPS 链接不须要服务器使用RSA私钥解密获取 Pre-master 信息，能够省去CPU 的消耗。若是业务访问链接集中，缓存命中率高，则HTTPS的接入能力讲明显提高。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际能够承载13k/的接入，收效很是可观。segmentfault

三、硬件加速

为接入服务器安装专用的SSL硬件加速卡，做用相似 GPU，释放 CPU，可以具备更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡能够提供35k的解密能力，至关于175核 CPU，至少至关于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡能够实现接近10台服务器的接入能力。

四、远程解密

本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则能够充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器能够选择 CPU 负载较低的机器充当，实现机器资源复用，也能够是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。

五、SPDY/HTTP2

前面的方法分别从减小传输延时和单机负载的方法提升HTTPS 接入性能，可是方法都基于不改变HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用TLS/SSL 带来的优点，经过修改协议的方法来提高HTTPS 的性能，提升下载速度等。

1.3 来源JD老司机HTTPS优化指南

1.3.1 优化1：TLS Record Size 动态调整

TLS Record 协议工做在表示层，在传输层和应用层之间提供诸如数据封包，加解密，HMAC 校验等功能，以下图:

Nginx 在创建 TLS 链接时会为每一个链接分配 Buffer 用于发送原数据（TLS Record Size，默认16KB），当服务端发送数据时，数据会被切分红 16KB 的多个块，每一个块用 MAC 签名，加上协议的元数据以及被加密后的原数据造成一个 TLS Record 结构发送到客户端，在客户端只有当协议栈接收到完整的 TLS Record 时才可以解密验证，才会向应用层提交。

因为 16KB 的包大小以及丢包等因素的影响，相对于 TCP，HTTPS 的 TTFB( Time To First Byte ) 延时较大。

TTFB 是判断网站性能的重要指标，主流浏览器都是边下载边解析渲染的，延时较大最直观的影响就是最终用户在浏览器端看到内容的速度较慢。

固然 TLS Record Size 也不能一味地变小，好比当它等于 MSS 时，变小就会有较大的头部负担，致使总体吞吐量降低。

咱们当前使用的是 TLS Record Size动态调整算法，随着 CWND 从 Initcwnd 增加到 16K，在延时和吞吐量之间达到相对平衡。

实现思路方式: 开发动态调整工具。

1.3.2 优化2: False Start

经过启用 False Start，客户端能够在 Change Cipher Spec 和 Finished 报文后当即发送应用数据，使得本来须要两次 RTT 的彻底握手变动为一次 RTT。

国内南北网络的平均延时是 50ms，这也就意味着每个地处南方的用户访问地处北方的站点，人都可节省 50ms，效果显著。

根据 RFC7918 文档，只有使用具备前向安全的秘钥交换算法以及足够强度的对称加解密算法时 False Start 才会启动。

须要注意的是，Chrome 浏览器为了解决一些特殊 SSL 服务如 SSL Terminator 硬件设备的不兼容性，要求只有和支持 NPN/ALPN 的服务端通讯才会开启 False Start。

NPN 随着 SPDY 被 HTTP/2 代替已被 Chrome 移除，而 ALPN 只在 Openssl-1.0.2 后才开始支持，加之 Openssl 新版本的 Bug 修复以及性能优化，因此若是有条件建议在服务端部署较新版本的 Openssl。

实现思路与方式:

Nginx配置以下:

ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;

参考资料: http://www.javashuo.com/article/p-nngitqez-gn.html

1.3.3 优化3: OCSP Stapling

OCSP 设计之初是 CRL(Certificate Revocation List) 的替代品，但愿经过在线实时的网络交互检查证书吊销状态，可是这个功能有点鸡肋：

暴露用户隐私，Https 旨在提升安全性和保护隐私，OCSP 显得有点背道而驰
OCSP Responder 基本在国外，并且服务能力未知，假设访问 OCSP Responder 的延时很大，或者是客户端和 OCSP Responder 的链路主动或被动地断开，客户端没法很好地肯定是否应该接受证书。

OCSP Stapling 经过服务端对 OCSP 结果的预取并把结果随着证书一块儿发给客户端，从而绕过客户端的在线验证过程，能够很好地解决上边两个问题。

咱们在本身的网站中都应该配置使用 OCSP Stapling，可是须要注意的是 OCSP Stapling 也并不是彻底能起到检查证书吊销的做用，以致于像 Chrome 浏览器就已经彻底不作证书吊销检查了。

实现思路与方式:

Nginx实现配置:

ssl_stapling on;
ssl_stapling_verify on;
resolver 223.5.5.5 223.6.6.6 valid=300s;
resolver_timeout 5s;

参考资料: http://www.jianshu.com/p/638033161329

1.3.4 优化4: HSTS

HSTS（HTTP Strict Transport Security）经过在 HTTPS Response Header 中携带 Strict-Transport-Security 来告知浏览器：之后请直接经过 HTTPS 访问我，当第二次用户在浏览器端访问 HTTP 站点，浏览器会在内部作 307 重定向，直接经过 HTTPS 访问。以下图：

经过 HSTS 能有效地避免 SSL 剥离攻击，并能减小 2 个 RTT，强烈建议配置使用。但同时也需关注首次访问的中间人攻击，以及准备回滚措施以防 HTTPS 回滚。

实现思路与方式:

Nginx实现:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY";

参考资料: http://www.ttlsa.com/nginx/http-hsts-nginx/, http://www.ttlsa.com/web/hsts-for-nginx-apache-lighttpd/

1.3.5 优化5: 会话复用

常见的会话复用有 Session ID 和 Session Ticket 两种形式，其中 Session ID 是 TLS 协议的标准字段，而 Ticket 是扩展字段，根据相关统计，Ticket 的客户端支持率只有 40% 左右。

经过会话复用，把彻底握手变动为简单握手，避免最耗时的秘钥协商阶段，能显著提高性能，以下图，客户端在发起链接时携带上一次彻底握手时服务端返回的 SessionID，服务端收到后在内存中查找缓存的会话信息并恢复加密通讯。

可是原生 Nginx 只实现了单机版本的会话复用（SSL_SESSION_CACHE 关键字），而当前咱们都习惯以集群方式部署 Nginx 来达到高可用，因此咱们经过新增 Nginx 模块以及对 Nginx 源码的少许改造，支持分布式会话复用，以下图，不管请求落到哪一台 Nginx 机器，均可以复用已缓存的会话信息。

该 Nginx 模块（ngx_ssl_session_cache_module）

已经开源，支持 Redis 和 Memcached 两种分布式缓存系统，且对 Openssl 没有任何代码依赖，欢迎使用，详见：

传送门:https://github.com/hzarch/ngx_ssl_session_cache_module.git

实现思路与方式:

简单的Nginx实现:

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;

1.3.6 优化6: 双证书

256 位 ECC 秘钥加密强度等同于 3072 位 RSA 秘钥水平且性能更高，并且秘钥更短意味着更少的存储空间，更低的带宽占用，因此对于有条件的企业建议开启 ECC & RSA 双证书支持。

对比 ECDHE_RSA、ECDHE_ECDSA 秘钥交换认证算法所需的 RSA_SIGN、ECDSA_SIGN 算法，如下是咱们在普通工做站上经过 OPENSSL SPEED 测试的性能数据，能够明显看到 ECDSA_SIGN 性能提高。

实现思路与方式:

参考资料: https://www.zeroling.com/nginx-kai-qi-https-shuang-zheng-shu-zhi-nan/

1.3.7 优化7: 对称加密优化

AES-GCM 是目前经常使用的分组加密算法，缺点是性能低以及移动端耗电量大，因此谷歌在 2014 年推出了一种新的流式加密算法 CHACHA20-POLY1350，在 ARM 平台上性能是 AES-GCM 的 3-4 倍。

Intel 从 Westmere 处理器开始支持一种新的 x86 指令扩展集 AES-NI，AES-NI 能从硬件上加速 AES 的性能，在支持 AES-NI 指令集的主机上实测 AES-GCM 性能是 CHACHA20 的 5 倍左右。

原先咱们为权衡兼容性和安全性，因此参考 Mozilla 的推荐
（https://wiki.mozilla.org/Security/Server_Side_TLS）

默认采用中档配置，该配置假设客户端不支持 AES-NI，因此 CHACHA20 优先于 AES-GCM，然而随着底层技术的发展，移动端从 ARMV8-A 架构开始逐渐支持 AES 指令集。

像经常使用的 IPhone 5S，Galaxy Note 4(Exynos)，红米 2，锤子 T2，荣耀 5X 等都是基于的 ARMV8 架构，考虑到当前互联网企业的用户都以年轻群体为主，因此咱们改变策略优先使用 AES-GCM。

实现思路与方式:

对称加密是有客户端发起，因此对于BS架构，暂无配置资料。

1.3.8 优化8: HTTP/2

HTTP/2 是 HTTP/1.1 在 1999 年发布后的首次更新，HTTP/2 带来了诸如多路复用、头部压缩、二进制分帧等特性，能大幅提高 Web 性能。

使用时可让客户端选择或经过 NPN/ALPN 动态协商是采用 HTTP/1.X over TLS 仍是 HTTP/2 over TLS，并且后端服务无需修改代码进行适配，具备比较大的灵活性。

可是也须要注意HTTP/2 并非万能的解药，使用时需对网站自己的状况作充分评估，需规避诸如为HTTP/1.X 调优而提出的域名散列等问题。

1.3.9 优化9: 加速卡

以上全部的优化都是软加速范畴，主要目的是减小 RTT，可是对于没法避免的彻底握手，服务端仍是会进行大量的加解密运算，以 ECDHE_RSA 为例，像 RSA_Sign 函数在 Intel E5-2650 V2 主机上每秒只能执行 1.2W 次左右，而此时 24 个核已全是满载状态。

CPU 向来都不适合处理大规模的浮点运算，解决这类问题性价比最高的方式无疑是采用硬件加速卡（GPU 就是其中一种），经过把加解密运算转移到加速卡来替换 Openssl 的加解密处理。

加速卡安装在主机的 PCIE 插槽内，受限于主机 PCIE 插槽数量，支持线性扩容，根据加速卡类型不一样，像 RSA_Sign 计算性能在单卡状态下都能提高 3-6 倍左右。

实现思路与方式:

硬件加速，云上没法实现。

1.3.10 优化10: 优化注释

因为没法优化浏览器端代码，当前延时只能优化到一个 RTT，若客户端私有，可参考 TLS V1.3开发 0-RTT协议。

1.3.11 优化11: 算法分离

利用软优化以及硬件加速卡，基本能知足大部分的业务场景，但这却不是最优解，咱们发现：

不一样厂家不一样型号的加速卡存在性能差别，同型号的加速卡不一样算法也存在性能差别，像咱们测试的一款 Cavium 卡，ECDHP256 和 RSA2048_Sign 存在 20% 的性能差距

Openssl-1.0.2 版本实现了更快速以及更安全的 EC_GFp_nistz256_method 方法用于 P256 曲线操做，该方法利用了 Intel AVX 扩展，性能提高显著。

在老旧的 Intel E5-2620 主机测试 Openssl-1.0.2 单核 ECDH 性能达到 8040，4 倍于 Openssl-1.0.1u，24 核全开时性能达到 9.7W，在 E5-2650 V2 上，极限性能更是达到 17.5W，远高于加速卡单卡的 5-8W。

正是因为这种差别性，咱们提出算法分离的架构，但愿充分利用硬件性能。

如上图，经过这种架构咱们把接入集群从 CPU 密集型转换成 IO 密集型，具体的算法运算，私钥存储等都在专有集群完成，极大地加强了接入集群的可扩展性。

另外经过这种架构咱们不只能够充分利用闲置的计算资源，也能够最优化 HTTPS 卸载服务的吞吐率，并且对于计算集群的增删改，咱们支持在 Web 管控端上批量修改，卸载服务会实时拉取并应用修改，此外再辅以计算集群的总体监控，极大地简化了运维复杂度。

二、Https调优压测

任何压力都没法彻底模拟线上正常环境，随此处仅供参考。

环境说明:

IP	配置	带宽	域名	网站类型	服务器坐标
120.76.121.45	1核2G	1M	ssl.saevan.com	纯静态html	广东省深圳市

办公网环境: 坐标青岛，电信联通双线。

压测软件: AB

原网站ab吞吐.

[root@evan-node-1 ~]# ab -n100 -c20 http://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            80

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20  `
Time taken for tests:   14.422 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1432500 bytes
HTML transferred:       1409100 bytes
Requests per second:    6.93 [#/sec] (mean)
Time per request:       2884.332 [ms] (mean)
Time per request:       144.217 [ms] (mean, across all concurrent requests)
Transfer rate:          97.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       42   46   2.9     45      60
Processing:    97 2658 1938.3   1910   12252
Waiting:       43   59  77.7     46     641
Total:        145 2703 1938.7   1961   12302

Percentage of the requests served within a certain time (ms)
  50%   1961
  66%   2883
  75%   3339
  80%   4162
  90%   5345
  95%   6364
  98%   8385
  99%  12302
 100%  12302 (longest request)

配置RSA证书后，未进行优化结果:

[root@evan-node-1 ~]# ab -n100 -c20 https://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20
Time taken for tests:   18.004 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1432500 bytes
HTML transferred:       1409100 bytes
Requests per second:    5.55 [#/sec] (mean)
Time per request:       3600.891 [ms] (mean)
Time per request:       180.045 [ms] (mean, across all concurrent requests)
Transfer rate:          77.70 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      142  602 585.7    403    3993
Processing:   378 2493 2099.5   1854   10143
Waiting:      374 2493 2099.7   1854   10143
Total:        520 3095 2173.7   2448   11135

Percentage of the requests served within a certain time (ms)
  50%   2448
  66%   3007
  75%   3786
  80%   4304
  90%   5531
  95%   9210
  98%  10532
  99%  11135
 100%  11135 (longest request)

优化Https后：

优化选项有:False Start、OCSP Stapling、HSTS、会话复用；

[root@evan-node-1 ~]# ab -n100 -c20 https://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20
Time taken for tests:   17.801 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1441200 bytes
HTML transferred:       1409100 bytes
Requests per second:    5.62 [#/sec] (mean)
Time per request:       3560.120 [ms] (mean)
Time per request:       178.006 [ms] (mean, across all concurrent requests)
Transfer rate:          79.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      138  440 395.2    382    2155
Processing:    91 2742 2360.6   2000   15302
Waiting:       89 2742 2360.6   2000   15302
Total:        231 3182 2409.8   2468   15457

Percentage of the requests served within a certain time (ms)
  50%   2468
  66%   3082
  75%   3453
  80%   4480
  90%   7026
  95%   8385
  98%   9550
  99%  15457
 100%  15457 (longest request)

最终第三方对于SSL配置优化的评分

三、CA证书类型

3.1 SSL证书类型

基础级SSL证书（域名型DV SSL），即只对域名的全部者（通常是域名管理员邮箱，好比admin@hotmail.com）进行在线检查，发送验证邮件给域名管理员或以该域名结尾的邮箱，至于该域名的管理员是真实注册的单位仍是另有其人，不得而知了。

专业级SSL证书（IV SSL），会对域名全部权和证书申请人的真实身份进行验证的专业级SSL证书适用于我的专业网站。

企业级 SSL 证书（OV SSL），是要购买者提交组织机构资料和单位受权信等在官方注册的凭证，认证机构在签发SSL证书前不只仅要检验域名全部权，还必须对这些资料的真实合法性进行多方查验，只有经过验证的才能颁发SSL证书。

SSL 证书（EV SSL），与其余SSL证书同样，都是基于SSL/TLS安全协议，都是用于网站的身份验证和信息在网上的传输加密。它跟普通SSL证书的区别也是明显的，安全浏览器的地址栏变绿，若是是不受信的SSL证书则拒绝显示，若是是钓鱼网站，地址栏则会变成红色，以警示用户。

3.2 经常使用证书加密算法

ECC:参考资料: https://www.wosign点com/ecc/，主要用于移动端

RSA:就是咱们经常使用的证书类型

四、总结

现在，全世界都对HTTPS抛出了橄榄枝：

a)微信小程序要求全部的请求必须是 HTTPS 请求

b)苹果要求全部 IOS App 2016 年末强制使用 HTTPS 加密，虽然该计划暂时被延期

c)百度、谷歌优先收录 HTTPS 站点，相同权值的站点 HTTPS 排名靠前

d)Chrome 浏览器对 HTTP 页面提出警告，以下图，当前为中性警告，即默认状况下只有当 HTTP 页面检测到密码或信用卡字段时才会提示不安全，但同时 Chrome 也明确表示，该计划将会愈来愈严格，最终会对全部 HTTP 页面提示不安全。

经过目前软优化没法最根本解决压力问题，但以目前现状，咱们尚未升级到压力问题，经过基础GET压测，并未有大幅度明显性能降低（一切测试都不能彻底模拟整个生产环境）,所需根据需求先上迭代，是如今增长HTTPS的一个好的渠道。