To clear out my idea,
I was thinking about an option to decide if to bump or not based on a SSL handshake test on the destination Service.
I do not know skype traffic that much but I do know that a PTR can be "faked" and have seen it couple times in the past.
I considered what to do and one of the options is to do the bump in two steps and to identify requests that was not supposed to be bumped.
It's a bit complicated since in the nature of the idea there would be at least one failure for the client attempt to reach a destination.
I do not like the idea and I know it's not a nice one but I think that if an admin can identify the goal and determine that he doesn't care about traffic
detained to a specific host for both filtering and caching then all traffic to these hosts can be tunneled or spliced.
The methods I have in mind are:
- Using firewall\kernel level of bumping exceptions
- Using some no-bump external_acl helper
I have a specific model for doing such a thing with Linux ipset and I only need couple domains to evaluate the concept.
Eliezer
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer@xxxxxxxxxxxx
-----Original Message-----
From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Amos Jeffries
Sent: Monday, July 18, 2016 10:27 AM
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Skype+intercept+ssl_bump
On 15/07/2016 10:38 p.m., Evgeniy Kononov wrote:
> Hello!
>
> Can you help me with correct settings for squid to use skype ?
>
FYI: there are currently no known "correct" setting for Skype when SSL-Bump is involved.
There are settings known to work when Squid is setup as an explicit proxy, and some which almost-always (but only 99.999%) working for Squid intercepting port 80.
Intercepting port 443 and bumping the crypto has issues distinguishing Skype-TLS from real TLS and HTTPS.
That said, I have been giving it some thought today and suspect that since MS are apparently filtering Skype traffic through their own machines these days we could maybe use the "dst" ACL reverse-DNS behaviour to detect and splice that traffic.
If you want to experiment with that and have good results there are many here who would like some good news on this.
> With this setup I have problem with group chats, calls and attachments in messages.
> Attachments sended, but not delivered to respondent.
> Unable to create group chats and if it created, what respondents do not see the chat or can not make calls.
> I tried add IP regexp to access list, but after that all https traffic was spliced.
> Skype work well when I change ssl_bump bump all to ssl_bump splice all
> How can I exclude skype from SSL bumping ?
The problem is with identifying it in fairly reliable way from all the other traffic. That is where we are currently all stuck.
Yuri and Eliezer have been trying various things and talking about it on-list in recent weeks/months. But so far no results I'm confident about recommending.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
