HPKP 遇到的阻礙

關於 HPKP,可以參考「HTTP Public Key Pinning 介绍」這篇介紹,寫得很清楚。

HPKP 是解決 CA 架構錯發憑證的方案 (無論是無意或是故意),像是最近吵的比較熱的 WoSign 發出 GitHub 的憑證的問題就可以用 HPKP 解。

原理上來說,就是在 HTTP header 裡面指出這個站台所允許的 Root CA 有哪些。所以跟 HSTS 一樣是走 Trust On First Use 架構,當 client 第一次連上的時候會記下資訊,之後就可以使用這個資訊來驗證。

但 HPKP 與 HSTS 不同的地方在於,HSTS 只是個 Yes/No 問題 (i.e. 是否強迫使用 HTTPS),而且通常 migrate 上去後就不會拔掉。

但 HPKP 則是要指定 Root CA,這代表不能隨便換一家簽。當你用的那家 Root CA 出包時就苦了... (就像 WoSign 免費憑證的問題)

這使得 HPKP 的實作成本過高,而且得到效益太低,另外也因為替代的方案有不少 (像是 Certificate Transparency),導致 HPKP 根本沒什麼人用:「Is HTTP Public Key Pinning Dead?」。

在 comment 有人直接拉出來統計,使用的比率反而在下降:

From my stats looking to the Alexa 1K top websites from 2015-07-26 to 2016-07-31 the number of websites NOT using HPKP increase from 99.47% to 99.58% which means almost nothing.

不過我覺得算是平行發展吧,這些驗證的技術都不怎麼衝突... HPKP 解決問題的方法非常的技術面,而 Certificate Transparency 還是走稽核路線讓 Root CA 回報每一個發出的 Certificate...

This entry was posted in Computer, Murmuring, Network, Security, WWW and tagged , , , , , , , , , , , . Bookmark the permalink.

One Response to HPKP 遇到的阻礙

  1. 記得沒錯 HPKP 應該不是限定 Root CA 而是整個 trust chain 裡面的任意一個層級?
    比較麻煩的是因為至少要 pin 兩組 key 上去作為備用,另外就是如果 pin 的不是 CA 而是最底下一層,每次換 private key / cert 的時候要時間要算的非常小心不然很容易出事 ...

Leave a Reply

Your email address will not be published. Required fields are marked *