记录一次开启 OCSP stapling 解决app内webview加载慢的问题

发现问题的过程

开始

• 咱们有个app,实质是webview打个壳
• 测试发如今某些ios的机器上启动app特别慢
• 在安卓上没有问题,在电脑上用浏览器打开也没问题
• 并且跟ios的机型好像也不要紧,部分ios设备特别慢

问题提交给app的开发人员

• 具体测试发现使用http的时候没有问题,使用https就会有问题

接着测试 http2

• 第一个怀疑是http2的问题,由于以前好像曾经有过这个经历.并且在http下是不会使用http2的
• 实验 服务器关闭tls下的http2 ,结果问题还在,排除http2的问题

测试nginx的tls配置

• 怀疑多是nginx某些tls的配置致使的问题,改了各类配置例如ssl_prefer_server_ciphers ssl_ciphers ssl_ecdh_curve 都是一些TLS的密钥交换群和密钥交换算法的配置,都无效

进一步惊人的发现

• 由于咱们办公室的wifi使用的是电信的网络,有些测试的手机用的也是电信的卡
• 当使用移动的手机分享热点并给有bug的手机连上以后,问题就解决了,而且有bug的手机在切换回办公室wifi或者电信网络也没有什么问题

猜想

• 猜想是TLS握手过程须要访问某个url,可是在电信下会有问题

抓包

• 对有bug的手机进行抓包,发现了app打开的过程当中会去访问 http://ocsp.int-x3.letsencrypt.org 而且很是的慢

准备解决问题

查找资料

• 首先是https的过程,能够参考https://juejin.im/post/5ea06953f265da47e159581e

证书的验证

• 在TLS的握手的过程当中,服务器把本身的证书给客户端之后,客户端须要验证服务器的证书有效
• 通常采用证书链的方式,通常的网站证书是由CA签发的,而CA的证书是由更高级的CA签发的,最高级的证书通常内置在操做系统和浏览器中,被称做根证书,根证书是被无条件信任的
• 这整个链条组成了证书信任链,最后只要在本机中找到根证书,就能确认网站的证书是能够信任的
• 通常为了快速的认证,网站给客户端提供证书的时候,会把整个证书链的证书都一块儿给.这样客户端不须要额外的网络请求,只须要验证一下,每一个证书是否过时,是否由上一级证书签名,而且本身本机有没有对应的根证书便可

• 例如咱们网站的证书链是这样的

DST Root CA X3
⤵
Let's Encrypt Authority X3 ⤵ 咱们网站的证书 复制代码

信任链的问题

• 可是证书信任链条有个问题,一旦证书被签发.证书就会被信任,哪怕证书被泄露或者是被滥用
• 为了解决这个问题,加入了证书吊销的操做,因而就有了查询证书吊销的协议 OCSP
• OCSP协议的介绍能够查看wiki https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol

OCSP的问题

• 能够在wiki中看到,OCSP也是有他的问题

1. 隐私问题

• OCSP检查为某些用户带来了隐私问题，由于它要求客户端与第三方（尽管客户端软件供应商信任的一方）联系以确认证书的有效性。

2. 性能问题

• 客户端在TLS握手前须要访问OCSP的检查url,形成阻塞

浏览器的支持

• 能够在wiki中看到
• 大多数主要浏览器对OCSP都有普遍的支持：

1. Internet Explorer的是创建在CryptoAPI的的的Windows从而与首发7版本的Windows Vista中（不是XP [7] ）支持OCSP检查。[8]
2. Mozilla Firefox的全部版本均支持OCSP检查。Firefox 3默认状况下启用OCSP检查。[9]
3. macOS上的Safari支持OCSP检查。从Mac OS X 10.7（Lion）开始默认启用。在此以前，必须先在“钥匙串”偏好设置中手动激活它。[10]
4. Opera 从8.0开始支持OCSP检查
5. Google Chrome 特立独行,Chrome在2012年就禁止了OCSP检查,理由是延迟和隐私问题.取而代之的是使用自身的方法检查证书的撤销问题.

• 这就是为何在安卓上不会有问题,而在电脑上,若是你使用的是chrome也不会有这个问题

OCSP问题的解决方案OCSP stapling

• OCSP stapling说白了就是由服务器去请求OCSP信息,而且在握手阶段提供给客户端,使得客户端不须要再去查询OCSP信息
• 这样在客户端TLS握手的时候不须要再去额外请求一个OCSP查询,也就不会被阻塞

问题的解决和分析

• 在nginx的配置中开启 OCSP stapling

ssl_stapling on;
ssl_stapling_verify on;
resolver 223.5.5.5; #resolver即为dns服务器,必须指定,不然nginx没法解析OCSP的域名,服务器在国内可使用 223.5.5.5 或者 114.114.114.114 ,服务器在国外可使用8.8.8.8 或者 1.1.1.1
复制代码

• 也能够自行下载OCSP返回并配置上

ssl_stapling               on;
ssl_stapling_verify        on;
ssl_trusted_certificate    /your/path/to/chained.pem;
复制代码

• 具体过程本身google(baidu)

而后问题解决

关于 ocsp.int-x3.letsencrypt.org

• 由于咱们使用的是Let's Encrypt Authority X3的证书,因此查询OCSP的域名就是 http://ocsp.int-x3.letsencrypt.org
• 按道理来讲,哪怕服务器不配置OCSP stapling,那么客户端应该会自行去查询OCSP,虽然可能会慢一点,应该也不会这么慢才是

traceroute

• 在电脑上直接访问ocsp.int-x3.letsencrypt.org,会发现有时候访问不了,有时候访问很慢
• 直接traceroute该域名获得如下结果

traceroute to a771.dscq.akamai.net (69.171.242.30), 64 hops max, 72 byte packets
 1  192.168.20.1 (192.168.20.1)  0.600 ms  0.341 ms  0.338 ms
 2  115.196.136.1 (115.196.136.1)  2.218 ms  3.241 ms  4.372 ms
 3  61.164.12.206 (61.164.12.206)  2.465 ms  2.318 ms  2.648 ms
 4  61.164.22.141 (61.164.22.141)  3.861 ms  3.106 ms  4.270 ms
 5  202.97.26.13 (202.97.26.13)  11.297 ms  12.619 ms  7.708 ms
 6  202.97.57.157 (202.97.57.157)  5.853 ms * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
复制代码

• 在第6跳之后,就没有消息了

• 查询202.97.57.157,为电信在上海的骨干交换网ip

• 而若是网络是移动,就正常

• 初步诊断,缘由是由于电信错误的路由策略,致使发往69.171.242.30包迷路了(或者直接被丢包了)