HSTS と Preload list
SSL/TLSは認証と暗号化通信を実現する、言うまでもなくインターネットにおいて最も重要な技術の一つです。これが無ければインターネットの業務利用（余談ですがいまだに通常の非暗号化メールが普通に使われているのがとてもとてもとても疑問です。あれは盗み見られる可能性を業界全体で目をつむったことになっているのでしょうか・・・）はあり得ませんでしたし、電子商取引に代表される様々なサービスやSaaS、パブリッククラウドというものが世に定着することもなかったでしょう。
仕事柄SSL/TLSに対応していないサービスとどう付き合うべきか？と相談をいただきますが、それがOT(Operational Technology: インターネットとの接続を意識していない工場等でシステムを制御する技術の総称）等の特殊IT環境ではない場合、「付き合うのをやめましょう」と言い切っています。
HSTS (HTTP Strict Transport Security)
ウェブサイトにブラウザなどのクライアントがアクセスした際に、リクエスト非SSL/TLSであった場合、ウェブサイトからのレスポンスヘッダーに特定の値を入れることで、クライアントからの接続要求を強制的にTLS化させ、TLS通信を強制するものです。
(https://www.acunetix.com/blog/articles/what-is-hsts-why-use-it/)
ウェブサイトでの設置漏れを防ぐようにCDNのCloudflare等ではデフォルトでウェブサイトのレスポンスヘッダーにHSTSヘッダーを挿入することを強制する機能を提供しています。
これはRFC6797で定義された挙動です。
また最近のブラウザはHSTSの指定関係なく、優先的にTLS接続を試みる実装がなされています。例えば example.com とアドレスバーに入力した場合、優先的にhttps://example.com へのTLS接続を試みて、失敗した場合http://example.com への接続を行っています。(Chromeではデベロッパーツールを開いた状態ではこの動作は再現しませんので注意してください。）
Preload List
ではブラウザでデベロッパーツールを開いた状態で http://www.google.com にアクセスしてみます。
前述の通り２回接続が出力されています。
１回目の接続施行ではHTTP307 Internal Redirect が戻っています。この際InitiatorがOtherとなっていることに注目してください。レスポンス時間も1msとなっており、実際外部と通信していないことがわかります。
そして２回目の接続でセッションが確立しHTTP200が戻っています。
通常HSTSではサーバからの以下のレスポンスヘッダーが戻ることでブラウザは再度TLSでの接続を試みます。
Strict-Transport-Security: max-age=31536000;
ただし今回の例だと以下の変わった値がResponseとしてセットされています。
これは Preload List というもので制御されているためです。
Preload List とはブラウザに内蔵されているあらかじめTLS接続を必須化するドメインリストのことです。
リストの管理はこのサイトで行われており、例えばサービス事業者が自分たちのドメインをTLS必須化したい場合ここから申し込み審査が通ればPreload List に登録されます。
その一覧はブラウザに関係なくGoogleで管理されており（ただしそのリストの内どれを内蔵させるかはブラウザ依存）https://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json
で確認可能です。
ものすごい大量のドメインが管理されています。例えばwww.xxx.comのように特定サービスのドメインもあれば*.dev等のようにTLD (Top Level Domain)毎登録されているものもあります。またChromeでれば内蔵されているPreload List はchrome://net-internals/#hstsから確認可能です。
重要なことですがPreload Listに登録されているドメインとの非TLS通信はブラウザ側で許可していません。httpと指定しても最初から強制的にhttpsに接続を行います。
が1msでレスポンスが戻っているのはそのためです。（外部通信前にブラウザ内部で判断されている）
Preload list のメリット
HSTS レスポンスヘッダーよりPreload ListでのTLS強制化の方がメリットが高い理由が一つあります。
Preload Listに登録されていないドメインに非TLS接続のリクエストを行った場合、初回接続試行の後サーバからhttps://www.xxxxx.comへ接続しなおしなさいという指示がレスポンスヘッダーで戻ってきます。この時にこの通信は暗号化されておらず改竄が可能です。結果としてブラウザが２回目の接続施行としてhttps://www.xxxxx.badsite.comへ誘導される可能性があります。このためサービス提供事業者は自社サービスドメインをPreload Listに登録しておく方が安全と言えます。
またPreload list設定を持たないクライアントからの接続が想定される場合もあるためHSTSはレスポンスヘッダーとして設定しておくことが推奨されます。なぜなら先ほどご紹介したhttps://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json を見るとわかる通りこのリストはとても大量で17MBあり、今後も増えていきます。IoT環境などだとコンピュートリソースや電源の節約のためにリストを持たないケースもあるためです。
Discussion