On 17/10/2012 6:30 p.m., Cameron Charles wrote:
Thank you for the prompt and very informing reply, does this mean then
that filtering https connections at the level i desire is not possible
at all (using squid)?, also for information purposes firefox and
safari do a similar job of handling, or not handling this situation,
infact they provide even less useful erro outputs.
At this level yes.
Things naturally change entirely when you can break into the encryption.
Squid-3.3 offers a rather horrendously evil workaround via ssl-bump -
but unfortunately its the only thing that actually works while browser
people refuse to handle the 3xx properly.
Amos
On 17 October 2012 16:18, Amos Jeffries <squ...@treenet.co.nz> wrote:
On 17/10/2012 4:08 p.m., Cameron Charles wrote:
Hi all,
I am currently trying to setup basic "url/domain level" filtering on
HTTPS traffic using an external acl, i can see clearly in the access
log that the information i require is there and the external acl finds
and filters it as desired, returning the correct response for
deny/allow and i can successfully browse https sites that are allowed,
however sites that deny_info should redirect to the error page fail
and only a browser based error is returned, the error is as follows...
Two datums you need to be aware of ... (re-ordered your listed facts so the
explanation makes sense)
For the failed denies the access.log shows the following (here trying
https version of facebook)
1350442727 17/Oct/2012-13:58:47-EST 770 10.0.1.103 TCP_DENIED
307 408 CONNECT www.facebook.com:443 student1-2008 - text/html
A sucessful https browse to an allowed site looks like the following
1350442986 17/Oct/2012-14:03:06-EST 9058 10.0.1.103 TCP_MISS 200
24489 CONNECT play.google.com:443 student1-2008 play.google.com
... 1) these are CONNECT requests. They are not HTTPS nor are the resulting
tunnels necessarily containing HTTPS requests even if they are going to port
443.
They simply tell Squid to open a TCP connection to the named server and
port. Just a TCP connection.
This being Chrome you are using it is more likely that they are going to
send SPDY protocol than HTTPS - but either one or somethine else entirely
might result from that tunnel. It depends on things outside Squids control
and knowledge what the client and server negotiate between themselves with
the packets going through it *after* CONNECT setup.
in firefox this is all that is displayed:
Unable to connect - Firefox can't establish a connection to the
server at www.facebook.com.
Google is a little more descriptive giving this error:
Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error.
... 2) this is Chromes way of reporting to the user that something
(anything!) other than complete end-to-end success happened. Friendly no?
Squid successfully performed the checks and deny_info redirection
(TCP_DENIED/307 got logged), but Chrome is not handling the 307 status in
any useful way.
im not sure which bits from my conf are useful as for the most part
its all the same as when im not bothered by https, which could be my
problem, but the line responsible for the checking is :
adapted_http_access deny !request_policy_check_acl
and the deny info catching it is:
deny_info URL request_policy_check_acl
If these arent enough im happy to post more conf lines im just not
sure which ones may be of interest or more likely which ones are
missing
If anyone has any clue about this error id love to hear it
Your config is correct for what you want to do. This is a usability bug in
Chrome (and some other browsers have it too) not handling non-200 status
codes nicely when they arrive on a CONNECT request.
Amos
