On Thu, Sep 22, 2016 at 03:29:42PM -0400, Dave Garrett wrote: > > Yes, all of these other channels are protected using TLS... which you > do not control in any way. Also, many sites/services already prioritize > FS cipher suites, so the deprecation of plain RSA key exchange doesn't > actually affect the vast majority of people. (e.g. Facebook & Twitter > both prefer ECDHE with NIST P-256) Within this very argument is > already the argument that supervision at endpoints is required here. > he security on the pipe is irrelevant. I don't see how you can make a > point to bring this up but think keeping plain RSA KE suites is a > useful solution.
Well, if you have client and server that both have RSA KE enabled (even if not preferred), you can do something like this: - Intercept ClientHello. Strip any FPS ciphersuites and any associated extensions, strip EMS and ALPN but keep client_version and client_random the same. - The server will select RSA KE. - Intercept Certificate message and replace it with MITM cert. - Intercept ClientKeyExchange decrypt the key and re-encrypt with the original server key. - Compute the session key and log it. - Intercept the ClientFinished message and replace it with fixed version. - Intercept the ServerFinished message and replace it with fixed version. - Get off the active path, becoming passive. - Log the data transfer on the connection, and later decrypt it if desired. The keys will match, because they only depend on randoms (which were preserved) and the encrypted secret (which was preserved too). The EMS was stripped because it would break this. The MITM proxy knows the secrets needed to fix the Finished messages. Preferring FS won't help, because MITM proxy can downgrade the crypto negotiation. (And it is not like one can easily get the keys without either replacing the cert or knowing the RSA private key corresponding to it). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
