Here's an unrelated bug report which points toward the problem being a too short ephemeral key (Server Temp Key: DH, 512 bits). But I'm not seeing anything like that in my output, even when adding the -debug parameter to the OpenSSL invocation.

I want to find out exactly which key is "too small" so that I can either fix it locally, or forward it to whoever is in a position to fix it and give them enough information that they should be able to fix it without too much trouble. So how do I find out which key exactly OpenSSL is complaining about?

I'm willing to use other tools as well for investigating this; answers need not be limited to using OpenSSL.

@RuiFRibeiro I know about stackoverflow.com/q/30701397 already. Please do tell me how it helps me determine which exact key OpenSSL is complaining about. All it says is how to reconfigure Apache, but that doesn't help me determine which key is too short, does it? Let alone that this isn't a HTTPS issue.
– a CVnDec 31 '16 at 17:40

1 Answer
1

I want to find out exactly which key is "too small" so that I can either fix it locally, or forward it to whoever is in a position to fix it and give them enough information that they should be able to fix it without too much trouble. So how do I find out which key exactly OpenSSL is complaining about?

Its not really a problem of "one key is too small, which one is it" per se. When you perform key agreement in TLS, you do so using Diffie-Hellman domain parameters. When the client advertises cipher suites with Diffie-Hellman in its Client Hello, the Server Hello responds with a Diffie-Hellman group and its ephemeral/temporary public key in that group. As a client, you are expected to execute the protocol using the server's ephemeral/temporary public key, and communicate your ephemeral/temporary public key to the server in the next message.

More formally, you are talking about a multiplicative group Zp. The server chooses a secret value X, computes its ephemeral/temporary public key as x = gX mod p, and sends you the domain parameters {p, g} and its public key x. You would calculate the ephemeral/temporary public key as y = gY mod p, and the client/server agreed upon secret drops out of gXY mod p after a few messages.

The complaint is that p is too small, it does not provide anything close to reasonable security levels, and its subject to being brute forced. So whatever the server calculates (x = gX mod p) and whatever you calculate (y = gY mod p) does not achieve reasonable security. For the details, see the paper on the Logjam attack.

There are other attacks in these Diffie-Hellman agreements as used in TLS, but this is one of the bigger ones. For example, the TLS working group is discussing re-use of server side precomputed DH keys as we speak at [TLS] Requiring that (EC)DHE public values be fresh.

If you want to view the actual parameters that are causing the trouble, then you will probably need to run Wireshark or use tcpdump. s_client displays Server Temp Key info only on successful handshake (and only in version 1.0.2 up, but as of this month that's the lowest version supported upstream). It will dump the protocol messages (sent and) received in hex if you add -msg, but you have to decode them by hand which
isn't easy; if you want to try see this SO question.

You have three fixes available that I am aware.

First, change email hosting providers to one which is more astute with respect to security.

Second, write to your current email hosting provider and ask them to fix their server.

Third, you can use RSA key transport rather than Diffie-hellman key exchange. If you choose this option, then you lose forward secrecy.
The TLS working group is dropping RSA key transport from TLS 1.3, so you won't be able to use this option with future versions of TLS. I expect TLS 1.2 to hang around for some time, so it probably won't be a problem in practice for some time. OpenSSL normally allows this, but some people disable it to force forward secrecy; if you have a cipherlist that specifies !kRSA remove it (temporarily).

If you use -V uppercase instead of -v it includes the codepoints (1.0.0 up), but the resulting lines are too long for a traditional 80-column window; either use a wider window, or less -S or similar, or redirect to a file and then view or edit the file.

Note that list includes static-DH and static-ECDH suites (except in 1.1.0?) which are practically never used; for a list limited to usable ephemeral suites do ciphers -v 'EDH:EECDH:!EXPORT:!LOW'.