Returning back to the beginning of the subject there are couple other ideas on the table to allow these connections to exit or somehow either predict them or identify them as they come. The first thing is that you don't really care to pass authentication sessions from a caching perspective, since these should never be cached. Let say we know every one of the domains IP addresses and these are not a CDN one, it would be possible to identify them and splice them. I can think about a tiny script that will identify the IP addresses of this service and will splice these. The issue is that I cannot guarantee that it will open other doors which you might not want to. If you wish to try my concept I can try to give it some work but my condition is to try it in binary form only for the testing period. Let me know how it sounds, 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 Steve Hill Sent: Wednesday, July 6, 2016 5:47 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Skype, SSL bump and go.trouter.io I've been finding some problems with Skype when combined with TProxy and HTTPS interception and wondered if anyone had seen this before: Skype works so long as HTTPS interception is not performed and traffic to TCP and UDP ports 1024-65535 is allowed directly out to the internet. Enabling SSL-bump seems to break things - When making a call, Skype makes an SSL connection to go.trouter.io, which Squid successfully bumps. Skype then makes a GET request to https://go.trouter.io/v3/c?auth=true&timeout=55 over the SSL connection, but the HTTPS server responds with a "400 Bad Request" error and Skype fails to work. The Skype client clearly isn't rejecting the intercepted connection since it is making HTTPS requests over it, but I can't see why the server would be returning an error. Obviously I can't see what's going on inside the connection when it isn't being bumped, but it does work then. The only thing I can think is maybe the server is examining the SSL handshake and returning an error because it knows it isn't talking directly to the Skype client - but that seems like an odd way of doing things, rather than rejecting the SSL handshake in the first place. -- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve@xxxxxxxxxxxx Email: steve@xxxxxxxxxxxx Phone: sip:steve@xxxxxxxxxxxx Sales / enquiries contacts: Email: sales@xxxxxxxxxxxx Phone: +44-1792-824568 / sip:sales@xxxxxxxxxxxx Support contacts: Email: support@xxxxxxxxxxxx Phone: +44-1792-825748 / sip:support@xxxxxxxxxxxx _______________________________________________ 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
