1
$\begingroup$

There are several ways to decrypt TLS e.g. in an enterprise environment. I did not see using "backdoored" DH parameters being mentioned somewhere though according to my understanding it should work in principle: How does a non-prime modulus for Diffie-Hellman allow for a backdoor?

Would it be possible for a recent desktop CPU to decrypt traffic in (nearly) realtime? Does it depend on the ciphers or TLS version? Are there any advantages/disadvantages for using this option? I guess stealing the custom parameters is similar to stealing the private and you loose PFS?

$\endgroup$
1
  • $\begingroup$ The Logjam researchers in 2015 found some sites using 512-bit DH (which they broke) even when not intentionally downgraded, and many more using 768-bit (which they considered breakable at modest cost). Of course these weren't hidden as a 'backdoor' normally is, they just went unnoticed by the large majority of people (and admins) who don't care about security until after they've been compromised. $\endgroup$ Jan 22, 2022 at 1:50

2 Answers 2

1
$\begingroup$

Would it be possible for a recent desktop CPU to decrypt traffic in (nearly) realtime?

If you're asking specifically about backdoored DH groups, well, if you're using a version of TLS that allows the server [1] to propose a nonstandard DH group (and the client would accept that group; sane ones wouldn't), then yes, it could propose an extremely weak group (e.g. one for which $p-1$ has no large factors), and this would make recovering the shared secret (and hence the traffic keys) easy.

Such 'weak DH groups' aren't possible if you're doing a sane version of TLS (or the client refuses to accept some rather odd options); on the other hand, if you are doing DH, you can just have the server use a guessable DH private value (e.g. one which is a function of the server hello cookies); the attacker could use that to listen in.

On the third hand, if you're in control of the server, well, why bother? The server has the traffic keys in hand; if the adversary controls that, it'd be even easier to have the server give the session keys to whoever's listening in.

[1]: I think it's the server that proposes the DH group in TLS 1.2; if not, just swap client and server in the above argument.

$\endgroup$
1
  • 1
    $\begingroup$ For TLS1.0-1.2 without RFC7919, if the client offers and the server accepts a ciphersuite using (FF)DHE, the server chooses the group and the client must either conform or abort the handshake. With 7919 the client can request standardized (Oakley-style) groups, but the server can still choose otherwise, in which case the client probably aborts. I don't know anything that implements 7919 without also implementing TLS1.3, which not only does the XXDHE 'forwards' (client offers keyshare(s) to server) but is preferable on other grounds. $\endgroup$ Jan 22, 2022 at 1:52
0
$\begingroup$

In the TLS protocol, the server decides on the group for the key exchange: finite-field Diffie-Hellman group or elliptic curve. The server must choose within constraints given by the client. In TLS 1.3, groups are identified from a small list of standard groups. Earlier versions of the protocol allow the server to describe a custom group. For elliptic curves, this is rarely supported: most software only supports named curves. But for finite-field Diffie-Hellman, the client classically only constrains the size of the group, and the server sends the numerical value of the parameters. While most software today supports the NamedGroup extension, most clients will accept numerical values for backward compatibility. So a client may be tricked into accepting FFDH parameters that are backdoored.

However, this is pretty mostly irrelevant as a security threat, because the server picks the parameters. If the server wants to compromise the key exchange, it can also do a perfectly strong key exchange and then log the shared secret somewhere. So for weak FFDH parameters to be a security concern, there has to be an extremely unlikely security model:

  • The server is running backdoored code (or has a backdoored configuration), and you aren't able to detect that the backdoor was inserted.
  • The backdoored code is only in a small part of the TLS stack, and you're confident that there's no backdoor elsewhere that could, for example, leak the plaintext or the shared secret directly.

Basically, backdoored FFDH in TLS can only be the server shooting its own foot. It's irrelevant for eavesdropping on traffic between other hosts. Either the server is backdoored and you don't need it, or the server is not backdoored and it won't do you any good.

$\endgroup$
1
  • $\begingroup$ Actually, there's a third threat model: whoever did the server didn't know their cryptography and accidentally selected weak DH parameters. $\endgroup$
    – poncho
    Jan 22, 2022 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.