HTTPSとHTTPの両方でサービスを提供しているサイトでHSTSを有効にするのは理にかなっているのでしょうか。
つまり、サイトがHTTPS経由でアクセスされている場合は、HSTS-Headerを追加します。ただし、HTTPからHTTPSへのリダイレクトはありません。サーバーはHTTPを介してWebサイトも提供します(もちろんHSTSヘッダーはありません)。
私の目標:
つまり、HTTPSが壊れているユーザーにはHSTSヘッダーが表示されず、HTTPS経由で自分のWebサイトに一度アクセスしたユーザーは将来的にHTTPSを使用する必要があります。
HTTP経由で送信されたHSTSヘッダーは、仕様に準拠したブラウザーでは無視されます。これは、ブラウザーでHSTSルールを設定することにより、中間者が訪問者が非HTTPS Webサイトにアクセスできないようにするためです。 ( RFC 6797 を参照)
したがって、技術的に正しくない場合でも、安全にHSTSヘッダーをすべてのユーザーに提供し、HTTPとHTTPSを介して同じページを提供し、安全でないページから安全なページに意図的にリダイレクトしないでください。
これにより、HTTPSバージョンにアクセスした訪問者は(少なくともヘッダーの期間中は)今後のアクセス時に強制的にそのサイトに戻され、故意にHTTPバージョンにアクセスした訪問者はそのまま残ります。いずれかの時点でHTTPSバージョンへのリンクをたどると、将来的にHTTPSに強制されます。
それが理にかなっているかどうかに関しては、それはあなたの目的とあなたの訪問者に依存します-あなたは壊れたプロキシから多くの訪問者を持っていますか?一部のページで不快感を与える可能性のある情報を提供していますか?
個人的には、私は安全なバージョンを提供し、安全でないサイトからのリダイレクトを強制します。特に、検索エンジンは安全なサイトを優先する方向に動いているようです。
HSTSヘッダーは、サイトがHTTP経由でアクセスされている間は効果がありません。
HSTSの目的は、ブラウザにサイトをHTTPS経由で強制的にロードすることです。HTTP経由でサイトを表示するオプションは直観に反しています。
HTTPSとHTTPの両方でサービスを提供しているサイトでHSTSを有効にするのは理にかなっているのでしょうか。
私はHSTSについて完全に確信しているわけではありませんが、そうだと思います。
(アイデア自体は健全です。これは、「 Opportunistic Encryption 」が想定しているものに似ています。少なくとも一部の接続に少なくともある程度の量の暗号を使用することにより、攻撃者の作業を困難にします。)
RFCの要約には次のように書かれています。
この仕様は、Webサイトが安全な接続を介してのみアクセス可能であることを宣言したり、ユーザーがユーザーエージェントに安全な接続を介してのみ特定のサイトと対話したりできるようにするメカニズムを定義します。
そして、文の「および/または」のビットはここで重要に思われます。
HSTSでできることは、次のように宣言することです:このサイトは、すべてHTTPSです。このサイトは、ファイアウォールがポート80へのすべての接続をブロックしている場合でも機能します。そして、後から考えます:プレーンなHTTPリンクがどこかに残っているかどうかここでは、それは間違いです。静かにHTTPSにアップグレードしてください。
そして、このsilent-upgrade-xor-failureビットは、彼らがここで与えるシナリオからあなたを救うでしょう:(セクション2.3.1.3)
サイトの開発者がログインページで「混合コンテンツ」を注意深く精査したとしても、攻撃者がコード(例: 、スクリプト)を別の安全に読み込まれていないサイトページに挿入します。
サーバーはクライアントをHTTPSにリダイレクトすることが期待されていますが( セクション7.2 ):
HSTSホストが非セキュアなトランスポートを介してHTTP要求メッセージを受信した場合、恒久的なリダイレクトを示すステータスコードを含むHTTP応答メッセージを送信する必要があります。
...これは必須ではなく、SHOULDです。
つまり、要約すると、はい、あなたが求めていることは、HSTSの可能な使用と正当な使用の両方である必要があります。
別のこと:サイトのHTTPSバージョン(たとえば、自宅から)とサイトのプレーンHTTPバージョン(たとえば、オフィスのWIFIから)の両方を使用するラップトップユーザーをサポートする場合は、HSTSタイムアウトを設定する必要があります。十分に低い。 (おそらく数分。)