第三者によるHSTS Preload Listへの勝手な登録についての考察
HSTS(HTTP Strict Transport Security)とは、ウェブサイトへの接続でHTTPSを使用するようブラウザに強制するための仕組みであり、中間者攻撃を防ぐための効果的なセキュリティ対策である。
ただし、最初の1回目の接続についてはHTTPで行われる可能性が残るため、初回からHTTPSによる接続を強制するドメインのリストをブラウザに組み込んでしまおう、というのがHSTS Preload Listであり、
Strict-Transport-Security
ヘッダにpreload
を追加する他にいくつかの要件を満たすことで登録を申請できるようになる。
この申請時にはドメインの所有権の確認などの手続きが行われないため第三者による勝手な登録が可能であり、これが問題になるのかどうかを考えた。
HSTS Preload Listに登録できる条件
Strict-Transport-Security - HTTP | MDNによると
Strict-Transport-Security
ヘッダにpreload
ディレクティブが含まれているStrict-Transport-Security
ヘッダのincludeSubDomains
ディレクティブが含まれているStrict-Transport-Security
ヘッダのmax-age
ディレクティブが31536000
(1年)以上である
を満たすようにすれば良いとされているが、実際のHSTS Preload List Submissionにいくつかのドメインを入力してみたときの動作とエラーメッセージから推測すると、HSTS Preload Listに登録できるようになるためには、おおよそ以下のような条件を追加で満たす必要があるようだ。
例として、example.com
をHSTS Preload Listに登録するようにSubmission Formに入力した場合、
example.com
とwww.example.com
のどちらにもウェブサイトが存在するhttp://example.com
にアクセスするとLocation
ヘッダによりhttps://example.com
にリダイレクトされる
(http://www.example.com
やhttps://www.example.com/
にリダイレクトされない)Strict-Transport-Security
ヘッダが2個以上存在しない
などの条件が必要であることが判明した。
現状調査
適当な政府や企業サイトのドメインについて調査したところ、かなり多くのサイトでHSTS Preload Listに登録されていないにもかかわらずpreload
ディレクティブが指定されていた。
しかしながら
includeSubDomains
ディレクティブが指定されていないmax-age
ディレクティブの値が1年以下
といったHSTSヘッダ自体の要件を満たしていないもののほか、
www.
付き、もしくはwww.
なしのどちらかにしかウェブサイトが存在しないwww.
付き、もしくはwww.
なしのどちらかにしか有効なStrict-Transport-Security
ヘッダが存在しないhttp://example.com
からhttps://www.example.com
にリダイレクトしているStrict-Transport-Security
ヘッダが2個以上存在している
などの理由で、HSTS Preload Submissionでは弾かれるものが多かった。
一方で、いくつかのサイトではHSTS Preload Listに登録できる条件をすべて満たしていながらも、未登録となっているものを少数ながら発見した。
そのようなサイトは第三者が勝手にPreload Listへの登録申請が可能である。

実在するサイトのドメインを入力した例
勝手に登録された場合の影響
有効なHSTSが設定されている場合、ブラウザは必ずHTTPSを使用し、また証明書エラーを無視できなくなる。
そのため、サブドメインで社内向けにHTTPのみでウェブサイトを公開している場合や、HTTPSであっても自己署名証明書をPCの証明書ストアに登録せずにエラーを無視して閲覧させていた場合に閲覧できなくなる、といった影響は考えられる。
ただし、HSTS Preload Listが効果を発揮するのは初回接続時のみであり、ユーザが事前に1回でもhttps://example.com/
やhttps://www.example.com/
にアクセスしていた場合は、
HTTPのみのサイトや自己署名証明書を使ったHTTPSのサイトは表示できないのは同様であり、
第三者が勝手にHSTS Preload Listに登録してしまったとしても影響は小さい。
これはHSTS Preload自体にそこまで効果がない、と言っていることと同じではあるが、HSTS Preload List Submissionにも
The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS.
と書かれている。それどころか、
While HSTS is recommended, HSTS preloading is not recommended.
と、HSTS Preloadはもはや推奨されていない。1
一方で、後からHSTS対応をやめたいとなった際に、HSTS Preload Listに登録していなければincludeSubDomains
を消したりmax-age
を短くすることでHSTS状態を更新して無効化できるのだが、
HSTS Preload Listに登録されてしまっている場合は無効化するまでに時間がかかってしまう点が問題となるケースは考えられる。
しかしこのケースにおいても、正攻法(HTTPS対応する)や回避策(別のドメインを使うなど)による対策はできる他、単純に無効化されるまで待てばよいので、現実的には大きな問題となるとは考えにくい。
対策
HSTS Preload Listからの削除について書かれたHSTS Preload List Removalによると、
If you want to be removed from the preload list but do not completely want to disable HSTS, it is up to you whether you would like remove the includeSubDomains directive or change the max-age value, as long as you remove the preload directive.
とあり、意訳すると「まずはpreload
ディレクティブを消した上で、includeSubDomains
を消すかとmax-age
の値を変えるのかはお好みでどうぞ」と言っている。
したがって、HSTS Preload Listに登録されたくない場合も同様に考えて、単純にStrict-Transport-Security
ヘッダにpreload
を入れないのが最も簡単で確実な対策ではないか、と考えられる。
Strict-Transport-Security
ヘッダにpreload
を指定しておきながら、Strict-Transport-Security
ヘッダやStrict-Transport-Security
ヘッダ以外の要件を満たさないことによって第三者によるHSTS Preload Listへの登録を防ぐよりは、シンプルで良いと考える。
結論
専門家ではない人間が調べた限りではあるが、結論としては以下になるのではないだろうか。
- ヘッダに
preload
を入れていると第三者が勝手にHSTS Preload Listに登録してしまう可能性がある。 - 勝手にHSTS Preload Listに登録されてしまった場合、HSTS対応をやめる際に時間がかかってしまうが、現実的に大きな問題になることは考えにくい。
- HSTS Preload Listに登録することを目指していないのであれば、
preload
を入れないほうが良い。 - そもそもHSTS Preloadが非推奨となっている。
その他参考
- RFC 6797 - HTTP Strict Transport Security (HSTS)
- RFC 6797 - HTTP Strict Transport Security (HSTS) 日本語訳
-
いつの間に非推奨になったのかと思ってWayback Machineで調べたところ、2025年1月23日と2025年1月24日の間に更新された模様。 ↩︎