HSTSプリロードとは？プリロードリストの登録要件とリスク、ヘッダーと登録状況の確認方法

1. HSTSプリロードリストとは

HTTP Strict Transport SecurityはRFC 6797で定義されています。サーバーがHTTPSでStrict-Transport-Security: max-age=…を送ると、ブラウザはmax-age秒のあいだ、そのホストにはHTTPSでしか接続しないことを覚えます。ただし、訪問者のブラウザが一度もこのヘッダーを受け取っていない間は、最初の平文のhttp://リクエストを守るものがなく、同じネットワーク上の攻撃者に傍受されるおそれがあります。RFCはこの初回接続の弱点を説明し、あらかじめ設定されたポリシーを対策の一つとして挙げています。

プリロードリストは、その対策を実際の形にしたものです。リストはChromiumプロジェクトが管理しており、新しいエントリーはChromeのソースコードに直接書き込まれます。ChromiumプロジェクトのHSTSのページとhstspreload.orgによると、Firefox、Safari、EdgeはChromeのリストをもとに独自のリストを持っています。エントリーを含むバージョンのブラウザでは、プリロードされたドメインは初回起動の時点からHTTPS専用になります。申請にはincludeSubDomainsが必須なので、その下にあるすべての名前も同じ扱いです。

誤解されやすい点が3つあります。

• preloadディレクティブ自体は、ブラウザの中では何もしません。RFC 6797には含まれておらず、ブラウザは知らないディレクティブを無視します。これは、ドメインの所有者が登録に同意していることをリストの管理者に伝える合図です。ヘッダーにこれが入った時点で、誰でもフォームからそのドメインを申請できます。
• 登録できるのは、登録可能ドメイン全体だけです。申請するのはexample.comで、www.example.comやshop.example.comではありません。エントリーは、インターネットから到達できない社内用の名前も含め、すべてのサブドメインに及びます。
• トップレベルドメインごとプリロードされている例もあります。たとえば.appや.devの下のドメインは、所有者が何も申請していなくても、リストを使うブラウザでは最初からHTTPS専用です。

2. いまでもプリロードは必要か

多くのサイトにとって、答えはおそらく「いいえ」です。申請サイト自身が現在、HSTSは推奨するがHSTSプリロードは推奨しないと明記しています。ChromeとSafariは、HSTSポリシーの有無にかかわらず、http://で始まるナビゲーションを自動でHTTPSに切り替えようとします。そのため、プリロードが埋めようとしていた初回訪問の隙間は大きく狭まりました。hstspreload.orgによれば、プリロードが追加の保護になるのは、能動的な攻撃者によってこの自動切り替えが失敗した場合だけで、HSTSそのものと比べた利点はごくわずかです。

それでも、次の3つがすべて当てはまるなら、検討する意味はあります。

• 初回訪問でのダウングレードが問題になる。たとえば、利用者が公衆Wi-Fiからログインや支払いをする。
• 社内向けや外部の事業者が運用するものも含め、現在と将来のすべてのサブドメインが、有効な証明書でHTTPSを提供できる。
• そのドメインと、そこでのHTTPSを何年も維持するつもりがある。

反対に、完全には管理できないサブドメインを他のチームや外部の事業者が運用している場合、公開ドメインの下に社内ホストがある場合、短期のキャンペーン用ドメインの場合、売却や譲渡の可能性がある場合は、見送るか先送りしてください。エントリーは、誰かが削除を申請するまで、次の所有者にもそのまま引き継がれます。preloadがなくても、きちんと設定したHSTSヘッダーがあれば、再訪する利用者はすでに守られています。

3. 正確な登録要件

hstspreload.orgは申請時に次の条件を確認します。登録後も満たし続ける必要があり、満たさなくなったドメインは削除されることがあります。また、ヘッダーからpreloadを外すと、そのドメインはすぐに削除フォームの対象になります。

多くのサイトがつまずくのがリダイレクトの条件です。https://example.com/がhttps://www.example.com/へリダイレクトする場合、そのリダイレクトのレスポンス自体に完全なヘッダーが必要です。www.example.comが設定したポリシーはベースドメインには適用されないため、wwwのページに付いたヘッダーは数に入りません。確認を通るヘッダーは次のような形です。

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

4. リスク：プリロードを取り消しにくい理由

• 削除には数か月かかります。削除はソースコードの変更なので、ブラウザのアップデートを通じてしか利用者に届きません。削除のページによると、大半のChrome利用者に届くまで6〜12週間かかることがあり、他のブラウザではさらに長くなる可能性があります。更新されないブラウザには古いエントリーが残り続けます。
• HTTPSに対応できないサブドメインは使えなくなります。典型的なのは、社内DNSでしか名前解決できないイントラネットのホスト、自己署名証明書を使うプリンターやルーター、ストレージの管理画面、忘れられた検証用サーバー、そしてCNAMEで外部サービスに向けたヘルプデスクやステータスページ、メールのクリック計測リンクなど、HTTPでしか応答しないものです。ドメインがプリロードされたブラウザでは、これらはエラーになり、警告を越えて進む手段もありません。
• 証明書の不備がそのまま接続不能になります。HSTSホストでは、RFC 6797により、ブラウザは証明書エラーがあれば接続を打ち切り、利用者に先へ進む選択肢を与えません。どれか1つのサブドメインで証明書が期限切れになれば、交換するまで全員が締め出されます。申請の前に、更新の自動化と有効期限の監視を整えてください。
• 再訪者のブラウザにはポリシーが残ります。リストから外れても、ブラウザがヘッダーから学んだポリシーは消えません。max-ageが2年なら、利用者が再訪してHTTPSでmax-age=0を受け取らない限り、その記憶は2年間続きます。
• 意図しない申請。テンプレートからコピーしたヘッダーにpreloadが入っていれば、それだけで誰でもドメインを申請できます。次章の計画を終えるまで、このディレクティブは入れないでください。

5. 申請前にmax-ageを段階的に延ばす計画

hstspreload.orgは、最初の段階からincludeSubDomainsを付けたうえで、max-ageを段階的に延ばすよう勧めています。各段階で崩れたページを探し、トラフィックやログイン数、売上などの指標を見守り、問題を直してから、その段階のmax-ageの期間を少なくとも丸ごと待って次へ進みます。まずテスト用のグループで段階を進めてもかまいませんが、その後は全員を対象に同じ段階を踏んでください。

nginxでは、エラーページにもヘッダーが付くようalwaysパラメーター付きでHTTPSのserverブロックから送り、HTTPのリダイレクトは同じホストのまま保ちます。locationブロックの中にadd_headerを1行でも書くと、そこではserverレベルのヘッダーが置き換えられる点に注意してください（nginxのheadersモジュール）。

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # 段階1：段階ごとに値を変える
    add_header Strict-Transport-Security "max-age=300; includeSubDomains" always;
}

段階的な引き上げだけで5週間以上かかります。さらにhstspreload.orgによると、申請後、新しいエントリーが安定版のChromeに届くまで数か月かかることがあります。公開日に間に合わせるための手早い対策にはなりません。

6. HSTSヘッダーの確認方法

ターミナルで、重要な3つのレスポンスを確認します。

curl -sS -D - -o /dev/null http://example.com/
curl -sS -D - -o /dev/null https://example.com/
curl -sS -D - -o /dev/null https://www.example.com/

1つ目は301か308でLocation: https://example.com/を返すはずです。平文のHTTPで届いたHSTSはブラウザに無視されるため、ここにHSTSヘッダーは必要ありません。2つ目は、それ自体がwwwへのリダイレクトであっても、3つのディレクティブがそろったstrict-transport-securityを返す必要があります。3つ目もヘッダーを送るべきです。wwwしか開かない利用者は、ベースドメインのポリシーを受け取らないからです。Windowsではcurl.exeを使い、-o NULを指定します。

次の誤りに注意してください。

• HSTSヘッダーが2つある。CDNとオリジンサーバーの両方が付けると、RFC 6797によりブラウザは最初の1つだけを処理し、hstspreload.orgの確認では「Multiple HSTS headers」というエラーになります。どの層がヘッダーを受け持つかを決めてください。
• ディレクティブのつづりの誤り。ブラウザは知らないディレクティブを警告なしに捨てます。末尾のsが抜けたincludeSubdomainでは、サブドメインが誰にも気づかれないまま対象外になります。
• 一部のレスポンスにだけ付いていない。トップページには付いていても、エラーページやAPI、別の層が返す静的ファイルには付いていないことがあります。

Chromeの開発者ツールでは、ブラウザがポリシーを保存した後にNetworkパネルを開き、アドレスバーにhttp://example.com/と入力します。最初のエントリーに307 Internal RedirectとNon-Authoritative-Reason: HSTSが表示されれば、リクエストがサーバーに届く前に、ブラウザが自分でHTTPSに切り替えたということです。ヘッダーの構文はMDNのリファレンスにまとまっています。

7. プリロードリストの登録状況の確認方法

• hstspreload.org：フォームにドメインを入力すると、プリロード済み、保留中、未登録のどれかが表示され、現在の要件に照らしたエラーや警告も示されます。保留中のドメインはまだ守られていません。ブラウザのリリースに含まれるのを待つ必要があります。
• chrome://net-internals/#hsts：Chromeで「Query HSTS/PKP domain」にドメインを入力します。static_で始まる項目はそのバージョンのブラウザに組み込まれたリストから、dynamic_で始まる項目はブラウザが受け取ったヘッダーから来ています。「Delete domain security policies」で消せるのは動的な部分だけなので、プリロードされたエントリーはブラウザのアップデートで外れるまで残ります。
• 他のブラウザ：Firefox、Safari、EdgeはChromeのリストから派生した独自のコピーを、それぞれの日程で配布します。そのため、追加や削除が届く時期はブラウザごとに異なります。

DNS、CDN、証明書を変更したら、もう一度確認してください。hstspreload.orgは、要件を満たさなくなったドメインが将来自動的に削除される可能性があるとしています。

8. リストから外れるには：削除の手順と期間

1. ベースドメインで、有効な証明書を使ったHTTPSの提供を続けます。削除フォームはこれを確認します。
2. preloadを外したHSTSヘッダーを送ります。hstspreload.orgはこのヘッダーを削除の申請として扱います。HSTSを続けたいならincludeSubDomainsと長いmax-ageはそのままにし、HSTSを完全にやめるならmax-age=0を送ります。
3. 削除フォームからドメインを申請します。
4. 待っている間に、削除を決めるきっかけになったサブドメインに有効な証明書を用意するか、別のドメインへ移します。削除が大半のChrome利用者に届くまで6〜12週間かかることがあり、他のブラウザではさらに長くかかります。
5. 再び登録したい場合を除き、preloadを二度と送らないでください。

max-age=0が効くのはHTTPSで送ったときだけで、再訪して受け取った利用者に限られます。最も遅いケースを前提に計画してください。組み込みのエントリーが残った古いブラウザや、保存済みの2年間のポリシーは、方針を変えた後も長くHTTPSを強制し続けることがあります。

9. 無料の公開準備スナップショットでわかること

無料の公開準備スナップショットは、登録不要で1つの公開ドメインに8項目の受動的なチェックを行い、スコアと各チェックの結果を返します。HSTSに関係するのは次の2つです。

• HTTPセキュリティヘッダーのチェックは、入力したドメインのトップページを、最大5回のリダイレクトをたどったうえで読み取ります。HTTPSの対象でStrict-Transport-Securityがなければ「中」と判定し、観測した値を表示します。
• リダイレクト状態のチェックは、ドメイン名だけ、またはhttps://のアドレスを入力した場合に、max-ageが180日（15,552,000秒）未満なら「低」として示します。計画の段階1〜3では、この結果になるのが想定どおりです。

includeSubDomains、preloadディレクティブ、サブドメイン、リストの登録状況はチェックしません。これらはhstspreload.orgと上記のcurlコマンドで確認してください。ヘッダーの結果を最初に開きたい場合は、同じスナップショットを実行する無料のセキュリティヘッダーチェッカーを使ってください。証明書についてはTLS証明書とHSTSの解説を、公開前の確認全体については、HSTSをリダイレクトやDNSと並べて扱うWebサイト公開前チェックリストを参照してください。