web-dev-qa-db-ja.com

SSL証明書を構成した後、Webサーバーでどの暗号を使用する必要がありますか？

多くの 素晴らしい質問 があり、Webサイトに使用するのに最適な証明書は何ですか。ただし、証明書を購入すると、暗号リストを選択または編集することもできます。

各ベンダーはこの設定を少し異なるものと呼ぶかもしれませんが、私の理解では、クライアントとサーバーの間で暗号化プロトコルをネゴシエートするために暗号リストが使用されています。

  1. ウェブサイトの暗号リストを選択するための基本は何ですか？デフォルトを変更する必要がある場合「初心者」は信頼できるアドバイスを得るためにどこに行くべきですか？

  2. 2011年9月のBEASTまたは2012年のCRIME攻撃の時点で、従来の推奨事項のいずれかが変更されましたか？

  3. OS /ベンダー/およびバージョンでサポートされている暗号のリストを保持している人はいますか？このようなものが役に立つと言うのは正しいですか？

  4. 一部の証明書は、特定の暗号と互換性がないか、優先されませんか？

  5. 詳細はどこで確認できますか？具体的には、セカンダリー後の数学クラスを再受験することなく、暗号を比較する簡単な機能をどのように取得できますか？

cryptographyencryptiontlswebservercertificates
30
goodguys_activate

SSL/TLS では、暗号スイートは、鍵合意、対称暗号化、整合性チェックなどのいくつかのタスクのために、一連のアルゴリズムを選択します。

証明書タイプは、鍵合意の選択に影響します。 キーのタイプとキーの使用法の2つのパラメータを考慮する必要があります：

  • RSA鍵を使用すると、名目上、「RSA」および「DHE_RSA」暗号スイートを使用できます。しかし、サーバー証明書に「KeyEncipherment」フラグが含まれていない鍵使用拡張がある場合、名目上は「DHE_RSA」に制限されます。
  • DSA鍵では、「DHE_DSS」暗号スイートのみを使用できます。
  • Diffie-Hellman鍵では、発行する認証局の鍵タイプに応じて、「DH_RSA」または「DH_DSS」のいずれか1つのみを使用できます。

ほとんどのSSLサーバー証明書にはRSAキーがあり、これはキー使用拡張によって制限されていないため、「RSA」と「DHE_RSA」の両方のキータイプを使用できます。

「DHE」は「Diffie-Hellman Ephemeral」の略です。これは Perfect Forward Secrecy を許可します。 PFSとは、攻撃者がサーバーの秘密キー（ファイルに保存されているため、盗難の可能性が高い）を盗んだ場合でも、過去の記録されたトランザクションを解読できないことを意味します。これは、特に監査中にシステムを美しく見せたい場合に望ましい特性です。

整合性チェックの場合、MD5を使用しないでください。可能であれば、SHA-1も使用しないでください。 MD5およびSHA-1の現在知られている弱点は、TLSのセキュリティに影響を与えません（証明書内で使用される場合を除き、CAではなくユーザーが選択します）。それにもかかわらず、MD5（または、それほどではないが、SHA-1）を使用することは、広報活動にとって悪いことです。 MD5は「壊れています」。 MD5を使用する場合は、正当化する必要があります。 SHA-256の選択を疑う人はいません。一般的なコンセンサスは、SHA-1がレガシーな理由で「許容できる」ということです。

対称暗号化の場合、（ほとんど）RC4、3DES、およびAES（後者の場合、256ビットバージョンは過剰です; AES- 128はすでに問題ありません）。次の点が可能です。

  • RC4と3DESはどこでもサポートされます。最も古いクライアントはAESをサポートしていない可能性があります（たとえば、Internet Explorer 6.0はAESベースの暗号スイートをネゴシエートできないようです）。

  • RC4には既知の弱点があります。すぐに致命的となるものはありません。状況はSHA-1の状況と多少似ています。学術的には「壊れています」が、現時点では問題ではありません。これは、RC4を回避できない場合は、RC4を使用しない正当な理由です。

  • 3DESは64ビットのブロック暗号です。これは、1つのセッションで数ギガバイトを超える暗号化を行うと、いくつかの（学術的な）弱点があることを意味します。

  • 3DESはCPUに負荷がかかる可能性があります。 2.7 GHz Intel i7では、 OpenSSL はAES-128で180 MB/sの暗号化速度を達成します（ AES-NI命令 を使用した場合、はるかに優れている可能性があります）。 3 MBで25 MB /秒。 25 MB/sは依然として良好です（100 Mbits/sリンクが処理できる2.5倍であり、シングルコアを使用します）が、状況によっては無視できない場合があります。

  • BEAST攻撃は古い学問的な弱点であり、最近実際に適用できることが実証されています。攻撃者がリンクをスパイし、クライアントで悪意のあるコードを実行する必要があります（そのコードは外部のスパイシステムと通信する必要があります）。 BEASTの作者は、悪意のある内部コードがJavaまたはJavascriptを使用している場合にそれを実行することに成功しました。一般的な解決策は、免疫のないTLS 1.1または1.2に切り替えることです。また、これはブロック暗号のみに関係します。 CBCモードでは、RC4は影響を受けません。

  • SSL/TLSハンドシェイクでは、クライアントはサポートされている暗号スイートを発表し（推奨スイートが最初に来る）、サーバーは使用するスイートを選択します。サーバーがクライアントの設定を尊重するのはtraditionalです-つまり、サーバーが処理できるクライアントによって送信されたリスト内の最初のスイートを選択します。ただし、サーバーは独自の優先順位を適用できます。

  • DHEはサーバーでのCPU消費がいくらか高いことを意味します（ただし、毎秒数百の新しいSSLセッションを確立しない限り、顕著な違いはありません）。

  • RC4を使用するDHE暗号スイートはありません。

要約：これにより、以下の暗号スイートの推奨リストが表示されます。 BEAST攻撃があなたに適用される可能性がある場合（つまり、クライアントがWebブラウザである場合）、これを使用します

  • セッションでSSL-3.0またはTLS-1.0を使用している場合は、TLS_RSA_WITH_RC4_128_SHAを使用してみてください。
  • クライアントがTLS 1.1+をサポートしている場合、またはTLS_RSA_WITH_RC4_128_SHAをサポートしていない場合、またはPFSがBEASTのようなアクティブな攻撃よりも重要であると考える場合（たとえば、長期的な機密性について最も懸念しているのではなく、即時違反）、次にTLS_DHE_RSA_WITH_AES_128_CBC_SHA256を使用します（クライアントがSHA-256をサポートしていない場合はTLS_DHE_RSA_WITH_AES_128_CBC_SHAにフォールバックします）。
  • DHE暗号スイートがクライアントでサポートされていない場合は、対応する非DHEスイートを使用してください。
  • 一般的なフォールバックはTLS_RSA_WITH_3DES_EDE_CBC_SHAで、どこでも機能するはずです。

上記の選択は、ネゴシエートされたプロトコルバージョンに応じてスイートの選択を変更できることを前提としていることに注意してください。これは、特定のSSLサーバーで利用可能なオプションである場合とそうでない場合があります。

BEASTが当てはまらない場合（クライアントは悪意のあるコードを実行しません）、RC4サポートを完全に削除します。 AES-128とSHA-256に集中します。それぞれ3DESおよびSHA-1でフォールバック。可能な場合はDHEを使用します。

29
Thomas Pornin

Mozillaが提案した暗号スイート（2014年1月）が気に入っています。

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

ソース： https://wiki.mozilla.org/Security/Server_Side_TLS

パフォーマンスとセキュリティのバランスをとろうとします。ただし、 私のマイクロソフトの推奨どおり 、RC4から離れます

2
VP.

修正はどこにあり、どのように見えますか？唯一の修正は、関​​連するすべてのプラットフォーム上のすべてのブラウザがTLS 1.1または1.2を実装することです。ただし、これが従来のプラットフォームのように起こるとは思いません。

したがって、今のところ私はRC4を回避策としてのみ見ています。ほとんどのSW開発者は過去に最新のTLS標準を実装するのに失敗し、現在は現状のままです。

2
Jui

SSL Labs経由で2016を更新：

主に、強力な認証とキー交換、転送秘密、少なくとも128ビットの暗号化を提供するAEADスイートに依存する必要があります。他の弱いスイートもサポートされている可能性がありますが、それらは、何もサポートしていない古いクライアントとのみ交渉されます。

避けなければならない時代遅れの暗号プリミティブがいくつかあります。

匿名Diffie-Hellman（ADH）スイートは認証を提供しません。

  • NULL暗号スイートは暗号化を提供しません。
  • エクスポート暗号スイートは、接続でネゴシエートされると安全ではありませんが、より強力なスイート（FREAK攻撃）を優先するサーバーに対しても使用できます。
  • 弱い暗号（通常は40ビットと56ビット）を備えたスイートは、簡単に解読できる暗号化を使用しています。
  • RC4は安全ではありません。
  • 3DESは遅くて弱いです。

開始点として、RSAキーとECDSAキーの両方用に設計された次のスイート構成を使用します。

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA

注この構成例では、OpenSSLに必要な非標準のスイート名を使用しています。他の環境（IISなど）での展開には、標準のTLSスイート名を使用する必要があります。

参考： https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites

1
bhushan5640

まず、BEAST攻撃を無視した暗号を見てみましょう。

強力なキーを持つ「現在の」暗号のみを使用し、誰も使用していない歴史的な暗号はサポートしないことをお勧めします。つまりRC4などはありません。また、米国政府が暗号を解読できるように、鍵は非常に弱いため、輸出レベルの暗号には使用しないことをお勧めします。より高品質の暗号をエクスポートすることはもはや違法ではないと私は信じていますが、その概念はまだサーバー設定に存在しています。最後に、MD5などの大きな問題があるハッシュアルゴリズムは避けてください。

現在、BEAST攻撃..明らかに、TLS 1.0で使用されているCBCモードのAESは、選択された平文回復攻撃に対して脆弱です。 mail.google.comは、今週、128ビットRC4にすばやく切り替えて、これを防御しました。今後2週間でこの攻撃について非常に懸念している場合（Googleのように）、同じ回避策を適用できます。他の場合では、修正を待つだけで、この攻撃を考慮せずに暗号を構成します。

0
chris

Apache2と強力なSSLアルゴリズムを選択するための興味深い構成がここにあります。

Mozilla SSL設定ジェネレータ https://mozilla.github.io/server-side-tls/ssl-config-generator/

最新のブラウザーに対する2019.02の推奨事項は次のとおりです。

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384：ECDHE-RSA-AES256-GCM-SHA384：ECDHE-ECDSA-CHACHA20-POLY1305：ECDHE-RSA-CHACHA20-POLY1305：ECDHE-ECDSA-AES128-GCM-HEHAAA：EHA -AES128-GCM-SHA256：ECDHE-ECDSA-AES256-SHA384：ECDHE-RSA-AES256-SHA384：ECDHE-ECDSA-AES128-SHA256：ECDHE-RSA-AES128-SHA256

読み取り可能：

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
0
amprantino