web-dev-qa-db-ja.com

セキュリティ、互換性のために推奨されるssl_ciphers-Perfect Forward secrecy

私は現在、次の暗号でnginxを使用しています。

ssl_ciphers HIGH:!aNULL:!eNULL:!LOW:!ADH:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;

古いブラウザー、特に古いモバイルブラウザーとの互換性を維持したいので、SHA1を完全に禁止しません。

SHA256がMAC（メッセージ認証コード）のSHA1よりも優先され、可能な場合は常に使用されるようにするにはどうすればよいですか。

つまり、ssl_ciphers文字列にSHA256：！SHA：を追加することで、SHA256を強制的に適用できますが、これもSHA1を完全に禁止します。

ただし、最初にssl_cipherを使用すると、SHA1のみを使用する傾向があります。何かお勧めですか？

更新29.12.2014

建設的な意見と議論をしてくださった皆さんに感謝します。

サーバー側のTLS Mozillaページは全体的にかなり良いトピックをカバーしていると私はまだ思っていますが、私は モダン互換性 DSS暗号はそれから削除し、Anti-weakpasswordsのコメントで推奨されているように（！DSS）を明示的に禁止する必要があるという制限付き-発見してくれてありがとう。

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:!3DES:!MD5:!PSK

興味深いことに、ssllabsはこれを警告したりレートを下げたりしませんでした...

さらに、カスタム生成されたdiffie hellmanパラメータを使用することを好みます。標準のものは明らかに安全であると考えられていますが。 OpenSSL標準のDiffie Hellmannパラメータ（素数）は何ですか？

openssl dhparam -check -out /etc/ssl/private/dhparams.pem 2048

パラノイアと楽しい場合は4096に増やします。

tlsnginxforward-secrecy
36
binaryanomaly

最初に、暗号スイートのネゴシエーションがどのように機能するかを簡単に説明します。たとえば、TLS 1.2ドキュメント セクション7.4.1.2から始まるRFC 5246 を使用して、短い短い形式で確認できます。

  • ClientHello：クライアントは、クライアントがサポートする暗号スイートをサーバーに通知します
  • 今度はサーバーが1つ選択します
    • 次に選択する方法を制御する方法について説明します。
  • ServerHello：サーバーは、選択した暗号スイートをクライアントに通知するか、クライアントに失敗メッセージを提供します。

今、実際の選択について。私は nginx ssl module documentation 、 Qualys 2013記事、Apache、Nginx、およびOpenSSLを構成するForward Secrecyについて 、および Hynek Hardening Your Webを使用しましたサーバーのSSL暗号 参照用の記事。後者の2つはApacheとNginxの両方をカバーします（どちらもベースとしてOpenSSLを使用するため）。

基本的に、選択した順序を使用するようにNginxに指示する必要があり、順序を選択する必要があります。その順序の結果がどうなるかを確認するには、OpenSSLコマンドラインを使用できます。

openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

注：その文字列から：！3DESを削除することをお勧めします。 3キーのトリプルDESは効率的ではありませんが、それでもそれ自体はほぼ112ビットのセキュリティで安全であり、非常に一般的です。

上記のコマンドを使用して、構成で最も好ましい暗号スイートと最も好ましくない暗号スイートを決定し、結果が気になるまで変更します。私が提供した参照には独自の文字列があります。上記の例を取得するために少し修正しました（たとえば、RC4とSEEDを削除し、すべてのTLS 1.2暗号スイートを「SSLv3」暗号スイートの上に置きます）。

次に、特にNginxの場合、設定ファイルを変更して次のようなものを含めます。

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

本当に主張する場合は、SSLv3をssl_protocolsに追加します。

Ssl_prefer_server_ciphersはnginxに指定した順序を使用するように通知し、クライアントが暗号リストを提示する順序を無視します。ClientHelloとOpenSSL暗号-v ...の間の唯一の共有暗号スイートが最も好ましい場合暗号、それはもちろんnginxが使用するものです。何も一致しない場合は、クライアントに失敗の通知を送信します。

ここでは、ssl_ciphersコマンドを選択します。nginxがOpenSSLに優先暗号スイートリストを通知するためです。 openssl ciphers -vコマンドを使用して、プラットフォームで得られる結果を確認してください。理想的には、OpenSSLのバージョンを変更した後でもう一度確認してください。

また、 ngtsでのHSTS（HTTP Strict Transport Security）のセットアップに関するスコットヘルメの記事 もお読みください。これにより、ホストはクライアント側でHTTPSの使用を強制できます。必ず、ssl listenステートメントを使用して、httpブロック内にHSTSヘッダーを含めてください。

追加するように編集：少なくともこの後（前でもない場合）に Qualys SSL Labs に移動してHTTPSセキュリティ情報を表示し、 Test Your Server にアクセスしてください。これまでの数年間。推奨は定期的に変更され、時には頻繁に逆転することもあります（RC4、たとえば、むち打ち症が引き起こすものなど）。 ブラウザをテストする ！

27
Anti-weakpasswords

Mozillaには、正しい暗号スイートを選択するのに役立つオンラインツールがあります。

https://mozilla.github.io/server-side-tls/ssl-config-generator/

サーバーのバージョン、ソフトウェアのバージョンなどを入力して、セキュリティとレガシーサポートのバランスを選択できます。

8
Alex W

最高の互換性のためには、cloudflare-cipher-suiteは最適ではありません。私は次の方が良いことがわかりました：

# suggestion from sslabs / including PFS, good compatibility
#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;


# suggestion my mozilla-server-team - good compatibility, pfs
#ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;

ssllabs で各設定を確認すると、これらの2つのスイートについて次のステートメントが見つかります。

  • Forward Secrecyはい（ほとんどのブラウザで）ROBUST

提案されたcipher_suiteの間、それは言う：

  • Forward Secrecyはい（最新のブラウザ）

追加情報： Nginx + SSL + SPDYのガイド

3
that guy from over there

OpenSSLは当然、それ以外の場合は同等の暗号スイートに新しいMACを優先します。たとえば、長いopenssl ciphers -v暗号文字列の出力は次で始まります：

ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1

もちろん、TLSはサーバーとクライアントの両方で相互にサポートされている暗号スイートのみを使用し、ChromeもFirefoxもHMAC-SHA256暗号スイートをサポートしていません。HMAC-SHA1以降（さらにはHMAC-MD5）でも）私は彼らの開発者（およびNSSの開発者、および両方が使用するTLSライブラリ）が開発者の労力とTLSハンドシェイクのサイズを浪費し、新しい不要で後方互換性のない暗号スイートを追加することに懐疑的であると私は信じています。

たとえば、 Chrome 33でサポートされている暗号スイートを優先順に ：

  1. ChaCha20-Poly1305 、
  2. AES-128-GCM、
  3. AES-256-CBCとHMAC-SHA1
  4. RC4（ugh）およびAES-128-CBCとHMAC-SHA1 ...

OpenSSLはChaCha20-Poly1305をサポートしていません。 AES-GCMもサポートしておらず（???）、RSA証明書を使用している場合、ECDHE-RSA-AES256-SHAは当然暗号スイートですChromeが使用します。（Firefox 29はECDHE-RSA-AES128-SHA。）

（他のWebサイトで使用されている「SHA-256」暗号スイートは、おそらくChaCha20-Poly1305またはAES-128-GCMです。これらは AEADs であり、HMACを使用しませんが、暗号スイートは [〜＃〜] prf [〜＃〜] でSHA-256を使用します。

3
Matt Nordhoff

https://cipherli.st/ は、以下を提供する別のサイトです。

上記の暗号は、nginx、Lighttpd、またはApache構成でコピー貼り付け可能です。これらはすべての最新のブラウザーに強力なSSLセキュリティを提供し、さらにSSLラボテストでA +を取得します。

このようなものは常に古くなっていますが、その価値のために、2018年5月にnginxに関する推奨事項を以下に示します。

ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_prefer_server_ciphers on; 
ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
2
artfulrobot

Comodoの推奨事項は次のとおりです。

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

ソース： https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/789/37/

2
Michael

ハッシュ関数の選択（SHA-1とSHA-256）は暗号スイートに実際には依存しませんが、プロトコルバージョン。基本的に、 TLS 1.2 を使用する場合はSHA-256を取得し、古いバージョンを使用する場合はSHA-1を取得します。

（はい、これは少し複雑な状況の簡略化された説明であることを知っていましたが、ここでは機能します。）

通常、クライアントとサーバーは両方がサポートする最高のプロトコルバージョンを使用するため、可能な場合はいつでもTLS-1.2（したがってSHA-256）を取得しているはずです。これには、サーバーのコード（OpenSSL）とクライアントのコードの両方が最新である必要があることに注意してください。 ssl_protocols 。

1
Tom Leek