W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

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>
Message-ID: <BA2DAF1B-723D-47B0-94D1-7913BD1CA5F8@exa-networks.co.uk>
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC