[squid-users] Skype, SSL bump and go.trouter.io

[Eliezer Croitoru]

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 at ngtech.co.il


-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Steve Hill
Sent: Wednesday, July 6, 2016 5:47 PM
To: squid-users at lists.squid-cache.org
Subject: [squid-users] 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 at opendium.com
    Email:            steve at opendium.com
    Phone:            sip:steve at opendium.com

Sales / enquiries contacts:
    Email:            sales at opendium.com
    Phone:            +44-1792-824568 / sip:sales at opendium.com

Support contacts:
    Email:            support at opendium.com
    Phone:            +44-1792-825748 / sip:support at opendium.com
_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users