2011年頃、ドメイン所持者が意図せぬ形で、認証局よりサーバ証明書がご発行される事件がありました。この対策として、Certificate Transparency (CT) という仕組みが導入されました。
CTの仕組み
CTの利用の流れは幾つかありますが、一例を示します。
- 1. 認証局が証明書を発行する際に第三者が運営するCTログサーバにプレ証明書を登録します。登録時に、登録の証左となるSigned Certificate Timestamp (SCT)が認証局に渡されます。
- 2. 認証局は、登録時に得られるSigned Certificate Timestamp (SCT)を証明書に付与して発行します。
- 3. ブラウザ(PC版Chrome)がWebサイトにアクセスする際、証明書にSCTがついてない場合は、エラー画面を表示します。
( https://no-sct.badssl.com/ )
ログサーバにあるドメインの証明書が登録されていることは誰でも確認することが出来ます。そのため、意図せぬ証明書が発行されていれば検知することが出来ます。
Chromiumが認識するCTログサーバは以下より確認出来ます。
github.com
SCT Auditing
SCTは、証明書がCTログサーバに登録されてる証左として扱われてました。つまり、SCTがついているサーバ証明書は、CTログサーバで必ず確認できるはずです。
しかし、CTログサーバが悪意を持って振る舞った場合、認証局にはSCTを払い出すが、登録情報を公開しないという事もできます。これでは、ドメイン所持者はCTログサーバを意図せぬ証明書が発行されているか確認できません。
そこで、ブラウザは、Webサーバを通して得られたSCTが本当にログサーバ上で公開されているか確認するというのが、Google Chromeで実装が進められているSCT Auditingです。この仕組では、疑わしいSCTをGoogleのサーバにレポートすることで実現されます
プライバシーの問題
SCT Auditing では SCTをブラウザからGoogleのサーバにアップロードするため、プライバシーの問題が発生します。つまり、ユーザがどのサーバと接続したのかが分かってしまいます。そこで、フェーズを2段階に分け、試しながらSCT Auditingを有効にしていく模様です。
- phase 1: SCT Auditingをオプトインしたユーザのみ有効
- phase 2: プライバシー保護を行い、その他のユーザも有効 (今の所デスクトップ版のみ)
現在、 phase 2の設計について議論が行われている段階です。
docs.google.com
phase 1
下記の通り、Opt in したユーザ
Webサイトの閲覧の安全性向上のためにGoogleのサーバに情報を送る Enhanced Safe Browsingを利用している場合に、SCT AuditingのレポートをGoogleのサーバに送るようになっています。
phase 2
オプトアウトしていない、より広いユーザでSCT Auditingを有効にし、CTの仕組みを強固にします。また、ユーザのプライバシーを保護する仕組みが入っています。
SCTリストサブセットの取得
ブラウザはサーバから得たSCTがGoogleに認識されているか、まずGoogleからSCTのリストのサブセットを取得します。SCTリストのサブセットの要求にはk匿名性クエリを用います。
SCTの対応するMerkleTreeLeafのハッシュ数バイトをGoogleサーバに送信します。Googleのサーバはマッチするハッシュのセットを返します (10000ドメイン以上のリストとなる)。
こうすることで、ブラウザは、該当のSCTをGoogleがすでに認識しているか確認できます。
さいごに
まだ議論の最中で、色々実証実験などを踏まえて細かいところは変わっていきそうです。
詳しい内容は先にも上げた、phase 1およびphase 2の資料を御覧ください
phase 1
docs.google.com
phase 2
docs.google.com