3月vivo千镜发布了《如何优化HTTPS实现访问加速》文章，介绍了HTTPS访问速度优化的一种思路：减少RTT的次数以实现对TLS握手过程的优化。在本文中，我们将继续介绍其他HTTPS优化方案：针对TCP握手的过程进行优化-TCP fast open和证书校验过程优化-OCSP Stapling。
TCP fast open简称TFO（下文均称TFO），“TCP的快速打开”是对TCP握手流程的一种优化方案，由google提出并在RFC 7413中进行叙述，此方案可以提高两端的打开速度，提高页面响应速度。原本的TCP协议是需先进行三次握手建立连接，而后传输数据，他则是在服务端与客户端建立连接的握手阶段就开始交换数据，因此可以节省1个RTT的时延达到优化HTTPS访问加速的目的。
关于TFO的实际使用中，需要注意以下几点：
1）TFO的性能优化针对的是重复连接，而非首次连接，需要TCP先经过一个3次握手获取TFOcookie（Fast Open Cookie）；
2）客户端与服务端必须同时支持TFO，且TFO最大程度上复用了TCP的API，当前是否进行TFO的标识体现在TCP报文OPTION字段的变化中。
1. 首次请求
-
客户端发送SYN包，包尾增加FOC请求，且该选项的cookie字段为空
-
服务端收到FOC后，用来源IP加密生成cookie后，加在SYN+ACK的尾部一起发回客户端
-
客户端保存cookie并发送ACK，开始数据传输
2. 后续重复请求
-
客户端发送 SYN包、之前首次握手后存储的TFOcookie（用于证明自己的身份），并携带正式发送给服务端的数据；
-
服务端验证 cookie，若验证通过，则证明客户端是之前建立连接过的“老朋友”，向其发送SYN+ACK包后，可以在收到客户端的ACK前向其发送数据包；
-
客户端发送ACK包。
注意：若第2步的cookie验证不通过则依照之前的三次握手进行正常握手交互。
服务端对客户端源IP进行AES-128算法加密生成16字节cookie，传递给客户端用作身份证明，同时服务端用于加密cookie密钥会定期循环轮换，以保证对加密IP生成的cookie的更新，防止攻击者随着时间的推移逐渐积累收集到的cookie对服务端进行攻击；由于客户端IP可能也会定期更改，生成的cookie也与以前不同，也一定程度上保证了cookie的安全性。
从上面介绍的流程可以看到，TFO 的优势在于：
对重复握手部分数据传输效率的优化：TFO利用了重连握手期间的1 个RTT提前进行数据传输，复用多次重连的这个过程积累下来也是比较大的优势，谷歌的TFO报告中证明TFO相比TCP，对于35%的http请求可以节省1个RTT[4]。
TCP SYN DDOS攻击的防御：当攻击者使用虚假IP向服务器重复SYN数据包和FOC请求，占满TFO建立连接的内存，让很多个TFO连接处于等待ACK的状态，当占用的TFO到达阈值后（管理预设），服务器将禁用TFO，使得后续TFO请求执行常规TCP握手，由TCP的防御机制去处理DDOS攻击，直到挂起的TFO超时释放到阈值以下。
因为TFO的优化思路是在SYN包中就带上数据包，那当SYN包重发的时候，就会造成接收方收到重复的数据，所以建议发送和接收方均需具有处理重复数据的能力。
同时TFO 对于内核也有一定的要求[3]：
-
IPv4在3.6（客户端）和3.7（服务端）版本中支持。IPv6在3.16版本支持；
-
Google Chrome和Chromium浏览器在Linux上提供TFO支持，包括Chrome OS和Android；
-
苹果公司的iOS 9和OS X 10.11支持TCP快速打开，但并未为各连接默认启用；
-
Microsoft Edge从Windows 10 Preview build 14352开始支持TFO。
感兴趣的小伙伴可以检查下自己的环境是否支持，去体验下TFO的优化效果。
然后我们再来看看HTTPS访问加速的另一个思路：证书优化。
如上图所示，为了证明自己的可信度，服务器会在TLS的握手过程中，将证书发给客户端，这个过程的耗时主要在于1）证书传递到客户端；2）客户端验证书的有效性这两步，那么我们就从这两个角度进行优化思考。
当客户端向服务端发起一个请求，服务端会先返回一个证书，为了加快传输的效率，必然要尽可能减少证书大小，故而可考虑优先使用ECDSA证书，而不是RSA证书。为什么呢？
RSA与ECDSA的对比
RSA是现在应用最成熟的数字签名算法，用到了初等数论中的欧拉定理，安全性依赖大整数因数分解的困难性，但因为受制于素数产生技术，导致产生密钥非常麻烦，很难一次一密，且运算代价高，速度也很慢。
ECDSA是ECC与DSA的结合，签名过程类似DSA，但签名中使用的算法为ECC，其安全性基于椭圆曲线离散对数的难解性，相同强度下，ECC160比特的长度大远小于1024比特的RSA[1]，较短的密钥也使得处理速度更快，存储空间和传输带宽占用更少。
客户端根据内置CA对服务端发来的证书中的信息进行有效性和合法性校验。但是证书状态是CA不断更新的，客户端也需要实时去获取证书合法性的最新情况，则不可避免的要向CA去请求最新的证书状态，这时候就需要OCSP（CRL缺点较多，现已基本被替代，故不多做介绍）。
OCSP（Online Certificate Status Protocol）在线证书状态协议，是一个协议状态查询的接口，主要是实现了客户端可实时请求CA服务器查询证书有效性，但是此方式会存在些实用性的问题[5]：
-
泄露隐私：由于client在OCSP要求下会直接访问CA服务器，此过程中则会泄露很大一部分用户浏览习惯等数据，这会严重损害用户的个人隐私；
-
性能负担：客户端每收到一个请求就需要联系Responder，增加了HTTP的连接数，验证证书的负担加重；
-
可靠性：线路延迟等因素在请求Responder阶段会增加整个验证流程的耗时，对于证书验证的成功率影响也变得更大；
-
安全性：因为可靠性的问题，客户端对于OCSP检测容忍失败，失败后仍会判断证书有效，若攻击者阻断了客户端对Responder的请求，就可以一直使用不合法证书进行访问。
随后就提出了OCSP stapling的概念，优化点在于：OCSP变为由web server发起，并支持在验证信息的缓存，跳过了自己验证CA的过程，极大程度上减少频繁访问的情况，提高握手效率，也提高了HTTPS的性能。
随着人们对于安全性的要求逐渐提高，HTTPS也变的越来越普及。在访问量很大的情况下，HTTPS带来的功耗、性能、响应时间等方面的影响也更容易被关注，因此这些优化就变得尤为重要。HTTPS的优化之路还很长，希望各位都能学会优化访问速度的技巧，在日常使用HTTPS时，降低对业务的影响。
参考文章
[1] 张岩,张爱丽. 数字签名算法RSA和ECDSA的比较与分析[J]. 科协论坛（下半月）,2010(2):96-97. DOI:10.3969/j.issn.1007-3973.2010.02.054.
[2] TFO那些事：https://blog.csdn.net/u014023993/article/details/85928026
[3]https://zh.wikipedia.org/wiki/TCP%E5%BF%AB%E9%80%9F%E6%89%93%E5%BC%80
[4] TCP Fast Open：http://conferences.sigcomm.org/co-next/2011/papers/1569470463.pdf
[5] OCSP stapling：https://zhuanlan.zhihu.com/p/302697430
[6]RFC7413：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43269.pdf
精彩文章推荐
关于vivo千镜安全架构的深度解析
远程锁卡，锁住你的隐私和财产
一种基于eBPF的Android系统监测方案
关于 Android任意URL跳转的这些危害你知道吗？
原文始发于微信公众号（vivo千镜）：如何优化HTTPS实现访问加速（篇二）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论