Re: SSL/TLS everywhere fail

On 12/04/2015 12:18 PM, Ted Hardie wrote:
> On Thu, Dec 3, 2015 at 6:26 PM, Alex Rousskov wrote:
> 
>     On 12/03/2015 05:38 PM, Ted Hardie wrote:
>     > Look particularly at section 3.  As you will note from that, there are
>     > certainly middleboxes which are within scope (configured HTTP proxies
>     > among them).  But there are others which are not.  I know of no
>     > interception proxy requiring a newly installed root CA which would fit
>     > within the current policy, but I'm willing to be informed should there
>     > be one.


>     The prevalence of interception proxies is our other engineering failure,
>     but if I have deliberately installed your root CA on my phone and
>     clicked "I agree to be monitored by Ted" button in my favorite browser,
>     then you are no longer wiretapping my Google requests per RFC 2804.


> ​It is also utterly unnecessary if I you are agreeing to be monitored.​ 

Unfortunately, MitM attacks on consenting participants are increasingly
necessary today. In practice, there is no support for the explicit proxy
to decode my browser connection to Google even if I am consenting to
that action. There is also no support for me to express that consent.
There is even no support for me to communicate with that proxy securely
while it analyses my traffic!

I am certain that a very significant portion (possibly more than 80%) of
monitoring cases that do not violate the spirit of RFC 2804 would not
utilize MitM attacks if they could monitor without them.


> In the case where you are agreeing to be monitored, you direct the
> traffic to the inspection point.

Yes, I can configure my browser to talk to a proxy. [ For now, let's
ignore the fact that it is difficult to do cost-efficiently in a diverse
environment with a thousand different user agents. ]


> This allows you to use cryptographic
> confirmation that you are talking to the appropriate proxy, since it can
> provide you such an assertion over that hop (which it cannot do the same
> if acting as an interception proxy).  

No, secure communication with forward proxies is currently not supported
by many popular browsers. They can tunnel HTTPS through a forward HTTP
proxy, but they cannot be configured to encrypt their connection to the
forward proxy using TLS.

However, let's ignore that huge problem as well. Let's assume I trust my
unsecure connection to the forward proxy.

Now, I enter "google.com" in my address bar and ... I get an error
because Google redirects me to a secure site and the forward proxy
cannot inspect my HTTPS communication with Google, blocking me despite
my consent to be inspected.

I have consented. I have set up an explicit proxy. The proxy plays by
the rules. And yet nothing works! At this point, my employer is forced
to attack my HTTPS traffic even though neither they nor me want to
resort to those dirty tricks.


> That is deeply sad for that class of cases, but
> mostly indicative that these are mostly used where consent isn't
> present, because the organization involved doesn't care to get it.

Unfortunately, getting consent changes nothing (as I illustrated above)
because we failed to provide the protocols and tools to support
consent-driven monitoring. While there are certainly cases of lazy and
careless organizations, the attacks would have been in the tiny minority
among organizations (and parents) if those tools existed (not because
they would stop being lazy and careless, but because it is very
difficult to make those attacks work _well_).


> I am not sure who the "our" is in your "our other engineering failure"

Folks making internet work, including IETF and this WG participants.


> and since the problem goes back a long way, there are likely
> participants in this working group who have never known a web without
> this problem.  But the baseline truth is that there have always been
> folks who have traded their ease of configuration and lowered costs for
> their users privacy and individual security.   

Very true. Another baseline truth is the lack of a standard,
widely-supported, easy-to-configure, low-cost method to setup explicit
proxies in diverse environments. It is us who failed to agree on and
provide such a method long time ago, and I doubt the situation will
improve for HTTP/3. Our collective failure skewed the scale for the
unfortunate trade you are describing.


Alex.

Received on Friday, 4 December 2015 21:16:34 UTC