可領全套安全課程、配套攻防靶場

現任美團安全部技術專家，十年以上互聯網產品研發經驗，專注於分佈式系統架構設計，目前主要從事安全防禦產品研發工作。

緣起

偶刷《長安十二時辰》，午睡時，夢到我穿越到了唐朝，在長安城中的靖安司，做了一天的靖安司司丞。

當徐賓遇害消失的時候我不在司內，當時的情形我不得而知。

後來徐賓醒了，據他描述說“通傳陸三”是暗樁，險些致徐賓於死地。

而擅長大案牘術的高智商人才居然被一個普通通傳的幾句話騙至險境，實在丟了我的臉。

陸三是通傳，熟知靖安司的號令傳遞系統望樓信號，他是暗樁的消息，傳遍整個機構。

這讓張小敬和姚汝能認為望樓系統已無法完成消息保密傳送的功能，其實他們根本不瞭解這望樓。

整個望樓系統由“傳遞系統+加密系統”組成，靖安司作為一個軍事級別的機構，信息傳遞絕對是多重加密的。

只看懂望樓圖案，或者只有密碼本都是破譯不了密碼的，對於通傳陸三是暗樁的影響，也只需要更換密碼本即可。

這些可是我學了RSA非對稱加密後設計的望樓系統，早就評估過這些風險了。

即使HTTPS通訊中，丟了密鑰也...

嗯？如果HTTPS證書私鑰丟了，會怎樣？是不是也沒法防範這個私鑰被利用了？

想到這個問題，我突然從夢中驚醒，去溫故一下證書吊銷機制。

疑問

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

HTTPS通訊過程

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

1.第一個階段，完成 Client Hello、Server Hello等握手。包含使用SSL版本、服務器和客戶端的隨機數、密碼套件、數據壓縮等參數響應。

2.第二階段，服務端把域名證書的公鑰下發給瀏覽器（客戶端），瀏覽器（客戶端）校驗證書合法性。

3.第三階段，客戶端把自己的證書發送給服務端（證書登陸的情況下），服務端檢測客戶端證書等。

4.第四階段，完成密鑰協商、對稱加密密鑰交換。

（簡稱解釋：RN: Random Number；PMS: Pre Master Secret；MS: Master Secret）

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

<strong>證書完整性驗證

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

<strong>證書有效性驗證

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

證書吊銷狀態檢測

如果，證書在有效期之內需要丟了怎麼辦？

需要吊銷證書了，那麼這裡就多了一個證書吊銷狀態的檢測。

用戶將需要吊銷的證書通知到CA服務商，CA服務商通知瀏覽器該證書的撤銷狀態。

來看一個證書吊銷後的瀏覽器提醒：

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

<strong>驗證發行者

HTTPS數字證書的使用分兩個角色：

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

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

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

<strong>檢查域名(IP)規範

中間CA提供了對域名證書的管理以及頒發的顆粒度度控制。

證書的生效範圍會限於固定域名、域名範圍（包括子域）或者固定IP。

比如下圖是https://www.baidu.com的HTTPS證書DNS信息。

上圖所示，DNS範圍包含了多個域名，同時二級以及二級以上域名都支持範圍形式。

以*通配義字符表示。

但*.example.com的二級域名範圍就不能包含a.b.example.com這個三級域名。

同時，DNS範圍也支持IP的，只是IP不支持範圍形式，必須把所有IP列表都放入列表中。

<strong>檢查策略約束

法律策略相關檢測（略）。

證書的吊銷狀態檢測方式

上面提到了瀏覽器（客戶端）在驗證證書合法性時的驗證範圍，我們暫時只關注證書吊銷信息的檢測，下面我們仔細來了解一下兩種檢測機制的實現原理。

1. Certificate Revocation Lists (CRL)

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

CRL分佈在公共可用的存儲庫中，瀏覽器可以在驗證證書時獲取並查閱CA的最新CRL。

該方法的一個缺陷是撤銷的時間粒度限於CRL發佈期。

只有在計劃更新所有當前發佈的CRL之後，才會通知瀏覽器撤銷。

各家簽名CA廠商的策略不一樣，有的是幾小時，有的是幾天，甚至幾周。

2015年，美國幾所大學的學生論文中，統計了當時的CA證書吊銷情況，如下圖：

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

• 證書的CRL信息

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

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

• CRL 檢測流程

可以想象一下，在瀏覽器去校驗證書合法性時，還要去下載一個1M的文件後，再去校驗。

校驗通過後才去連想要訪問的網站服務器，這相當浪費時間、效率。

同時，很多瀏覽器所處網絡是有網絡訪問限制的，可能在一個局域網，比如我們村，或者物理距離非常遠，存在嚴重的網絡延遲問題。

2. Online Certificate Status Protocol (OCSP)

在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP的描述中，瀏覽器從在線OCSP服務器（也稱為OCSP Response Server）請求證書的撤銷狀態，OCSP Server予以響應。

這種方法避免CRL更新延遲問題。

同樣的，X.509 v3證書的OCSP信息也是存儲在拓展信息中，如alipay.com證書那張圖的綠色框內部分。

• OCSP 檢測流程

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

• OCSP的優點

相對於CRL方式，證書吊銷後，CA Server可以立刻將吊銷信息發送給瀏覽器，生效時間快。

響應包內容短，不像CRL的響應包，都將近1M以上。

• OCSP的缺點

第一個缺點：瀏覽器的每次HTTPS請求創建，都需要連接CA OCSP Server進行驗證，有的瀏覽器所在IP與CA OCSP Server的網絡並不是通暢的，比如我們村。

而且，OCSP的驗證有網絡IO，花費了很長的時間，嚴重影響了瀏覽器訪問服務器的用戶體驗。

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

• OCSP機制衍生出來的問題

設想一個場景，你是瀏覽器企業，研發的瀏覽器在檢查證書吊銷狀態時，得不到OCSP server的響應，你會如何選擇？

• 如果你選擇拒絕該證書信息，並且拒絕後續的HTTPS通訊，那麼這個方式稱之為Hard-fail
• 如果你選擇信任該證書，認為沒有被吊銷，那麼這個方式稱之為Soft-fail

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

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

• OCSP Stapling

OCSP Stapling的方案是解決了CRL、OCSP的缺點，將通過OCSP Server獲取證書吊銷狀況的過程交給Web 服務器來做，Web 服務器不光可以直接查詢OCSP信息，規避網絡訪問限制、OCSP服務器離用戶的物理距離較遠等問題，還可以將查詢響應緩存起來，給其他瀏覽器使用。

由於OCSP的響應也是具備CA RSA私鑰簽名的，所以不用擔心偽造問題。

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

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

• OCSP Must-Staple

面對hard-fail、soft-fail的問題，各家瀏覽器廠商的態度都不一樣。

同時，不管瀏覽器如何選擇，都不能滿足廣大域名用戶的需求，那麼不如把這個選擇交給域名用戶自己。

為此，OCSP Must-Staple應運而生了，瀏覽器必須檢測OCSP響應。

域名證書創建時，自定義設定啟用這個選項，將這個信息打入X.509 v3的擴展中，瀏覽器讀取後，強制進行OCSP檢測，走hard-fail模式。

這個規範被起草在 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系統開始，Internet Explorer 7瀏覽器內置了CryptoAPI，來支持OCSP方式檢測證書吊銷情況。檢測範圍包括issuer發行商的證書、subject服務器的證書。

為什麼IE訪問HTTPS的網站時，會比別的瀏覽器慢？你應該已經知道答案了。

3. Mozilla Firefox

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

• 中級證書的吊銷狀態驗證

在2015年，Firefox 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 官方短期內並無支持Multi-staple的打算。

• 域名證書的吊銷狀態驗證

在Firefox的官方WIKI上，提到針對域名證書的吊銷驗證分為如下5個方案：

方案一：Short-Lived Certificates，默認情況下，針對有效期少於10天的證書，直接跳過驗證，認為不安全。可以在security.pki.cert_short_lifetime_in_days參數裡配置。

方案二：OCSP Stapling，跟RFC規範一樣。如果security.OCSP.enabled的值為0，則忽略OCSP response。

方案三：OCSP Must-staple，跟RFC規範一樣。可以通過設置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 參數來禁用。

方案四：OCSP，跟RFC規範一樣。如果OCSP的響應在2秒（EV證書是10秒）內沒返回，則直接忽略。

方案五：CRLite，類似Chrome CRLSets的一種檢測機制，用於OCSP、OCSP stapling失敗後的機制。Firefox的官方計劃把這種機制作來代替CRL方式作為主要的檢測機制（OCSP\\OCSP stapling失敗後）。

4. Chrome

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

那麼，Chrome這麼選擇的理由是什麼呢？

顯然，通過上面CRL跟OCSP兩種驗證方式的比較來看，前者時效性不行，後者影響性能。那麼，google Chrome就決定自建證書吊銷狀態驗證系統。

Chrome的安全工程師Adam Langley在他的BLOG上寫了一篇文章：《Revocation checking and Chrome's CRL》，對於Chrome的HTTPS證書驗證這塊，Adam Langley可是非常有看法的，非常反對使用CRL、OCSP的方式來校驗證書吊銷狀態，連續寫了好幾篇關於證書吊銷狀態檢測的文章，同時，也在chromium的開發者主頁上的安全板塊有提到【What'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的最大問題是包含的證書吊銷數據太少，個別情況下佔了主流CRL證書吊銷信息的2%不到。

而且，CRLSets的更新也不是那麼及時，chrome為了用戶體驗，為了性能，為了用戶隱私，犧牲了一點點安全性，也是可以理解的。但好像對不起最安全瀏覽器的稱號了。

[手動狗頭]????

彙總

如上圖，在2015年，Northeastern University、University of Maryland、Duke University等幾所大學的研究人員分析了市場上流行的五個瀏覽器（多個平臺、多個版本），把各個瀏覽器在不同級別證書下的支持情況繪製了表格。 （論文在參考文獻中給出）

從圖中可以看出，我們印象中最安全的瀏覽器Chrome表現卻讓你大跌眼鏡，在HTTPS的安全性這塊，表現最差。

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

而IE瀏覽器卻出乎我們意料，在HTTPS的安全性這塊，支持的非常好，可以說是這幾個瀏覽器中最安全的了，可是...可是他網頁打開速度慢啊...????

截至至今天（2019年7月16日），已經4年過去了，很多瀏覽器、WebServer的支持情況也有很大的變化，並不能反映出當下互聯網的現狀，這些數據也作為參考吧。

附：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).

總結

<strong>證書洩露的危害

那麼，證書丟了，會對網站安全產生很大影響嗎？回頭看下使用該證書的條件：

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

如果幾個都具備，那麼你就是該網站的官方了。

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

如果證書被黑客拿到，搭建一個具備相同域名的網站，通過DNS汙染的方式使得用戶瀏覽器訪問該域名，那麼可以成為一個反向代理，把用戶的請求解析後，偽造程客戶端來跟真實的Web服務器通訊，從而獲取雙方通信的明文信息，達到攻擊的目的。

那這種情況怎麼防範？中間人攻擊的防禦方式是開啟客戶端對證書的認證，但你的證書私鑰又丟了，那能咋辦？

通過本文前面章節的瞭解到，這種情況，也只能主動到CA廠商那申請證書吊銷了，不管有幾個瀏覽器支持，也得申請，畢竟，這損失能減少一點是一點。

<strong>證書洩露了怎麼辦？

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

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

注

本文的參考文獻，大部分都是5-6年前的資料，這麼多年過去了，互聯網技術產品日新月異，裡面很多結論早已不符合現狀，尤其是瀏覽器當今對證書吊銷狀態檢測的支持情況。

部分內容，僅作為參考，便於讀者去了解技術變遷的背景知識。

參考文獻

• 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

<strong>結束

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

轉載自：https://www.secpulse.com/archives/113075.html6

今天你知道了嗎？

加群，黑客技術大咖在線解答(群號評論區見)

閱讀更多 暗網視界 的文章

關鍵字: 黑客 證書 操作系統