第三者による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の「Submission Requirements」の項には追加で

• 証明書が有効であること
• HTTPからHTTPSへは同じホストにリダイレクトすること
• すべてのサブドメインでHTTPS接続できること
• HTTPSからのリダイレクト時は、リダイレクト元にもHSTSヘッダがあること

などの条件が記されていた。

なお、すべてのサブドメインについて調べることはできないので、実際の動作としてはwwwサブドメインを決め打ちでチェックする(wwwで名前解決できる場合はチェックする)、という動作をしているようだ。

その他、実際にいくつかのドメインを入力してみたときの動作から、

• Strict-Transport-Securityヘッダが2個以上存在しない
• http://example.comからのリダイレクト回数が3回以内

という条件も必要であることが判明した。

現状調査

適当な政府や企業サイトのドメインについて調査したところ、かなり多くのサイトでHSTS Preload Listに登録されていないにもかかわらず、Strict-Transport-Securityヘッダにpreloadディレクティブが指定されていた。 しかしながら

• includeSubDomainsディレクティブが指定されていない
• max-ageディレクティブの値が1年以下

といったHSTSヘッダ自体の要件を満たしていないもののほか、

• 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はもはや推奨されていない。¹

一方で、後から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) 日本語訳