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

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 14 Feb 2017 22:37:12 +0000

At the moment, it feels like the functions provided by proxy servers are 
being squeezed out by changes in the protocol.

I can understand the desire for privacy, and we've had the argument 
about whether it should be available to all or not too many times 
already.

However, there are other functions that a proxy is commonly used for 
that are becoming impossible with the direction TLS, HTTPS HSTS, cert 
pinning etc are going.

Whilst I can understand a desire and need for privacy, an ability to be 
able to go to a website without betraying which site you're going to 
(e.g. see https://tools.ietf.org/html/draft-schwartz-dns-sni-01 
<https://tools.ietf.org/html/draft-schwartz-dns-sni-01>) there's 
probably 1 remaining IMO critical bona fide purpose for a proxy which is 
becoming very problematic for users.

Blocking requests.

So, do we feel there is still a place for blocking requests?  Our 
customers still certainly want this.

Currently the user experience is either appalling (generic connectivity 
failure report which wastes a lot of user time), or requires deployment 
of a MitM, which is being squeezed out as well.  We should be able to do 
better, but it doesn't appear to be being addressed at all, and the gulf 
is widening.

I believe we need to put some time into working out how we can allow a 
proxy to block requests without an awful user experience that costs 
users and tech support countless hours to deal with.

This means we have a need to be able to respond to CONNECT with a 
denial, and some kind of message that can be displayed to the user.

It may be that the only way this can be achieved is by the concept of a 
trusted proxy.

Otherwise if the group consensus is that requests should not be blocked, 
we need to deal with the consequences of that.

Adrien

P.s. another key feature is caching, but that is becoming less useful 
anyway.  Customers can often live without caching, they do not tolerate 
being unable to block however.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 15 Feb 2017 07:35:55 +0000

--------
In message <emde1bfa93-84c0-49f7-83a4-b9bed24e0276@bodybag>, "Adrien de Croy" writes:

>I believe we need to put some time into working out how we can allow a=20
>proxy to block requests without an awful user experience that costs=20

That would be possible with the "envelope/message" split which I
used as argument against adopting SPDY for H2, but since people
were in the politically naive "SSL ALL THE THINGS" mode at the time,
nobody seems to have even thought about the long term implications.

>being unable to block however.

Caching is incredibly important on the server side still.  That is why
CDNs are having such a party.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 15 Feb 2017 21:31:25 +0200 (EET)

> denial, and some kind of message that can be displayed to the user.

Maybe

https://tools.ietf.org/id/draft-nottingham-proxy-explanation-00.txt

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0390.html

https://bugzilla.mozilla.org/show_bug.cgi?id=637619#c31

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0419.html

/ Kari Hurtta

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:02:24 +0000

Thanks for that

looks like I already knew about it lol.

Do we have any idea about whether this has browser support, I assume FF 
so far only?

Adrien

------ Original Message ------
From: "Kari Hurtta" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "HTTP working group mailing list" <[email-masked]>; "Kari 
Hurtta" <[email-masked]>
Sent: 16/02/2017 8:31:25 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Feb 2017 15:08:16 -0500

there is no firefox support for that right now. It would require a
convincing UI and probably interest from another client to proceed with.
The concern is obviously some kind of phish mitm any time you are asked to
display https and you display anything not authenticated by that origin.

On Wed, Feb 15, 2017 at 3:02 PM, Adrien de Croy <[email-masked]> wrote:

> Do we have any idea about whether this has browser support, I assume FF so
> far only?
>
> Adrien
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:11:52 +0000

yes, that's what caused the problem in the first place, and until we 
trust the proxy I don't think we'll move on from there.

Which means the connection to the proxy needs to be TLS.

We already support this with WinGate and I've verified it with Chrome 
and Firefox.  In that case couldn't the client trust an error response 
body from CONNECT?

Adrien

------ Original Message ------
From: "Patrick McManus" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Kari Hurtta" <[email-masked]>; "HTTP working group 
mailing list" <[email-masked]>
Sent: 16/02/2017 9:08:16 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>convincing UI and probably interest from another client to proceed 
>with. The concern is obviously some kind of phish mitm any time you are 
>asked to display https and you display anything not authenticated by 
>that origin.
>
>
>>Do we have any idea about whether this has browser support, I assume 
>>FF so far only?
>>
>>Adrien
>>
>>
>>><https://tools.ietf.org/id/draft-nottingham-proxy-explanation-00.txt>
>>>
>>>
>>><https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0390.html>
>>>
>>><https://bugzilla.mozilla.org/show_bug.cgi?id=637619#c31>
>>>
>>><https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0419.html>
>>>
>>>/ Kari Hurtta
>>>
>>
>>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:17:39 +0000

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>

>Which means the connection to the proxy needs to be TLS.

or at the very least the response message from the proxy needs to be 
digitally signed.  I could understand why a browser may not wish to have 
2 TLS layers going on at the same time.

Adrien

>>with. The concern is obviously some kind of phish mitm any time you 
>>are asked to display https and you display anything not authenticated 
>>by that origin.
>>
>>
>>>Subject: Re: The future of forward proxy servers in an http/2 over 
>>>TLS world
>>>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Feb 2017 15:22:14 -0500

On Wed, Feb 15, 2017 at 3:11 PM, Adrien de Croy <[email-masked]> wrote:

>
>
> yes, that's what caused the problem in the first place, and until we trust
> the proxy I don't think we'll move on from there.
>
> We already support this with WinGate and I've verified it with Chrome and
> Firefox.  In that case couldn't the client trust an error response body
> from CONNECT?
>
> Adrien
>

(firefox hat)

we trust the error came from the proxy - but we don't trust displaying
custom text it in the usual way without significant UI around it as we
would normal content - content comes from the origin and in https is
authenticated as coming from the origin. While we will authenticate a proxy
(and its a good feature!), we aren't trusting it to generate https://
content - just transport it over a CONNECT tunnel so if there is an an
error message that isn't generated by the origin, we would need a different
way to display it. I'm not saying that's impossible - I'm just saying it
doesn't exist.

we would need new UI for messages clearly from an authenticated (I'm not
sure I would use the word trusted) third party. The alternative, as you
mention, is to double down on two-party communication - that imperils the
traditional role of proxy. Some people feel that's a better model and some
disagree. That fight continues in what people choose to implement.

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 15 Feb 2017 12:24:52 -0800

On Wed, Feb 15, 2017 at 12:17 PM, Adrien de Croy <[email-masked]> wrote:

> digitally signed.  I could understand why a browser may not wish to have 2
> TLS layers going on at the same time.
>

​Chrome supports speaking to an HTTP proxy via TLS. However, that's not
sufficient to display error pages in response to connect requests. If the
user attempts to navigate to an https:// URL, the UI presented should
either be:

* Actual content from the server which has been end-to-end authenticated
via a TLS connection to the origin.
* Browser UI

In the general case, the proxy is not in a position to be trusted by the
browser, alas.

Cheers,

Ryan

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:27:30 +0000

also, as was the argument made way back.

a client that can't tell the difference between a 403 and a 200 status 
response to a connect, and therefore can't display the body in a way 
appropriate to this should just be fixed.

It's entirely possible to render the body on a 403 response, knowing 
it's a 403 response, in a way that can't expose the user to any 
phishing, for example

a) disable and/or strip any hyperlinks
b) suppress any jscript or embedded resources (CSS, JS) except images, 
which are vetted also
c) show it in a different frame with diagonal black and yellow

This would have solved the problem from the start.

Adrien

------ Original Message ------
From: "Ryan Hamilton" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Sent: 16/02/2017 9:22:06 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>On Wed, Feb 15, 2017 at 12:11 PM, Adrien de Croy <[email-masked]> 
>wrote:
>​We used to do this in Chrome, but removed it because of the potential 
>for phishing. Here's just on example
>
>Imagine that at user has their browser configured to do proxy auto 
>discovery. They walk into a cafe and join a wireless network which 
>sends their traffic to a malicious proxy. The user types 
>https://mail.example.com/, and is presented with a CONNECT error page 
>whose contents look exactly like the actual mail.example.com login page 
>to which they dutifully type their username and password.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 15 Feb 2017 13:33:05 -0700

On 02/14/2017 03:37 PM, Adrien de Croy wrote:
> we have a need to be able to respond to CONNECT with a denial

Please note that many admins are forced to tell Squid (and other
proxies) to respond with 200 OK to CONNECT and then peek into SSL Hellos
because the CONNECT request itself does not have enough information to
block or allow traffic. Common complaints include, but are not limited to:

* use of IP addresses instead of domain names in the CONNECT target
* [policy-violating] non-SSL traffic inside CONNECT tunnels
* [old] SSL versions
* [insecure] SSL ciphers
* [no longer trusted] server certificates

The above problems will remain even if browsers allow CONNECT error
reporting [in some general-enough cases, with limited vocabulary].

To solve these (and many other) problems, the browsers will either have
to let an HTTPS-protected proxy to do SSL-to-origin for them or come up
with a new request method that allows the proxy to respond with an error
_after_ examining the SSL handshakes. Stockholm syndrome aside, I cannot
imagine browsers suddenly falling that much in love with proxies!

Cheers,

Alex.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:33:56 +0000

Maybe that's where we need to start.

In the way that the browser discovers and selects the proxy.

DHCP + DNS + WPAD is completely insecure.

Let alone not even standardised.  Different clients do proxy auto-detect 
in different ways.

Maybe some of these cases should involve different behaviour depedning 
on how the client selected the proxy.

For example in a corporate network, where the proxy is mandated by AD 
group policy, you could argue that the publis wifi attacker argument 
doesn't hold water.

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Ryan Hamilton" <[email-masked]>
Sent: 16/02/2017 9:23:35 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>
>how did they trust the proxy?
>
>I'm suggesting trusted proxy, which means the proxy would need to use a 
>cert trusted by the client.
>
>I'd go further and say we need to do better than proxy auto-detect as 
>well - it needs to be secured.
>
>Adrien
>
>
>>>and Firefox.  In that case couldn't the client trust an error 
>>>response body from CONNECT?
>>
>>whose contents look exactly like the actual mail.example.com login 
>>page to which they dutifully type their username and password.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:39:50 +0000

------ Original Message ------
From: "Ryan Hamilton" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Sent: 16/02/2017 9:26:37 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>I'm not sure what a "Trusted proxy" means in this context. If the proxy 
>can mint certificates that are trusted by the browser, then the proxy 
>can terminate TLS connections at the proxy and impersonate the origin. 
>This is a supported use-case in Chrome (and other browsers).
minting certs is a MitM function.  I wasn't referring to that.

But if the proxy can mint certs that are trusted by the browser, the 
question is how is that.  The proxy would need to be using a signing 
cert that is trusted by the browser, and how did it get installed in the 
browser?

In any case as per my original post, MitM is getting squeezed out by 
HSTS, PKP etc.  Instead of promoting an arms-race between client vendors 
and proxy vendors (e.g. our current next step is to attack HSTS and PKP 
to enable us to continue to display block pages that don't cause our 
customers headaches) how about we work together to allow decent secure 
blocking of requests?

Blocking is a completely legitimate need in corporate networks and 
others.

Currently the balance of power has swung to the user, whether that's a 
child surfing where he/she shouldn't or whoever.

Blocking has become less precise, and the way it's going will have to be 
done at the IP or TCP level.  The lower the level you block at, the 
worse the user experience, and the more time wasted in organisations 
chasing phantoms mis-reported by browsers.

Does h2 even support a proxy?  CONNECT is HTTP/1

Adrien

>
>
>On Wed, Feb 15, 2017 at 12:23 PM, Adrien de Croy <[email-masked]> 
>wrote:
>>
>>I'm suggesting trusted proxy, which means the proxy would need to use 
>>a cert trusted by the client.
>>
>>>>We already support this with WinGate and I've verified it with 
>>>>Chrome and Firefox.  In that case couldn't the client trust an error 
>>>​We used to do this in Chrome, but removed it because of the 
>>>potential for phishing. Here's just on example
>>>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 20:47:01 +0000

------ Original Message ------
From: "Ryan Hamilton" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Sent: 16/02/2017 9:22:06 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>to which they dutifully type their username and password.

so at this point you have a browser rendering a usable form from a 403 
body, and processing it?

this seems like just a really stupid thing for a browser to do, rather 
than a protocol problem.

It's not like the 403 status was hidden from the client.

The original FF bug reported by Adam Barth which kicked this all off 
involved a browser following a 302 response to a CONNECT method.

Maybe browsers shouldn't follow 302 responses to CONNECT.

But deciding to block bodies chucked the baby out with the bath water, 
and we have been answering tech support tickets on it ever since and 
telling people the only work-around is MitM.

Adrien

---

From: Patrick McManus <[email-masked]>
Date: Wed, 15 Feb 2017 15:48:43 -0500

> Does h2 even support a proxy?  CONNECT is HTTP/1

yes - connect is defined in 7540 and implemented in (at least) chrome and
firefox. You can do nifty h2 over h2 with it creating a truly exciting
level of multiplexing (i.e. multiple connect tunnels can be muxed in one
connection to the proxy and each tunnel can of course carry h2 with
multiple muxed streams).

-P

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 Feb 2017 20:52:14 +0000

No, CONNECT is HTTP, full stop.  The use of that method is defined for HTTP/1.1, HTTP/2, and even HTTP/QUIC.  You can speak HTTP/2 to a proxy if you want – you get a multiplexed connection to the proxy, and what the proxy uses on the back-end is opaque to you.

I’m somewhat sympathetic to the complaint that we’ve doubled down on two-party communication when there are legitimate use cases for having a third party with some level of access to the traffic.  The problem is that these use cases run the gamut as to how much access they need, and they’re equally applicable to illegitimate cases.  (Or rather, cases *I* perceive as illegitimate, since that’s a policy judgement and not a technical one.)

Groups such as IEEE’s Encrypted Traffic Inspection working group are trying to build something like this, but they make me nervous.  You can’t build a mechanism into a protocol that restricts it to virtuous uses – see RFC3751 for a good example here.  The best that can be achieved is to surface to the user an authenticated identity of who’s spying on their traffic – but we all know the outcome of user dialogs asking “would you like to agree to some technical gobbledygook, or would you like to not see your dancing kittens?”

From: Adrien de Croy [mailto:[email-masked]]
Sent: Wednesday, February 15, 2017 12:40 PM
To: Ryan Hamilton <[email-masked]>; [email-masked]
Subject: Re: The future of forward proxy servers in an http/2 over TLS world

------ Original Message ------
From: "Ryan Hamilton" <[email-masked]<mailto:[email-masked]>>
To: "Adrien de Croy" <[email-masked]<mailto:[email-masked]>>
Sent: 16/02/2017 9:26:37 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS world

I'm not sure what a "Trusted proxy" means in this context. If the proxy can mint certificates that are trusted by the browser, then the proxy can terminate TLS connections at the proxy and impersonate the origin. This is a supported use-case in Chrome (and other browsers).
minting certs is a MitM function.  I wasn't referring to that.

But if the proxy can mint certs that are trusted by the browser, the question is how is that.  The proxy would need to be using a signing cert that is trusted by the browser, and how did it get installed in the browser?

In any case as per my original post, MitM is getting squeezed out by HSTS, PKP etc.  Instead of promoting an arms-race between client vendors and proxy vendors (e.g. our current next step is to attack HSTS and PKP to enable us to continue to display block pages that don't cause our customers headaches) how about we work together to allow decent secure blocking of requests?

Blocking is a completely legitimate need in corporate networks and others.

Currently the balance of power has swung to the user, whether that's a child surfing where he/she shouldn't or whoever.

Blocking has become less precise, and the way it's going will have to be done at the IP or TCP level.  The lower the level you block at, the worse the user experience, and the more time wasted in organisations chasing phantoms mis-reported by browsers.

Adrien

On Wed, Feb 15, 2017 at 12:23 PM, Adrien de Croy <[email-masked]<mailto:[email-masked]>> wrote:

I'm suggesting trusted proxy, which means the proxy would need to use a cert trusted by the client.

I'd go further and say we need to do better than proxy auto-detect as well - it needs to be secured.

Adrien

------ Original Message ------
From: "Ryan Hamilton" <[email-masked]<mailto:[email-masked]>>
To: "Adrien de Croy" <[email-masked]<mailto:[email-masked]>>
Sent: 16/02/2017 9:22:06 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS world

On Wed, Feb 15, 2017 at 12:11 PM, Adrien de Croy <[email-masked]<mailto:[email-masked]>> wrote:
We already support this with WinGate and I've verified it with Chrome and Firefox.  In that case couldn't the client trust an error response body from CONNECT?

​We used to do this in Chrome, but removed it because of the potential for phishing. Here's just on example

Imagine that at user has their browser configured to do proxy auto discovery. They walk into a cafe and join a wireless network which sends their traffic to a malicious proxy. The user types https://mail.example.com/, and is presented with a CONNECT error page whose contents look exactly like the actual mail.example.com<http://mail.example.com> login page to which they dutifully type their username and password.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 21:11:53 +0000

attached is what I get when I block https to youtube without MitM

I'm sorry but even a dialog box that said "proxy denied connection", and 
even just printed the status line would be more useful than this:

"The webpage at https://www.youtube.com/ might be temporarily down or it 
may have moved permanently to a new web address"

this is PURE FICTION.

It serves only to confuse users, and cause them to look in the wrong 
places for the problem.

A savvy user may see the "ERR_TUNNEL_CONNECTION_FAILED" and realise it's 
something to do with a proxy.

but the connection didn't fail, it was refused.

This is just a source of pain for all users.  There's no excuse to be 
lying to browser users like this.

Adrien

------ Original Message ------
From: "Mike Bishop" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>; "Ryan Hamilton" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 16/02/2017 9:52:14 AM
Subject: RE: The future of forward proxy servers in an http/2 over TLS 
world

>No, CONNECT is HTTP, full stop.  The use of that method is defined for 
>HTTP/1.1, HTTP/2, and even HTTP/QUIC.  You can speak HTTP/2 to a proxy 
>if you want – you get a multiplexed connection to the proxy, and what 
>the proxy uses on the back-end is opaque to you.
>
>
>
>I’m somewhat sympathetic to the complaint that we’ve doubled down on 
>two-party communication when there are legitimate use cases for having 
>a third party with some level of access to the traffic.  The problem is 
>that these use cases run the gamut as to how much access they need, and 
>they’re equally applicable to illegitimate cases.  (Or rather, cases 
>*I* perceive as illegitimate, since that’s a policy judgement and not a 
>technical one.)
>
>
>
>Groups such as IEEE’s Encrypted Traffic Inspection working group are 
>trying to build something like this, but they make me nervous.  You 
>can’t build a mechanism into a protocol that restricts it to virtuous 
>uses – see RFC3751 for a good example here.  The best that can be 
>achieved is to surface to the user an authenticated identity of who’s 
>spying on their traffic – but we all know the outcome of user dialogs 
>asking “would you like to agree to some technical gobbledygook, or 
>would you like to not see your dancing kittens?”
>
>
>
>>I'm not sure what a "Trusted proxy" means in this context. If the 
>>proxy can mint certificates that are trusted by the browser, then the 
>>proxy can terminate TLS connections at the proxy and impersonate the 
>>origin. This is a supported use-case in Chrome (and other browsers).
>>
>cert that is trusted by the browser, and how did it get installed in 
>the browser?
>
>
>
>HSTS, PKP etc.  Instead of promoting an arms-race between client 
>vendors and proxy vendors (e.g. our current next step is to attack HSTS 
>and PKP to enable us to continue to display block pages that don't 
>cause our customers headaches) how about we work together to allow 
>decent secure blocking of requests?
>
>
>
>Blocking has become less precise, and the way it's going will have to 
>be done at the IP or TCP level.  The lower the level you block at, the 
>>>>>Chrome and Firefox.  In that case couldn't the client trust an 
>>>>>error response body from CONNECT?
>>>>>
>>>>
>>>>
>>>>https://mail.example.com/, and is presented with a CONNECT error 
>>>>page whose contents look exactly like the actual mail.example.com 
>>>>login page to which they dutifully type their username and password.
>>>>
>>
>>

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 15 Feb 2017 14:14:12 -0700

On 02/15/2017 01:24 PM, Ryan Hamilton wrote:

> sufficient to display error pages in response to connect requests.

UI problems aside, it is sufficient -- the level of trust towards an
HTTPS proxy is the same as the level of trust towards an HTTPS origin
server because both destinations are (or can be) validated using the
same set of trust mechanisms. Chrome (among other browsers) just does
not want to solve the UI problems associated with handling two trusted
but different sources of information.

> the UI presented should either be:
> 
> * Actual content from the server which has been end-to-end authenticated via a TLS connection to the origin.
> * Browser UI

This is a false dichotomy IMO. Just because a browser currently lacks a
third UI does not mean that such UI cannot be added. The HTTPS proxy has
been end-to-end authenticated via an end-to-end TLS connection just like
the origin server would have been. There is no difference there. The
only difference is the lack of a distinct-enough UI for proxy-generated
content.

It is a difficult UI problem, but browsers, given enough motivation,
have solved plenty of difficult UI problems (or even shipped without
good solutions).

Alex.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 21:14:58 +0000

the one for IE is even worse.  It offers a connection troubleshooter 
button.

After exhorting the user to try 3 useless pointless tasks that will not 
help at all.

What a time waster!

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Mike Bishop" <[email-masked]>; "Ryan Hamilton" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 16/02/2017 10:11:53 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>I'm sorry but even a dialog box that said "proxy denied connection", 
>and even just printed the status line would be more useful than this:
>
>"The webpage at https://www.youtube.com/ might be temporarily down or 
>it may have moved permanently to a new web address"
>
>this is PURE FICTION.
>
>A savvy user may see the "ERR_TUNNEL_CONNECTION_FAILED" and realise 
>it's something to do with a proxy.
>
>>a third party with some level of access to the traffic.  The problem 
>>is that these use cases run the gamut as to how much access they need, 
>>and they’re equally applicable to illegitimate cases.  (Or rather, 
>>cases *I* perceive as illegitimate, since that’s a policy judgement 
>>and not a technical one.)
>>
>>
>>
>>vendors and proxy vendors (e.g. our current next step is to attack 
>>HSTS and PKP to enable us to continue to display block pages that 
>>don't cause our customers headaches) how about we work together to 
>>allow decent secure blocking of requests?
>>
>>
>>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 21:20:25 +0000

Edge is about the same without the button and a more millenial-friendly 
translation of the IE text.

FF on the other hand states the actual problem, that the proxy refused 
to make the connection.

I guess I'll be recommending FF from now on to my customers with this 
problem.

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Mike Bishop" <[email-masked]>; "Ryan Hamilton" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 16/02/2017 10:14:58 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>>>No, CONNECT is HTTP, full stop.  The use of that method is defined 
>>>for HTTP/1.1, HTTP/2, and even HTTP/QUIC.  You can speak HTTP/2 to a 
>>>proxy if you want – you get a multiplexed connection to the proxy, 
>>>and what the proxy uses on the back-end is opaque to you.
>>>
>>>
>>>
>>>two-party communication when there are legitimate use cases for 
>>>having a third party with some level of access to the traffic.  The 
>>>problem is that these use cases run the gamut as to how much access 
>>>they need, and they’re equally applicable to illegitimate cases.  (Or 
>>>rather, cases *I* perceive as illegitimate, since that’s a policy 
>>>judgement and not a technical one.)
>>>
>>>
>>>
>>>>proxy can mint certificates that are trusted by the browser, then 
>>>>the proxy can terminate TLS connections at the proxy and impersonate 
>>>>the origin. This is a supported use-case in Chrome (and other 
>>>>browsers).
>>>>
>>>Currently the balance of power has swung to the user, whether that's 
>>>a child surfing where he/she shouldn't or whoever.
>>>
>>>
>>>
>>>be done at the IP or TCP level.  The lower the level you block at, 
>>>the worse the user experience, and the more time wasted in 
>>>organisations chasing phantoms mis-reported by browsers.
>>>
>>>
>>>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 15 Feb 2017 21:36:54 +0000

last image...

this is what you get if you turn on https inspection (MitM).

So you can guess what our customers do.

How this is a win for the internet is beyond me, but it's what we're 
forced to do.

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Mike Bishop" <[email-masked]>; "Ryan Hamilton" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 16/02/2017 10:20:25 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>>After exhorting the user to try 3 useless pointless tasks that will 
>>not help at all.
>>
>>What a time waster!
>>
>>Adrien
>>
>>>Subject: RE: The future of forward proxy servers in an http/2 over 
>>>TLS world
>>>
>>>>they need, and they’re equally applicable to illegitimate cases.  
>>>>(Or rather, cases *I* perceive as illegitimate, since that’s a 
>>>>policy judgement and not a technical one.)
>>>>
>>>>
>>>>
>>>>can’t build a mechanism into a protocol that restricts it to 
>>>>virtuous uses – see RFC3751 for a good example here.  The best that 
>>>>can be achieved is to surface to the user an authenticated identity 
>>>>of who’s spying on their traffic – but we all know the outcome of 
>>>>user dialogs asking “would you like to agree to some technical 
>>>>gobbledygook, or would you like to not see your dancing kittens?”
>>>>
>>>>
>>>>
>>>>>the proxy can terminate TLS connections at the proxy and 
>>>>>impersonate the origin. This is a supported use-case in Chrome (and 
>>>>>other browsers).
>>>>>
>>>>Blocking has become less precise, and the way it's going will have 
>>>>to be done at the IP or TCP level.  The lower the level you block 
>>>>at, the worse the user experience, and the more time wasted in 
>>>>>>>On Wed, Feb 15, 2017 at 12:11 PM, Adrien de Croy 
>>>>>>><[email-masked]> wrote:
>>>>>>>
>>>>>>>Imagine that at user has their browser configured to do proxy 
>>>>>>>auto discovery. They walk into a cafe and join a wireless network 
>>>>>>>which sends their traffic to a malicious proxy. The user types

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 16 Feb 2017 19:21:34 +0200 (EET)

Patrick McManus <[email-masked]>: (Wed Feb 15 22:22:14 2017)
> disagree. That fight continues in what people choose to implement.

My sugeestion for UI is

--------------

	Message from proxy <proxy URL>

	[View proxy message]

--------------

And [View proxy message]  is button which

- possible opens new window or tab
- Shows <proxy URL> on location bar of that window or tab
- Displays message from proxy

- Possible lock symbol reflects TLS
  of proxy connection

That way this is equivalent to navigation
to another site. And because "navigation"
does not happen automatically, change
of location bar is not hidden from user.

/ Kari Hurtta

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 16 Feb 2017 11:15:58 -0700

On 02/16/2017 10:21 AM, Kari Hurtta wrote:
> - Possible lock symbol reflects TLS of proxy connection
> 

As an added bonus, your approach would eliminate the need to dumb down
the proxy error vocabulary.

I would polish this further by explicitly saying "Error" instead of
using more vague "Message" and use the already common "view error
details" UI (with an explanation) for that "button".

Needless to say, implementing the guts behind this simple UI is going to
be difficult in most browsers because they probably lack proxy security
context visualization code for showing that detailed message and because
the browser infrastructure (history, etc.) may not be ready to handle
location bar URLs that are not really suitable for submitting or
re-submitting requests.

This UI does not solve the "CONNECT request lacks details" problem, but
it would encourage solutions to that problem by turning on the light at
the end of the tunnel currently ending in MitM nightmares.

Thank you,

Alex.

---

From: Tom Bergan <[email-masked]>
Date: Thu, 16 Feb 2017 10:25:12 -0800

You started by stating, without proof, that proxies are needed to block
requests. What are you actually trying to do, and why does that require a
proxy? Do your users opt-in to the feature, or are you trying to impose the
feature on unwilling users? How much control do you have over the user's
machine? Is your proxy installed on the user's machine (like an
anti-virus), on end-user routers, in ISPs, or in a third party? Are you
trying to block hosts or specific URLs? Do you need to inspect the body of
the request or the response, or the headers, or just the URL? How do we
know you're trying to do something that's even feasible in the first place?
(see the previous citation of RFC 3751)

etc.

On Tue, Feb 14, 2017 at 2:37 PM, Adrien de Croy <[email-masked]> wrote:

> I can understand the desire for privacy, and we've had the argument about
> whether it should be available to all or not too many times already.
>
> However, there are other functions that a proxy is commonly used for that
> are becoming impossible with the direction TLS, HTTPS HSTS, cert pinning
> etc are going.
>
> able to go to a website without betraying which site you're going to (e.g.
> see https://tools.ietf.org/html/draft-schwartz-dns-sni-01) there's
> failure report which wastes a lot of user time), or requires deployment of
> a MitM, which is being squeezed out as well.  We should be able to do
> better, but it doesn't appear to be being addressed at all, and the gulf is
> widening.
>
> proxy to block requests without an awful user experience that costs users
> and tech support countless hours to deal with.
>
> This means we have a need to be able to respond to CONNECT with a denial,
> and some kind of message that can be displayed to the user.
>

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 16 Feb 2017 12:47:15 -0700

On 02/16/2017 11:25 AM, Tom Bergan wrote:

> requests.

Adrien did not state that at all! He actually stated that

  * proxies are used to block requests;
  * blocking requests is a critical proxy purpose;
  * blocking by proxy becomes increasingly difficult or even impossible
    due to ongoing protocol changes

All are well-known facts that do not require a proof, I hope.

[ If you are implying that requests should never be blocked or should
only be blocked by user agents, then I hope that other folks on the
mailing list can prove you wrong without appearing to be as biased as a
proxy developer would. ]

> What are you actually trying to do

We are blocking requests that violate some policy (the actual policies
vary from use case to use case, of course). What we are trying to do is
to convince browser folks that they should find a good way to show proxy
errors to their users.

> and why does that require a proxy?

Blocking does not require a proxy, but proxies have often been the best
tool for the job for many years and continue to be the best tool for the
job in many cases today.

> Do your users opt-in to the feature, 

Yes, of course. Any use of a proxy without client consent is outside
this discussion scope.

> How much control do you have over the user's machine?

The level of control varies from "it is our machine, not the user's" to
"we kindly suggest that users follow documented configuration steps for
their machine". Often, we deal with a complex mixture of control levels.

> Is your proxy installed on the user's machine (like
> an anti-virus), on end-user routers, in ISPs, or in a third party? 

All of the above and more, depending on the use case.

> Are you trying to block hosts or specific URLs? 

Depends on the policy, and those are not the only two options. For
example blocking based on an outdated SSL version used by the client or
a recently revoked certificate sent by the server is not uncommon.

> Do you need to inspect the
> body of the request or the response, or the headers, or just the URL?

For the purpose of this discussion, we are blocking based on all
available unencrypted (from proxy point of view) information such as an
HTTP CONNECT request header. The more information the proxy gets, the
more accurate its blocking decision can become.

Do some policies benefit from knowing specific URLs? Sure! Does blocking
become unnecessary when those URLs become hidden from the blocker? No.
It just becomes less precise, more arbitrary, etc.

There are other sources of information, of course, but they are outside
this discussion scope.

> How do we know you're trying to do something that's even feasible in the
> first place?

We know it is feasible because it has been done. Unfortunately, the
working solutions become uglier and uglier for everybody involved, from
users to admins to developers. Adrien is

* asking whether blocking requests by proxy is still a valid HTTP use
case from this WG point of view

* begging for a specific browser enhancement that would solve many
blocking problems and provide a pathway to more solutions down the road.

HTH,

Alex.

> On Tue, Feb 14, 2017 at 2:37 PM, Adrien de Croy wrote:
> 
>     __
> 
>     At the moment, it feels like the functions provided by proxy servers
>     are being squeezed out by changes in the protocol.
> 
>     that are becoming impossible with the direction TLS, HTTPS HSTS,
>     cert pinning etc are going.
> 
>     Whilst I can understand a desire and need for privacy, an ability to
>     be able to go to a website without betraying which site you're going
>     to (e.g. see https://tools.ietf.org/html/draft-schwartz-dns-sni-01
>     probably 1 remaining IMO critical bona fide purpose for a proxy
>     which is becoming very problematic for users.
> 
>     Blocking requests.
> 
>     Currently the user experience is either appalling (generic
>     connectivity failure report which wastes a lot of user time), or
>     requires deployment of a MitM, which is being squeezed out as well. 
>     We should be able to do better, but it doesn't appear to be being
>     addressed at all, and the gulf is widening.
> 
>     I believe we need to put some time into working out how we can allow
>     a proxy to block requests without an awful user experience that
>     costs users and tech support countless hours to deal with.
> 
>     It may be that the only way this can be achieved is by the concept
>     of a trusted proxy. 
> 
>     Otherwise if the group consensus is that requests should not be
>     blocked, we need to deal with the consequences of that.
> 
>     Adrien
> 
>     P.s. another key feature is caching, but that is becoming less
>     useful anyway.  Customers can often live without caching, they do
>     not tolerate being unable to block however.
> 
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 16 Feb 2017 19:57:39 +0000

--------

>mailing list can prove you wrong without appearing to be as biased as a

Don't waste too much time on this, some of us have been trying to
drive this point home for a couple of years.

Even the fact that laws and regulations specifically remove privacy
in many contexts, stock-traders, prisoners, children etc. does not
seem to persuade a certain segment of "techno-liberalists" that
such legitimate applications of MiTM exist, and that politicians
have both the legal right and might to decide that it be so.

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 16 Feb 2017 22:02:26 +0200 (EET)

>     due to ongoing protocol changes

And sometime proxies fail to fulfill CONNECT request even when they are 
trying do best.

In that case it usefull, if user (and specially helpdesk) is able to
see why proxy was failed. 

Proxy is able to tell more than what Browser's generic message is
doing.

Proxy's explanation reduces need for dig proxy's log for error.
It is not very easy to correlate helpdesk-request to proxy's
log entries.

/ Kari Hurtta

---

From: Tom Bergan <[email-masked]>
Date: Thu, 16 Feb 2017 12:17:22 -0800

Ok, I see that I unintentionally stepped on a landmine. Sorry.

> mailing list can prove you wrong without appearing to be as biased as a

Yes, I'm asking why the blocking needs to happen in a proxy. For example,
Chrome's SafeBrowsing feature doesn't use a proxy. Your client is a willing
participant that will customize their software and configuration as you ask
them. Why does the protocol for deciding what to block necessarily need to
happen over a proxy, rather than a side-channel? Maybe I'm being naive and
don't know all the obvious reasons why a proxy is needed and a side-channel
won't work. Has someone written an RFC describing why?

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 16 Feb 2017 20:35:47 +0000

Hi Tom

the predominant use-cases are as follows.

1. A corporation, with many employees with computers and internet 
access.  The employer doesn't want the employees spending all day on 
facebook, youtube, or other sites, unless it's the customer-support / 
social media department.

2. A school which doesn't want students surfing porn

In all these cases, you have the issue of many computers, and a single 
policy.  To block in the browser requires several things, a centralised 
management of the policy, disseminated to the browserm some way of 
securing this so the users don't disable it etc.

If on the other hand you intercept outbound connections, and force them 
through a proxy, or require use of a proxy for internet access, you can 
enforce the policy in a place that's removed from the users.

Other features like a shared cache, AV scanning etc are also commonly 
used.

Also, there are products that provide categorization of sites.  If you 
wanted to allow all sites except porn sites, and to block that in a 
browser, you would need to know what all the porn sites are.

There are products that track this, but they are expensive, have a large 
resource footprint etc. You can't be running this on every endpoint.

So central control is required, and this is a proxy.

HTH

Adrien

------ Original Message ------
From: "Tom Bergan" <[email-masked]>
To: "Alex Rousskov" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 17/02/2017 9:17:22 AM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>On Thu, Feb 16, 2017 at 11:47 AM, Alex Rousskov 
><[email-masked]> wrote:
>Yes, I'm asking why the blocking needs to happen in a proxy. For 
>example, Chrome's SafeBrowsing feature doesn't use a proxy. Your client 
>is a willing participant that will customize their software and 
>configuration as you ask them. Why does the protocol for deciding what 
>to block necessarily need to happen over a proxy, rather than a 
>side-channel? Maybe I'm being naive and don't know all the obvious 
>reasons why a proxy is needed and a side-channel won't work. Has 
>someone written an RFC describing why?

---

From: Roland Zink <[email-masked]>
Date: Thu, 16 Feb 2017 22:34:16 +0100

Why would be a proprietary side-channel be better? Still it is a third 
party which needs to be trusted and a standard proxy let me choose which 
service provider to use which isn't possible with a proprietary 
side-channel.

Regards,
Roland

Am 16.02.2017 um 21:17 schrieb Tom Bergan:
> example, Chrome's SafeBrowsing feature doesn't use a proxy. Your 
> client is a willing participant that will customize their software and

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 16 Feb 2017 13:52:31 -0800

On Thu, Feb 16, 2017 at 12:35 PM, Adrien de Croy <[email-masked]> wrote:

> 1. A corporation, with many employees with computers and internet access.
> The employer doesn't want the employees spending all day on facebook,
> youtube, or other sites, unless it's the customer-support / social media
> department.
>
> management of the policy, disseminated to the browserm some way of securing
> this so the users don't disable it etc.
>

Many browsers provide enterprise management functionality for exactly this
sort of use case.
​

> Other features like a shared cache, AV scanning etc are also commonly used.
>

Many enterprises go this route​ of using a proxy that mints certificates
and MITMs the connection to enforce policy.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 17 Feb 2017 17:22:04 +1300

On 17/02/2017 9:17 a.m., Tom Bergan wrote:
> On Thu, Feb 16, 2017 at 11:47 AM, Alex Rousskov wrote:
> 

Here is one reason:
 https://tools.ietf.org/html/rfc7725

The Browser behaviour of censoring the intermediary generated error text
prevents ISP and all other non-CDN entities from using that status code
in protest or to inform the user base about network censorship and other
unjust restrictions.

The problem is not limited to proxies, we are just the WG members
speaking up about the problem.  A firewall could blindly respond with
the byte string of a HTTP 4xx/5xx response and it would be censored on
HTTPS traffic just as much as any proxy.

Basically the Browser behaviour is colluding to perform censorship.

Amos

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 17 Feb 2017 04:47:43 +0000

------ Original Message ------

>>2. A school which doesn't want students surfing porn
obviously there are many other use cases as well.

>>policy.  To block in the browser requires several things, a 
>>centralised management of the policy, disseminated to the browserm 
>>some way of securing this so the users don't disable it etc.
>
>Many browsers provide enterprise management functionality for exactly 
>this sort of use case.

yes, but most deployment situations involve many different platforms and 
browsers.  The proxy solution works for all, does not suffer from 
version hell with incompatible browser updates etc.

>
>>If on the other hand you intercept outbound connections, and force 
>>them through a proxy, or require use of a proxy for internet access, 
>>you can enforce the policy in a place that's removed from the users.
>>
>>There are products that track this, but they are expensive, have a 
>>large resource footprint etc. You can't be running this on every 
>>endpoint.
>>
>Many enterprises go this route​ of using a proxy that mints 
>certificates and MITMs the connection to enforce policy.
>
They do, but I'm not even talking about this.  The question was about 
whether control should be in the UA or a proxy.

If I look back over the last couple of years, all the time we have 
recommended using MitM to customers is for dealing with this specific 
issue.  No other issue.  They aren't by and large asking us how do we 
cache https sites, they are asking us how can we show proper block pages 
for https sites.

Adrien

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 17 Feb 2017 06:52:45 +0200 (EET)

> cert that is trusted by the browser, and how did it get installed in the 

If proxy CA certificate can be installed to browser, then it is also possible
to install browser plugin to browser.

That browser plugin can implement some kind sidechannel. 

But different browsers and OSes, cpus need all diffrent plugin.
Proxy CA certificate format does not change here.

I see why that direction is selected.

And network border (or proxy) need some way to verify plugin
is active and sidechannel is in use on many use scenario.
Otherwise may be even disabled accidentally on browser update.

Hmm. One radical sidechannel is what tells symmectric encryption
key of TLS connection. I guess that this is not acceible for browser
plugin either. In that case proxy can verify that it have symmectric 
encryption key for TLS connection.

Internet Content Adaptation Protocol (ICAP, RFC 3507)
can perhaps act as standardised sidechannel protocol,
but that does not look like practical and is is
not implemneted by browsers. Basically that means
that content is moved several times. And also
network border (or proxy) can not verify that sidechannel
is on use.

/ Kari Hurtta

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 17 Feb 2017 05:05:28 +0000

I fail to see what a side-channel would even add in this case.

There's already communication between the client and the proxy.  It's 
the CONNECT request message and its response.

It was the abandonment of that response in non-200 cases that led to the 
need to deploy MitM.

It was deemed easier to just do this, rather than code a browser to not 
follow a 30x response to CONNECT or to not display working forms from 
403 response bodies to CONNECT requests.

The phishing argument gets wheeled out every time, but it doesn't hold 
water for a second.

A browser displaying a form and performing its action does so by the 
browser's choice.  To do so based on content in a 403 response to 
CONNECT is unjustifiable.  Displaying the original URI in the navigation 
bar is completely wrong as well.

But instead of just saying "hang on a minute, this is a 403 from a 
CONNECT" and displaying in some safe mode, clearing the URL, no that was 
too much work, we'll just throw the whole thing away, who cares about 
users, they can run around in circles doing the suggestions we tell them 
which we know are false.

Make sure the URL is valid
search for it
Check your connectivity

I've had people who have spent hours checking cables, routers, ringing 
site operators etc to finally get to us and when we tell them what is 
going on, they are very far from impressed.

But now I have 2 answers, MitM or Firefox.

Cheers

------ Original Message ------
From: "Kari Hurtta" <[email-masked]>
To: "HTTP working group mailing list" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "Kari Hurtta" 
<[email-masked]>; "Ryan Hamilton" <[email-masked]>; "HTTP 
working group mailing list" <[email-masked]>
Sent: 17/02/2017 5:52:45 PM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>>the

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 17 Feb 2017 07:25:55 +0200 (EET)

Adrien de Croy <[email-masked]>: (Fri Feb 17 07:05:28 2017)
> It was the abandonment of that response in non-200 cases that led to the 

For that use case I suggested change for browser UI (show
buttow for [View proxy message] and "navigate" to that message
and change location bar to reflect proxy URL).

That is even needed for regular CONNECT errors (when
proxy is not doing blocking).

/ Kari Hurtta

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 17 Feb 2017 07:46:04 +0100

> So central control is required, and this is a proxy.

And there are many "old" large companies having a pre-RFC1918 internal
network where there's no option but using a proxy for connectivity with
the net. In these situations there's an even more compelling desire to
install the access control on such proxies.

Willy

---

From: Tom Bergan <[email-masked]>
Date: Thu, 16 Feb 2017 22:50:35 -0800

Ok, thanks, it took me a while to parse what you're talking about. You
started by talking about TLS, HSTS, and PKP, and I thought you were talking
about the challenges of MITM-ing a connection. Moving blocking logic to a
side-channel removes the need to MITM.

Now it sounds like you just want to show custom error messages for rejected
CONNECT requests. Ryan can speak to Chrome's policy on this better than me.

[sorry for the dup, replied from the wrong address]

On Thu, Feb 16, 2017 at 9:05 PM, Adrien de Croy <[email-masked]> wrote:

> There's already communication between the client and the proxy.  It's the
> CONNECT request message and its response.
>
> follow a 30x response to CONNECT or to not display working forms from 403
> response bodies to CONNECT requests.
>
> browser's choice.  To do so based on content in a 403 response to CONNECT
> is unjustifiable.  Displaying the original URI in the navigation bar is
> completely wrong as well.
>
> site operators etc to finally get to us and when we tell them what is going
> on, they are very far from impressed.
>
> Cc: "Adrien de Croy" <[email-masked]>; "Kari Hurtta" <
> [email-masked]>; "Ryan Hamilton" <[email-masked]>; "HTTP

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 17 Feb 2017 09:15:43 +0000

exactly.

This was what used to happen prior to 2008 or so.

I think basically the browser just needs to stop trying to hide the 
existence of the proxy from the user.

It needs to be clear the response comes from the proxy not the origin 
server.  I could imagine many ways to achieve this.

Even if there were a (centrally administerable) setting in the browser 
to show these or not, with limits on what it could contain, I'd have 
something to go back to my users with.

Adrien

------ Original Message ------
From: "Tom Bergan" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Kari Hurtta" <[email-masked]>; "HTTP working group 
mailing list" <[email-masked]>; "Ryan Hamilton" <[email-masked]>
Sent: 17/02/2017 7:50:35 PM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>started by talking about TLS, HSTS, and PKP, and I thought you were 
>talking about the challenges of MITM-ing a connection. Moving blocking 
>logic to a side-channel removes the need to MITM.
>
>Now it sounds like you just want to show custom error messages for 
>rejected CONNECT requests. Ryan can speak to Chrome's policy on this 
>better than me.
>
>>It was the abandonment of that response in non-200 cases that led to 
>>the need to deploy MitM.
>>
>>It was deemed easier to just do this, rather than code a browser to 
>>not follow a 30x response to CONNECT or to not display working forms 
>>from 403 response bodies to CONNECT requests.
>>
>>CONNECT is unjustifiable.  Displaying the original URI in the 
>>navigation bar is completely wrong as well.
>>
>>CONNECT" and displaying in some safe mode, clearing the URL, no that 
>>was too much work, we'll just throw the whole thing away, who cares 
>>about users, they can run around in circles doing the suggestions we 
>>tell them which we know are false.
>>
>><[email-masked]>; "Ryan Hamilton" <[email-masked]>; 
>>"HTTP working group mailing list" <[email-masked]>

---

From: [email-masked]
Date: Fri, 17 Feb 2017 13:14:05 +0100 (CET)

Hi,

I'll answer once, because every single long timer in the list is sick to death of browser/privacy people asking "why" every couple of months, with accusing/unkind/moralistic vocabulary, and then going AWOL as soon as the presented facts do not go their way.

Aside from special professions where monitoring and eventually blocking is a legal requirement, blocking at the proxy level is just a matter of network scale for corporations.

The biggest your private network is, the less you are able to control individual endpoints, because there are too many of them, they break down and are replaced all the time, and they are increasingly diverse, from desktops to laptops to tablets to smartphones to printers to appliances to the connected lightbub some idiot brought to impress his boss with software-controlled colours. Plus if your org is big enough you get visitors with their own hardware, BYOD hardware to (supposedly) cut IT support costs, etc, etc. So forget about any mechanism that requires installing specific software addons endpoint-side.

The biggest your private network is, the more likely you have somewhere a business-critical function deployed on a badly secured system (mistakes happen, contractors can be incompetent or careless, gray IT is a fact of life). So you need to protect this network, it's not just an Internet extension.

The biggest your private network is, the more likely *bignumber* of users slacking and watching cat videos on youtube will translate in expensive network upgrades, including paying civil works to lay down new dark fiber to your premises. Civil works that business units will refuse to pay, since no one managed to write a convincing business plan that includes watching cat videos so far. (The ways CDNS and systematic encryption have killed any hope of caching at the gateway does not help either). As a bonus the very same business units will hang you dry because you let this traffic saturate links that were needed for business functions.

Educating people properly, fixing every system, getting IT support to audit, configure and fix every possible endpoint, has prohibitive costs, and would bring down the company velocity to a halt. Not every company can afford a workforce composed exclusively of bright-eyed responsible up to date computer scientists. Not every company can afford to design its own hardware and desktop software that it is sure of (besides, don't forget the lightbulbs). Most companies can not airgap every critical system (the other armchair answer to security problems). There are too many of them, they change all the time, they are all networked right and left.

So you try to limit the breakage, by forcing all your outbound traffic through a gateway, and blocking at that gateway anything likely to generate non-business-related high level of traffic, and anything linked to security attacks. Which requires subscribing to expensive web reputation services, listening hard to the notifications of your country's cyber command (aka your spooks), etc

If you're nice you can rate-limit non business-critical traffic instead of blocking it, but that still requires identifying this traffic at the gateway (layer-7 URL matching, because who wants to track what is akamai's, youtube's, etc ip plan today).

So there *is* blocking at the gateway level, there *will* *be* blocking at the gateway level, the question is not whether this blocking should exist or not, but if the user experience can be made less miserable than it is today because of unilateral browser changes.

Regards, 

-- 
Nicolas Mailhot

---

From: Francesco Chemolli <[email-masked]>
Date: Fri, 17 Feb 2017 13:00:54 +0000

> On 17 Feb 2017, at 12:14, [email-masked] wrote:
> 
> So there *is* blocking at the gateway level, there *will* *be* blocking at the gateway level, the question is not whether this blocking should exist or not, but if the user experience can be made less miserable than it is today [...]

..Following up with with 10 minutes of open stage enthusiastic standing ovation.

I support this description of the state of things, and the conclusion.
Let's remember that there's not only browsers: HTTP is taking over the role of transport for most remaining holdouts of other mechanisms for sever-to-server inter-organisation message passing. In this use-case the user interface is obviously much less of an issue (if at all), but the use-case for to a centralised HTTP L7 forward control point is very much there.

I've had several conversations with UA contributors over this, and from what I recall everyone agrees that the presentation side of things is the most critical aspect; I hope this thread will renew interest in finding a solution, ideally shared so to give end-users the least surprise.

	Francesco Chemolli (kinkie)
	Squid

---

From: Chris Bentzel <[email-masked]>
Date: Mon, 27 Feb 2017 01:08:40 +0000

Hi - interesting discussion. I work on Chrome but not on UX.

---

We could probably look at improving the UI around
ERR_TUNNEL_CONNECTION_FAILED listed further up the thread. Thanks for
bringing that up.

---

I think it would be interesting to have a consistent error code(s) for
responding to a CONNECT in a way that specifies the proxy is blocking it.
This could help non-browser-clients understand what's going on, and even if
browser clients don't want to display strings/UX provided by the proxy it
would be able to provide more details. Sorry if this was already discussed
(I saw 451 mentioned for example). This would ideally let users know that
their access is being blocked, but would not give richer information (like
who to contact) if response code with custom browser UX is used.

---

In terms of showing a response body, there are two concerns:

a) There have historically been a number of attacks around 407 and
responses to CONNECT [1][2][3]. While these are ultimately implementation
issues rather than fundamental problems, this worries me that it will
likely open up another attack.

b) To limit, the body would need to be treated as from a totally unique
origin or even just plain text. You could imagine plain text showing up
similar to a beforeunload handler or alert for example. However, these have
been increasingly been abused for scams. It wouldn't be a stretch of
imagination to think of a proxy which blocks access to a site with text of
"Access to facebook blocked because we detected you have a virus. Call
1-800-555-1212 to talk to our technical support."

Given the high prevalence of WPAD in clients it'd be a bit scary to even
show text in that case. Arguably if a proxy is explicitly specified and
uses https it may be reasonable to then show the text in the response body
even if it doesn't work in the common case.

[1]:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/pbp-final-with-update.pdf
[2]: http://falseconnect.com/
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=431504

On Fri, Feb 17, 2017 at 8:04 AM Francesco Chemolli <[email-masked]>
wrote:

> So there *is* blocking at the gateway level, there *will* *be* blocking at
> the gateway level, the question is not whether this blocking should exist
> or not, but if the user experience can be made less miserable than it is
> today [...]
>
>
> Let's remember that there's not only browsers: HTTP is taking over the
> role of transport for most remaining holdouts of other mechanisms for
> sever-to-server inter-organisation message passing. In this use-case the
> user interface is obviously much less of an issue (if at all), but the
> use-case for to a centralised HTTP L7 forward control point is very much
> there.
>
> I've had several conversations with UA contributors over this, and from
> what I recall everyone agrees that the presentation side of things is the
> most critical aspect; I hope this thread will renew interest in finding a
> solution, ideally shared so to give end-users the least surprise.
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Feb 2017 12:50:40 +1100

Hey Chris,

Thanks. A couple of thoughts below.

> On 27 Feb 2017, at 12:08 pm, Chris Bentzel <[email-masked]> wrote:
> 
> We could probably look at improving the UI around ERR_TUNNEL_CONNECTION_FAILED listed further up the thread. Thanks for bringing that up.
> 
> ---
> 
> I think it would be interesting to have a consistent error code(s) for responding to a CONNECT in a way that specifies the proxy is blocking it. This could help non-browser-clients understand what's going on, and even if browser clients don't want to display strings/UX provided by the proxy it would be able to provide more details. Sorry if this was already discussed (I saw 451 mentioned for example). This would ideally let users know that their access is being blocked, but would not give richer information (like who to contact) if response code with custom browser UX is used.
> 
> ---
> 
> a) There have historically been a number of attacks around 407 and responses to CONNECT [1][2][3]. While these are ultimately implementation issues rather than fundamental problems, this worries me that it will likely open up another attack.
> 
> b) To limit, the body would need to be treated as from a totally unique origin or even just plain text.

Agreed.

> You could imagine plain text showing up similar to a beforeunload handler or alert for example. However, these have been increasingly been abused for scams. It wouldn't be a stretch of imagination to think of a proxy which blocks access to a site with text of "Access to facebook blocked because we detected you have a virus. Call 1-800-555-1212 to talk to our technical support."
> 
> Given the high prevalence of WPAD in clients it'd be a bit scary to even show text in that case. Arguably if a proxy is explicitly specified and uses https it may be reasonable to then show the text in the response body even if it doesn't work in the common case. 

I think only in response to a CONNECT to a explicitly configured proxy over HTTPS (with some discussion about what that means WRT autoproxy.conf with and without WPAD) would be a good start. 

What I'm hearing from the discussion is that while treating it like a unique origin (with significant control over UX, e.g., HTML) would be Nice To Have, at this point *any* ability to indicate the real nature of the problem would help avoid deploying more MitM, which I think is in everyone's interest.

The sweet spot sounds like it needs to balance the network administrator's desire to convey the reason (e.g., explanatory text) and their identity (e.g,. a name, perhaps an icon) with the browser vendors' need to minimise the new surface area exposed, as well as resources to implement. 

I wrote that draft with that in mind -- happy to change the details. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 27 Feb 2017 10:40:01 -0700

On 02/26/2017 06:50 PM, Mark Nottingham wrote:

> What I'm hearing from the discussion is that [...] *any* ability to
> indicate the real nature of the problem would help avoid deploying
> more MitM

> The sweet spot sounds like it needs to balance the network 
> administrator's desire to convey the reason and their identity with
> the browser vendors' need to minimise the new surface area exposed,
> as well as resources to implement.

> I wrote that draft with that in mind -- happy to change the details. 

I do not know how to phrase this so that it does not sound unnecessary
harsh, but it feels like you are hearing what you want to hear (i.e.,
what your draft enables): On this thread, I have heard virtually no
reasonable justification for limiting the proxy error vocabulary.

Yes, several folks shared stories about those old browser bugs and were
justifiably worried about the dangers of incorrectly presenting
from-proxy content. And yes, one person said that he is going to
recommend FireFox because that browser reveals a tiny bit more about the
error, but there is a huge gap between all that and a claim that a
limited vocabulary would both alleviate those fears and address enough
use cases IMHO.

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.

Thank you,

Alex.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Feb 2017 10:53:47 +1100

Hi Alex,

> On 28 Feb 2017, at 4:40 am, Alex Rousskov <[email-masked]> wrote:
> 

Sorry you feel that way.

> limited vocabulary would both alleviate those fears and address enough

Absolutely; 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. My observation so far is that browser vendors seem *very* reluctant to dive in and offer that. 

> Solution), then we will be in an even worse position than we are today.

I wasn't claiming consensus, Alex -- just trying to move the discussion forward. If you have a proposal that you think can get traction, please make it!

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 27 Feb 2017 18:17:48 -0700

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.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Feb 2017 07:37:49 +0100

Hi Alex,

> 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,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Feb 2017 08:05:27 +0000

--------
In message <[email-masked]>, Willy Tarreau writes:

>of MiTM precisely is the natural outcome of this lack of consensus.

... and of legislation.

This is what is happening in the country where Spinoza, Decartes,
Huygens, Hobbes and Locke were at liberty to think and publish:

	https://legalict.com/general/the-netherlands-a-surveillance-state/

Consensus in this WG or better yet IETF would be nice, but it would
still not matter one iota, if the consensus isn't workable for
governments.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 28 Feb 2017 04:55:35 -0800

On Mon, Feb 27, 2017 at 10:37 PM, Willy Tarreau <[email-masked]> wrote:

> solution to a problem not everyone agrees with.
>

I agree with that - I also think there is large dose of confusion between
"interop the wg can define" and "expectations of what other products
implement". As co-chair I think its perfectly fine for this group to
consider technical gaps for any problems related to HTTP (there are
chartering considerations for documents - but let's just handwave that for
a minute) including this one - Mark's old draft is a good example. That's
the easy part.

The hard part is whether it addresses the fundamental problem or not - and
sometimes you can't assess that right away (although that's a reason we try
and gauge implementor interest before officially taking on new work). In
this case, if the problem is one of clarity and an unconstrained vocabulary
then maybe we're onto something. If the problem is more that a User Agent
thinks it should be emphasizing two party instead of three party
communication (as I suggest upthread) then this working group is unlikely
to be the forum where that fundamental stalemate is broken until something
about the market conditions shift. I think you could make arguments for the
market having shifted simultaneously in contradicting directions already
and that might have ramifications for HTTP interop.

-Patrick

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Feb 2017 14:32:03 +0100

Hi Patrick!

> and that might have ramifications for HTTP interop.

That's a very interesting way to describe the problem in my opinion.
In fact if we summarize :

  1. user agents focus on more control of the end-to-end confidentiality
     and integrity and there's no way we'll go backwards and possibly very
     few people will argue against the benefits ;

  2. some places need to enforce some control on how their internet access
     is used. Their motivations are outside the scope of this WG, some of
     them will do it for what we'll call undesired state surveillance,
     others will to it to limit malware propagation or protect against
     information leaks, others will do it for legal/moral reasons (protect
     children against unsuitable contents) and others will do it as a way to
     limit the waste of their precious shared resource that their bandwidth
     is.
 
  3. likely everyone agrees that user-friendliness is very important, to
     report connection failures, reasons for access being blocked, or even
     the safety and privacy risks of pursuing browsing on a given site (due
     to the proxy's inspection or to the connection being unsafe between the
     proxy and the origin).

  4. by combining to these three contracticting goals, we've created a new
     standard solution which is MITM decryption. It's become so common that
     when I speak to people selling products to enterprises, it seems to
     even be the de-facto standard way to deploy a proxy for them! This
     totally ruins the first goal above!
 
  5. and now that point #1 is out of the picture and point #2 is under
     control again, and point #3 is best covered by the MiTM solution.

So... let's see the picture the other way around now. OK, some places are
only willing to offer a free internet access in exchange for a little bit
of control. If we provide the ability for the user to control what and
when he's controlled and to know whether he's safe or not, we can have
both #1 and #3 back without the need for the ugly #4 which only satisfies
the less defendable #2 but which has become standard.

That's why I think that a technical solution like trusted proxies can be
good. Let the user know whether he can have a TLS tunnel to the origin or
has to retry in clear using "GET https://". Let's have the same warnings
as when I'm asked whether or not I want to share my location with the site.
If we end up with the ability for admins to think "all this should pass
without any analysis otherwise my users will come talk to me with a basebal
bat" then we can re-establish some reasonable balance where everyone finds
their own benefit.

I think it's sad that in 2017 browsing from an enterprise on a site using
RSA2048 and AES128 is less safe than when I used to connect to my bank in
1998 using RSA512 and DES40! At least by then I didn't have to trust my
admin.

Just my 2 cents,
Willy

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 28 Feb 2017 22:09:35 +0200 (EET)

> especially for CONNECT errors, especially for folks concerned about user

Yes, this looks like common sense. And still no one browser does that.

Or I am mistaken?

When proxy is selected or not by proxy.pac, it is not obvious that
is proxy used for particular request.

> and other fancy stuff that, AFAIK, others have already proposed.

You means passing https -URLs to proxy for retrieval.

Proxy needs also then way to report what certificate it
got from server. Proxy of course check that certificate,
but browsers differiante different certificate classes
on UI  (that is "Extended Validation" certs produce
different location bar).

In that case location bar probbaly need to be two lines:

First line tells proxy and certificate status of proxy URL
Second line tells reported certifcate of server and visited URL

/ Kari Hurtta

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 28 Feb 2017 13:52:31 -0700

> Yes, this looks like common sense. And still no one browser does that.

According to Adrien, FireFox complies with the first SHOULD (at least):
https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0288.html

> is proxy used for particular request.

It is always obvious for the browser. I assume you mean that it is not
obvious for the user, and I agree with that (with cases not limited to
just PAC-driven proxy selection!).

Exposing hidden or obscured proxy usage should be (but is not) a great
motivation for anti-proxy folks arguing that the user must have full
control at all costs. This disconnect feeds conspiracy theories that
those folks prioritize things other than user's informed consent and
control.

> You means passing https -URLs to proxy for retrieval.

Yes. A.k.a. "GET https://" inside a TLS connection to the proxy.

> got from server.

To be more precise, the _browser_ needs that, but, yes, this is probably
required, and that is exactly why I mentioned secure response signing
(or something like that) as a prerequisite. The proxy would need to
somehow forward origin's response signature or public certificate (at
least). This is where an HTTP extension is required. Everything else is
already supported (at the protocol level) AFAICT.

> Second line tells reported certifcate of server and visited URL

  Third line tells whether the proxy certificate is Transparently Logged
  Fourth line tells the Root CA that signed the proxy certificate
  Fifth line tells the majority stock holder of that Root CA
  Sixth line tells whether that stock holder signed the XYZ pledge
  ...

I continue to resist the temptation to tell browser folks how to do UI.
I am sure that they can build great UIs, and that they do not need this
WG "help" with that. It is a solvable design problem. With enough
motivation, they can solve it.

Alex.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Feb 2017 21:26:25 +0000

--------

>Yes, this looks like common sense. And still no one browser does that.

I think common sense can be summarized as follows:

1. If any proxy is involved, both the client and server should know
   that, so that they can judge for themselves to what extent they
   want to trust the proxy.

2. A legitimate proxy has no reason to try hide its own existence
   or to deliberately reduce the security, privacy or integrity of
   the communication, beyond what is required for doing its job.

3. It should be as hard as possible to insert and hide an ilegitimate
   proxy (=MITM attack) which undetected can impact security, privacy
   or integrity of the communication.

On the client side the only politically reasonable and neutral
solution is to announce the precense of a proxy by inserting a
prominent identification of it above the address bar, so that the
user sees:

	BIGCORP Inc. Proxy (Contact IT/Bill x1234) inspects this connection

	https://mybank.com/

Or as it may be:

	ELBONIA Government National & Child safety Proxy inspects this connection

	http://bikeshed.org

The "proxybar" should be suitably decorated to indicate if the
connection to the proxy has any kind of privacy and if there is any
reason to think that the proxy really is who it claims to be.

The current "political" stance by the user agents means that literally
millions of people are behind proxies, legitimate and ilegitimate,
without knowing it or being able to see it, without significant
X.509-skillz.

As for the political fight for a fundamental human right to privacy:

More people would probably pay attention, if they could clearly see
who tried to mess with their communication.

---

From: Roland Zink <[email-masked]>
Date: Wed, 1 Mar 2017 00:05:54 +0100

Not sure if this is what is needed as it can get complicated when more 
than one proxy is involved. At least currently browsers do not inform me 
about all the 3rd parties involved, e.g. all the companies which get the 
URL I browse.

- Content from 3rd parties is just displayed even when users do not want 
see it and may be dangerous
- Content from CDNs is just displayed without notifying the user about 
which CDN is delivering the content
- Reverse proxies are not announced to the user
- Requests are send to foreign countries without notifying the user
- When a MITM attack is detected and a local CA certificate is installed 
locally then even this isn't made known to the user by some browsers

It would be nice to see which 3rd parties are involved directly and 
indirectly. In some cases, for example when some intelligence service 
takes the browsed URL from some tracking company but this seems to be 
impossible.

A proxy is an additional 3rd party which I may trust and want to use 
(for some service it provides) or I have to use, which is the bad case. 
In the first case I don't necessarily need the information about all the 
proxies involved but of cause I want the to know about the latter case.

Is it really bad when a browser allows me to trust a proxy?

Regards,
Roland

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 1 Mar 2017 08:10:30 +0200 (EET)

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0377.html
From: Alex Rousskov <[email-masked]>

> I continue to resist the temptation to tell browser folks how to do UI.

Good.

> WG "help" with that. 

Sometime WG does that.

https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-10#section-4.1

| 4.1.  Security Indicators
| 
|    User Agents MUST NOT provide any special security indicia when an
|   "http" resource is acquired using TLS.  In particular, indicators
| 
|    that might suggest the same level of security as "https" MUST NOT be
|   used (e.g., a "lock device").

I was not suggesting any requirement on here:

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0376.html

| In that case location bar probbaly need to be two lines:
| 
| First line tells proxy and certificate status of proxy URL
| Second line tells reported certifcate of server and visited URL

"probbaly" should be "probably".

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0378.html
From: Poul-Henning Kamp <[email-masked]> 

> 	ELBONIA Government National & Child safety Proxy inspects this connection

Yes, that is similar than what I was meaning.

But I'm not suggesting any requirements.

That was just similar than my suggestion for UI on
on CONNECT errors.

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0297.html

--------------

	[View proxy message]

--------------

- Possible lock symbol reflects TLS
  of proxy connection
=================================================

This is not suggesting that WG tells how to do UI.

This is more as "This is one possibility which perhaps 
resolves your requirements."

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0377.html
From: Alex Rousskov <[email-masked]>

> just PAC-driven proxy selection!).

Yes, I mean that it is not obvious for the user.

/ Kari Hurtta