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
