百度HTTPS性能优化经验

Posted AIOps智能运维

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了百度HTTPS性能优化经验相关的知识,希望对你有一定的参考价值。

前言

上文讲到HTTPS对用户访问速度的影响。今天将为大家介绍百度在访问速度、计算性能、安全等方面对HTTPS进行优化的经验方法。

HTTPS访问速度优化


1TCP Fast Open

HTTPS和HTTP使用TCP协议进行传输,也就意味着必须通过三次握手建立TCP连接,但一个RTT的时间内只传输一个syn包是不是太浪费?能不能在syn包发出的同时捎上应用层的数据?其实是可以的,这也是TCP Fast Open的思路,简称TFO。具体原理可以参考RFC7413。

TFO对于系统版本有一定的要求,TFO的IPv4支持在3.6(客户端)和3.7(服务端)版本中被合并进Linux内核主线,从3.13版本开始默认打开。IPv6服务器的TFO支持被合并进入3.16版本。Microsoft Edge从Windows10 Previewbuild14352开始支持TFO。

2HSTS

在系列文章的第一篇中,我们提到过用户的HTTP请求会被302跳转到HTTPS,这会有两个影响:

  1. 不安全,302跳转不仅暴露了用户的访问站点,也很容易被中间者劫持。

  2. 降低访问速度,302跳转不仅需要一个RTT,浏览器执行跳转也需要执行时间。

由于302跳转事实上是由浏览器触发的,服务器无法完全控制,这个需求导致了HSTS的诞生。

HSTS(HTTP Strict Transport Security)的作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接。服务端返回一个HSTS的HTTP Header,浏览器获取到HSTS头部之后,在一段时间内,不管用户输入www.baidu.com还是http://www.baidu.com,都会默认将请求内部跳转成https://www.baidu.com。Chrome,Firefox,IE,EDGE等常见浏览器都支持了HSTS(http://caniuse.com/#feat=stricttransportsecurity)。

3Session Resume

Session Resume顾名思义就是复用Session,实现简化握手。复用Session的好处有两个:

  1. 减少了CPU消耗,因为不需要进行非对称密钥交换的计算。

  2. 提升访问速度,不需要进行完全握手阶段二,节省了一个RTT和计算耗时。

TLS协议目前提供两种机制实现Session Resume,分别介绍一下。

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

百度通过对TLS握手协议及服务器端实现的优化,已经支持全局的Session Cache,能够明显提升用户的访问速度,节省服务器计算资源。

2
Session Ticket

上节提到了Session Cache的两个缺点,Session Ticket能够弥补这些不足。

Session Ticket的原理参考RFC4507。简述如下:

Server将Session信息加密成Ticket发送给浏览器,浏览器后续握手请求时会发送Ticket,Server端如果能成功解密和处理Ticket,就能完成简化握手。

显然,Session Ticket的优点是不需要服务端消耗大量资源来存储Session内容

Session Ticket的缺点:

  • Session Ticket只是TLS协议的一个扩展特性,目前的支持率不是很广泛,只有60%左右。

  • Session Ticket需要维护一个全局的key来加解密,需要考虑key的安全性和部署效率。

总体来讲,Session Ticket的功能特性明显优于Session Cache。希望客户端实现优先支持Session Ticket。

4OCSP Stapling

OCSP全称在线证书状态检查协议(RFC 6960),用来向CA站点查询证书状态,比如是否撤销。通常情况下,浏览器使用OCSP协议发起查询请求,CA返回证书状态内容,然后浏览器接受证书是否可信的状态。

这个过程非常消耗时间,因为CA站点有可能在国外,网络不稳定,RTT也比较大。那有没有办法不直接向CA站点请求OCSP内容呢?OCSP Stapling就能实现这个功能。

OSCP Stapling工作原理简单来说就是浏览器发起Client Hello时会携带一个certificate status request的扩展,服务端看到这个扩展后将OCSP内容直接返回给浏览器,完成证书状态检查。由于浏览器不需要直接向CA站点查询证书状态,这个功能对访问速度的提升非常明显。关于OCSP Stapling的详细介绍可参考RFC6066第8节。

Nginx目前已经支持OCSP Stapling File,只需要配置OCSP Stapling File的指令就能开启这个功能:

ssl_staplingon;

ssl_stapling_fileocsp.staple;

5False Start

通常情况下,应用层数据必须等完全握手全部结束之后才能传输。这样比较浪费时间,那能不能类似TFO一样,在完全握手的第二个阶段将应用数据一起发出来呢?Google提出了False Start来实现这个功能,详细介绍参考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。

简单概括False Start的原理就是在client_key_exchange发出时将应用层数据一起发出来,能够节省一个RTT。

False Start依赖于PFS(perfect forward secrecy,完美前向加密),而PFS又依赖于DHE密钥交换系列算法(DHE_RSA,ECDHE_RSA,DHE_DSS,ECDHE_ECDSA),所以尽量优先支持ECDHE密钥交换算法实现FalseStart。

6试用SPDY或者HTTP2

SPDY是Google推出的优化HTTP传输效率的协议(https://www.chromium.org/spdy),它基本上沿用了HTTP协议的语义,但是通过使用帧控制实现了多个特性,显著提升了HTTP协议的传输效率。

SPDY最大的特性就是多路复用,能将多个HTTP请求在同一个连接上一起发出去,不像目前的HTTP协议一样,只能串行地逐个发送请求。Pipeline虽然支持多个请求一起发送,但是接收时依然得按照顺序接收,本质上无法解决并发的问题。

HTTP2是IETF2015年2月份通过的HTTP下一代协议,它以SPDY为原型,经过两年多的讨论和完善最终确定。

本文就不过多介绍SPDY和HTTP2的收益,需要说明两点:

  • SPDY和HTTP2目前的实现默认使用HTTPS协议

  • SPDY和HTTP2都支持现有的HTTP语义和API,对WEB应用几乎是透明的。

HTTPS计算性能优化


1优先使用ECC

ECC椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是NIST推荐的密钥长度对照表。

表1  NIST推荐使用的秘钥长度

百度HTTPS性能优化经验

对于RSA算法来讲,目前至少使用2048位以上的密钥长度才能保证安全性。ECC只需要使用224位长度的密钥就能实现RSA2048位长度的安全强度,在进行相同的模指数运算时速度显然要快很多。

2使用最新版的OpenSSL

一般来讲,新版的OpenSSL相比老版的计算速度和安全性都会有提升。比如OpenSSL1.0.2采用了Intel最新的优化成果,椭圆曲线p256的计算性能提升了4倍。(https://eprint.iacr.org/2013/816.pdf)

OpenSSL2014年就升级了5次,基本都是为了修复实现上的BUG或者算法上的漏洞而升级的,所以尽量使用最新版本,避免安全上的风险。

3硬件加速方案

现在比较常用的TLS硬件加速方案主要有两种:

  1. SSL专用加速卡

  2. GPUSSL加速

上述两个方案的主流用法都是将硬件插入到服务器的PCI插槽中,由硬件完成最消耗性能的计算。但这样的方案有如下缺点:

  1. 支持算法有限。比如不支持ECC,不支持GCM等。

  2. 升级成本高

    1. 出现新的加密算法或者协议时,硬件加速方案无法及时升级。

    2. 出现比较大的安全漏洞时,部分硬件方案在无法在短期内升级解决。比如2014年暴露的Heartbleed漏洞。

  3. 无法充分利用硬件加速性能。硬件加速程序一般都运行在内核态,计算结果传递到应用层需要IO和内存拷贝开销,即使硬件计算性能非常好,上层的同步等待和IO开销也会导致整体性能达不到预期,无法充分利用硬件加速卡的计算能力。

  4. 维护性差。硬件驱动及应用层API大部分是由安全厂家提供,出现问题后还需要厂家跟进。用户无法掌握核心代码,比较被动。不像开源的OpenSSL,不管算法还是协议,用户都能掌握。

4TLS远程代理计算

也正是因为上述原因,百度实现了专用的SSL硬件加速集群。基本思路是:

  1. 优化TLS协议栈,剥离最消耗CPU资源的计算,主要有如下部分:

    1. RSA中的加解密计算。

    2. ECC算法中的公私钥生成。

    3. ECC算法中的共享密钥生成。

  2. 优化硬件计算部分。硬件计算不涉及协议及状态交互,只需要处理大数运算。

  3. Web Server到TLS计算集群之间的任务是异步的,即Web Server将待计算内容发送给加速集群后,依然可以继续处理其他请求,整个过程是异步非阻塞的。

HTTPS安全配置

1协议版本选择

SSL 2.0早就被证明是不安全的协议,统计发现目前已经没有客户端支持SSL 2.0,所以可以放心地在服务端禁用SSL 2.0协议。

2014年爆发了POODLE攻击,SSL 3.0因此被证明是不安全的。但是统计发现依然有0.5%的流量只支持SSL 3.0。所以只能有选择地支持SSL 3.0。

TLS 1.1及1.2目前为止没有发现安全漏洞,建议优先支持。

2加密套件选择

加密套件包含四个部分:

  1. 非对称密钥交换算法。建议优先使用ECDHE,禁用DHE,次优先选择RSA。

  2. 证书签名算法。由于部分浏览器及操作系统不支持ECDSA签名,目前默认都是使用RSA签名,其中SHA1签名已经不再安全,Chrome及微软从2016年开始不再支持SHA1签名的证书(http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。

  3. 对称加解密算法。优先使用AES-GCM算法,针对1.0以上协议禁用RC4(RFC7465)。

  4. 内容一致性校验算法。MD5和SHA1都已经不安全,建议使用SHA2以上的安全哈希函数。

3HTTPS防攻击

1
防止协议降级攻击

降级攻击一般包括两种:加密套件降级攻击(Cipher Suite Rollback)和协议降级攻击(Version Rollback)。降级攻击的原理就是攻击者伪造或者修改Client Hello消息,使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。

为了应对降级攻击,现在Server端和浏览器之间都实现了Signaling Cipher Suite Value(SCSV)功能,原理参考https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。

简单来说就是如果客户端想要降级,必须发送TLS_SCSV的信号,服务器如果看到TLS_SCSV,就不会接受比服务端最高协议版本低的协议。

2
防止重新协商攻击

重新协商(TLS Renegotiation)分为两种:加密套件重协商(Cipher Suite Renegotiation)和协议重协商(Protocol Renegotiation)。

重新协商会有两个隐患:

  1. 重协商后使用弱的安全算法。这样的后果就是传输内容很容易泄露。

  2. 重协商过程中不断发起完全握手请求,触发服务端进行高强度计算并引发服务拒绝。

对于重协商,最直接的保护手段就是禁止客户端主动重协商,当然出于特殊场景的需求,应该允许服务端主动发起重协商。

总  结

HTTPS的实践和优化涉及到了非常多的知识点,由于篇幅关系,本文对很多优化策略只是简单介绍了一下,如果想要了解协议背后的原理,还是需要详细阅读TLS协议及PKI知识。对于大型站点来说,如果希望做到极致,HTTPS的部署需要结合产品和基础设施的架构来进行详细的考虑,比起部署支持HTTPS的接入和对它的优化,在产品和运维层面上花费的功夫会更多。本系列的下一篇文章将对此进一步进行介绍。

文章整理自百度HTTPS技术联合团队

↓↓↓ 点击"阅读原文" 【了解更多精彩内容】 

以上是关于百度HTTPS性能优化经验的主要内容,如果未能解决你的问题,请参考以下文章

浅谈Vue 项目性能优化 经验

全面解析Android性能优化,含腾讯阿里百度京东美团爱奇艺等大厂实战解析

MYSQL性能优化的最佳20+条经验

ELK性能优化实战总结:Java大厂74道高级面试合集

MySQL 性能优化的最佳20多条经验分享

Unity技术支持团队性能优化经验分享