VPN 経由の最初のリクエストを HTTPS にする方法

最初に http:// と入力し、リダイレクト後に https:// に到達するブラウザは、すでに 一つのリクエストを平文で送信しており、VPN はそれを変更しません。トンネルはクライアントから出口ノードまでの区間を保護します、トランスポート層より上は何も暗号化されないため、出口と起点の間のオブザーバーには平文ホップが表示されます。最初のリクエストを HTTPS にすることは、実際の HTTPS アドレス、ブラウザのアップグレード モード、サイト独自のポリシーの 三つの部分からなるクライアント側の変更です。以下の手順は私が使用する順序であり、それぞれの手順に、完了したかどうかを示すチェックマークが付いています。

ステップ 1: 最初のリクエストが実際に何であるかを確認する

何かを変更する前に、ブラウザが送信する内容を確認してください。コールド キャッシュからリロードされたページでネットワーク パネルを開き、最初の行を読み取ります、スキームが http でステータスが 301 または 308 の場合、その行以降はすべて 二番目のリクエストになります。 curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com は、同じシーケンスをブラウザの外で再現し、最終的に表示された URL を出力します。

二つの結果が考えられ、それぞれに異なる修正が必要です。サイトが同じホスト上で HTTPS を提供している場合、解決策は HTTP フォームの公開を停止することです、ブックマーク、Wiki リンク、デスクトップ ショートカット、クリックする電子メール テンプレートを更新します。サイトが HTTPS をまったく提供しない場合、ブラウザの設定によって HTTPS が作成されることはありません、正直な答えは、宛先に問題があるということです。アカウント ページでの証明書の例外は、トランスポートの問題を資格情報の問題に変換するため、二番目のケースを例外として無視しないでください。設定を変更する前に、どのケースに該当するかを書き留めてください。

ステップ 2: ブラウザの HTTPS 専用モードをオンにする

アップグレード モードは 二番目の部分であり、モードは交換できません。有効にする前に、サイレント アップグレード、警告付きアップグレード、またはロードの拒否などの動作を確認してください。

Firefox では、コントロールは about:config の背後とプライバシー設定ページにあり、スイッチとして dom.security.https_only_mode が使用され、サイトごとの例外は南京錠メニューから管理されます。 Chrome と Edge では、同じ考えが [設定]、[プライバシーとセキュリティ]、[セキュリティ] の下にあり、[常に安全な接続を使用する] というラベルが付いています。ラベルが何であれ、ポート 80 でのみ応答するホストに対する動作を確認してください、アップグレードしてからサイレントにフォールバックするモードは、有効にしていると考えている保護ではないためです。 Firefox HTTPS 専用ドキュメントには、そのブラウザのアップグレード、警告、例外動作が詳しく記載されています。

ステップ 3: アドレス バーだけでなくリソースを修正する

アップグレードが失敗した場合は、アドレス バーではなく正確なエラーを読み取ります。 HTTPS リスナーのないホスト、証明書と一致しないホスト名、および期限切れのチェーンでは、異なるメッセージが生成され、異なる所有者に属します。最初のギャップのみがサーバー側のギャップです、 二番目は通常、更新されなかったブックマークです、 三つ目は、VPN 接続とは関係のない更新の問題です。

VPN がオンになっているため、アカウント サイトに証明書の例外を追加しないでください。この例外により、VPN が防止する予定の傍受を正確に検出するチェックが無効になります。

三番目の部分はページ内にあり、人々が見逃している部分です。 HTTPS 経由で読み込まれるページでも、http URL から画像、フォント、またはスクリプトを取得することができ、ブラウザーはそれらをブロックするか、ページ全体のセキュリティ インジケータをダウングレードします。ネットワーク パネルで失敗したリクエストを検査し、アドレス バーにすべてのリクエストが説明されていると想定するのではなく、その所有者でリソース参照を修正します。運営しているサイトでは、ブラウザで URL を書き換えるのではなく、CMS またはテンプレートに保存されている URL を修正することを意味します。ソースを変更できない場合は、混合コンテンツを既知のギャップとして記録します、平文リソースを取得するページ上の南京錠は誤った信号であるためです。

ステップ 4: HSTS で追加されるものと追加されないもの

HSTS はブラウザの設定ではなくサイト ポリシーであり、新しいプロファイルで入力された http:// が存続する唯一のメカニズムです。ブラウザーはホストの Strict-Transport-Security ヘッダーを認識すると、その後のリクエストを送信する前に https に書き換えます、これはまさに必要なプロパティです。ブラウザがアクセスしたことのないホストに対しては何も行われません、また、同じアプリケーションを提供する別のホスト名に対しては何も行われません。

オリジンが送信した内容を curl -sSI https://example.com | grep -i strict-transport-security で確認します。欠落しているヘッダーはサーバーの変更であり、クライアントがインストールできるものではありません。存在する場合は、max-age を読み取り、includeSubDomains が設定されているかどうかを確認します、これは、訪問間の最大有効期間が短く、 includeSubDomains が欠落しているとすべてのサブドメインが保護されないためです。 RFC 6797 は、ユーザー エージェントがポリシーを適用する方法と、ユーザー エージェントが無視できるものを定義します。プリロードは別のコミットメントであるため、ドメインがリストに載っていることを誰かに約束する前に、hstspreload.org API を通じてステータスを確認してください。

検証とロールバック

ロールバックは、クライアント設定にとっては安価ですが、HSTS にとっては高価です。 HTTPS 専用モードをオフにすると、以前の動作がすぐに復元されます、 max-age が長いとそうはならず、すでにそれを受け取った訪問者は有効期限が切れるまでアップグレードを続けます。

したがって、完了と呼ぶ前に、順番に確認してください。コールド キャッシュからリロードし、ネットワーク パネルの最初のリクエストが https であり、先行するリダイレクトがないことを確認します。次に、サブドメインを確認します、これは、通常、これらのポリシーが想定よりも狭いことが判明する場所が includeSubDomains であるためです。次に、サードパーティのアセットを取得する 一つのページを確認します、これは、混合コンテンツは他の修正が行われても残る失敗であるためです。

それをすべて行っても最初のリクエストが http のままである場合、クライアントはもはや変数ではなく、ユーザーがクリックするリンクが変数です。制御している場所で http 形式のホスト名を検索し、更新し、同じコールド キャッシュ リロードで再テストします。 トンネルによってリクエストを閲覧できる人が変わりますが、リクエストが暗号化されているかどうかは決して変わらないため、VPN の質問は全体を通して分けてください。チケットに含める行は、最初のリクエストが重要であり、リダイレクトはすでに送信されたリクエストの受信にすぎないということです。