web-dev-qa-db-ja.com

サーバーがLogjamに対して脆弱でないかどうかを確認するにはどうすればよいですか？

Logjam に応じて、サービスを強化したことを証明したいと思います。 DHパラメータは少なくとも2048ビットで、自己生成する必要があることを知っています。しかし、HTTPSサイト以外で実際にこれを確認する方法を見つけることができません。 （ ここで私ができること ）他のSSLで保護されたサービスでもこれを確認したいと思います。

  • メール（PostfixおよびDovecot）
  • SSH
  • VPN
  • 他の

openssl s_client -starttls smtp -crlf -connect localhost:25しかし、その結果、

CONNECTED(00000003) depth=3 C = SE, O = ME, OU = Also ME, CN = Me again verify error:num=19:self signed certificate in certificate chain

verify return:0 Server certificate

-SNIPED SOME VALUES-

--- SSL handshake has read 6118 bytes and written 466 bytes

--- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression:

NONE Expansion: NONE SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 6EAA8A5B22E8C18E9D0E78A0B08447C8449E9B9543601BC53F57CB2059597754
    Session-ID-ctx: 
    Master-Key: <MASTERKEY>
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432213909
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
--- 250 DSN

DHパラメータをテストするにはどうすればよいですか？そして、私が危険にさらされているかどうかを知るために何に注意すべきですか？

tlsopenssldiffie-hellman
29
LvB

煙のテストを行います：（ OpenSSL blog 。（Archived here 。）から盗まれます））

openssl s_client -connect www.example.com:443 -cipher "EDH" | grep "Server Temp Key"

RSA-2048に匹敵する快適なセキュリティマージンを提供するには、キーは少なくとも2048ビットである必要があります。 1024ビットより短いキーの接続は、今日すでに問題になっている可能性があります。 （注：OpenSSL 1.0.2が必要です。以前のバージョンのクライアントでは、この情報は表示されません。）

（接続がすぐに失敗した場合、サーバーは一時的なDiffie-Hellman（OpenSSL-speakでは「EDH」、別の場所では「DHE」）をまったくサポートしておらず、Logjamから安全です。）

[...]

最後に、エクスポート暗号が無効になっていることを確認します。

$ openssl s_client -connect www.example.com:443 -cipher "EXP"

接続は失敗するはずです。

言い換えると：

  • openSSL 1.0.2を入手してください。
  • -cipher "EDH"オプションを接続文字列に追加します。
  • サーバーでエクスポート暗号が有効になっている場合、脆弱性を想定します
  • 512ビット（または2048ビット未満）が発生した場合、脆弱性を想定します。
20
StackzOfZtuff

そのため、このメソッドで実際にキー交換を詳細に分析できるので、新しい投稿で「StackzOfZtuff」の回答にコメントを付けることにしました。この回答は this からコピーされたもので、superuser.comに投稿されています（Thomas Porninに感謝します）。

-msgオプションを指定してopensslを使用すると、必要な情報が得られます

openssl s_client -connect mail.example.com:143 -starttls imap -cipher EDH -msg

これは、次のような完全なTLS ServerKeyExchangeメッセージを示しています。

<<< TLS 1.2 Handshake [length 030f], ServerKeyExchange 0c 00 03 0b 01 00 ff ff ff ff ff ff ff ff c9 0f da a2 21 68 c2 34 c4 c6 62 8b 80 dc 1c d1 29 02 4e 08 8a 67 cc 74 02 0b be a6 3b 13 9b 22 51 4a

thomas Porninによると、この方法で読むことができます（次のとおり逐語的にコピーしました）。

  • 0c 00 03 0b：タイプが "ServerKeyExchange"（つまり "0c"）で、長さが0x00030Bバイトのメッセージ。
  • 最初の要素は、2バイトの長さのヘッダーを持つビッグ整数としてのDH係数です。ここでは、長さは01 00としてエンコードされます。これは、0x0100バイトを超えてエンコードされる整数を意味します。これは256バイトなので、モジュラスの長さは2041〜2048ビットです。
  • モジュラスバイトは、符号なしビッグエンディアン順で続きます。このモジュラスの上位バイトは、この場合、ff ff ff ff ....です。この場合、モジュラスの長さは正確に2048ビットになります。

この方法を使用すると、サーバーがRFC 3526で事前定義されたDHグループを使用していないことを確認することもできます（Ubuntu 14.04を使用する私のApache2.4.7は、まだ使用しています http://httpd.Apache.org/ docs/2.4/mod/mod_ssl.html は、このバージョンではPEMエンコードされたSSLCertificateFileに追加されたDHパラメータを使用する必要があることを示しています。

4
r_3

脆弱性を発見した人々から

別のオンラインテスト

これら二つは私に矛盾した答えを与えます。リンクされた研究者たちは、悪用されるように構成できる方法が存在する場合、サイトが脆弱であると報告しています。 2番目のリンクがより実用的なことを示しているように、「今は脆弱か？」情報。

0
cmaynard