[bogomipz]

>"This despite industry complaints that eliminating TLS RSA would cause problems, especially in the finance industry, for companies that need the ability to monitor the plaintext of TLS connections on their networks"

How do they monitor plaintext of TLS? Do they "man in the middle" this traffic? Can you elaborate? Is this a compliance issue or sorts?

[wolf550e]

Since they have the key for their own certificate, they can man in the middle forward secret connections too (these days, ECDHE). By supporting only non-PFS RSA key exchange with TLS 1.2, they had the ability to retroactively decrypt traffic without doing full man in the middle. Maybe they mirror a port on a switch and run an IDS/antivirus that decrypts the traffic and analyzes it. Maybe they log all traffic for a while and want to decrypt it only if needed.

In any way, the solution someone came up with was to do Diffie Hellman but reuse the ephemeral key (make it static) and share it with the decryption box. This turns (EC)DHE into not forward secure key exchange. The client can notice this happens because the server will reuse the DH key. I didn't hear about any browser planning to warn the user about this. The ssllabs tester will complain.

[technion]

If you are using a non-forward secrecy supporting implementation, such as RSA, the SSL key on the server is all that's required to be able to decrypt the conversation.

That's why you can use Wireshark in the manner described here, by installing the SSL key on your client machine, and decrypting the whole session:

https://support.citrix.com/article/CTX116557

You'll note the article warns, it won't work with DHE. Similarly, it won't work with ECDHE. Modern forward secrecy ensures that even with the key, an attacker is constrained in their ability to decrypt the ciphertext.

I can only assume the industry request was based on running this sort of thing at a larger scale.