- From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
- Date: Mon, 29 Feb 2016 19:32:00 +0000
- To: "HTTP WG" <ietf-http-wg@w3.org>
> FYI - would be interested in what people thought, as I know some folks > have this problem. Hi Mark, I am interested. To explain our predicament: My business provides content filtering for schools. In the UK, Schools have a legal obligation to protect children from ‘harmful’ content, so content filtering is not going to go away. Historically DNAT’ing port 80 to a filtering proxy farm and blocking port 443 was enough: the primary concern of schools is to stop children to accessing adult material, games and social media sites. Nowadays most of the educational content is under HTTPS and the main worry is radicalisation. In order to do so, a school can decide to perform SSL decapsulation. We offer this solution through the installation of a local firewall/proxy which is fine for secondary schools but quite expensive for primaries who prefer to use ‘cloud’ services ( primary teachers are not very IT literate and do not have an IT department ). Therefore many schools do block port 80/443 and only allow traffic to our our proxies servers or use AD to force the use of the proxy. While it does not allow some of the most advanced feature we provide (like for example, checking search queries for self-harm terms as the full URL is not available), we can still block pages on a per host basis. ( I am happy to debate elsewhere why we decided to not offer SSL decapsulation ‘in the cloud’ at this point, and therefore why we rely on a ‘CONNECT’ based solution - just bring your lawyer to it :p ) So currently when a site is identified as ‘not for educational use’ (what is or is not deemed educational is under the control of the school), our only way to prevent the page to load is to completely kill the TCP connection after the inspection of the Host field in the CONNECT message. However, on a regular basis a site will be blocked due to an over-zealous policy or simply a wrong categorisation for a site. Currently, our customers have no way to know if the ‘network error’ the browser is reporting is due to a genuine issue or a policy enforcement. Browser implementation of this draft would end this user confusion. Our own proxy (you could call it a ‘software defined http gateway’) is already capable of using it. A modified version of our code (which is open source) implements the draft (returning new response). You can have a look :-) # git clone git@github.com:thomas-mangin/exaproxy.git # cd exaproxy # env exaproxy.http.connections=100 exaproxy.tls.enable=false exaproxy.security.connect=80 exaproxy.redirector.enable=true exaproxy.redirector.program=etc/exaproxy/redirector/icap-deny-proxy-explanation exaproxy.redirector.protocol='icap://' ./sbin/exaproxy This instance will refuse ANY connection to any site returning a 403 page with an application/proxy-explanation+json payload. You can test it running the following test script # ./QA/test/connect-http-google-proxy-explanation Sincerely, Thomas
Received on Monday, 29 February 2016 19:32:29 UTC