Re: [squid-users] Trouble filtering/denying HTTPS traffic

On 10/17/2012 02:18 AM, Amos Jeffries 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.

This is not just Chrome. All modern versions of MSIE/Chrome/Firefox
give an error like "cannot connect" or "proxy refusing connection".
It does not matter what HTTP error code Squid sends to the browser
since the browsers ignore the returned HTTP-based error messages
when sending a CONNECT and simply complain with "cannot connect".
FYI: old versions (4.x) of firefox did accept an HTTP error message
but the latest ones do not.

Marcus

>
>> 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 - 12:03:16 MDT