nginx が HSTS を構成する方法

Netcraft は最近、SSL/TLS Web サイトのテストに関する調査結果を発表し、HTTP Strict Transport Security HSTS を正しく実装しているユーザーは 5% のみであると指摘しました。

HSTS とは

#HTTPS (SSL および TLS) は、ユーザーと Web サイト間の通信中のセキュリティを確保し、攻撃者による傍受、変更、なりすましを困難にします。ユーザーがドメイン名または http:// リンクを手動で入力すると、Web サイトへの最初のリクエストは暗号化されず、プレーン http を使用します。最も安全な Web サイトは、ユーザーを https 接続に誘導するリダイレクトを即座に送り返しますが、中間者攻撃者は最初の http リクエストを傍受し、それによってユーザーのその後の応答を制御できる可能性があります。

当然のことながら、HSTS はこの潜在的なセキュリティ問題を解決するために登場しました。ユーザーがドメイン名または http 接続を入力した場合でも、ブラウザは厳密に https 接続にアップグレードします。

HSTS の仕組み

HSTS ポリシーは、安全な HTTPS サイトから送信される HTTP 応答ヘッダーで公開されます。

Strict-Transport-Security: max-age=31536000

ブラウザが HTTPS サイトからこのヘッダーを確認すると、ドメイン名には HTTPS (SSL または TLS) 経由でのみアクセスできることがわかります。そして、この情報を 31536000 (1 年分) にキャッシュします。

オプションのパラメーター includeSubDomains は、ポリシーが現在のドメインのすべてのサブドメインに適用されることをブラウザーに伝えます。

Strict-Transport-Security: max-age=31536000; includeSubDomains

nginx 設定 HSTS

nginx 設定ファイルに HSTS 応答ヘッダーを設定します。

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

always パラメーターにより、内部生成されたエラー応答を含むすべての応答でこのヘッダーが設定されるようになります。 1.7.5 より前の nginx バージョンは always パラメーターをサポートしておらず、内部生成されたエラー応答ではこのヘッダー情報が設定されません。

add_header ディレクティブの継承ルール:

nginx 構成ブロックは、add_header ディレクティブが配置されているカプセル化ブロックを継承するため、add_header ディレクティブをトップレベルのサーバー ブロックに配置するだけで済みます。重要な例外があり、ブロックに add_header ディレクティブ自体が含まれている場合、ブロックはそれを囲んでいるブロックからヘッダーを継承しないため、すべての add_header ディレクティブを再定義する必要があります。

server {
    listen 443 ssl;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
 
    # This 'location' block inherits the STS header
    location / {
        root /usr/share/nginx/html;
    }
 
    # Because this 'location' block contains another 'add_header' directive,
    # we must redeclare the STS header
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}

テスト HTTP Strict Transport Security:

ユーザーが HSTS ポリシーを提案すると、そのキャッシュ情報の期間は max-age で指定されます。この間、ブラウザは暗号化されていない HTTP を介した Web サービスへのアクセスを拒否し、証明書エラーの例外を許可することを拒否します (Web サイトが以前に有効で信頼できる証明書を送信した場合)。 includeSubDomanis パラメーターが指定されている場合、これらの制限は現在のドメイン内のすべてのサブドメインにも適用されます。

HSTS をテストするときは、max-age 時間を短く設定してください。

各 HTTPS 応答に STS ヘッダーが必要かどうか:

私たちの目標は、ユーザーが HTTPS セッションを開始したときに、できるだけ早く HSTS ポリシーを提示することです。セッション中に HSTS ポリシーを受信した場合でも、HTTP ハイジャック攻撃に対して脆弱です。ブラウザーは STS ヘッダーを 1 回確認するだけでよいため、すべてのロケーション ブロックとすべての応答に STS ヘッダーを追加する必要は厳密にはありません。ただし、ホームページまたはログイン ページに追加するだけでは不十分な場合があります。キャッシュされた応答に追加するだけでは、クライアントに表示されない可能性があります。動的コンテンツに特に注意を払い、適切な範囲で URL をカバーするようにしてください。

HTTP と HTTPS の同時実行

Web サイトを HTTP と HTTPS で同時に実行する必要がある場合があります

server {
    listen  80;
    listen  443 ssl;
    ...
}

HTTP リクエストを同時に実行する必要がある場合があります。 https

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
 
    # Discourage deep links by using a permanent redirect to home page of HTTPS site
    return 301 https://$host;
 
    # Alternatively, redirect all HTTP links to the matching HTTPS page
    # return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name www.ttlsa.com;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Enhanced HSTS

STS ヘッダーを確認してから宣言された最大有効期間まで、クライアントを HTTP インターセプトから保護します。ただし、HSTS は HTTP セッション ハイジャックに対する完璧なソリューションではありません。 HSTS で保護された Web サイトに HTTP 経由でアクセスする場合、ユーザーは引き続き脆弱です:

1. これまでその Web サイトにアクセスしたことがない

2. 最近再訪問したオペレーティング システムをインストールしましたシステム

3. 最近ブラウザを再インストールしました

4. 新しいブラウザに切り替えました

5. 新しいブラウザに切り替えました携帯電話などのデバイス

6. ブラウザのキャッシュを削除します

7. 最近サイトにアクセスしていないため、最大有効期限が切れています

この問題を解決するために、Google は「HSTS プリロード リスト」サイトのドメイン名とサブドメイン名を維持することを主張し、https://hstspreload.appspot.com/ そのドメイン名を通じて提出しました。このドメイン名のリストは配布され、主要な Web ブラウザにハードコーディングされます。このリストのドメイン名にアクセスするクライアントは、HTTPS を積極的に使用し、HTTP を使用したサイトへのアクセスを拒否します。

STS ヘッダーが設定されるか、ドメインが HSTS プリロード リストに送信されると、それを削除することはできません。これは、ドメイン名を HTTPS 経由で利用できるようにするための一方的な決定です。

以上がnginx が HSTS を構成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。