web-dev-qa-db-ja.com

ECDHE_RSA_WITH_AES_128_GCM_SHA256-ECDHEキーの長さを確認する方法

サーバー：SSL証明書、2048ビットRSA公開鍵、署名アルゴリズムはsha256RSA

ここで何が欠けていますか？ ！

  • 私はRFCを精査しましたが、TLS暗号スイートでECDHE鍵サイズ（または鍵交換アルゴリズムの鍵サイズ）を決定する方法についてはまだ何も見つけていません。コンプライアンス上の理由から、ECDHEが256ビット以上であることを確認する必要があります。

  • RFC8422とRFC4492の両方で、ECDHE_RSAの場合、証明書にはRSA公開鍵が含まれている必要があることを強調しています...

SSHでは、「ecdh-sha2-nistp384」などの鍵交換アルゴリズムに曲線サイズ（ハッシュサイズも決定します）が含まれている理由がわかりません。TLS暗号スイートのビットにはこれは当てはまりません。

  • DHE_RSA_WITH_AES_128_GCM_SHA256-Diffie Hellman Ephermalが2048ビットであることをどのように確認できますか？

CertとCipher Suite以外に、確認する必要のある他の情報はありますか？コードを掘り下げる必要がありますか？これで何か助けてくれてありがとう！

certificatescryptographypublic-key-infrastructurersaecc
2
Drew

（追加のケースを追加したい人のためのCW）

TLSのDHEおよびECDHE鍵交換の一時鍵のサイズ/強度は、

  • プロトコル（バージョン）

  • サーバー側の実装コード（通常はライブラリ）、およびときどき構成

  • クライアント側の実装（同上）

第1に、TLS 1.0から1.2（およびDHEにはSSL 3ですが、2015年以降は誰もSSL 3を使用するべきではありません）とTLS 1.3の間には大きな違いがあります。 1.2までのTLSでは、タイトルで指定した形式の暗号スイートが使用されます。

  • DHEパラメータはサーバーによって選択され、通常はDHEを許可する暗号スイートを提供する以外にクライアントからの入力はありません。 someサーバー実装では、パラメーターを構成できます。 RFC 7919 2016では、拡張機能10（以下を参照）を使用して、クライアントが標準化されたグループの小さなセットを指定することを許可します。すべてのグループは少なくとも2048ビットですが、実装はわかりません1.2以下の場合は7919を使用します。 1.3については以下を参照してください。

    （Oracle/Open）Java 768ビットのハードコードされた7つのDHEを介したJSSEサーバー（エクスポートスイートの場合は512ビットを除き、引き続きサポートされます）。この問題に関するいくつかのスタックにかなりのQがあります。 Logjamの後に発生し、clientの最大1024と共に発生します。Java 8は、オプションでデフォルトを1024ビットに変更しました（ 2048まで（およびクライアントの最大2048まで）のシステムプロパティ）Java Oracle以外のプロバイダー（IBM、Androidのような、そしてしばらくの間Apple MacOSX ）が異なる場合があります。

    OpenSSLライブラリは、ClientHelloが表示される前にSSL_[CTX_]set_tmp_dhでパラメータを設定するか（設定された認証キーと証明書を知っている場合）、またはSSL_[CTX_]set_tmp_dh_callbackを使用して設定するために呼び出されるコールバックを提供する必要がありますそれらを必要とする各ハンドシェイクのパラメータ。 OpenSSLを使用する一部のサーバープログラムは、この選択をユーザーに渡します。Apachemod_sslは、デフォルトでハードコーディングされていましたが、デフォルトでは RFC 3526 "more IKE" 少なくとも2048ビットのグループですが、 'custom 'DHEパラメータ（PEM形式のOpenSSLコマンドラインが生成）とサーバー証明書をSSLCertificateFileに含めます。 nginxには、別個のssl_dhparamディレクティブが必要です。

    （誰かが他の人を追加したいですか？）

  • ECDHEは一般に RFC 4492 5.1.1 で指定された「名前付き」（標準化された）曲線に限定されます RFC 7027 によってオプションで変更され、最近（したがって、まだ広く実装されていません） RFC 8422 による。 4492はarbitrary_explicit曲線のオプションを定義しましたが、実際には誰もそれらを使用していなかったため、8422はそれらを非推奨にしました。 Ifクライアントが拡張10を指定します。これは、当初はサポートされていた曲線であり、現在はサーバーの選択を制限し、サーバーの設定を示す、supported_groupsとして再利用されています。 が続く; 4492では拡張10は技術的にオプションでしたが、ECDHE（およびECDSA authなどの他のECC）を実装するIMEクライアントは、古いSSL2形式の「互換性」ハロー（Java 6とOpenSSL 0.9.8ではデフォルトで設定されていましたが、拡張機能10のコンテンツの設定を許可するものは多くなく、実際にはサーバーを制約しません。

    （Oracle/Open）Java= 7サーバーはクライアント設定を尊重し、拡張機能がP-256を使用していない場合。6のソースはありませんが、ECDHEが有効になっている場合、同じように動作します。 all-これはそのままではありません; JSSEprotocolサポートは存在しますが、デフォルトで基盤となるECCプロバイダーがある場合にのみ有効になりますないので、追加する必要があります。確認するには：Java 8 up。

    OpenSSLライブラリは元々、DHEと同様にアプリケーションが_set_tmp_ecdh[_callback]を呼び出す必要がありましたが、1.0.2では、アプリケーションはクライアントの設定に従う_set_ecdh_autoを呼び出すことができます（「スイートB」が構成されていない限り、P-256またはP-384）、および1.1.0 upはデフォルトで「auto」を実行します。

TLS 1.3はこれを大幅に変更します。鍵交換は暗号スイートによって選択されず、代わりにHello拡張機能によってのみ制御され、Hello交換中にこれらの拡張機能を使用して完全に完了します。以前のように2番目のフライトに拡張される個別のServerKeyExchangeメッセージとClientKeyExchangeメッセージではありません。そして、それはDHEとECDHEの両方を 標準化されたパラメーターの小さなセット に制限します：DHEの場合、すべて2048ビット以上の7919グループ、およびECDHEの場合は8422によって保持される曲線のみ（X9/SECG/NIST）P-256 P-384 P-521および（Bernstein et al）X25519 X448。

4
dave_thompson_085

特定の曲線またはDH鍵の長さが暗号に記載されていません。クライアントは単にいくつかのカーブをサポートし、これらをClientHello（elliptic_curves拡張子）、クライアントがサポートされている暗号を表示する方法に似ています。同様に、サーバーには多数の曲線と特定のDHパラメータが設定されており、暗号の選択が行われる方法と同様に、これらをクライアントが提供する曲線に合わせることができます。

TLS 1.3では、これは少し異なります。つまり、クライアントは、サーバーが特定の曲線をサポートし、この仮定に基づいてすでに鍵交換を開始すると想定しています。これが失敗した場合でも、以前の動作にフォールバックできます。

TLSとECDHEを使用した場合、曲線選択はどのように機能するのですか？暗号化スタック交換 も参照してください。

2
Steffen Ullrich