Colm MacCárthaigh wrote: > > If you maintain that draft-green is Wiretapping, then that is also the > correct term for what is happening today. Today, operators are using a > static key, used on the endpoints they control, to decrypt traffic > passively. The only difference is DH vs RSA, and I know you'll agree that's > not material.
What I'm currently seeing in the installed base for getting at the plaintext of TLS-protected traffic, are these two approaches: (1) Server-side: Reverse-proxy (2) Client-side: TLS-intercepting proxy and neither of these needs to break TLS and neither needs to break forward secrecy of the SSL/TLS-protected(!) communication. While Server-side reverse proxies (1) _might_ be used to "inspect/monitor" traffic, more often it seems to be used for scaling / load-balancing to multiple backend servers of a server farm. We ship such functionality for the backend specifically for scaling/load-balancing, and for placing the SSL termination point into a DMZ (firewalled backend servers). We a proprietary scheme to forward SSL/TLS client certs from the reverse proxy to the backend servers. (2) is often used by so-called "AV-Software" of the "Internet Security" kind, and studies have shown over and over again just how badly many of that stuff breaks security (by botching the TLS server certificate validation and/or server endpoint identification). I also see (2) being used by some of our customers in the form of TLS intercepting internet proxies, mostly in countries that lack constitutional strong privacy protections (US, UK&CommonWealth, middle EAST). It regularly breaks outgoing communication scenarios and confused application admins, because the fake TLS server certificates will be rejected by our app client unless the trust in explicitly configured. Something which IT/networking departments occasionally fail to properly explain to their colleague application admins. Whenever outgoing communication requires the use of SSL/TLS client certs, existing TLS intercepting proxies don't work (and I'm really glad that they break). A growing number of legal/governmental data exchange scenarios use SSL/TLS client certs (something I really appreciate, because the use of client certs fixes a number of problems). :-) Personally, I consider server-side reverse proxies primarily as an implementation detail of the backend (how workload is distributed within the backend). The client-side TLS intercepting proxies, however, are a constant security problem, and unless it is a ***TRUELY*** voluntary, consenting opt-in, and running on the same machine as the user, and with the user in full control on whether and how that intercepting proxy is used. If presence & use of a TLS intercepting proxy is the result of anything along the lines of "compliance", "policy" or "conformance", then it is wire-tapping, with a probability near certainty. -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
