30

In response to Logjam I want to prove I've hardened my services. I know that the DH param has to be 2048 bits at least and self generated. But I am unable to find a way to actually check this for something other than an HTTPS site. (thats I can do here) I would like to check my other SSL protected services for this as well:

  • Mail (Postfix and Dovecot)
  • SSH
  • VPN
  • Any other

I got as far as openssl s_client -starttls smtp -crlf -connect localhost:25 But that yielded: 

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

How can I test the DH parameters? and what should I watch for to know if I'm at risk?

Improve this question
4
  • 1
    You can also check your server here: ssllabs.com/ssltest/index.html If you get a "This server supports weak Diffie-Hellman (DH) key exchange parameters" message you a vulnerable to logjam.
    – Mike Dotterer
    May 22, 2015 at 14:16
  • Here's a great logjam online checker that also shows the weak ciphers: tools.keycdn.com/logjam It does the check explained in this thread and summarises the results.
    – Scott Lee
    May 22, 2015 at 16:46
  • nmap can also be used to detect DHE_EXPORT ciphers: nmap --script ssl-enum-ciphers -p 443 www.example.com | grep EXPORT
    – cciegeek
    May 22, 2015 at 18:09
  • Mike, Scott and cciegeek - those answers don't apply in the OP's scenario.
    – Rory Alsop ♦
    May 23, 2015 at 7:35

3 Answers 3

Reset to default
22

Do the smoke test: (stolen from OpenSSL blog. (Archived here.))

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

The key should be at least 2048 bits to offer a comfortable security margin comparable to RSA-2048. Connections with keys shorter than 1024 bits may already be in trouble today. (Note: you need OpenSSL 1.0.2. Earlier versions of the client do not display this information.)

(If the connections fails straight away, then the server does not support ephemeral Diffie-Hellman ("EDH" in OpenSSL-speak, "DHE" elsewhere) at all and you're safe from Logjam.)

[...]

Finally, verify that export ciphers are disabled:

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

The connection should fail.

In other words:

  • get OpenSSL 1.0.2.
  • add the -cipher "EDH" option to your connect string.
  • assume vulnerability if export ciphers are enabled on the server
  • assume vulnerability if 512 bit (or anything less than 2048 bit) turns up.
Improve this answer
7
  • 1
    OK I had to build my own openssl to make this work. but yes now I can check it. I must have missed the openssl blog when I did my own Google Searches. thanks
    – LvB
    May 21, 2015 at 15:41
  • 1
    For people who don't have openssl 1.0.2 and don't want to compile it themselfs: someone explained how to make use of the -msg option of s_client at superuser.com: superuser.com/questions/905557/openssl-display-dh-parameters This way you can also check if your own DH parameters are used or if the server uses the ones defined here: tools.ietf.org/html/rfc3526#section-3
    – r_3
    May 22, 2015 at 18:26
  • So how do I check if my courier on wheezy is vulnerable?
    – rubo77
    May 23, 2015 at 9:21
  • @rubo77: Try this: openssl s_client -connect mail.example.com:25 -starttls smtp -cipher "EDH"
    – StackzOfZtuff
    May 23, 2015 at 10:01
  • Also note that -cipher "DHE" also works in OpenSSL 1.0.2+ to achieve the same goal. My guess is as "DHE" is known to the world it's now an option you can pass.
    – Thomas Ward
    Jun 2, 2015 at 16:31
5

So I decided to put my comment to "StackzOfZtuff" answer in a new post, as you can actually dissect the key exchange in more detail with this method. This answer is copied from this post over at superuser.com (so all thanks go Thomas Pornin):

use openssl with its -msg option yields the information we care for

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

This shows the full TLS ServerKeyExchange message like

<<< 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

according to Thomas Pornin you can read it this way (I copied the following verbatim):

  • 0c 00 03 0b: message of type "ServerKeyExchange" (that's the "0c") of length 0x00030B bytes.
  • First element is the DH modulus as a big integer, with a two-byte length header. Here, the length is encoded as 01 00, meaning an integer encoded over 0x0100 bytes. That's 256 bytes, so the modulus has length between 2041 and 2048 bits.
  • The modulus bytes follow, in unsigned big-endian order. The top bytes of that modulus are, in this case, ff ff ff ff.... The modulus then has length exactly 2048 bits.

Using this method you can also make sure, that your server doesn't use the DH Groups predefined in RFC 3526 (which my Apache2.4.7 using Ubuntu 14.04 still does, although http://httpd.apache.org/docs/2.4/mod/mod_ssl.html states that this version should use DH parameters added to the PEM-encoded SSLCertificateFile).

Improve this answer
0

From the people who found the vulnerability

Another online test

These two give me conflicting answers. I think the researchers in link one report that your site as being vulnerable if there is any way in which it can be configured that will allow it to be exploited. Where as the second link shows the more pragmatic, "is it vulnerable right now?" information.

Improve this answer
7
  • Your first link does not answer the question, the second link does.
    – LvB
    Jun 1, 2015 at 15:10
  • The first link has a similar test to the second list, that take a more "researcher" view than am I vulnerably right this moment. But it does answer the question IMHO.
    – cmaynard
    Jun 2, 2015 at 20:32
  • Question is about other uses than a website. Any test limited to http so websites is not an answer to the question. Next time READ IT. Especially since you list a link I already used in the question itself.
    – LvB
    Jun 2, 2015 at 20:35
  • Fair point, but you don't have to yell.
    – cmaynard
    Jun 2, 2015 at 20:40
  • When your number > 4 of doing the same mistake. You risk a yelling ;)
    – LvB
    Jun 2, 2015 at 20:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .