How to check if a server is not vulnerable to Logjam?

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.

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