HTTP 公開鍵のピン留め

HTTP公開鍵ピンニング（HPKP）は、HTTPヘッダーを介して配信される廃止されたインターネットセキュリティメカニズムであり、 HTTPSウェブサイトが、誤って発行された、または不正なデジタル証明書を使用する攻撃者によるなりすましに抵抗できるようにします。^[1]サーバーはこれを使用して、同じドメイン名への将来の接続の証明書チェーンに表示される必要がある公開鍵のハッシュのセットをクライアント（Webブラウザーなど）に配信します。

たとえば、攻撃者が証明機関を侵害し、Web オリジンの証明書を誤って発行する可能性があります。このリスクに対抗するため、HTTPS Web サーバーは、一定期間有効な「固定」公開鍵ハッシュのリストを提供します。その後の接続では、その有効期間中、クライアントはサーバーが証明書チェーン内の 1 つ以上の公開鍵を使用することを期待します。使用されない場合はエラー メッセージが表示されますが、ユーザーはこれを (簡単に) 回避することはできません。

この技術では、証明書をピン留めするのではなく、公開キーハッシュをピン留めします。つまり、秘密キーにアクセスできる場合は、キー ペアを使用して任意の証明機関から証明書を取得できます。また、ユーザーはルート証明書または中間証明書(証明機関によって作成) の公開キーをピン留めして、サイトをその証明機関によって発行された証明書に制限することもできます。

HPKPの仕組みが複雑で、誤って誤用される可能性（システム管理者によるロックアウト状態を引き起こす可能性がある）があるため、2017年にブラウザはHPKPを非推奨にし、2018年には証明書の透明性を優先してHPKPのサポートを削除しました。^{[2] [3]}

サーバーは、 （またはレポート専用の目的） という名前のHTTP応答ヘッダー フィールドを介して、HPKP ポリシーをユーザー エージェントに伝達します。Public-Key-PinsPublic-Key-Pins-Report-Only

HPKP ポリシーは、 Web サイトの正規の X.509公開鍵証明書チェーン内の 1 つの証明書のサブジェクト公開鍵情報のハッシュ(および少なくとも 1 つのバックアップ キー) をディレクティブで指定し、ユーザー エージェントが公開鍵のピン留めを実施する期間をディレクティブで指定し、ピン留めポリシーにすべてのサブドメイン (ヘッダーを送信したドメインの) を含めるオプションのディレクティブと、ピン留め違反レポートを送信する URL を含むオプションのディレクティブを指定します。証明書チェーンがユーザー エージェントによって有効であるとみなされるためには、証明書チェーン内の証明書の公開鍵の少なくとも 1 つがピン留めされた公開鍵と一致する必要があります。 pin-sha256max-ageincludeSubDomainsreport-uri

公開時点では、RFC 7469 ではSHA-256ハッシュ アルゴリズム のみが許可されていました。(RFC 7469 の付録 A には、HPKP ポリシーのハッシュを生成するために使用できるいくつかのツールと必要な引数が記載されています。)

ウェブサイト運営者は、特定のルート証明機関のルート証明書公開鍵をピン留めして、その証明機関（およびその鍵で署名されたすべての中間証明機関）のみがウェブサイトのドメインに対して有効な証明書を発行できるようにするか、1 つ以上の中間発行証明書の鍵をピン留めするか、エンド エンティティの公開鍵をピン留めするかを選択できます。

現在の固定キーを置き換える必要がある場合に備えて、少なくとも 1 つのバックアップ キーを固定する必要があります。このバックアップ キーがないと、HPKP は無効になります (バックアップ キーは、現在の証明書チェーンに存在しない公開キーとして定義されます)。^[4]

HPKPはRFC 7469で標準化されています。^[1]これは、よく知られているWebサイトやサービスの公開鍵ハッシュをWebブラウザやアプリケーション内でハードコードする静的証明書ピンニングを拡張したものです。^[5]

ほとんどのブラウザは、さまざまな企業コンテンツ検査スキャナ^{[6]やウェブデバッグツール（mitmproxyや}Fiddlerなど）を有効にするために、プライベートルート証明書を含む証明書チェーンのピン留めを無効にしています。RFC 7469標準では、「ユーザー定義」ルート証明書のピン留め違反レポートを無効にすることを推奨しており、ブラウザがピンの検証を無効にすることは「許容される」とされています。^[7]

ユーザーエージェントがピン検証を実行し、提供された証明書チェーンで有効な SPKI フィンガープリントが見つからない場合、違反の詳細を含む JSON 形式の違反レポートを report-uri ディレクティブで指定されたホストに POST します。この URI はHTTPまたはHTTPS経由で提供できますが、ユーザーエージェントは違反を報告しているドメインと同じドメインの HTTPS URI に HPKP 違反レポートを送信することはできません。ホストは、に HTTP を使用するかreport-uri、別のドメインを使用するか、レポートサービスを使用できます。^[8]

一部のブラウザでは もサポートされておりPublic-Key-Pins-Report-Only、ユーザーにエラーは表示されずにこのレポートのみがトリガーされます。

HPKPは採用がピークに達した時期には、上位100万のインターネットサイトのうち3,500サイトで使用されていたと報告されていますが、その数は2019年末頃には650サイトにまで減少しました。^[9]

批判と懸念は、HPKP SuicideやRansomPKPとして知られる悪意のある、または人為的なエラーによるシナリオを中心に展開されました。^[10]このようなシナリオでは、ウェブサイトの所有者は、自分の鍵へのアクセスを失ったり、悪意のある攻撃者によって新しい鍵が発表されたりすることで、自分のドメインに新しいコンテンツを公開する能力が著しく損なわれます。

• 認証局の侵害
• 証明書の透明性
• HTTP 厳格なトランスポートセキュリティ
• HTTP ヘッダーフィールドのリスト
• DNS認証局の承認
• MDN Web Docsの HTTP 用公開鍵ピンニング拡張機能 (HPKP)