nginx で HSTS を有効にしてブラウザを HTTPS アクセスにリダイレクトする方法の詳細な説明

前回の記事では、https を使用したローカルノードサービスアクセスを実装しました。前回の記事の効果は次のように確認できます。

しかし、現在 http を使用してアクセスすると、アクセスできません。次の図に示すように:

そこで、まず最初に nginx 設定を使用する必要があります。ユーザーがブラウザに http リクエストを入力すると、nginx を使用して https にリダイレクトします。そこで、簡単な nginx リダイレクト関数を作成する必要があります。

したがって、nginx に次のリダイレクト設定を追加する必要があります。

サーバー{
 xxx.abc.com を聴く;
 サーバー名 xxx.abc.com;
 ^/(.*)$ https://$host$1 を永続的に書き換えます。
}

したがって、nginx の主な設定コードは次のようになります。

サーバー{
 xxx.abc.com を聴く;
 サーバー名 xxx.abc.com;
 ^/(.*)$ https://$host$1 を永続的に書き換えます。
}
サーバー{
 443 ssl を聴く;
 サーバー名 xxx.abc.com;

 ssl_certificate cert/server.crt;
 ssl_certificate_key cert/server.key;

 ssl_session_cache 共有:SSL:1m;
 ssl_session_timeout 5分;

 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers をオン;

 位置 / {
 proxy_pass http://localhost:3001;
 }
}

上記の設定後、設定を有効にするには nginx を再起動する必要があります。ブラウザにドメイン名 http://xxx.abc.com を入力すると、自動的に https://xxx.abc.com/ にリダイレクトされます。ネットワーク上のリクエストを見てみましょう。以下に示すように、2 つのリクエストがあります。

上記のリクエストからわかるように、ブラウザは最初に Web サイト (http://xxx.abc.com) への http リクエストを開始し、リダイレクト応答を受信した後、https リクエストを開始して最終的な応答コンテンツを取得します。ユーザーにとって、その操作は透過的でユーザー エクスペリエンスは良好ですが、https リンクの前にプレーンテキストの http リクエストとリダイレクトが行われます。その後、攻撃者は中間者攻撃によって http リクエストをハイジャックすることができます。その後の攻撃を実行する。たとえば、データの盗聴などです。リクエストや応答の改ざん、フィッシングサイトへのジャンプなど。そのため、http リクエストは十分に安全ではないため、近年ではすべての Web サイトは https 経由でアクセスする必要があります。

一般的なハイジャックのプロセスがどのようなものかを確認するために、HTTP リクエストのハイジャックとフィッシング Web サイトへのジャンプを例に挙げてみましょう。

手順は次のとおりです。
1. ブラウザは http リクエスト (http://xxx.abc.com など) を開始します。リクエストが送信された後、攻撃者は中間者として http リクエストをハイジャックします。
2. 攻撃者は、http リクエストをハイジャックした後、現在のリクエストをフィッシング Web サイト (http://xxx.yyy.com など) に転送します。
3. フィッシング Web サイトは偽の Web ページ コンテンツを返します。
4. 最後に、攻撃者は偽の Web ページのコンテンツをブラウザに返します。

上記のように、http リクエストは https ウェブサイトにリダイレクトされません。代わりに、攻撃者は http リクエストを直接ハイジャックし、最終的にフィッシング ウェブサイトをブラウザーに返します。そのため、HTTP リダイレクトを直接使用すると、プレーンテキストの HTTP リクエストの問題が発生します。したがって、HTTP リダイレクトを直接使用するのは安全ではありません。そのため、HSTS がこの問題を解決すると思われます。 HSTS を見てみましょう。

2. HSTS を理解する

上記のリダイレクト方法を使用して http を https にリダイレクトすると、https にリダイレクトする前に http プレーンテキスト リクエストが存在するため、攻撃者が http リクエストをハイジャックしやすくなるというセキュリティ上の問題があります。そのため、ユーザーのブラウザーが http リクエストを開始したときに、ブラウザーがそれを https リクエストに直接変換するようにする必要があります。次に、https 経由でページをリクエストします。これにより、攻撃者が攻撃することが一般的に困難になります。下図のような概略図を見てみましょう。

手順は次のように理解できます。

1. ユーザーがブラウザに http://xxx.abc.com と入力すると、ブラウザはドメイン名が通信に https を使用する必要があることを認識します。
2. したがって、ブラウザは Web サイト (https://xxx.abc.com など) への https リクエストを直接開始します。
3. ウェブサイトは応答コンテンツを返します。

では、問題は、ブラウザはドメイン名に https を使用する必要があることをどうやって知るのかということです。現時点では HSTS があります。

HSTS とは何ですか?

HSTS の正式名称は HTTP Strict-Transport-Security です。これは、国際インターネットエンジニアリング組織 IETF によってリリースされたインターネット セキュリティ ポリシー メカニズムです。 HSTS ポリシーを採用している Web サイトでは、ブラウザーが常に Web サイトの https 暗号化バージョンに接続するようになります。セッションハイジャックのリスクを軽減するために、ユーザーは URI アドレスバーに暗号化されたアドレスを手動で入力する必要がありません。

HSTS の基本的な構文は次のとおりです。

厳格なトランスポートセキュリティ: max-age=expireTime [; includeSubDomains] [; preload]

max-age は必須パラメータです。秒単位の値です。これは HSTS ヘッダーの有効期限を表し、通常は 1 年、つまり 31536000 秒に設定されます。
includeSubDomains はオプションのパラメータです。このパラメータが設定されている場合、現在のドメインとそのサブドメインに対して HSTS 保護が有効になっていることを意味します。
preload はオプションのパラメータであり、ブラウザの組み込みリストにドメイン名を追加する場合にのみ必要です。

次に、Baidu がこれをどのように処理するかを見てみましょう。まず、ブラウザの URI に http://www.baidu.com/ と入力して Enter キーを押します。ブラウザは自動的にこれを https://www.baidu.com/ のようなリクエストに変換します。ただし、Chrome ブラウザを使用してネットワーク リクエストを表示すると、次のように 2 つのリクエストが送信されることがわかります。

2 番目は、次に示すように https リクエストです。

上記から、最初のリクエストのステータス コードは 307 であり、リクエスト ヘッダーには「暫定ヘッダーが表示されています」というマークが付いていることがわかります。これは、ブラウザーがリクエストを傍受し、リクエストが送信されなかったことを意味します。したがって、ブラウザはドメイン名を https を使用して要求する必要があると判断し、2 番目の https 要求を送信します。

nginxでHSTSを設定する

nginx 構成ファイルで HSTS 応答ヘッダーを設定します。コードは次のとおりです。

add_header 厳格なトランスポート セキュリティ "max-age=172800; includeSubDomains"

したがって、nginx の構成は次のようになります。

サーバー{
 xxx.abc.com を聴く;
 サーバー名 xxx.abc.com;
 ^/(.*)$ https://$host$1 を永続的に書き換えます。
}
サーバー{
 443 ssl を聴く;
 サーバー名 xxx.abc.com;
 add_header Strict-Transport-Security "max-age=172800; includeSubDomains";
 ssl_certificate cert/server.crt;
 ssl_certificate_key cert/server.key;

 ssl_session_cache 共有:SSL:1m;
 ssl_session_timeout 5分;

 ssl_ciphers HIGH:!aNULL:!MD5;
 ssl_prefer_server_ciphers をオン;

 位置 / {
 proxy_pass http://localhost:3001;
 }
}

次に、nginx の設定を保存して再起動します。

再起動後、https を使用して初めて Web サイトにアクセスすると、nginx はクライアント ブラウザーに、ユーザーが今後 http を入力した場合、ブラウザーも https を使用して nginx サーバーにアクセスするように指示します (以下を参照)。

ただし、nginx を再起動して最初のアクセスで http を使用すると、ジャンプはしますが、https にジャンプするときのみ HSTS が使用されるため、HSTS は使用されません。しかし、もう一度 http を入力すると、307 ステータス コードと「暫定ヘッダーが表示されています」のようなプロンプトが表示されます。

HSTS プリロード リストの理解

HSTS は HTTPS のダウングレード攻撃を解決できますが、HSTS が有効になる前の最初の http リクエストで http リクエストがハイジャックされるという問題を回避することはできません。たとえば、最初にブラウザ キャッシュをクリアしてから、初めて http リクエストを使用すると、最初の http もプレーン テキストで送信されます。https にジャンプするときに HSTS が使用されます。今後は、ブラウザ キャッシュをクリアせず、nginx を再起動しない限り、HSTS 保護が使用されます。そのため、最初の http リクエストの問題を解決するために、ブラウザメーカーは、定期的に更新できる組み込みテーブルを備えた HSTS プリロード リスト ソリューションを提案しました。リスト内のドメイン名については、ユーザーが以前にアクセスしたことがない場合でも、https プロトコルを使用してリクエストされます。

現在、このプリロード リストは Google Chrome によって管理されており、Chrome、Firefox、Safari、IE 11、Microsoft Edge で使用されています。このリストにドメイン名を追加する場合は、まず次の条件を満たす必要があります。

1. 有効な証明書を持っていること（SHA-1 証明書を使用する場合、有効期限は 2016 年より前である必要があります）。

2. すべての HTTP トラフィックを HTTPS にリダイレクトします。
3. すべてのサブドメインで HTTPS が有効になっていることを確認します。
4. HSTSレスポンスヘッダーを出力します。
5. max-age は 18 週間 (10886400 秒) 未満にすることはできません。
6. includeSubdomains パラメータを指定する必要があります。
7. プリロードパラメータを指定する必要があります。

上記の条件をすべて満たしている場合でも、HSTS プリロード リストに含まれない場合があります。詳細については、https://hstspreload.org/ をご覧ください。

Chrome の chrome://net-internals/#hsts ツールを使用すると、Web サイトが PreloadList に含まれているかどうかを確認したり、ドメイン名をローカルの Preload List に手動で追加したりすることができます。

HSTSの欠点

HSTS は、HTTP セッション ハイジャックに対する完璧な解決策ではありません。ユーザーが初めて Web サイトにアクセスするときは、その Web サイトは HSTS によって保護されていません。これは、ブラウザが最初のアクセス時に HSTS を受信して​​いないため、プレーンテキスト HTTP 経由でアクセスすることが可能だからです。

ユーザーが HTTP 経由で HSTS で保護された Web サイトにアクセスすると、次の状況でダウングレード ハイジャックが発生する可能性があります。

1. これまでこのウェブサイトにアクセスしたことはありません。
2. 最近、オペレーティング システムを再インストールしました。
3. 最近ブラウザを再インストールした。
4. 新しいブラウザに切り替えます。
5. ブラウザのキャッシュを削除します。
6. サイトは最近アクセスされておらず、max-age の有効期限が切れています。
この問題を解決するには、上で紹介した HSTS プリロード リスト メソッドを使用できます。

HSTS 対応ブラウザ

現在、主流のブラウザはすでに HSTS 機能をサポートしています。詳細については、次のリストを参照してください。

Google Chrome 4以上
Firefox 4以上
Opera 12以上
OS X Mavericks以降のSafari
Internet Explorer以上

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。