[[273630]]

緣起

偶刷《長安十二時辰》，午睡時，夢到我穿越到了唐朝，在長安城中的靖安司，做了一天的靖安司司丞。當徐賓遇害消失的時候我不在司內(nèi)，當時的情形我不得而知。后來徐賓醒了，據(jù)他描述說“通傳陸三”是暗樁，險些致徐賓于死地。而擅長大案牘術(shù)的高智商人才居然被一個普通通傳的幾句話騙至險境，實在丟了我的臉。陸三是通傳，熟知靖安司的號令傳遞系統(tǒng)望樓信號，他是暗樁的消息，傳遍整個機構(gòu)。這讓張小敬和姚汝能認為望樓系統(tǒng)已無法完成消息保密傳送的功能，其實他們根本不了解這望樓。

[[273631]]

整個望樓系統(tǒng)由“傳遞系統(tǒng)+加密系統(tǒng)”組成，靖安司作為一個軍事級別的機構(gòu)，信息傳遞絕對是多重加密的。只看懂望樓圖案，或者只有密碼本都是破譯不了密碼的，對于通傳陸三是暗樁的影響，也只需要更換密碼本即可。這些可是我學了RSA非對稱加密后設計的望樓系統(tǒng)，早就評估過這些風險了。即使HTTPS通訊中，丟了密鑰也…嗯?如果HTTPS證書私鑰丟了，會怎樣?是不是也沒法防范這個私鑰被利用了?想到這個問題，我突然從夢中驚醒，去溫故一下證書吊銷機制。

疑問

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

HTTPS通訊過程

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

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

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

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

證書完整性驗證

使用RSA公鑰解密來驗證證書上的私鑰簽名是否合法，如果簽名無效，則可認定證書被修改，直接報錯。

證書有效性驗證

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

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

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

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

驗證發(fā)行者

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

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

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

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

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

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

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

檢查策略約束

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

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

上面提到了瀏覽器(客戶端)在驗證證書合法性時的驗證范圍，我們暫時只關(guān)注證書吊銷信息的檢測，下面我們仔細來了解一下兩種檢測機制的實現(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分布在公共可用的存儲庫中，瀏覽器可以在驗證證書時獲取并查閱CA的最新CRL。該方法的一個缺陷是撤銷的時間粒度限于CRL發(fā)布期。只有在計劃更新所有當前發(fā)布的CRL之后，才會通知瀏覽器撤銷。各家簽名CA廠商的策略不一樣，有的是幾小時，有的是幾天，甚至幾周。2015年，美國幾所大學的學生論文中，統(tǒng)計了當時的CA證書吊銷情況，如下圖：

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

證書的CRL信息

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

可以看到，其CRL信息為http://crl3.digicert.com/SecureSiteCAG2.crl 以及http://crl4.digicert.com/SecureSiteCAG2.crl

CRL 檢測流程

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

2. Online Certificate Status Protocol (OCSP)

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

OCSP 檢測流程

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

OCSP的優(yōu)點

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

OCSP的缺點

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

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

OCSP機制衍生出來的問題

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

如果你選擇拒絕該證書信息，并且拒絕后續(xù)的HTTPS通訊，那么這個方式稱之為Hard-fail

如果你選擇信任該證書，認為沒有被吊銷，那么這個方式稱之為Soft-fail

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

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

OCSP Stapling

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

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

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

OCSP Must-Staple

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

CA廠商支持

目前支持該擴展的證書的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的時候，在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或更高的版本，可以這樣設置：[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

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

1. Mac Safari

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

2. Windows Internet Explorer

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

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

3. Mozilla Firefox

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

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

在2015年，F(xiàn)irefox 37開始，針對中級證書的檢測，Mozilla也啟用了自研的證書吊銷狀況檢查機制OneCRL來代替OCSP機制，目的還是想解決CRL、OCSP機制的缺點。而中級證書是不能采用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的打算。

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

在Firefox的官方WIKI上，提到針對域名證書的吊銷驗證分為如下5個方案：方案一：Short-Lived Certificates，默認情況下，針對有效期少于10天的證書，直接跳過驗證，認為不安全?？梢栽趕ecurity.pki.cert_short_lifetime_in_days參數(shù)里配置。方案二：OCSP Stapling，跟RFC規(guī)范一樣。如果security.OCSP.enabled的值為0，則忽略OCSP response。方案三：OCSP Must-staple，跟RFC規(guī)范一樣?？梢酝ㄟ^設置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 參數(shù)來禁用。

方案四：OCSP，跟RFC規(guī)范一樣。如果OCSP的響應在2秒(EV證書是10秒)內(nèi)沒返回，則直接忽略。

方案五：CRLite，類似Chrome CRLSets的一種檢測機制，用于OCSP、OCSP stapling失敗后的機制。Firefox的官方計劃把這種機制作來代替CRL方式作為主要的檢測機制(OCSPOCSP stapling失敗后)。

4. Chrome

2012年，Chrome禁用了CRLs、OCSP檢測: Google Chrome Will No Longer Check for Revoked SSL Certificates Online ，使用了自行設計的證書校驗機制 CRLSets

那么，Chrome這么選擇的理由是什么呢?顯然，通過上面CRL跟OCSP兩種驗證方式的比較來看，前者時效性不行，后者影響性能。那么，google Chrome就決定自建證書吊銷狀態(tài)驗證系統(tǒng)。Chrome的安全工程師Adam Langley在他的BLOG上寫了一篇文章：《Revocation checking and Chrome’s CRL》，對于Chrome的HTTPS證書驗證這塊，Adam Langley可是非常有看法的，非常反對使用CRL、OCSP的方式來校驗證書吊銷狀態(tài)，連續(xù)寫了好幾篇關(guān)于證書吊銷狀態(tài)檢測的文章，同時，也在chromium的開發(fā)者主頁上的安全板塊有提到【W(wǎng)hat’s the story with certificate revocation?】：Chrome’s primary mechanism for checking the revocation status of HTTPS certificates is CRLsets.Chrome also supports Online Certificate Status Protocol (OCSP). However, the effectiveness of OCSP is is essentially 0 unless the client fails hard (refuses to connect) if it cannot get a live, valid OCSP response. No browser has OCSP set to hard-fail by default, for good reasons explained by Adam Langley (see [Revocation still doesn’t work](No, don’t enable revocation checking) and https://www.imperialviolet.org/2014/04/19/revchecking.html).

Stapled OCSP with the Must Staple option (hard-fail if a valid OCSP response is not stapled to the certificate) is a much better solution to the revocation problem than non-stapled OCSP. CAs and browsers are working toward that solution (see the Internet-Draft: http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-03).

Additionally, non-stapled OCSP poses a privacy problem: in order to check the status of a certificate, the client must query an OCSP responder for the status of the certificate, thus exposing a user’s HTTPS browsing history to the responder (a third party).

That said, you can use enterprise policies to enable soft-fail OCSP (http://www.chromium.org/administrators/policy-list-3#EnableOnlineRevocationChecks) and hard-fail OCSP for local trust anchors (http://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors).

Chrome performs online checking for Extended Validation certificates if it does not already have a non-expired CRLSet entry covering the domain. If Chrome does not get a response, it simply downgrades the security indicator to Domain Validated.

See also this bug for more discussion of the user-facing UX: https://crbug.com/361820.

但這也不是完美解決了這個問題，來自【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ù)太少，個別情況下占了主流CRL證書吊銷信息的2%不到。而且，CRLSets的更新也不是那么及時，chrome為了用戶體驗，為了性能，為了用戶隱私，犧牲了一點點安全性，也是可以理解的。但好像對不起最安全瀏覽器的稱號了。[手動狗頭]

匯總

如上圖，在2015年，Northeastern University、University of Maryland、Duke University等幾所大學的研究人員分析了市場上流行的五個瀏覽器(多個平臺、多個版本)，把各個瀏覽器在不同級別證書下的支持情況繪制了表格。(論文在參考文獻中給出)從圖中可以看出，我們印象中最安全的瀏覽器Chrome表現(xiàn)卻讓你大跌眼鏡，在HTTPS的安全性這塊，表現(xiàn)最差。上面我們也談到，chrome為了訪問速度隱私等用戶體驗考慮，忽略了CRL、OCSP等證書吊銷狀態(tài)檢測機制，犧牲了TLS這塊的安全性支持。而IE瀏覽器卻出乎我們意料，在HTTPS的安全性這塊，支持的非常好，可以說是這幾個瀏覽器中最安全的了，可是…可是他網(wǎng)頁打開速度慢啊…截至至今天(2019年7月16日)，已經(jīng)4年過去了，很多瀏覽器、WebServer的支持情況也有很大的變化，并不能反映出當下互聯(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é)

證書泄露的危害

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

• 具備證書
• 具備域名
• 瀏覽器訪問該服務器

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

在安全界，有個攻擊手段，叫Man-in-the-middle attack中間人攻擊。

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

證書泄露了怎么辦?

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

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

注

本文的參考文獻，大部分都是5-6年前的資料，這么多年過去了，互聯(lián)網(wǎng)技術(shù)產(chǎn)品日新月異，里面很多結(jié)論早已不符合現(xiàn)狀，尤其是瀏覽器當今對證書吊銷狀態(tài)檢測的支持情況。部分內(nèi)容，僅作為參考，便于讀者去了解技術(shù)變遷的背景知識。

參考文獻

RFC3280 Internet X.509 Public Key Infrastructure Certificate

High-reliability OCSP stapling and why it matters

Security Certificate Revocation AwarenessThe case for “OCSP Must-Staple”

Security Certificate Revocation AwarenessSpecific Implementations

Security Sidebar: My Browser Has No Idea Your Certificate Was Just Revoked

SSL certificate revocation and how it is broken in practice

Revoking Intermediate Certificates: Introducing OneCRL

Revocation doesn’t work (18 Mar 2011)

Revocation checking and Chrome’s CRL (05 Feb 2012)

No, don’t enable revocation checking (19 Apr 2014)

Revocation still doesn’t work (29 Apr 2014)

An End-to-End Measurement of Certificate Revocation in the Web’s PKI

結(jié)束

嗯?話說《長安十二時辰》中望樓消息傳送機制的加固呢?嗨，夢都醒了，誰還記得這事啊。

作者：陳馳 (CFC4N)

現(xiàn)任美團安全部技術(shù)專家，十年以上互聯(lián)網(wǎng)產(chǎn)品研發(fā)經(jīng)驗，專注于分布式系統(tǒng)架構(gòu)設計，目前主要從事安全防御產(chǎn)品研發(fā)工作。