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

On 18 October 2012 08:58, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 18.10.2012 01:03, Marcus Kool wrote:
>>
>> 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
>
>
> This is NOT about 4xx/5xx error though. The reasonable arguments against
> displaying 4xx/5xx (including auth login pages) are all about how they are
> to display the information that the address bar and the displayed page are
> not related. When they do it is trivial to break security and foll the users
> who see an attacked sites login https:// URL in the address bar and a fake
> login page from some intermediary posting the credentials back to attackers
> server.
>
> This is specifically Chrome ("Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED):
> Unknown error.") responding to a 307 redirection.
>
> What they are supposed to do is present a popup asking teh user if they are
> allowed to repeat with the new location.
> RFC 2616:
> "If the 307 status code is received in response to a request other
> than GET or HEAD, the user agent MUST NOT automatically redirect the
> request unless it can be confirmed by the user, since this might
> change the conditions under which the request was issued."
>
> Instead they just bark some obscure code syntax at the user instead.
>
>
> Cameron, I'm reminded of another method. Have you tried 303 code instead?
> That one specifically tells the browser to change to GET and fetch as a
> regular page. Useful for portal login pages and error display pages for
> non-GET reuqests.
>
> Amos

Amos, i just gave the 303 code a try using the following deny_info line
        deny_info 303:http://10.0.1.26/policy/denied/request/%A
request_policy_check_acl

which the access log notes with the following
      1350516342 18/Oct/2012-10:25:42-EST 275 10.0.1.103 TCP_DENIED
303 398 CONNECT www.youtube.com:443 student1-2008 - text/html

Same error/outcome in the browser.

Cameron
Received on Wed Oct 17 2012 - 23:28:52 MDT