- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Wed, 15 Feb 2017 13:33:05 -0700
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Cc: Adrien de Croy <adrien@qbik.com>
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.
Received on Wednesday, 15 February 2017 20:33:34 UTC