Use of custom DH parameters for TLS decryption

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?

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.

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.