SSL設定 · 1 min read · Oct 12, 2025

NGINXウェブサーバーにおけるSSL完全前方秘匿性の実装

このHOW-TOでは、DebianおよびUbuntuシステム上でNGINXウェブサーバーを使用して完全前方秘匿性を実装するプロセスについて説明します。このプロセスは、他のGNU/Linuxシステムにも容易に適応できます。

要するに、完全前方秘匿性は次のことを保証します：”… 1つのメッセージの漏洩が他のメッセージの漏洩につながることはなく、また、複数のメッセージの漏洩につながる単一の秘密値が存在しないこと。” 詳細については、http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecyを参照してください。

2014年初頭にOpenSSLのHeartbleed脆弱性が明らかになったとき、PFSはSSL/TLSを真剣に使用するシステムにとって必須であることがますます明らかになりました。

私の結果と比較したい場合は、私のリファレンス実装をhttps://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.orgでテストでき、送信されるSSL証明書チェーンとNGINXヘッダーはhttps://indietorrent.orgで確認できます。

それでは、NGINXを構成してPFSを実装しましょう。

NGINXの設定ディレクトリに移動します：

cd /etc/nginx/

十分に強力なDiffie-Hellmanパラメータを生成する必要があります。4096ビットは過剰であり、システムのCPUに不当な負担をかけると主張する人もいますが、現代のコンピュータパワーを考慮すると、これは価値のある妥協のようです。詳細については、下記の参考文献セクションを参照してください。

openssl dhparam -out dh4096.pem 4096

このタスクに特化した設定ファイルをインクルードファイルに分けておくと便利です。これにより、多くのシステムにわたってPFSを実装するのが簡単になります。

vi /etc/nginx/perfect-forward-secrecy.conf

上記のファイルに次の内容を貼り付けます：

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

NGINXの主設定ファイル（デフォルトでは/etc/nginx/nginx.conf）のhttp {}ブロックの下部に、上記のファイルを含めるために次の行を挿入します：

# See: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# これは.../sites-enabled/*を含む行の後に来る必要があります。さもなければ、SSLv3サポートが誤って再有効化される可能性があります。
include perfect-forward-secrecy.conf;

変更を有効にするためにNGINXを再起動します：

service nginx restart

https://www.ssllabs.com/ssltest/analyze.htmlでテストを行った際に、セッション再開（キャッシュ）No（IDが割り当てられたが受け入れられなかった）が赤で表示され、サーバーがSNIを実装している場合は、次の内容をトップレベルの`http {}ブロックに追加します（つまり、前回の追加のすぐ下にnginx.conf`に追加します）：

# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

再度、変更を有効にするためにNGINXを再起動します：

service nginx restart

上記のテストは、もはやこの問題を報告しないはずです（問題が全体のテストスコアを減少させるわけではありません）。

さらに進める：長期間のHTTP厳格輸送セキュリティ（HSTS）の実装

これは簡単なもので、次の条件を満たす限り実行する価値があります：

  1. このヘッダーが設定されている任意のホストのすべてのリソースに対してSSLを強制したい（つまり、問題のウェブサイトのすべてのページ）。
  2. このヘッダーが設定されている任意のホストから要求されるリソースに対してSSL警告を受け入れて無視する能力がないことを受け入れられる（例：「ドメイン名の不一致」など）。HSTSの本質は、SSL証明書に関連する警告やエラー条件をオーバーライドできないことです。

このヘッダーを設定することが、ヘッダーをサポートしていないブラウザにおいて意図しない結果をもたらすかどうかについての情報をインターネットで探しましたが、十分な情報は得られませんでした。しかし、例えばInternet Explorer 6でこの実装をテストすることで、HSTSが実装されていないブラウザは単にヘッダーを無視することがわかり、懸念を和らげることができました。完璧です！

次の行を/etc/nginx/perfect-forward-secrecy.confの下部に追加し、変更を保存します：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# これは特定のクリックジャッキング攻撃を防ぎますが、他のサイトがあなたのサイトをフレームするのを防ぐので、必要に応じて削除または修正してください！
add_header X-Frame-Options SAMEORIGIN;

これらの特定の変更をNGINXが反映するためには、再起動ではなくリロードで十分です：

service nginx reload

HSTSが意図した通りに機能していることを確認するには、https://www.ssllabs.com/ssltest/analyze.htmlで実装をテストします。HSTSが正しく実装されている場合、スコアのすぐ下に「このサーバーは長期間のHTTP厳格輸送セキュリティをサポートしています。グレードはA+に設定されています。」という緑のボックスが表示されるはずです。

おめでとうございます！

これで、インターネット上で最も安全なSSL/TLS実装の1つを持つことができました。

参考文献：

Copyright © 2014 Ben Johnson

Share: X/Twitter LinkedIn
#SSL設定

新しい投稿を受信箱で受け取る

スパムはありません。いつでも購読を解除できます。