On 29/11/2012 7:22 p.m., Sean Boran wrote:
> Thanks for the various suggestions.
> - Running on HEAD from August, I would have thought I'm running
> (almost) the newest 3.3, Server bumping is in there.
Maybe. There are crtd helper crashes, data from wrong FD being used on
some ACLs after bumping, hanging SSL traffic, early aborted SSL traffic,
wrongly numbered certificates and http(s)_port options not being used by
the crtd properly issues all fixed since Aug.
> - http://wiki.squid-cache.org/ConfigExamples/Chat/Skype does not help,
> it is basically saying allow 443, and explains how to allow HTTP to
> all numeric addresses. I dont want to disable bumping for all numeric
> addresses.
Actually its all numeric IPs *if* the Skype UA is present.
Or you could invert the assumptions. Only bump if the UA is a browser
one :-)
> - If I run head Im not allowed to report issues here? :-)
More along the lines of this being a general help list. Reports only get
fixed *IF* someone has time and inclination to do so (in here that
usually means me personally). squid-dev has a larger team of people to
assist, and bugzilla is the *right* place to report issues that are
clearly bugs - even bugs in HEAD.
Amos
>
> I'll pull the latest HEAD and recompile and try that.
>
> Sean
>
>
> On 28 November 2012 00:03, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>> On 28.11.2012 11:32, Marcus Kool wrote:
>>> I have seen this issue on 3.1.x and cannot find anything in the Changelog
>>> that indicates that this issue is resolved in 3.3.
>>>
>>> What I observed in 3.1 is that sslbump assumes that all
>>> CONNECTs are used for SSL-wrapped HTTP traffic and lets
>>> all applications that use port 443 for other protocols hang
>>> when the SSL handshake fails.
>>>
>>> Marcus
>>>
>> "How evil can it be? oh. It's interception. Well then."
>>
>> 3.1 and 3.2 as you say, the situation is all-or-nothing. There are also not
>> going to be any more feature changes to them.
>>
>> 3.3 server-first bumping is a large step in the direction of proper
>> transparent interception for CONNECT. With server-bump failures it is
>> possible to take the bumping out of the transaction and relay the traffic as
>> if bumping was not being performed at all.
>> I'm not sure exactly where the testing and operational status of that
>> particular failover handling is now, but it was one of several design goals
>> behind server-bump.
>>
>> So, with my maintainer hat on... If you need HTTPS interception please skip
>> straight to 3.3. And please report your issues with that one to *bugzilla*
>> or *squid-dev*.
>>
>>
>>
>> ... back to the question at hand though...
>>
>>
>>
>>> On 11/27/2012 11:48 AM, Eliezer Croitoru wrote:
>>>> if it's linux machine try to use firewall rules to block all traffic with
>>>> TCP-RESET except dst port 80 and 443.
>>>>
>>>> This will close some of the things for you.
>>>> but 3.head 1408 it's kind of old.
>>>> you can try the latest 3.3.0.1 beta which have pretty good chance of to
>>>> solve it by the new features.
>>>>
>>>> Regards,
>>>> Eliezer
>>>>
>>>>
>>>> On 11/27/2012 3:19 PM, Sean Boran wrote:
>>>>> Typically one wishes to block Skype, but I'd like to enable it :-)
>>>>>
>>>>> Looking at the access.log, the following domains were excluded from ssl
>>>>> bump:
>>>>> .skype.com
>>>>> .skypeassets.com
>>>>> skype.tt.omtrdc.net
>>
>> Please read: http://wiki.squid-cache.org/ConfigExamples/Chat/Skype
>>
>> The ACLs should work equally well for ssl_bump_access as for http_access.
>>
>>
>> Amos
Received on Thu Nov 29 2012 - 08:45:10 MST
This archive was generated by hypermail 2.2.0 : Thu Nov 29 2012 - 12:00:05 MST