在服務(wù)器上啟用HTTP公鑰固定擴(kuò)展的教程

2020-05-27 13:02:06

字體：大中小

供稿：網(wǎng)友

　　這篇文章主要介紹了在服務(wù)器上啟用HTTP公鑰固定擴(kuò)展的教程,示例包括對(duì)Apache和NGINX以及Lighttpd服務(wù)器的演示,需要的朋友可以參考下

　　公鑰固定(Public Key Pinning)是指一個(gè)證書鏈中必須包含一個(gè)白名單中的公鑰，也就是說(shuō)只有被列入白名單的證書簽發(fā)機(jī)構(gòu)(CA)才能為某個(gè)域名*.example.com簽發(fā)證書，而不是你的瀏覽器中所存儲(chǔ)的任何 CA 都可以為之簽發(fā)。本文講述了這種機(jī)制的背景知識(shí)，并提供了 Apache、 Lighttpd 和 NGINX 上的配置范例。

　　HTTP 公鑰固定擴(kuò)展

　　用你使用的銀行做個(gè)例子，它一直使用 CA 公司 A 為其簽發(fā)證書。但是在當(dāng)前的證書體系下，CA 公司 B、CA 公司 C 和 NSA 的 CA 都能給你的銀行創(chuàng)建證書，而你的瀏覽器會(huì)毫無(wú)疑慮的接受它們，因?yàn)檫@些公司都是你所信任的根 CA。

　　如果你的銀行實(shí)現(xiàn)了 HPKP 并固定了它們的第一個(gè)中級(jí)證書(來(lái)自 CA 公司 A)，那么瀏覽器將不會(huì)接受來(lái)自CA 公司 B 和 CA 公司 C 的證書，即便它們也有一個(gè)有效的信任鏈。HPKP 也允許你的瀏覽器將這種違例行為報(bào)告給該銀行，以便銀行知道被偽造證書攻擊了。

　　HTTP 公鑰固定擴(kuò)展是一個(gè)從2011年開(kāi)始開(kāi)發(fā)的針對(duì) HTTP 用戶代理(即瀏覽器)的公鑰固定標(biāo)準(zhǔn)。它由 Google 發(fā)起，甚至在 Chrome 中實(shí)現(xiàn)的固定機(jī)制可以使用一個(gè)人工維護(hù)的網(wǎng)站公鑰固定列表，這個(gè)列表包含了固定的幾個(gè)網(wǎng)站的公鑰簽名。(LCTT 譯注：Chrome 和 FireFox 32 及以后版本都支持公鑰固定機(jī)制，并使用內(nèi)置的人工維護(hù)的公鑰固定列表數(shù)據(jù)，這些數(shù)據(jù)隨著瀏覽器軟件的更新而更新，主要包括幾個(gè)大型站點(diǎn)。目前還只有 Chrome 38+ 支持通過(guò) HTTP 響應(yīng)頭傳遞公鑰固定信息。)

　　以下是 HPKP 的幾個(gè)功能簡(jiǎn)述：

　　HPKP 是在 HTTP 層面設(shè)置的，使用 Public-Key-Pins (PKP)響應(yīng)頭。

　　該規(guī)則的保留周期通過(guò) max-age 參數(shù)設(shè)置，單位是秒。

　　PKP 響應(yīng)頭只能用于正確的安全加密通訊里面。

　　如果出現(xiàn)了多個(gè)這樣的響應(yīng)頭，則只處理第一個(gè)。

　　固定機(jī)制可以使用includeSubDomains參數(shù)擴(kuò)展到子域。

　　當(dāng)接收到一個(gè)新的 PKP 響應(yīng)頭時(shí)，它會(huì)覆蓋之前存儲(chǔ)的公鑰固定和元數(shù)據(jù)。

　　公鑰固定是用哈希算法生成的，其實(shí)是一個(gè)“主題公鑰信息(SKPI)”指紋。

　　本文首先會(huì)介紹一些 HPKP 工作的原理，接下來(lái)我們會(huì)展示給你如何得到需要的指紋并配置到 web 服務(wù)器中。

　　SPKI 指紋 - 理論

　　通常來(lái)說(shuō)，對(duì)證書進(jìn)行哈希是一個(gè)顯而易見(jiàn)的解決方案，但是其實(shí)這是錯(cuò)的。不能這樣做的原因是 CA 證書可以不斷重新簽發(fā)：同一個(gè)公鑰、主題名可以對(duì)應(yīng)多個(gè)證書，而這些證書有不同的延展或失效時(shí)間。瀏覽器從下至上地在證書池中構(gòu)建證書鏈時(shí)，另外一個(gè)版本的證書可能就替代匹配了你原本所期望的證書。

　　舉個(gè)例子，StartSSL 有兩個(gè)根證書：一個(gè)是以 SHA1 簽名的，另外是一個(gè)是 SHA256。如果你希望固定住 StartSSL 作為你的 CA，那么你該使用哪個(gè)證書呢?你也許可以使用這兩個(gè)，但是如果我不告訴你，你怎么會(huì)知道還有一個(gè)根證書呢?

　　相反地，對(duì)公鑰進(jìn)行哈希則不會(huì)有這個(gè)問(wèn)題：

　　瀏覽器假定子證書是固定不動(dòng)的：它總是證書鏈的起點(diǎn)。子證書所攜帶的簽名一定是一個(gè)有效的簽名，它來(lái)自其父證書給這個(gè)證書專門簽發(fā)的。這就是說(shuō)，父證書的公鑰相對(duì)于子證書來(lái)說(shuō)是固定的。所以可推論公鑰鏈?zhǔn)枪潭ǖ摹?/p>

　　唯一的問(wèn)題是你不能固定到一個(gè)交叉認(rèn)證的根證書上。舉個(gè)例子，GoDaddy 的根證書是 Valicert 簽名的，這是為了讓那些不能識(shí)別 GoDaddy 根證書的老客戶可以信任其證書。然而，你不能固定到 Valicert 上，因?yàn)樾碌目蛻粼谧C書鏈上發(fā)現(xiàn)了 GoDaddy 證書就會(huì)停止上溯(LCTT 譯注：所以就找不到固定信息了)。

　　此外，我們是對(duì) SubjectPublicKeyInfo(SPKI)進(jìn)行哈希而不是對(duì)公鑰位串。SPKI 包括了公鑰類型、公鑰自身及其相關(guān)參數(shù)。這很重要，因?yàn)槿绻麑?duì)公鑰進(jìn)行哈希就有可能導(dǎo)致發(fā)生曲解攻擊。對(duì)于一個(gè) Diffie-Hellman 公鑰而言：如果僅對(duì)公鑰進(jìn)行哈希，而不是對(duì)完整的 SPKI，那么攻擊者可以使用同樣的公鑰而讓客戶端將其解釋為其它組。同樣地，這樣也有可能強(qiáng)制將一個(gè) RSA 密鑰當(dāng)成 DSA 密鑰解釋等等。

　　固定在哪里

　　你應(yīng)該固定在什么地方?固定你自己的公鑰并不是一個(gè)最好的辦法。你的密鑰也許會(huì)改變或撤銷。你也許會(huì)使用多個(gè)證書，經(jīng)常輪換證書的話密鑰就改變了。也許由于服務(wù)器被入侵而撤銷證書。

　　最容易但是不是太安全的方法是固定第一個(gè)中級(jí) CA 證書。該證書是簽名在你的網(wǎng)站證書之上的，所以簽發(fā)該證書的 CA 的公鑰肯定是在證書鏈上的。

　　采用這種方法你可以從同一個(gè) CA 更新你的證書而不用擔(dān)心固定信息不對(duì)。如果該 CA 發(fā)行了一個(gè)不同的根證書，也許你會(huì)遇到一些問(wèn)題，對(duì)此并沒(méi)有太好的解決方案。不過(guò)你可以通過(guò)如下做法來(lái)減輕這種問(wèn)題的影響：

　　從一個(gè)不同的 CA 申請(qǐng)一個(gè)備用的證書，并固定該備份。

　　RFC 里面說(shuō)你至少需要做兩個(gè)固定。一個(gè)是當(dāng)前連接所使用的證書鏈上的，另外一個(gè)是備份的。

　　另外的固定是對(duì)備份公鑰的，它可以是來(lái)自另外一個(gè)給你簽發(fā)證書的不同 CA 的 SKPI 指紋。

　　在這個(gè)問(wèn)題上還有一種更安全的方法，就是事先創(chuàng)建好至少三個(gè)獨(dú)立的公鑰(使用 OpenSSL，參見(jiàn)此頁(yè) 了解 Javascript OpenSSL 命令生成器)，并將其中兩個(gè)備份到一個(gè)安全的地方，離線存儲(chǔ)、不要放到網(wǎng)上。

　　為這三個(gè)證書創(chuàng)建 SPKI 指紋并固定它們，然后僅使用第一個(gè)作為當(dāng)前的證書。當(dāng)需要時(shí)，你可以使用備份密鑰之一。不過(guò)你需要讓 CA 給你做簽名來(lái)生成證書對(duì)，這可能需要幾天，依你的 CA 的工作情況而定。

　　對(duì)于 HPKP 來(lái)說(shuō)這沒(méi)有問(wèn)題，因?yàn)槲覀兪褂玫氖枪 €的 SPKI 哈希，而不是證書。失效或不同的 CA 簽名鏈并不影響。

　　如果你按照上述方法生成并安全存儲(chǔ)了至少三個(gè)獨(dú)立的密鑰，并固定它們，也可以防止你的 CA 撤銷你的網(wǎng)站證書并簽發(fā)一個(gè)假證書時(shí)出現(xiàn)問(wèn)題。

　　SPKI 指紋

　　可以使用如下的 OpenSSL 命令來(lái)生成 SPKI 指紋，它出現(xiàn)在 RFC 草案中：

　　代碼如下:

　　openssl x509 -noout -in certificate.pem -pubkey |

　　openssl asn1parse -noout -inform pem -out public.key;

　　openssl dgst -sha256 -binary public.key | openssl enc -base64

　　結(jié)果：

　　代碼如下:

　　klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=

　　上面輸入的 certificate.pem 文件是本站(https://raymii.org)的證書鏈中第一個(gè)證書。(在寫本文時(shí)， COMODO RSA Domain Validation Secure Server CA, 序列號(hào) 2B:2E:6E:EA:D9:75:36:6C:14:8A:6E:DB:A3:7C:8C:07 )。

　　你也需要同樣對(duì)你的另外兩個(gè)備份公鑰生成指紋。

　　故障

　　在寫本文時(shí)(2015/1)，唯一支持 HPKP 的瀏覽器(chrome)有一個(gè)嚴(yán)重的問(wèn)題：Chrome 并不能夠區(qū)分 HSTS 和 HPKP 響應(yīng)頭中的 max-age 和 includeSubdomains 參數(shù)。也就是說(shuō)，如果你的 HSTS 和 HPKP 設(shè)置了不同的 max-age 和 includeSubdomains 參數(shù)，它們會(huì)互相搞亂。關(guān)于這個(gè)故障的更多信息參見(jiàn)：https://code.google.com/p/chromium/issues/detail?id=444511。感謝 Scott Helme(https://scotthelme.co.uk)發(fā)現(xiàn)并告訴我這個(gè) Chromium 項(xiàng)目的問(wèn)題。

　　Web 服務(wù)器配置

　　下面你可以看到三個(gè)主流 Web 服務(wù)器的配置方法。這只是一個(gè) HTTP 響應(yīng)頭，絕大多數(shù) Web 服務(wù)器都可以設(shè)置它。它只需要設(shè)置到 HTTPS 網(wǎng)站上。

　　下面的例子固定到 COMODO RSA Domain Validation Secure Server CA 及備份的 Comodo PositiveSSL CA 上，30天失效期，包括所有的子域。

　　Apache

　　編輯你的 Apache 配置文件(如 /etc/apache2/sites-enabled/website.conf 或 /etc/apache2/httpd.conf)，并添加下列行到你的 VirtualHost 中：

　　代碼如下:

　　# 如需要，載入 headers 模塊。

　　LoadModule headers_module modules/mod_headers.so

　　Header set Public-Key-Pins "pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains"

　　Lighttpd

　　Lighttpd 更簡(jiǎn)單一些，將下列行添加到你的 Lighttpd 配置文件(如 /etc/lighttpd/lighttpd.conf)：

　　代碼如下:

　　server.modules += ( "mod_setenv" )

　　$HTTP["scheme"] == "https" {

　　setenv.add-response-header = ( "Public-Key-Pins" => "pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains")

　　}

　　NGINX

　　NGINX 的配置更簡(jiǎn)短。添加以下行到你的 HTTPS 配置的 server 塊中：

　　add_header Public-Key-Pins pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains;

　　報(bào)告功能

　　HPKP 報(bào)告功能允許瀏覽器報(bào)告任何違例給你。

　　如果你在響應(yīng)頭中添加了附加的 report-uri="http://example.org/hpkp-report" 參數(shù)，并用該 URI 處理接收到的數(shù)據(jù)的話，客戶端會(huì)在發(fā)現(xiàn)違例時(shí)發(fā)送報(bào)告給你。這個(gè)報(bào)告是以 POST 方式發(fā)送到你指定的 report-uri 上，并以類似下面的 JSON 格式：

　　代碼如下:

　　{

　　"date-time": "2014-12-26T11:52:10Z",

　　"hostname": "www.example.org",

　　"port": 443,

　　"effective-expiration-date": "2014-12-31T12:59:59",

　　"include-subdomains": true,

　　"served-certificate-chain": [

　　"-----BEGINCERTIFICATE-----nMIIAuyg[...]tqU0CkVDNxn-----ENDCERTIFICATE-----"

　　"validated-certificate-chain": [

　　"-----BEGINCERTIFICATE-----nEBDCCygAwIBA[...]PX4WecNxn-----ENDCERTIFICATE-----"

　　"known-pins": [