web-dev-qa-db-ja.com

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256は安全な暗号スイートですか?

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256は、TomcatサーバーへのTLS 1.2接続に使用する安全な暗号スイートですか?潜在的な弱点またはより良い代替策は何ですか? Java 8.でサポートされている暗号を探しています。

11
JRA_TLL

TLS暗号スイートの名前は、ハンドシェイクと暗号化されたセッションの各部分で使用されているアルゴリズムとキーサイズがわかるように構造化されています。これを分解して、私たちにできる改善があるかどうか見てみましょう。

  • TLS-これ自体は何の意味もありませんが、TLS 1.2はTLSの最新バージョンであり、既知の脆弱性はないことを述べさせていただきます。
  • ECDHE-エフェメラルキーを使用した楕円曲線Diffie-Hellman。これが鍵交換方式です。一時的な(セッションごとに生成された)鍵を使用するDiffie-Hellman鍵交換は、前方秘密を提供します。つまり、サーバーの秘密鍵がわかっていても、事後にセッションを復号化することはできません。楕円曲線暗号化は、従来の公開鍵暗号化と同等の強度を提供すると同時に、より小さな鍵サイズを必要とするため、パフォーマンスを向上させることができます。さらに、RSAのブレイクに対するヘッジベットとしても機能します。
  • RSA-サーバーの証明書にはRSA公開鍵が含まれている必要があり、対応する秘密鍵を使用してECDHEパラメーターに署名する必要があります。これがサーバー認証を提供するものです。別の方法は、別の楕円曲線アルゴリズムであるECDSAですが、CAが署名する証明書のタイプによって制限される場合があります。
  • AES_128-対称暗号化暗号は、128ビットキーを使用するAESです。これはかなり高速で、壊れていません(NSAがAESをバックドアしていると考えている場合を除いて、別の時間のトピックです)AES_256(パフォーマンス面でコストがかかりすぎる可能性があります)以外は、最良の選択です RFC 5246で定義されている対称暗号 のほか、RC4(既知の弱点がいくつかあり、比較的すぐに壊れる可能性があります)および3DES_EDE(実用的なビット強度は108から112のみです)あなたのソース)。
  • CBC-暗号ブロックチェーンモード。ここで、おそらく選択を改善できます。 CBCモードは、可変長のデータを暗号化するためにブロック暗号を使用する方法であり、これまでTLSの問題の原因でした。BEAST、Lucky-Thirteen、およびPOODLEはすべてCBCモードのTLSに対する攻撃でした。パフォーマンスとセキュリティのより良い選択はAES_128_GCMです。これはTLS 1.2で導入された新しいAEAD暗号の1つであり、優れたパフォーマンスとセキュリティ特性を備えています。
  • SHA256-これは、TLS暗号スイートのメッセージ認証コード(MAC)機能の基礎となるハッシュ関数です。これは、各メッセージが送信中に改ざんされていないことを保証するものです。 SHA256は優れた選択肢であり、TLS 1.2のさまざまな部分のデフォルトのハッシュアルゴリズムです。ここではSHA-1を使用しても問題ないと確信しています。これは、悪用のウィンドウが非常に小さいためです。証明書の署名。 AEAD暗号スイートは最初から認証されているため、この追加のMACステップは必要ないか、実装されていません。

基本的に、現時点では実用的な問題のない優れた暗号スイートを選択しましたが、パフォーマンスを向上させ、将来のCBC関連の脆弱性から保護するために、AEAD暗号スイート(AES-GCMまたはGoogleのChaCha20-Poly1305)に切り替えることができます。 。

20
bonsaiviking

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256は、どの暗号スイートでも可能な「安全」です。その暗号スイートを使用したTLS 1.2に関連する既知のプロトコルの弱点はありません。もちろん、特定のimplementationは、物事を台無しにして、それ自体で弱点を導入する可能性があります。また、たとえば、サーバーのRSAキーのストレージを適切に保護できなかった場合などに、独自のセキュリティを踏みにじることもできます。または、そのRSA鍵に弱い鍵ペア生成を使用します。または、クライアントでの証明書検証を非アクティブ化します。または注意を実行しない場合に実行可能な、何十億もの愚かなアクション。

7
Thomas Pornin

すべてのCBC暗号に 最近の更新 があり、mightでほとんどの状況で安全ではありません。したがって、おそらく a check を実行してサーバーのセキュリティを再評価する必要があります。 (詳細 SSLLabsからの情報

何を使用するかについては、cfieberが正しくコメントし、Java 8への最善の(そして唯一の)策はTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256およびTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384証明書のタイプによって異なります。 ( ここ から取得)

1
Stoinov