要約

  • APNICの報告では、失効したLet's Encryptの証明書はCRLに記載されていた。今回の実験でChromeとSafariは失効を認識せず、Firefoxは認識した。
  • これは特定の実験条件での観察であり、全バージョンや全利用者の挙動を証明しない。CAによる公開とクライアントによる拒否は別の出来事である。
  • 短い有効期間、OCSP、ステープリング、DNSSEC/DANEはいずれも異なる依存関係と時間差を持ち、即時の万能な解決策ではない。

失効はしばしば、一つの操作で信用が消えるかのように説明される。しかしCAが署名したリストに番号を加えても、サーバーの手元にある証明書そのものは消えない。配布先には更新間隔があり、キャッシュには有効期限がある。ブラウザーには、どの状態情報を取得し、取得できなかったときに接続を許すかを決める実装方針がある。利用者の安全を左右するのは、この最後の判断まで記録が届いたかどうかだ。

APNICが9月21日に公開した技術セッション報告によると、主任科学者Geoff HustonはLet's Encryptの証明書を発行後に失効させた。該当証明書はCRLに現れたが、試したChromeとSafariは失効を認識せず、Firefoxは認識した。同報告には、ブラウザーのビルド、OS、設定、通信条件、各接続時刻を再現する完全な一覧はない。したがって「あるブラウザーは常に確認しない」と言い切る根拠にはならない。

CRLの署名は発行元を確かめる手掛かりであって、全端末が最新版を読んだ証拠ではない。リストには発行時刻と次回更新の目安があり、古くてもその期間内なら利用され得る。Hustonの4月の分析は、TLS接続のたびに大きなリストを取り寄せる負荷を説明する。会議報告は週次更新の一例として17,527件の失効を含むCRLを挙げ、今回の発行周期を七日と記す。この件数は影響を受けた人の数ではなく、七日も特定の利用者が危険だったという測定値ではない。

OCSPなら個別の証明書について照会できる。ただし照会先に閲覧行動を知らせる可能性があり、応答サービスの障害や遅延に左右される。署名された応答にもthisUpdateとnextUpdateがあり、かつて正しかった「有効」が今も正しいとは限らない。OCSPステープリングはサーバーに応答を添付させ、直接照会を減らせるが、失効済みの証明書を提示し続けるサーバーが不利な新情報を自発的に運ぶとは限らない。通信失敗時に拒否するか通すかもクライアントの判断だ。

4月の記事には、別のOCSP実験でSafariが今回と異なる振る舞いをした記録もある。二つの結果を平均して製品の恒久的な順位を作るべきではない。対象とする仕組み、キャッシュ、環境が違えば問うていることも違う。9月に確認できるのは、APNICが報じた一回の実験における分岐である。

有効期間を短くすれば、期限切れを正しく拒むクライアントにとって古い証明書が残る上限を狭められる。ただし盗まれた鍵を発見の瞬間に無効化するわけではなく、更新と配備の失敗は別の停止要因となる。HustonはAPNIC 62の資料でDNSSECとDANE、DNSキャッシュの期限を使う別設計を論じる。提案を既に全ブラウザーで採用された代替策と取り違えてはならない。

運用記録には、失効を決めた時刻、CAによる公開、取得可能だったCRLまたはOCSP応答、各配信拠点が実際に提示した証明書、明示したクライアント版の接続結果を分けて残したい。この実験は銀行への侵入や被害者数を報告していない。公開された不信任の記録が、必ずしも利用者側の拒否に到達しないという境界を報告したのである。

出典