[[273630]]

緣起

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

[[273631]]

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

疑問(wèn)

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

HTTPS通訊過(guò)程

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

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

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

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

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

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

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

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

證書(shū)吊銷狀態(tài)檢測(cè)

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

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

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

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

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

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

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

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

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

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

檢查策略約束

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

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

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

1. Certificate Revocation Lists (CRL)

CA會(huì)定期更新發(fā)布撤銷證書(shū)列表，Certificate Revocation Lists (以下簡(jiǎn)稱CRL)，RFC 5280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile。CRL分布在公共可用的存儲(chǔ)庫(kù)中，瀏覽器可以在驗(yàn)證證書(shū)時(shí)獲取并查閱CA的最新CRL。該方法的一個(gè)缺陷是撤銷的時(shí)間粒度限于CRL發(fā)布期。只有在計(jì)劃更新所有當(dāng)前發(fā)布的CRL之后，才會(huì)通知瀏覽器撤銷。各家簽名CA廠商的策略不一樣，有的是幾小時(shí)，有的是幾天，甚至幾周。2015年，美國(guó)幾所大學(xué)的學(xué)生論文中，統(tǒng)計(jì)了當(dāng)時(shí)的CA證書(shū)吊銷情況，如下圖：

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

證書(shū)的CRL信息

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

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

CRL 檢測(cè)流程

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

2. Online Certificate Status Protocol (OCSP)

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

OCSP 檢測(cè)流程

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

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

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

OCSP的缺點(diǎn)

第一個(gè)缺點(diǎn)：瀏覽器的每次HTTPS請(qǐng)求創(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)了很長(zhǎng)的時(shí)間，嚴(yán)重影響了瀏覽器訪問(wèn)服務(wù)器的用戶體驗(yàn)。

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

OCSP機(jī)制衍生出來(lái)的問(wèn)題

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

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

如果你選擇信任該證書(shū)，認(rèn)為沒(méi)有被吊銷，那么這個(gè)方式稱之為Soft-fail

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

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

OCSP Stapling

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

• 解決了訪問(wèn)慢的問(wèn)題
• 解決了用戶隱私泄露的問(wèn)題

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

OCSP Must-Staple

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

CA廠商支持

目前支持該擴(kuò)展的證書(shū)的CA廠商有Let’s Encrypt。如果使用的是openssl 1.1.0 以前的版本，可以使用11.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 來(lái)指定。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

各平臺(tái)上瀏覽器對(duì)證書(shū)吊銷的支持情況

1. Mac Safari

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

2. Windows Internet Explorer

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

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

3. Mozilla Firefox

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

中級(jí)證書(shū)的吊銷狀態(tài)驗(yàn)證

在2015年，F(xiàn)irefox 37開(kāi)始，針對(duì)中級(jí)證書(shū)的檢測(cè)，Mozilla也啟用了自研的證書(shū)吊銷狀況檢查機(jī)制OneCRL來(lái)代替OCSP機(jī)制，目的還是想解決CRL、OCSP機(jī)制的缺點(diǎn)。而中級(jí)證書(shū)是不能采用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)并無(wú)支持Multi-staple的打算。

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

在Firefox的官方WIKI上，提到針對(duì)域名證書(shū)的吊銷驗(yàn)證分為如下5個(gè)方案：方案一：Short-Lived Certificates，默認(rèn)情況下，針對(duì)有效期少于10天的證書(shū)，直接跳過(guò)驗(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ī)范一樣?？梢酝ㄟ^(guò)設(shè)置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 參數(shù)來(lái)禁用。

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

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

4. Chrome

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

那么，Chrome這么選擇的理由是什么呢?顯然，通過(guò)上面CRL跟OCSP兩種驗(yàn)證方式的比較來(lái)看，前者時(shí)效性不行，后者影響性能。那么，google Chrome就決定自建證書(shū)吊銷狀態(tài)驗(yàn)證系統(tǒng)。Chrome的安全工程師Adam Langley在他的BLOG上寫(xiě)了一篇文章：《Revocation checking and Chrome’s CRL》，對(duì)于Chrome的HTTPS證書(shū)驗(yàn)證這塊，Adam Langley可是非常有看法的，非常反對(duì)使用CRL、OCSP的方式來(lái)校驗(yàn)證書(shū)吊銷狀態(tài)，連續(xù)寫(xiě)了好幾篇關(guān)于證書(shū)吊銷狀態(tài)檢測(cè)的文章，同時(shí)，也在chromium的開(kāi)發(fā)者主頁(yè)上的安全板塊有提到【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.

但這也不是完美解決了這個(gè)問(wèn)題，來(lái)自【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的最大問(wèn)題是包含的證書(shū)吊銷數(shù)據(jù)太少，個(gè)別情況下占了主流CRL證書(shū)吊銷信息的2%不到。而且，CRLSets的更新也不是那么及時(shí)，chrome為了用戶體驗(yàn)，為了性能，為了用戶隱私，犧牲了一點(diǎn)點(diǎn)安全性，也是可以理解的。但好像對(duì)不起最安全瀏覽器的稱號(hào)了。[手動(dòng)狗頭]

匯總

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

證書(shū)泄露的危害

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

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

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

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

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

證書(shū)泄露了怎么辦?

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

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

注

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

參考文獻(xiàn)

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é)束

嗯?話說(shuō)《長(zhǎng)安十二時(shí)辰》中望樓消息傳送機(jī)制的加固呢?嗨，夢(mèng)都醒了，誰(shuí)還記得這事啊。

作者：陳馳 (CFC4N)

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