緣起

偶刷《長安十二時(shí)辰》，午睡時(shí)，夢到我穿越到了唐朝，在長安城中的靖安司，做了一天的靖安司司丞。當(dāng)徐賓遇害消失的時(shí)候我不在司內(nèi)，當(dāng)時(shí)的情形我不得而知。

后來徐賓醒了，據(jù)他描述說“通傳陸三”是暗樁，險(xiǎn)些致徐賓于死地。而擅長大案牘術(shù)的高智商人才居然被一個(gè)普通通傳的幾句話騙至險(xiǎn)境，實(shí)在丟了我的臉。陸三是通傳，熟知靖安司的號令傳遞系統(tǒng)望樓信號，他是暗樁的消息，傳遍整個(gè)機(jī)構(gòu)。這讓張小敬和姚汝能認(rèn)為望樓系統(tǒng)已無法完成消息保密傳送的功能，其實(shí)他們根本不了解這望樓。

[[315602]]

整個(gè)望樓系統(tǒng)由“傳遞系統(tǒng)+加密系統(tǒng)”組成，靖安司作為一個(gè)軍事級別的機(jī)構(gòu)，信息傳遞絕對是多重加密的。只看懂望樓圖案，或者只有密碼本都是破譯不了密碼的，對于通傳陸三是暗樁的影響，也只需要更換密碼本即可。

這些可是我學(xué)了RSA非對稱加密后設(shè)計(jì)的望樓系統(tǒng)，早就評估過這些風(fēng)險(xiǎn)了。即使HTTPS通訊中，丟了密鑰也…嗯?如果HTTPS證書私鑰丟了，會怎樣?是不是也沒法防范這個(gè)私鑰被利用了?想到這個(gè)問題，我突然從夢中驚醒，去溫故一下證書吊銷機(jī)制。

疑問

• HTTPS的證書過期是誰來判斷?
• 證書的合法性又是誰檢查的呢?
• 什么時(shí)候觸發(fā)?
• 影響性能嗎?
• 如何吊銷證書?
• HTTPS的請求是客戶端(瀏覽器)發(fā)起的，他是如何知道證書被吊銷的?
• 驗(yàn)證HTTPS證書的過程是什么樣的?

HTTPS通訊過程

大家都清楚，HTTPS的握手是在TCP握手完成后，流程都熟的很，但還是要溫故一下：

• 第一個(gè)階段，完成 Client Hello、Server Hello等握手。包含使用SSL版本、服務(wù)器和客戶端的隨機(jī)數(shù)、密碼套件、數(shù)據(jù)壓縮等參數(shù)響應(yīng)。
• 第二階段，服務(wù)端把域名證書的公鑰下發(fā)給瀏覽器(客戶端)，瀏覽器(客戶端)校驗(yàn)證書合法性。
• 第三階段，客戶端把自己的證書發(fā)送給服務(wù)端(證書登陸的情況下)，服務(wù)端檢測客戶端證書等。
• 第四階段，完成密鑰協(xié)商、對稱加密密鑰交換。

簡稱解釋：RN: Random Number;PMS: Pre Master Secret;MS: Master Secret

對于第二階段中的證書檢驗(yàn)這塊，相信很多人都不太了解，甚至都不知道會檢驗(yàn)什么內(nèi)容，那么下面我們就來了解一下。

證書完整性驗(yàn)證

使用RSA公鑰解密來驗(yàn)證證書上的私鑰簽名是否合法，如果簽名無效，則可認(rèn)定證書被修改，直接報(bào)錯(cuò)。

證書有效性驗(yàn)證

CA在頒發(fā)證書時(shí)，都為每個(gè)證書設(shè)定了有效期，包括開始時(shí)間與結(jié)束時(shí)間。系統(tǒng)當(dāng)前時(shí)間不在證書起止時(shí)間的話，都認(rèn)為證書是無效的。

證書吊銷狀態(tài)檢測

如果，證書在有效期之內(nèi)需要丟了怎么辦?需要吊銷證書了，那么這里就多了一個(gè)證書吊銷狀態(tài)的檢測。用戶將需要吊銷的證書通知到CA服務(wù)商，CA服務(wù)商通知瀏覽器該證書的撤銷狀態(tài)。來看一個(gè)證書吊銷后的瀏覽器提醒：

Chrome返回了NET::ERR_CERT_REVOKED，并且拒絕繼續(xù)訪問，更不提供強(qiáng)制訪問的接口，沒了繼續(xù)訪問的手動點(diǎn)擊鏈接。

驗(yàn)證發(fā)行者

HTTPS數(shù)字證書的使用分兩個(gè)角色：

• 證書發(fā)行方issuer，有簽名密鑰的私鑰。
• 證書申請方subject，使用證書公鑰進(jìn)行身份驗(yàn)證的用戶 瀏覽器檢查證書的發(fā)行者字段與證書路徑中上級證書的subject字段相同。

為了增加安全性，PKI在實(shí)現(xiàn)時(shí)，多數(shù)都驗(yàn)證了發(fā)型方的密鑰、簽名等信息是否跟當(dāng)前證書的密鑰相同。但對于信任鏈來說，根證書自己簽發(fā)的，也就是說它們的issuer和subject是一樣的。

同時(shí)，這些CA根證書都是被操作系統(tǒng)、瀏覽器等直接打入系統(tǒng)的。比如：

檢查域名(IP)規(guī)范

中間CA提供了對域名證書的管理以及頒發(fā)的顆粒度度控制。證書的生效范圍會限于固定域名、域名范圍(包括子域)或者固定IP。比如下圖是https://www.baidu.com的HTTPS證書DNS信息。

上圖所示，DNS范圍包含了多個(gè)域名，同時(shí)二級以及二級以上域名都支持范圍形式。以通配義字符表示。但.example.com的二級域名范圍就不能包含a.b.example.com這個(gè)三級域名。同時(shí)，DNS范圍也支持IP的，只是IP不支持范圍形式，必須把所有IP列表都放入列表中。

檢查策略約束

法律策略相關(guān)檢測(略)。

證書的吊銷狀態(tài)檢測方式

上面提到了瀏覽器(客戶端)在驗(yàn)證證書合法性時(shí)的驗(yàn)證范圍，我們暫時(shí)只關(guān)注證書吊銷信息的檢測，下面我們仔細(xì)來了解一下兩種檢測機(jī)制的實(shí)現(xiàn)原理。

1. Certificate Revocation Lists (CRL)

CA會定期更新發(fā)布撤銷證書列表，Certificate Revocation Lists (以下簡稱CRL)，RFC 5280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile。

CRL分布在公共可用的存儲庫中，瀏覽器可以在驗(yàn)證證書時(shí)獲取并查閱CA的最新CRL。

該方法的一個(gè)缺陷是撤銷的時(shí)間粒度限于CRL發(fā)布期。只有在計(jì)劃更新所有當(dāng)前發(fā)布的CRL之后，才會通知瀏覽器撤銷。各家簽名CA廠商的策略不一樣，有的是幾小時(shí)，有的是幾天，甚至幾周。2015年，美國幾所大學(xué)的學(xué)生論文中，統(tǒng)計(jì)了當(dāng)時(shí)的CA證書吊銷情況，如下圖：

這個(gè)統(tǒng)計(jì)可以看出，CA證書廠商的CRL數(shù)量不一，大部分是30-50個(gè)，而GoDaddy有300多個(gè)CRL的地址，同時(shí)有近30W個(gè)證書是吊銷狀態(tài)的，文件大小平均達(dá)到了1M。

證書的CRL信息

CRL信息是CA在頒發(fā)證書時(shí)，寫入在X.509 v的擴(kuò)展區(qū)域的，比如alipay.com的證書信息：

可以看到，其CRL信息為：

• http://crl3.digicert.com/SecureSiteCAG2.crl
• http://crl4.digicert.com/SecureSiteCAG2.crl

(2) CRL 檢測流程

可以想象一下，在瀏覽器去校驗(yàn)證書合法性時(shí)，還要去下載一個(gè)1M的文件后，再去校驗(yàn)。校驗(yàn)通過后才去連想要訪問的網(wǎng)站服務(wù)器，這相當(dāng)浪費(fèi)時(shí)間、效率。同時(shí)，很多瀏覽器所處網(wǎng)絡(luò)是有網(wǎng)絡(luò)訪問限制的，可能在一個(gè)局域網(wǎng)，比如我們村，或者物理距離非常遠(yuǎn)，存在嚴(yán)重的網(wǎng)絡(luò)延遲問題。

2. Online Certificate Status Protocol (OCSP)

在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP的描述中，瀏覽器從在線OCSP服務(wù)器(也稱為OCSP Response Server)請求證書的撤銷狀態(tài)，OCSP Server予以響應(yīng)。這種方法避免CRL更新延遲問題。同樣的，X.509 v3證書的OCSP信息也是存儲在拓展信息中，如alipay.com證書那張圖的綠色框內(nèi)部分。

(1) OCSP 檢測流程

瀏覽器在獲得Web服務(wù)器的公鑰證書后，開始驗(yàn)證公鑰的合法性，這里會向該公鑰的擴(kuò)展信息中提供的OCSP Server地址發(fā)送OCSP Response，獲得響應(yīng)后，確認(rèn)證書有效，再繼續(xù)跟Web服務(wù)器通信。

(2) OCSP的優(yōu)點(diǎn)

相對于CRL方式，證書吊銷后，CA Server可以立刻將吊銷信息發(fā)送給瀏覽器，生效時(shí)間快。響應(yīng)包內(nèi)容短，不像CRL的響應(yīng)包，都將近1M以上。

(3) OCSP的缺點(diǎn)

第一個(gè)缺點(diǎn)：瀏覽器的每次HTTPS請求創(chuàng)建，都需要連接CA OCSP Server進(jìn)行驗(yàn)證，有的瀏覽器所在IP與CA OCSP Server的網(wǎng)絡(luò)并不是通暢的，比如我們村。而且，OCSP的驗(yàn)證有網(wǎng)絡(luò)IO，花費(fèi)了很長的時(shí)間，嚴(yán)重影響了瀏覽器訪問服務(wù)器的用戶體驗(yàn)。

第二個(gè)缺點(diǎn)：在瀏覽器發(fā)送服務(wù)器HTTPS證書序號到CA OCSP Server時(shí)，也將暴露了用戶的隱私，將用戶訪問的網(wǎng)址透漏給了CA OCSP Server。

(4) OCSP機(jī)制衍生出來的問題

設(shè)想一個(gè)場景，你是瀏覽器企業(yè)，研發(fā)的瀏覽器在檢查證書吊銷狀態(tài)時(shí)，得不到OCSP server的響應(yīng)，你會如何選擇?

• 如果你選擇拒絕該證書信息，并且拒絕后續(xù)的HTTPS通訊，那么這個(gè)方式稱之為Hard-fail
• 如果你選擇信任該證書，認(rèn)為沒有被吊銷，那么這個(gè)方式稱之為Soft-fail

如果是hard-fail模式，那瀏覽器對任何HTTPS服務(wù)器訪問的先決條件都取決于OCSP Server，這將是一個(gè)致命的單點(diǎn)故障，對于具有資深架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)的你來說，你會這么選擇嗎?

如果是soft-fail模式，取不到OCSP Server的響應(yīng)就忽略了，那么，要這個(gè)機(jī)制還有啥意義呢?要你有何用?

(5) OCSP Stapling

OCSP Stapling的方案是解決了CRL、OCSP的缺點(diǎn)，將通過OCSP Server獲取證書吊銷狀況的過程交給Web 服務(wù)器來做，Web 服務(wù)器不光可以直接查詢OCSP信息，規(guī)避網(wǎng)絡(luò)訪問限制、OCSP服務(wù)器離用戶的物理距離較遠(yuǎn)等問題，還可以將查詢響應(yīng)緩存起來，給其他瀏覽器使用。由于OCSP的響應(yīng)也是具備CA RSA私鑰簽名的，所以不用擔(dān)心偽造問題。

• 解決了訪問慢的問題
• 解決了用戶隱私泄露的問題

通訊過程如上，但對于Web服務(wù)器在去OCSP Server查詢證書狀態(tài)時(shí)，也同樣面臨無法獲取到OCSP Response的問題，在響應(yīng)給瀏覽器時(shí)，瀏覽器也還是要面臨hard-fail、soft-fail的選擇問題，這很讓瀏覽器頭大。

(6) OCSP Must-Staple

面對hard-fail、soft-fail的問題，各家瀏覽器廠商的態(tài)度都不一樣。同時(shí)，不管瀏覽器如何選擇，都不能滿足廣大域名用戶的需求，那么不如把這個(gè)選擇交給域名用戶自己。為此，OCSP Must-Staple應(yīng)運(yùn)而生了，瀏覽器必須檢測OCSP響應(yīng)。域名證書創(chuàng)建時(shí)，自定義設(shè)定啟用這個(gè)選項(xiàng)，將這個(gè)信息打入X.509 v3的擴(kuò)展中，瀏覽器讀取后，強(qiáng)制進(jìn)行OCSP檢測，走h(yuǎn)ard-fail模式。這個(gè)規(guī)范被起草在 X.509v3 Extension: OCSP Stapling Required draft-hallambaker-muststaple-00 ，不過，暫未被采納為RFC標(biāo)準(zhǔn)。

(7) CA廠商支持

目前支持該擴(kuò)展的證書的CA廠商有Let’s Encrypt。如果使用的是openssl 1.1.0 以前的版本，可以使用11.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 來指定。RFC 比如生成csr的時(shí)候，在openssl.cnf中增加：

[v3_req ] 
basicConstraints = CA:FALSE 
keyUsage = nonRepudiation, digitalSignature, keyEncipherment 
subjectAltName = @alt_names 
1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05如果是使用openssl 1.1.0或更高的版本，可以這樣設(shè)置：[ v3_req ] 
basicConstraints = CA:FALSE 
keyUsage = nonRepudiation, digitalSignature, keyEncipherment 
subjectAltName = @alt_names 

各平臺上瀏覽器對證書吊銷的支持情況

1. Mac Safari

在Mac OS X 10.7 (Lion)以后，Safari/macOS默認(rèn)情況下，不檢測CRLs、OCSP，走自己的key chain體系。(資料比較少，apple官方也搜不到幾條)

2. Windows Internet Explorer

Windows Vista系統(tǒng)開始，Internet Explorer 7瀏覽器內(nèi)置了CryptoAPI，來支持OCSP方式檢測證書吊銷情況。檢測范圍包括issuer發(fā)行商的證書、subject服務(wù)器的證書。

為什么IE訪問HTTPS的網(wǎng)站時(shí)，會比別的瀏覽器慢?你應(yīng)該已經(jīng)知道答案了。

3. Mozilla Firefox

在2010年時(shí)，Mozilla Firefox的所有版本都支持OCSP方式檢測。在Firefox 3里把OCSP檢測機(jī)制設(shè)定為默認(rèn)機(jī)制。在以后的版本更新中，F(xiàn)irefox針對中級證書跟域名證書做了不同的策略。

(1) 中級證書的吊銷狀態(tài)驗(yàn)證

在2015年，F(xiàn)irefox 37開始，針對中級證書的檢測，Mozilla也啟用了自研的證書吊銷狀況檢查機(jī)制OneCRL來代替OCSP機(jī)制，目的還是想解決CRL、OCSP機(jī)制的缺點(diǎn)。而中級證書是不能采用OCSP stapling方式，不允許被緩存的。所以…還有，

RFC 6961 defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this.

Firefox 官方短期內(nèi)并無支持 Multi-staple 的打算。

(2) 域名證書的吊銷狀態(tài)驗(yàn)證

在Firefox的官方WIKI上，提到針對域名證書的吊銷驗(yàn)證分為如下5個(gè)方案：

• 方案一：Short-Lived Certificates，默認(rèn)情況下，針對有效期少于10天的證書，直接跳過驗(yàn)證，認(rèn)為不安全?？梢栽趕ecurity.pki.cert_short_lifetime_in_days參數(shù)里配置。
• 方案二：OCSP Stapling，跟RFC規(guī)范一樣。如果security.OCSP.enabled的值為0，則忽略O(shè)CSP response。
• 方案三：OCSP Must-staple，跟RFC規(guī)范一樣?？梢酝ㄟ^設(shè)置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 參數(shù)來禁用。
• 方案四：OCSP，跟RFC規(guī)范一樣。如果OCSP的響應(yīng)在2秒(EV證書是10秒)內(nèi)沒返回，則直接忽略。
• 方案五：CRLite，類似Chrome CRLSets的一種檢測機(jī)制，用于OCSP、OCSP stapling失敗后的機(jī)制。Firefox的官方計(jì)劃把這種機(jī)制作來代替CRL方式作為主要的檢測機(jī)制(OCSPOCSP stapling失敗后)。

4. Chrome

2012年，Chrome禁用了CRLs、OCSP檢測: Google Chrome Will No Longer Check for Revoked SSL Certificates Online ，使用了自行設(shè)計(jì)的證書校驗(yàn)機(jī)制 CRLSets

那么，Chrome這么選擇的理由是什么呢?顯然，通過上面CRL跟OCSP兩種驗(yàn)證方式的比較來看，前者時(shí)效性不行，后者影響性能。那么，google Chrome就決定自建證書吊銷狀態(tài)驗(yàn)證系統(tǒng)。

Chrome的安全工程師Adam Langley在他的BLOG上寫了一篇文章：《Revocation checking and Chrome’s CRL》，對于Chrome的HTTPS證書驗(yàn)證這塊，Adam Langley可是非常有看法的。

非常反對使用CRL、OCSP的方式來校驗(yàn)證書吊銷狀態(tài)，連續(xù)寫了好幾篇關(guān)于證書吊銷狀態(tài)檢測的文章，同時(shí)，也在chromium的開發(fā)者主頁上的安全板塊有提到【W(wǎng)hat’s the story with certificate revocation?】：

但這也不是完美解決了這個(gè)問題，來自【An Evaluation of the Effectiveness of Chrome’s CRLSets】：

This means that Chrome’s CRLSet, which currently lists the serial numbers of 24,206 revoked certificates, reflects only 1.08% of the revoked certificates collected by Websense in one hour.

這篇文章中提到CRLSet的最大問題是包含的證書吊銷數(shù)據(jù)太少，個(gè)別情況下占了主流CRL證書吊銷信息的2%不到。

而且，CRLSets的更新也不是那么及時(shí)，chrome為了用戶體驗(yàn)，為了性能，為了用戶隱私，犧牲了一點(diǎn)點(diǎn)安全性，也是可以理解的。但好像對不起最安全瀏覽器的稱號了。[手動狗頭]

匯總

 

如上圖，在2015年，Northeastern University、University of Maryland、Duke University等幾所大學(xué)的研究人員分析了市場上流行的五個(gè)瀏覽器(多個(gè)平臺、多個(gè)版本)，把各個(gè)瀏覽器在不同級別證書下的支持情況繪制了表格。(論文在參考文獻(xiàn)中給出)從圖中可以看出，我們印象中最安全的瀏覽器Chrome表現(xiàn)卻讓你大跌眼鏡，在HTTPS的安全性這塊，表現(xiàn)最差。

上面我們也談到，chrome為了訪問速度隱私等用戶體驗(yàn)考慮，忽略了CRL、OCSP等證書吊銷狀態(tài)檢測機(jī)制，犧牲了TLS這塊的安全性支持。

而IE瀏覽器卻出乎我們意料，在HTTPS的安全性這塊，支持的非常好，可以說是這幾個(gè)瀏覽器中最安全的了，可是…可是他網(wǎng)頁打開速度慢啊…截至至今天(2019年7月16日)，已經(jīng)4年過去了，很多瀏覽器、WebServer的支持情況也有很大的變化，并不能反映出當(dāng)下互聯(lián)網(wǎng)的現(xiàn)狀，這些數(shù)據(jù)也作為參考吧。

附：WebServer的支持情況

• The Apache web server has supported OCSP stapling since v2.3.3 (ref).
• The nginx web server has supported OCSP stapling since v1.3.7 (ref).

總結(jié)

1. 證書泄露的危害

那么，證書丟了，會對網(wǎng)站安全產(chǎn)生很大影響嗎?回頭看下使用該證書的條件：

• 具備證書
• 具備域名
• 瀏覽器訪問該服務(wù)器

如果幾個(gè)都具備，那么你就是該網(wǎng)站的官方了。

在安全界，有個(gè)攻擊手段，叫 Man-in-the-middle attack 中間人攻擊，如果證書被黑客拿到，搭建一個(gè)具備相同域名的網(wǎng)站，通過 DNS 污染的方式使得用戶瀏覽器訪問該域名，那么可以成為一個(gè)反向代理，把用戶的請求解析后，偽造成客戶端來跟真實(shí)的Web 服務(wù)器通訊，從而獲取雙方通信的明文信息，達(dá)到攻擊的目的。

那這種情況怎么防范?中間人攻擊的防御方式是開啟客戶端對證書的認(rèn)證，但你的證書私鑰又丟了，那能咋辦?通過本文前面章節(jié)的了解到，這種情況，也只能主動到CA廠商那申請證書吊銷了，不管有幾個(gè)瀏覽器支持，也得申請，畢竟，這損失能減少一點(diǎn)是一點(diǎn)。

證書泄露了怎么辦?

證書泄露了怎么辦?從瀏覽器的支持情況來看，好像及時(shí)申請吊銷了證書，也不能對丟失的證書起到太大的防范作用，很多瀏覽器并不是很支持的嘛。

不過，多少也能避免一些損失，畢竟IE瀏覽器對這塊的支持力度還是很大的嘛。