ある日、ローカルでカスタムドメインを設定したら、謎のエラーが！？ HSTSプリロードの罠とその回避法

なんじゃこりゃ！？カスタムドメインでオレオレ証明書ローカルホストを実行中に謎の警告画面

開発を進めているある日、ローカルで設定したカスタムドメイン（例: https://hogehoge.com）にアクセスしたら、なんと！画面にはいつもの警告文ではない見慣れないエラーが…。ブラウザがいつもの信頼されていない証明書の警告文ではなくHSTSという見慣れない文字！おかしいいつもと違う、、、
この背後にはHSTSプリロードの罠が潜んでいるのです。

---

HSTSとは？ユーザーを守るセキュリティの盾

まずはこの仕組みの正体、HSTS (HTTP Strict Transport Security) から解説していきましょう。

HSTSって何？

HSTSは、Webサイトがブラウザに「このサイトには常にHTTPSで接続してくださいね！」と命令する機能です。この指令を受けたブラウザは、次回からHTTPでのアクセスをHTTPSに自動的にリダイレクトし、安全な通信を保証します。

HSTSの利点とは？

1. セキュリティ強化: HSTSがあれば、悪意のある攻撃者がHTTP通信に介入する「SSLストリッピング攻撃」を防げます。

   • 例: 銀行サイトで「http://mybank.com」にアクセスすると、通常はHTTPで最初に接続されるのが、HSTSにより「https://mybank.com」に即リダイレクト。安全な通信を保証します。

2. 安全なユーザー体験: HSTSが設定されたサイトは、常にHTTPS接続が強制されるため、ユーザーが不用意にHTTPでアクセスしてしまうリスクがゼロになります。ユーザー体験がスムーズで、安全性もばっちりです。

3. ブラウザの警告回避: HSTS対応サイトは、HTTPで接続する際に警告を出さず、スムーズなHTTPS接続が可能です。

HSTSプリロードとは？

HSTSのさらなる進化形が、HSTSプリロードです。「常にHTTPS接続を強制したい」サイトの管理者は、自分のドメインをHSTSプリロードリストに登録できます。このリストに入ったドメインは、なんとブラウザが最初のアクセスからHTTPSを強制するんです。

プリロード登録のメリット

HSTSプリロードリストに登録されたサイトは、ブラウザに組み込まれるため、どんな状況でもHTTPSが強制され、より強力なセキュリティを提供します。例えば、ユーザーがHTTPで接続しようとしても、ブラウザが「いやいや、ここはHTTPSでいくよ」と勝手に安全な通信に切り替えてくれ、さらに信頼できない証明書の接続を拒否します。

でも、ちょっと待って！ローカルのテスト環境ではトラップに？

HSTSプリロードドメインをローカルホストのカスタムドメインとして設定し、そのドメインで自己署名証明書(オレオレ証明書)を使用してHTTPS接続を試みると、ブラウザは接続エラーを起こします。

エラーの原因

HSTSプリロードリストに含まれているドメインでは、以下のポリシーが適用されます：

1. HTTPS接続の強制
   対象のドメインでは、HTTP接続が自動的にHTTPSにリダイレクトされます。

2. 有効な証明書の必要性
   HSTSは、信頼された認証機関（CA）によって発行された証明書を要求します。自己署名証明書は信頼されていないため、ブラウザはこれを拒否します。

そのため、HSTSプリロードに登録されているカスタムドメインを使用すると、ブラウザは自己署名証明書を許容せず、証明書エラーとなります。さらに、最初に表示した画面のようにHSTSにより通常の証明書エラーのように「続行」を選んで無視するオプションもありません

回避策

では、HSTSプリロードの罠を避けてローカルテスト環境を構築するにはどうすれば良いのでしょうか？以下に、シンプルで効果的な回避策を紹介します。

回避策1: プリロードに登録されていないカスタムドメインを使用する

最も確実な方法は、HSTSプリロードリストに載っていないドメインをカスタムドメインとして使用することです。例えば、.localhost や .test といったHSTSに影響されないドメインを設定するのが理想的です。

手順

1. hostsファイルを編集して、ローカルIPにカスタムドメインを割り当てます。

   • Windows: C:\Windows\System32\drivers\etc\hosts
   • macOS/Linux: /etc/hosts

2. myapp.localhostを例に、以下のように設定します。

   127.0.0.1   myapp.localhost
   

3. サーバー設定で myapp.localhost も認識するように設定します（例えば、Apacheやnginxの設定ファイルを変更）。

回避策2: 開発用ブラウザを別途用意する

HSTSポリシーが設定されていない、別のブラウザや開発用のブラウザ（Firefox Developer Editionなど）を利用してHTTP通信のテストを行うことも検討できます。
しかし通常は別のドメインを使うほうが手軽で効果的です。

まとめ

HSTSとHSTSプリロードは、Webのセキュリティを強化するための非常に便利な仕組みですが、開発者にとってはテスト環境での落とし穴になりかねません。HSTSプリロードリストに載っていないカスタムドメインを利用することで、スムーズで安全なテスト環境が構築でき、HSTSの恩恵を享受しながら開発に集中することができます。

参考文献

HSTSとHSTSプリロードについてもっと詳しく知りたい方は、以下の公式リファレンスを参考にしてください。

1. HSTS仕様 - RFC 6797
   RFC 6797: HSTSの詳細仕様が記載されたドキュメントです。

2. Google Chrome HSTS Preload List Documentation
   Chrome HSTS Preload: HSTSプリロードリストの仕組みについて解説しています。

3. Mozilla Developer Network (MDN) - HTTP Strict Transport Security (HSTS)
   MDNのHSTSページ: HSTSヘッダーの設定方法と活用法が紹介されています。

---