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

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 <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 - 09:31:01 MDT