Subject: Browser display of 403 responses bodies on CONNECT

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 17 Jun 2015 20:47:23 +0000

Hi all

we're seeing nowadays many browsers don't display the content of a 403 
denial response to a CONNECT request, instead displaying some generic 
home-baked browser warning about being unable to make a connection.

This is causing quite a bit of trouble.

Is there any language in the RFC that encourages or discourages this 
behaviour, or should there be?

Personally I view this behaviour as undesirable at best and certainly 
confusing for customers as they see a page for a blocked http request 
explaining why the proxy blocked it, but not so for https requests.

I understand some proxies fake up the TLS connection in order to pipe 
back a block page, but this is a very undesirable way to resolve this 
issue, and has many side-effects (cert warnings etc).

Section 3.3 of RFC7230 discusses bodies on 2xx responses to CONNECT, but 
not other response codes.

Section 4.3.6 of RFC7231 (CONNECT) doesn't cover this either.

Section 3.1 of 7235 mentions in the context of a 401 that the 
representation should be presented to the user, but we can't use that 
instead as it has side-effects of popping login dialogs.  Interestingly 
the prose for 407 doesn't contain this recommendation either.  Maybe we 
need a general section on how clients should deal with bodies on error 
responses.

Regards

Adrien

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jun 2015 16:57:42 -0700

> home-baked browser warning about being unable to make a connection.

I believe that this is because our users have requested a secure site
and anything other than authenticated content provided by that site
would present an unparalleled opportunity for MitM phishing attacks.

> behaviour, or should there be?

I don't believe that there is any requirements on how content is
rendered, no.  Nor should there be.

RFC 2616 had some language around presentation to users, and asking
for permission and so forth, but I believe that was one thing that was
cleaned up in the latest round.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 18 Jun 2015 00:49:35 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 18/06/2015 11:57:42 a.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>would present an unparalleled opportunity for MitM phishing attacks.
how would this be any more or less of an opportunity than a block page 
for http?

Fundamentally the client is using a proxy, and made an HTTP request to 
the proxy for a tunnel which it denied.  This is before accessing the 
site, this is the tunnel setup stage which is HTTP not HTTPS.
To not display the block page from the proxy is just problematic and 
leads to support calls.

At the moment we have to respond to customers who query this with saying 
it's a browser bug not displaying the block page.

>rendered, no.  Nor should there be.
I wasn't talking about how to render, I was talking about whether to 
display a message body or not.

If we're not deprecating message bodies on CONNECT unsuccessful 
responses, they should surely be displayed.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 18 Jun 2015 00:54:05 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 18/06/2015 11:57:42 a.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>would present an unparalleled opportunity for MitM phishing attacks.

just to clarify then.

It's preferable to MITM the TLS to send a block page back, than to send 
a block page back on a 403 response to the CONNECT?

Absurd.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jun 2015 19:27:58 -0700

On 17 June 2015 at 17:54, Adrien de Croy <[email-masked]> wrote:
> It's preferable to MITM the TLS to send a block page back, than to send a
> block page back on a 403 response to the CONNECT?

That's a bit of a leap, isn't it?

What I'm suggesting is that if you type https://blah and you don't get
something that is authenticated as being from blah, then you expose
yourself to problems.

Now, if you wanted to fix this situation, I might suggest that a
custom error page might be appropriate.  That page might say that the
proxy denied the request to connect.  Showing content that the proxy
provided still seems inadvisable.

Rather than slinging mud, perhaps you could engage with browser
vendors in the usual venues:
https://bugzilla.mozilla.org/
https://code.google.com/p/chromium/issues/list
https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer
https://bugs.opera.com/wizard/
https://bugreport.apple.com/
etc...

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 18 Jun 2015 02:49:57 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 18/06/2015 2:27:58 p.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>That's a bit of a leap, isn't it?

I've seen code which does this, I can't remember sorry if it was in 
squid or hapoxy or nginx, maybe Willy or Amos can comment there.

>something that is authenticated as being from blah, then you expose
I don't think you can claim that an http error response to the proxy 
tunnel setup could be considered as an authenticated response from a 
site.  If a browser gives that impression, the browser should be fixed.

The problem with displaying anything other than what the proxy responds 
with is that important diagnostic information from the proxy (e.g. the 
rule which blocked the request and why) is lost.

I could imagine a scenario where the client shows the response from the 
proxy in some way that makes it obvious it's not the site that was 
requested.  And could for example disable script, and hyperlinks if 
there really were safety concerns.

But protecting people from this hypothetical risk has real world 
consequences which is affecting people.  I'm not convinced that using a 
403 to provide someone with a fake site for phishing is a credible 
threat, it's certainly not the easiest way for a system admin to gain 
access to that data.

We are talking here about the proxy operator being the threat, since 
this is only for CONNECT which is only sent to a proxy that has been 
configured by the client.

>provided still seems inadvisable.
Omitting it causes real problems.

>https://bugreport.apple.com/

Until today I considered this a temporary bug, I didn't realize it was 
intentional.

On this note, there are many other responses to a CONNECT request which 
could be problematic, such as a 302, or 404.  CONNECT doesn't seem to be 
particularly well fleshed out in the documents.

Thanks

Adrien

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 18 Jun 2015 15:56:24 +1200

> something that is authenticated as being from blah, then you expose

The browser has gone nowhere near "blah". It is gone to its configured
proxy and been told "No. Pinky is awaiting a blue moon".

Browser displays:
- The website you connected to is not responding.
- TLS connection failure

or one of a number of completely unrelated false statements complaining
about service from "blah".

The *only* thing that works is MITM decryption and injecting a 403/511
response explaining the reality.

> provided still seems inadvisable.

Such as 511? Browsers still refuse to implement support for that on
CONNECT. Anything that is non-200 status gets a browser custom error page.

> https://bugreport.apple.com/

Been there. Done that.

I've personally made reports to both IE and Chrome years ago, but had
them shunted away behind security lockdowns. So I've no idea how many
other complaints and discussions have been directed at those other
browsers. Their public bug systems are definitely not reflecting the
reality though. Even Firefox diverts into secrecy for a dependency bug
(<https://bugzilla.mozilla.org/show_bug.cgi?id=599295>). As mentioned in
some of the mozilla bugs reports (like
<https://bugzilla.mozilla.org/show_bug.cgi?id=491818#c44>), the major
browsers are all doing the same behaviour and reinforcing each other
like a cartel.

As I understand it the begining was this:
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c1>.

That the browsers circa 2009 followed a 3xx redirect silently without
changing the address bar URL to reflect where the attacker was sending
the user, and running all operations within the security context of the
original URL.  Sound a lot like Alt-Svc to anyone else?

One would assume the correct fix is to update the address bar and
disable security context appropriately. But
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c2>.

The problem with that is it results in
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c75> and
<https://bugzilla.mozilla.org/show_bug.cgi?id=479880#c80>. Mozilla
bugzilla is now riddled with 2009, 2010, 2012, 2013, 2014, and 2015 bug
reports either directly or indirectly resulting from proxy CONNECT
respones being hidden from the users. Unexpected auth, certificate
handling, or TCP issues all show up as the generic custom browser
message. The response each time is demonstrated in
<https://bugzilla.mozilla.org/show_bug.cgi?id=491818#c56>, but I'm
currently counting 12 open CONNECT + 403/407/302/301 bugs from the past
year that have not yet been silenced with WONTFIX.

Decrypting the TLS and injecting responses "works" at unseen cost of
re-opening the original CVE issue.
 ... and sends one more sysadmin down that slippery slope of TLS MITM
towards simply decrypting everything and proxying the https://. Cache
HIT ratios get quite high in HTTPS due to lack of secure Cache-Control
headers :-(

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 18 Jun 2015 16:11:43 +1200

> squid or hapoxy or nginx, maybe Willy or Amos can comment there.

Squid does at least. The guys doing Squid TLS decrypt tell me Chrome
barfs quite nasty binary errors at the user *unless* the proxy forges
certs and injects into the TLS stream.

> there really were safety concerns.

It goes a bit deeper than that.

Some of the Mozilla bugs are for things like IMAP server connectivity
being broken sporadically. On deeper investigation it turns out the PAC
file is giving a set of HTTP proxy, one of which rejects (403) on
CONNECT to non-443 ports.

The user sees email update checks responding with a simple and clear "no
new mail" (so innocent and trustworthy) for a few hours despite new
email arriving constantly. Then something changes the PAC interpretation
and the other proxy gets through - wham!! a huge pile of emails to
download, instant network congestion and potential IMAP server overload
on SME systems.

> particularly well fleshed out in the documents.

Have a read through <https://bugzilla.mozilla.org/show_bug.cgi?id=479880>.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Jun 2015 06:22:06 +0200

> would present an unparalleled opportunity for MitM phishing attacks.

Well, don't forget that there's nothing like a "secure site" at this
phase. The connection to the proxy is made in cleartext and the browser
sends proxy credentials (user:password) in clear over this connection.
What this means is that the connection *is* considered locally secure,
at least safe enough so that we don't care about the risks of sniffing.
So we should care even less about the risks of MITM!

Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 18 Jun 2015 04:51:28 +0000

------ Original Message ------
From: "Amos Jeffries" <[email-masked]>

>Have a read through 
><https://bugzilla.mozilla.org/show_bug.cgi?id=479880>.
>
>Amos

that's really sad.

I could fully support blocking 3xx responses to CONNECT as I can't 
imagine any bonafide use of this, but blocking bodies on 403 etc causes 
a lot of problems.

Executing script on non-200 response bodies seems reckless at best as 
well, that should have just been turned off.

What about the active attacker on the network that responds to CONNECT 
with 200? Are we relying on browsers identifying MitM to protect against 
that?

I would even settle for some XML that had to be sent back / parsed by 
the browser and turned into a meaningful error.  There's just no usable 
solution except for MitM, so we have another example of the fight for 
privacy causing more fallout and propagation of MitM, and still any 
attempts to ameliorate the "trusted" MitM are resisted.  Doesn't really 
help the poor user.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 18 Jun 2015 11:00:01 +0200

> ><https://bugzilla.mozilla.org/show_bug.cgi?id=479880>.

Indeed. IMHO the problem above is caused by the confusion between the proxy
and the origin. A proxied response doesn't come from the origin until the
200 appears. The only origin without 200 is the proxy itself, and if it was
handled this way there would be no problem with cookies.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Jun 2015 17:10:11 +1000

This was touched upon in WPD:

> When user agents encounter 5xx responses to a CONNECT request from a WPD proxy, they MUST present the response to the end user, but MUST NOT present or process it as a response to the eventual request to be made through the tunnel (i.e., it has an unidentified payload, as per {{RFC7231}} Section 3.1.4.1).
> 
> NOTE: Many user agents refuse to show an error response to a CONNECT to the user, in order to deal with the issues brought to light by {{bad-proxy}}. While effective in dealing with those attacks, doing so effectively disallows communication between the proxy and the end user; this requirement is designed to re-open that channel.

where {{bad-proxy}} is <http://research.microsoft.com/apps/pubs/default.aspx?id=79323>.

Fundamentally, I think this is a user experience problem, in that anything that can render HTML can fool some number of users thinking they're talking to the "real" Web site. For better or worse (I think better), we don't do UX here.

Cheers,

> On 18 Jun 2015, at 7:00 pm, Willy Tarreau <[email-masked]> wrote:
> 

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

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 23 Jun 2015 07:32:42 +0000

one could argue that by deprecating bodies on non-200 CONNECT responses 
because of inability of browser vendors to deal with the problem 
properly, we effectively DID do UX here.

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Willy Tarreau" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "Amos Jeffries" 
<[email-masked]>; "[email-masked]" <[email-masked]>
Sent: 23/06/2015 7:10:11 p.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

>>  When user agents encounter 5xx responses to a CONNECT request from a 
>>WPD proxy, they MUST present the response to the end user, but MUST 
>>NOT present or process it as a response to the eventual request to be 
>>made through the tunnel (i.e., it has an unidentified payload, as per 
>>{{RFC7231}} Section 3.1.4.1).
>>
>>  NOTE: Many user agents refuse to show an error response to a CONNECT 
>>to the user, in order to deal with the issues brought to light by 
>>{{bad-proxy}}. While effective in dealing with those attacks, doing so 
>>effectively disallows communication between the proxy and the end 
>>user; this requirement is designed to re-open that channel.
>
>where {{bad-proxy}} is 
><http://research.microsoft.com/apps/pubs/default.aspx?id=79323>.
>
>Fundamentally, I think this is a user experience problem, in that 
>anything that can render HTML can fool some number of users thinking 
>they're talking to the "real" Web site. For better or worse (I think 
>better), we don't do UX here.
>
>Cheers,
>
>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Jun 2015 09:56:53 +0200

On Tue, Jun 23, 2015 at 05:10:11PM +1000, Mark Nottingham wrote:
> Fundamentally, I think this is a user experience problem, in that anything
> that can render HTML can fool some number of users thinking they're talking
> to the "real" Web site.

Not if they replace the URL in the bar with the proxy's URL. Also don't
forget that we're talking about trusted proxies, the ones the user is
sending his login and password in clear text to.

> For better or worse (I think better), we don't do UX here.

We don't do UX but we do care about sane error reporting. In my opinion,
even rendering the response as pure text (a la "view source") would be
fine. I've been a number of times in a situation where a proxy was
refusing to forward a connection to a site which was not whitelisted,
and which returned a nice page where you could click to request that the
site be whitelisted.

It seems it's not possible anymore with browsers not presenting the response.
The alternative as usual will be that proxies will have no other choice than
returning a 200 to pretend the connection to the destination was established,
and spoofing the certificate. And that's far from being perfect because then
it supposes the transported protocol is HTTPS while it isn't necessarily.

The use of proxies is clearly and cleanly defined in my opinion, and the
proxy has a number of options to cleanly refuse an action and to explain
its motives. If we squeeze these options, only the dirty ones remain, and
cause even more MITM deployments.

It's a bit "fun" to see that most of those nasty MITM deployments are caused
to preserve a user experience that is not respected by those who mostly focus
on it and who complain a lot about MITM!

Best regards,
Willy

---

From: Francesco Chemolli <[email-masked]>
Date: Tue, 23 Jun 2015 11:21:27 +0200

> sending his login and password in clear text to.

Password in cleartext, maybe, or maybe not. But the point sticks: an
explicitly-configured proxy is a trusted component in a service chain,
either by deliberate choice of the user or of their IT department.

> and which returned a nice page where you could click to request that the

Yes, please! Want to be fancier? use an iframe-like structure, where
the outer frame is rendered by the browser and the inner frame is the
5XX body.
Specification-wise, a SHOULD-level statement could encourage this
while still keeping us out of the UX topic.

>From my experience any medium-to-large enterprise would be very
tempted to go this route in order to reduce the number of support
calls and complexity of managing them.

> on it and who complain a lot about MITM!

Yes.
A bit of pragmatism would do wonders :)

-- 
    Francesco Chemolli

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 24 Jun 2015 10:23:54 +0200

> provided still seems inadvisable.

Excuse me but that's pretty braindamaged. Just because browser people have
repeated this for years does not mean it is true.

The proxy is not an evil hijacker, the browser *chose* to use the proxy so
it can assume its choices.

If browser authors are "afraid" of "evil" block pages (why are they
connecting to this equipment in the first place?) they can add whatever
chrome they wish around the block pages to show it's a block page (exactly
like they do for all other error messages)

Also the pages browsers replace 403 with are intentionnaly misleading and
disparaging and designed to increase support calls. That's the browser
choice but the http spec is not here to promote and condone such
antisocial behaviour

Regards,

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 24 Jun 2015 10:03:02 +0000

I think the problem scenario is the active network attacker between the 
client and the proxy.

Since the client to proxy connection is not secured, the attacker can 
send anything back they like (including a 200 OK, but connect to 
something else or not).

Even though in many scenarios (e.g corporate LANs) this is an extremely 
unlikely scenario, I guess there are some cases where this might be 
possible.

It does seem a shame that all the millions of real corporate proxy users 
need to suffer because of paranoia over a vanishingly small possibility 
of an active network attacker.

But I believe the approach taken was expedient and heavy handed.  It 
should be possible for a browser vendor to distinguish this, and portray 
it in a way that allows the user to also distinguish it.  If we really 
are to take the stance that we don't do UX, we should not water down the 
spec to cater for lazy UX implementations either.

Adrien

------ Original Message ------
From: "Nicolas Mailhot" <[email-masked]>
To: "Martin Thomson" <[email-masked]>
Cc: "Adrien de Croy" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 24/06/2015 8:23:54 p.m.
Subject: Re: Browser display of 403 responses bodies on CONNECT

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 24 Jun 2015 12:30:16 +0200

Le Mer 24 juin 2015 12:03, Adrien de Croy a écrit :
> Since the client to proxy connection is not secured,

This is another thing that will need fixing sooner rather than later

> of an active network attacker.

Let's be honest here, the current setup is intended to punish users that
use proxies, and nothing else. Otherwise 511 would have gotten some
traction.

Regards,

-- 
Nicolas Mailhot

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Jun 2015 12:54:08 +0200

On 24.06.2015 12:03, Adrien de Croy wrote:
>
> I think the problem scenario is the active network attacker between 
> the client and the proxy.
>
This needs to be changed, although some browsers already support secure 
connections to the proxy. Chrome can do secure connections to the proxy 
when given HTTPS instruction (instead of PROXY) in a PAC file. Anybody 
know if it will display error messages from the proxy then?

Roland

function FindProxyForURL(url, host) {

return "HTTPS proxy.com:7128";

}

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Jun 2015 13:08:34 +0200

Btw. this is great if you want to run HTTP2 between browser and proxy as 
Chrome supports protocol negotiation with ALPN. Any proxies supporting 
this? It worked for me with nghttp2.

Roland

On 24.06.2015 12:54, Roland Zink wrote:
> This needs to be changed, although some browsers already support 
> secure connections to the proxy. Chrome can do secure connections to 
> the proxy when given HTTPS instruction (instead of PROXY) in a PAC 
> file. Anybody know if it will display error messages from the proxy then?
>
> Roland
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 25 Jun 2015 00:12:43 +1200

> this? It worked for me with nghttp2.

SSL/TLS has been accepted by Squid since, oh ... 1997.

ALPN is in the current stables, but only "negotiating" for HTTP/1.1.
When we get HTTP/2 into mainstream it will be supported there too.

>> file. Anybody know if it will display error messages from the proxy then?

If I'm understanding it right theres no difference on those connections.
I've not a clear picture there though.

Amos