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. On 17 October 2012 16:18, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
