2

opensl 1.0.2j を使用し、RSA:4096 キーと証明書を使用するクライアント サーバーがあり、サーバーが次の暗号のみを使用するように強制したいと考えています。

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDH-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256

私のサーバー側のコードは以下のようになります。

method = SSLv23_server_method();
ctx = SSL_CTX_new(method);
SSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256");
SSL_CTX_set_ecdh_auto(ctx, 1);
SSL_CTX_set_tmp_dh(ctx, dh);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
SSL_CTX_use_certificate_file(ctx, certFilePath, SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, privKeyPath, SSL_FILETYPE_PEM)
SSL_accept()

クライアント側のコードは次のようになります

method = SSLv23_server_method();
ctx = SSL_CTX_new(method);
SSL_CTX_set_cipher_list(ctx, "ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256");
SSL_CTX_set_ecdh_auto(ctx, 1);
SSL_CTX_set_tmp_dh(ctx, dh);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
SSL_CTX_use_certificate_file(ctx, certFilePath, SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, privKeyPath, SSL_FILETYPE_PEM)
SSL_connect()

サーバー上の最後のステップ ssl_accept() は失敗します

err: 336027900 'error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol'

クライアント側でECDHE*RSA*or ciphers を使用すると、正常に動作します。DHE*RSA*

不足しているものを教えてください。

編集：サーバーの証明書（certFilePath）には、ECDH公開鍵ではなくRSA公開鍵が含まれています。

4

1 に答える 1

2

メタ: TLS1.2 までのみ回答します。1.3 には、暗号スイートでの鍵交換と認証がなくなりました。

set_ecdh_autoまず、 andの両方を呼び出すのは意味がありませんset_tmp_ecdh-- これらは相互に排他的です。また、サーバーはクライアント認証を要求しないため、クライアントで自己証明書とキーを構成しても意味がありません。OTOHサーバーは、おそらくクライアントのデフォルトのトラストストアにない自己署名証明書を使用しているため、クライアントのトラストストアを構成する必要がある場合があります(これを行うにはいくつかの方法があります)。

第 2 に、「静的」ECDH 暗号スイートは、「静的」DH スイートが DHE スイートと異なるのと同様に、ECDHE スイートとはまったく異なります。どちらの静的形式も広く実装されておらず、ほとんど使用されていません。特に、OpenSSL 1.1.0 以降はそれらを実装しなくなったため、スケジュールを正しく覚えていれば、コードは約 1 年で廃止されます。

正確には、DH-RSA スイートには DH キー (keyAgreement を許可する) を含む証明書が必要であり、TLS<=1.1 の場合、証明書はRSA キーを使用してCAによって発行される必要があります。1.2 では、この後者の制限は削除されています。パブリック CA は DH キーの証明書を発行しません。また、自分で証明書を発行することも簡単ではありません。https://security.stackexchange.com/questions/44251/openssl-generate-different-type-of-self-signed-certificateおよび (私の) https://crypto.stackexchange.com/questions/19452/static-を参照してください。 dh-static-ecdh-certificate-using-openssl/ .

同様に、ECDH-RSA スイートは、keyAgreement を許可する ECC キーを含む証明書を必要とし、<=1.1 の場合は RSA によって発行されます。ECDH のキー (および CSR) は ECDSA と同じであり、KeyUsage のみが異なる必要があるため、これはやや簡単です。自己作成および自己署名のケースの場合、簡単です。ECC キーと証明書 (ECDSA で自動的に署名されます) を生成するだけです。

しかし最後に、これによって「不明なプロトコル」が発生することはありません。「共有暗号なし」とhandshake_failureが発生します。あなたが示したコードは「不明なプロトコル」を引き起こすべきではないので、おそらく最初に調査して修正する必要があります. s_client特にその-debugまたは-msgフックで、または-traceそれをコンパイルした場合は、代わりにコマンドラインを使用してみてください。

于 2018-10-24T21:39:03.093 に答える