- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 8 Aug 2016 23:25:24 +1200
- To: ietf-http-wg@w3.org
On 8/08/2016 7:00 a.m., Walter H. wrote: > On 07.08.2016 19:45, Ilari Liusvaara wrote: >> On Sun, Aug 07, 2016 at 07:25:22PM +0200, Walter H. wrote: >>> On 06.08.2016 02:25, Mark Nottingham wrote: >>>> Would this help? >>>> >>>> https://mnot.github.io/I-D/proxy-explanation/ >>>> >>>> Keep in mind that only helps for configured proxies. >>>> >>> configured proxies are not the bug; why not just simpy use plain HTML? >> >> Except that if you try rejecting the CONNECT, > then my browser shows the correct message > > e.g. > > While trying to retrieve the URL: https://www.xxx.ru/* > > The following error was encountered: > > * *Top-Level-Domain Blocked. * > > Access control configuration prevents your request from being allowed at > this time. > Please contact your service provider if you feel this is incorrect. > > in this case it has no relevance if the host www.xxx.ru really exists or > not, because the whole TLD .ru is blocked and this check is done much > before; > > I'm using squid as my MITM-proxy > >> the browsers just throw >> up generic error about connection failed and will just plain discard >> any payload the proxy sends. >> >> (And pretty much the same for non-browsers, if those even support >> CONNECT). > yes, because these apps warn you that there is a certificate in use they > don't know; install the signing certificate of the proxy and it works > as I've shown above ... > This is squid working aroudn al the problems we are discussing here. When you install the proxy CA cert Squid accepts the CONNNECT, MITM's the TLS session, accepts the first HTTPS message from the browser - and produces that error page that you see as if it were the response from the HTTPS www.xxx.ru origin for that page. It does all this nasty and complicated activity because the browser will not show the error in response to the original CONNECT. Amos
Received on Monday, 8 August 2016 11:26:11 UTC