Re: [TLS] datacenter TLS decryption as a three-party protocol

[[e-mail] (Martin Rex)]

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