AWS ELBアプリケーションロードバランサーでHSTSを有効にする
IISデプロイされたWebアプリケーションに対してHSTSを有効にします。
SSL終端のELBアプリケーションロードバランサーがあります。 IIS）でURL書き換えモジュールを有効にし、応答でHSTSヘッダーを決定して有効にするようにx-Forward-Protoタグを構成しました。
現在、ALBはIISからALBに、エンドユーザーにカスタムヘッダーを渡すようには見えません。ALSレベルでHSTSを有効にする方法があるかどうかを確認したかったので、カスタムヘッダーを受け入れるか、IISレベルで設定でき、ALBがHSTSヘッダーをブラウザーに渡すことができるかどうか。
HSTSは、ロードバランサーではなくバックエンドによって制御されるポリシーです。 AWSがこれを可能にする可能性があると主張することもできますが、これをより複雑にする他の問題があります（仕様違反、HTTPの永続的なリダイレクトなど）。
HSTSの問題は、HTTP経由でStrict-Transport-Securityを送信できない（できない）ことです。仕様では、安全な接続でのみヘッダーを送信するように規定されています。 HTTPは安全ではありません。ロードバランサーはHTTP経由でバックエンドと通信しているため、IISはヘッダーを送信していません。HSTSを有効にするには、バックエンドでHTTPSを使用する必要があります。
「Strict-Transport-Security」をクライアントに送信することが目的である場合は、ロードバランサーでレイヤー4リスナーを使用し、バックエンドでHTTPSを処理します。リクエストがHTTPで到着した場合、永続的なリダイレクト（301）を送信します。利点には、絶対制御、改良されたHTTP/2などが含まれます。
別のオプションは、HTTPSを使用してバックエンドと通信するようにリスナーを変更することです。バックエンドでHTTPSとSSLをセットアップします。
これはOPが使用したアプローチのようですが、何らかの理由でヘッダーが渡されませんでした。このアプローチが確実に機能することを確認し、詳細を追加したいだけです。
HTTP経由でバックエンドサーバーにHSTSヘッダーを設定することは完全に可能です。結局のところ、これは他のヘッダーと同じで、サーバーは喜んでそれを送信します。
ただし、HSTS仕様に従って、ブラウザはHTTP応答で受信したHSTSヘッダーを無視します。
しかし、それを機能させる方法があります。まず、HSTSヘッダーを送信するようにバックエンドサーバーを構成します。
次に、Application Load BalancerがHTTPSでリッスンしているが、ターゲットグループ（およびバックエンドサーバー）がHTTPであると想定すると、次のようになります。
- ブラウザがHTTPS経由でALBにリクエストを送信する
- ALBはリクエストをHTTP経由でバックエンドに転送します
- バックエンドサーバーは、HSTSヘッダーを含む応答をHTTP経由でALBに送信します
- ALBは同じ応答+ヘッダーをブラウザーに送信しますHTTPS経由。
したがって、ブラウザーはHTTPS経由で応答とHSTSヘッダーを受信し、HSTSに従います。
これを行うことに対する反対論は、HTTPを介してHSTSヘッダーを送信しないことです。ただし、同じ議論があなたのウェブサイト全体に当てはまります。誰もHTTP経由でインターネットにウェブサイトを提供するべきではありません。 ALBでHTTPSを終了し、バックエンドサーバーをHTTPで実行するのが安全であると考える場合は、同じ方法でHSTSヘッダーを送信しても安全です。
注：HSTSを使用している場合は、ほぼ確実にHTTPからHTTPSへのリダイレクトが設定されています。 HSTSヘッダーはHTTP経由のリダイレクトと共に送信されますが、ブラウザーはそれを無視することに注意してください。リダイレクトが発生し、HSTSヘッダーがHTTPS経由で送信されると、ブラウザーはそれに従います。
技術的には RFC6707セクション7.2 に従い、HSTSヘッダーをプレーンHTTP経由でブラウザーに送信しないでください。 すべきすることは、ヘッダーの設定を X-Forwarded-Proto 要求ヘッダー値に基づいて条件付きにすることです。