公鑰固定（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 草案 中：

結(jié)果：

上面輸入的 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 中：

Lighttpd

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

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 格式：

非強(qiáng)制，只報(bào)告

HPKP 也可以設(shè)置為非強(qiáng)制的，可以使用 Public-Key-Pins-Report-Only 來(lái)只發(fā)送違例報(bào)告給你。

這樣可以讓你在網(wǎng)站不可訪問(wèn)或 HPKP 配置不正確時(shí)不固定，之后你可以將這個(gè)響應(yīng)頭改為 Public-Key-Pins 來(lái)強(qiáng)制固定。

最新評(píng)論