追記 2021/11/15
Expect-CTヘッダの役割は、CTの利用が必須となり不要となる方向です
asnokaze.hatenablog.com
Certificate Transparency
Certificate Transparencyと呼ばれる、不正な証明書の発行を検知する仕組みがGoogle社によって考案され、RFC 6962として標準化されています。もちろん、Google Chromeもこの機能に対応しており、ログサーバーにSigned Certificate Timestamp(SCT)を検証し、正しく発行された証明書なのかを検証します。
詳しい仕組みについては、各社CAの説明を読むとわかりやすいかと思います。
このCTですが、GoogleのChrome teamはCA/Browserにて、2017年10月以降に発行された証明書は信頼されるためにChromeのCTポリシーを尊守することが期待される、とアナウンスをしているようです。
https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/78N3SMcqUGw/ykIwHXuqAQAJ
ChromeのCTポリシーは、chromiumのwikiより確認できます。
https://www.chromium.org/Home/chromium-security/certificate-transparency
また、来月行われるIETF97のHTTPbis wgで、サーバが明示的にCTに対応している旨をブラウザに通知するExpect-CTヘッダの議論が行われる予定です。これにより、何かの不具合が生じたときに検知できるようになります。
Expect-CT ヘッダ
まだ、議論が開始するような段階のためまだまだ決定したものではありませんが、Expect-CT ヘッダは以下のようなもののようです。(今のところ著者の個人githubリポジトリより仕様が確認できます。)
CTに対応してるWebサーバは、httpsで接続を受けた際、レスポンスヘッダにExpect-CTヘッダを付加します。
expect-ct: enforce;max-age=3600;report-uri=https://example.com/report-uri
これを受け取ったユーザエージェントは、それ以降の接続でCT対応のサーバ証明書が得られなかった場合は何かがおかしいと判断します。その際、Expect-CTヘッダで指定されたreport-uriにレポートを送信します。
Expect-CTヘッダには、以下のようなディレクティブが指定できます
- enforce: CTポリシーに違反した際、接続を拒否するように指示する
- max-age: このExpect-CTヘッダの有効期間を秒で指定
- report-uri: CTポリシーに違反したときのレポート送信先絶対URL
レポートされる内容は、jsonで以下の通りです。
{
"date-time": date-time,
"hostname": hostname,
"port": port,
"effective-expiration-date": expiration-date,
"served-certificate-chain": [ (MUST be in the order served)
pem1, ... pemN
],
"validated-certificate-chain":
pem1, ... pemN
],
"scts": [
sct1, ... sctN
]
}時刻と、サーバの情報、及び証明書チェーンとsctが送られるようです。
