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_at_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
Received on Wed Oct 17 2012 - 05:30:18 MDT
This archive was generated by hypermail 2.2.0 : Wed Oct 17 2012 - 12:00:02 MDT