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@xxxxxxxxxxxxx> 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
