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

On 02/27/2017 04:53 PM, Mark Nottingham wrote:

> it could be that a full HTML experience with a unique UX around it
> will meet the requirements better -- hence my "happy to change the
> details" above.

If browsers start displaying proxy-generated HTML errors, then [a draft
focusing on] constraining proxy vocabulary is hardly needed. Browsers
already apply reasonable constraints to resource presentations in other
contexts. They probably do not need us telling them how to do it!


> My observation so far is that browser vendors seem
> *very* reluctant to dive in and offer that.

Sure, why would they rush to solve a difficult problem that they can
obviously continue to ignore?! That sad fact does not imply, however,
that giving them a slightly smaller problem to solve (i.e., rendering
restricted but still capable of fooling users vocabulary) will change
the ultimate outcome.


> If you have a proposal that you think can get traction, please make it!

I can only dream of making traction, but I can suggest a different
attack angle:

1. When a client, while talking to a forward proxy, detects and reports
a communication error, it SHOULD mention that the proxy was involved and
SHOULD mention the address of that proxy.

It seems silly to propose that though -- it ought to be common sense,
especially for CONNECT errors, especially for folks concerned about user
privacy.


2. Clients would also need to support retrieval of HTTPS resources by a
forward HTTPS proxy. While such mechanism is already supported by HTTP
and TLS, its actual deployment probably requires secure response signing
and other fancy stuff that, AFAIK, others have already proposed.


Once the above two things are supported by popular clients, the need of
MitM attacks would be limited to outside-IETF-scope interception
environments (the motivation for which would also decrease significantly!).

Alex.

Received on Tuesday, 28 February 2017 01:18:18 UTC