記錄一次開啓 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包迷路了(或者直接被丟包了)