HSTS(HTTP Strict-Transport-Security)について

情報処理安全確保支援士試験にて出題されたHSTSについて、改めて調べてみました。

今回は有効化するにあたって確認・検討するべき事項を挙げます。
次回は有効化時の確認事項をまとめています。

HSTSの効果

※RFC6797 2.2 HTTP Strict Transport Security Policy Effects より

• UA（ユーザーエージェント）は、不セキュアなURI参照をHSTSホストに対してセキュアなURI参照に変換してから、それらのURIを使って実際のリソースにアクセスします。
• UAは、証明書エラーや警告が発生した場合には、すべてのセキュアな接続の試行を終了します。

簡単に言えば、HTTPによるアクセスをHTTPSに切り替えること、証明書エラー発生時にUAがユーザーを介さずに通信を終了させることです。

HSTSの設定イメージ

HSTSのルールに従うのは、UA（Webブラウザなど）側なので、サーバーでの実装はシンプルです。HTTPSでリクエストが来るたびに Strict-Transport-Security ヘッダを応答するように設定するだけです。

リバースプロキシによって特殊な処理を行うものではありません。

HSTSを設定するにあたってのタスク

参考程度に、HSTS設定時のタスクを抽出してみます。

HSTSを利用するための最終的な目標はHSTSプリロードを利用することです。プリロードにあたって、Googleが公開している条件を満たすことを目標にします。

下記サイトからHSTSプリロードの要求ができます。
https://hstspreload.org/

HSTSのプリロードを利用する場合には、下記条件を満たす必要があります。（2024年5月現在）

1. 有効な証明書を提供します。
2. ポート 80 でリッスンしている場合は、同じホスト上で HTTP から HTTPS にリダイレクトします。
3. すべてのサブドメインをHTTPS 経由で提供します。
   • 特に、wwwサブドメインの DNS レコードが存在する場合は、サブドメインに対して HTTPS をサポートする必要があります。
   • 注: HSTS プリロードは、公開アクセスできない内部サブドメインを含むすべてのサブドメインに適用されます。
4. HTTPS リクエストのベース ドメインで HSTS ヘッダーを提供します。
   • max-age少なくとも31536000秒数（1年）である必要があります。
   • ディレクティブincludeSubDomainsを指定する必要があります。
   • ディレクティブpreloadを指定する必要があります。
   • HTTPS サイトから追加のリダイレクトを提供する場合、そのリダイレクトには HSTS ヘッダー (リダイレクト先のページではなく) が含まれている必要があります。

行うべきこと

• HTTPリクエストをHTTPSへリダイレクトする設定をする

例えば、 http://www.example.com/home へのリクエストを受けた際に、 https://www.example.com/home にリダイレクトする設定を行います。HTTPとHTTPSで異なるコンテンツを応答しないか事前に確認する必要があります。自分の環境にあった設定を調べて設定をするようにしましょう。

• Strict-Transport-Security の書くディレクティブの値を決める

• max-age: 31536000以上にします。
• includeSubDomains: 設定します。影響範囲はアクセスしたURLのFQDNを基準に、それ以下のサブドメインへもHSTSを有効化します。
  • HSTSを有効化した example.com へアクセスした場合： *.example.com を対象にHSTSが有効化されます。
  • HSTSを有効化した www.example.com へアクセスした場合： *.www.example.com を対象にHSTSが有効化されます。
    ホスト名ごとに管理している担当者が違う場合、ほかのシステムへ影響（悪いものに限らず試験の結果が変わってしまうなど）が考えられるため、有効化するときには、事前に話を通しておきましょう。
• preload: 設定します。本番環境で設定したら忘れずに、既出のリンクからプリロードのリクエストをしておきましょう。

※HSTSプリロードの削除は簡単にはできないようですので、注意をしましょう。

各種ミドルウェア、クラウドサービスのHSTS有効化方法

• nginx: HTTP Strict Transport Security (HSTS) and NGINX
• apache:
  • mod_headers のドキュメント
  • SSL How-To
  • Red Hatのドキュメント
• BIG-IP: How to enforce HTTP Strict Transport Security (HSTS) on a virtual server
• AWS: Amazon CloudFront が設定可能な CORS、セキュリティ、およびカスタム HTTP レスポンスヘッダーをサポート
• GCP: HTTPSロードバランサの設定
• Azure: Azure Front Door のセキュリティヘッダー
• さくらインターネット: カスタムレスポンスヘッダーの設定

具体的なヘッダの値については、下記MDNのサイトを参照ください。

https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security

備考：HSTS利用時の特徴的な挙動

・UA（ユーザーエージェント）は、不セキュアなURI参照をHSTSホストに対してセキュアなURI参照に変換してから、それらのURIを使って実際のリソースにアクセスします。

HSTSが有効化になっていることをブラウザが把握している状態で、HTTP通信を試みると以下のように307ステータスコードによりHTTPSへリダイレクトされます。

・UAは、証明書エラーや警告が発生した場合には、すべてのセキュアな接続の試行を終了します。

通常の証明書エラー

HSTS利用時の証明書エラー

次回：HSTS有効化時に確認するべきこと