Re: The future of forward proxy servers in an http/2 over TLS world

Hi Alex,

On Mon, Feb 27, 2017 at 10:40:01AM -0700, Alex Rousskov wrote:
> This is not meant as an attack of some sort. I am only claiming that
> there is currently no consensus about or even rational justification for
> the limited vocabulary (and the latest example with a plain text phone
> number is a good illustration why there should not be). I am worried
> that if we push limited vocabulary as The Solution, and browsers
> painfully implement that, but the volume of needless MitM attacks does
> not go down substantially (because limited vocabulary is not The
> Solution), then we will be in an even worse position than we are today.

The root cause of the problem is that it's hard to get consensus on a
solution to a problem not everyone agrees with. The increasing presence
of MiTM precisely is the natural outcome of this lack of consensus. In
theory we should only focus on purely technical validity but many of us
tend to be biased thinking whether or not the use cases are valid and
whether or not by trying to solve the technical issues we're encouraging
some use cases that not everyone supports.

I remember in 95 the first time a network admin talked to me about caches
that were about to be installed, I was shocked, believing I would not have
a direct access to the origin servers anymore and that a cache in the
middle would decide what I should get. And his response was "the shared
bandwidth is so much limited that it's this or we have to disable web
browsing for everyone and only keep newsgroups". And in fact it was a
very good solution. But the same bias remains nowadays regarding why do
admins deploy proxies, what type of control they want to apply there, and
for what reason. It should not be our problem, our problem should be to
ensure that whenever they do this, the following conditions are met :

  - the end user is easily aware that he's passing via a proxy and that
    the contents he retrieves are possibly cached, filtered, aggregated,
    logged, etc.

  - the way it's done respects all interoperability rules

The fact that we don't put enough thinking into how to do this correctly
*when needed* results in the two important points above to be ignored by
resorting to MiTM to solve only technical issues, so our lack of
involvement in this area results in the opposite effect to what is seeked.

I tend to think we should revive the old discussions about trusted proxies
accessed over TLS, with the optional ability for them to perform the TLS
encryption (the "GET https://" as we used to call it) so that we can
address the problem where it is and with only technical means and without
any consideration for the impact on existing code nor on whether some of
us believe it's good or bad for the users to trust their admin. That will
significantly help building a solid solution to all these problems, will
result in no valid justification for any form of MiTM anymore and will
significantly improve the situation for those having to deal with this.

Just my two cents,

Received on Tuesday, 28 February 2017 06:38:22 UTC