HPKPの廃止通知を受けたsiteはpinを増やす前にheaderと証明書更新の責任を確認する

ChromeがHTTP Public Key Pinningを非推奨にしたという通知を見ても、すべてのsiteが新しいsecurity headerを急いで足す必要はありません。最初に、実際のHTTPS responseへHPKP headerが出ているかを確認します。出ていないsiteは、廃止予定への対応としてpinを新規に設定しません。すでに使っているsiteは、pinの値だけを増やす前に、証明書を更新する人、serverまたはCDNでheaderを替える人、設定を誤ったときに復旧を判断する人を分けます。

HTTP Public Key Pinningは、siteがcertificate chainに含まれる一つ以上の公開鍵をHTTP headerでpinする仕組みです。Chrome 67はこれを非推奨にし、Chrome 69で削除する予定を案内しています。理由として、certificateの誤発行を防ぐ目的がある一方、denial of serviceとhostile pinningの危険があることを挙げています。certificateの誤発行への対策としては、Chrome Developersがreporting機能を含むExpect-CT headerを案内しています。 Chrome Developersの案内

HPKPを使っているかは公開responseで確かめる

HPKPの対応を考えるとき、serverの設定fileや引継ぎ資料だけを見て判断しません。利用者が実際に開くHTTPS URLへrequestを送り、response headerにHPKPの設定が出ているかを確認します。top pageだけでなく、wwwを使うURL、wwwを使わないURL、subdomain、管理画面、CDNを経由するURLなど、certificateや配信経路が分かれている場所を一覧にします。

設定fileに古い記述が残っていても、公開responseへ出ていなければ、利用者のbrowserが受け取るheaderではありません。反対に、serverの担当者が知らないCDNやreverse proxyがheaderを加えている場合もあります。設定の置き場所を推測して書き換えるより、最初に公開responseを記録し、どこから出ているかをたどります。

確認表には、URL、HTTPまたはHTTPS、response headerの有無、TLSを終端する場所、certificateを更新する人、headerを変更できる人、確認した日時を書きます。certificateを発行する会社と、serverを設定する会社と、siteを運用する人が違う場合は、同じ担当欄にまとめません。HPKPはHTTP headerの話ですが、certificateの更新と切り離して扱えないためです。

説明用の仮例として、example.jpはserverで配信し、www.example.jpはCDNを通るsiteを考えます。example.jpにだけHPKP headerが出ているなら、二つのhostを同じ設定だと決めつけません。先にそれぞれのresponseとcertificateの担当を確かめます。二つのURLを一度に書き換え、どちらが直ったか分からなくするより、影響するhostを一つずつ分けて確認します。

pinを増やしても証明書更新の責任は減らない

HPKPは、certificate chainにある公開鍵をpinするheaderです。headerを書いたことと、次回のcertificate更新を安全に完了できることは別です。証明書の発行元、更新通知の受信先、更新作業の日時、serverまたはCDNへの反映、更新後のHTTPS接続確認は、pinの設定だけでは管理できません。

証明書の更新で問題が起きたとき、最初に必要なのは、誰がcertificateを発行または受け取り、誰が公開環境へ設定し、誰が利用者の画面を確認するかを知ることです。外部へ任せている場合も、siteを持つ側は契約先とaccountの所在、更新通知の宛先、緊急時の連絡方法を把握します。担当者が替わったあとにheaderだけが残り、certificateを替えられない状態を作らないでください。

HPKPを使うsiteでは、certificateの更新予定を決めた時点で、公開前と公開後の確認を分けます。公開前には、変更対象のhost、certificate chain、headerを変更する場所、元へ戻す方法、作業を止める判断を確認します。公開後には、HTTPSで接続できるか、意図したresponse headerが返るか、重要なpageとformが開くかを確認します。headerを直す作業と、certificateを替える作業を同じ一行の記録にしない方が、問題が出たときに原因を追えます。

HPKPとExpect-CTを同じheaderとして扱わない

Chrome Developersは、certificateの誤発行に対してExpect-CT headerとreporting機能を使うよう案内しています。これは、HPKPのpinをそのまま別の名前へ書き換えるという意味ではありません。目的、設定場所、reportを受ける先、確認する人を分けます。HPKPを外す作業とExpect-CTを検討する作業を一度に終えたことにしないでください。

Expect-CTを使うなら、まず何をreportとして受け、誰が読むかを決めます。reportを受けるURLやmailを作っても、読む人が決まらず、異常があったときの連絡先もなければ、運用の入口を増やすだけです。certificateに関する報告を受ける場所は、問い合わせformや通常のアクセス解析と混ぜず、必要な担当者が確認できる経路にします。

また、headerを追加する対象hostを決めずに、全subdomainへ同じ変更を広げません。公開site、管理画面、メールや外部serviceと関係するhostは、certificateと配信の条件が同じとは限りません。対象URL、headerを返す場所、reportを受ける場所、変更の承認者、作業後に確認するURLを一覧にしてから、小さい範囲で試します。

設定を誤ったときに戻せるかを先に決める

Chrome Developersは、HPKPにconfiguration errorからの復旧が難しい危険を挙げています。したがって、headerを厳しくする前に、設定を誤ったときに誰が戻すかを確認します。serverの管理画面、CDNの設定、source code、certificateのaccountのうち、実際にheaderを出している場所へ入れる人がいなければ、値を増やす判断はできません。

復旧手順は、技術者だけのメモにしません。siteを運用する人が、どのURLで問題を確認し、誰へ連絡し、どの作業を止めるかを分かる形へ残します。たとえば、更新直後にHTTPSの接続ができない場合は、問い合わせを受ける人、certificateを確認する人、headerを戻す人、公開状況を利用者へ伝える人を分けます。一人で兼ねる場合も、順番を書いておけば、焦って別の設定まで同時に替えずに済みます。

作業を依頼するときは、「security headerを設定する」とだけ渡しません。対象domainとhost、現在のresponse header、certificateの更新担当、変更場所、reportを読む人、戻す判断、確認URL、作業記録の保存先を渡します。委託した人がheaderを設定できても、site側がcertificateと配信のaccountを確認できなければ、次回の更新で判断できません。

HPKPを使っていないsiteは導入を目的にしない

HPKPを使っていないsiteにとって、今回の通知は新しいpinを追加する理由ではありません。まずHTTPS接続、certificateの更新、HTTP URLからHTTPS URLへの移動、混在したresource、更新通知の受信先を整える方が先です。使っていない仕組みを増やすと、管理するheaderと復旧条件が増えます。

HPKPを使っているsiteは、設定を残すか外すかを、certificate更新の計画とChromeの予定を見ながら決めます。Expect-CTを検討する場合も、reporting機能を含めた運用を持てるかを確認します。headerの文字列を最新に見せることではなく、certificateとresponse headerを誰が管理し、問題があったときに戻せるかを優先します。

最初の一手は、HTTPS URLを三つ選び、HPKP headerの有無、headerを出す場所、certificateを更新する人、変更を戻す人を表へ書くことです。HPKPがなければ、廃止通知のために導入しません。HPKPがあれば、pinの追加ではなく、公開responseと更新責任の確認から始めます。