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

Discussion:

Steve Hill

2016-07-06 14:47:15 UTC

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:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

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

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com

Eliezer Croitoru

2016-07-06 19:44:44 UTC

Permalink

Hey Steve,

There are couple options to the issue and a bad request can happen if squid transforms or modifies the request.
Did you tried to use basic debug sections output to verify if you are able to "replicate" the request using a tiny script or curl?
I think that section 11 is the right one to start with
(http://wiki.squid-cache.org/KnowledgeBase/DebugSections)
There were couple issues with intercepted https connections in the past but a 400 means that something is bad and mainly in the expected input and not a certificate but it is possible that other reasons are there.
I have not tried to use skype in a transparent environment for a very long time but I can try to test it later.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il

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

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

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

Steve Hill

2016-07-07 08:44:34 UTC

Permalink

Post by Eliezer Croitoru
There are couple options to the issue and a bad request can happen if
squid transforms or modifies the request. Did you tried to use basic
debug sections output to verify if you are able to "replicate" the
request using a tiny script or curl? I think that section 11 is the
right one to start with
(http://wiki.squid-cache.org/KnowledgeBase/DebugSections) There were
couple issues with intercepted https connections in the past but a
400 means that something is bad and mainly in the expected input and
not a certificate but it is possible that other reasons are there. I
have not tried to use skype in a transparent environment for a very
long time but I can try to test it later.

I tcpdumped the icap REQMOD session to retrieve the request and tried it
manually (direct to the Skype server) with openssl s_client. The Skype
server (not Squid) returned a 400. But of course, the Skype request
contains various data that the server will probably (correctly) see as a
replay attack, so it isn't a very good test - all I can really say is
that the real Skype client was getting exactly the same error from the
server when the connection is bumped, but works fine when it is tunnelled.

Annoyingly, Skype doesn't include an SNI in the handshake, so peeking in
order to exclude it from being bumped isn't an option.

The odd thing is that I have had Skype working in a transparent
environment previously (with the unprivalidged ports unfirewalled), so I
wonder if this is something new from Microsoft.
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

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

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com

Eliezer Croitoru

2016-07-07 10:07:20 UTC

Permalink

Can you verify please using a debug 11,9 that squid is not altering the request in any form?
Such as mentioned at: http://bugs.squid-cache.org/show_bug.cgi?id=4253

Have you tried adding:
request_header_access Surrogate-Capability deny all

Microsoft is in the edge of technology compared to what some might think but if they do not reveal their cards it doesn't mean they are stupid(not directed to you).
If there is a security expert out there for Linux, there is more then one for MS.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: ***@ngtech.co.il

-----Original Message-----
From: Steve Hill [mailto:***@opendium.com]
Sent: Thursday, July 7, 2016 11:45 AM
To: Eliezer Croitoru; squid-***@lists.squid-cache.org
Subject: Re: [squid-users] Skype, SSL bump and go.trouter.io

Steve Hill

2016-07-07 16:12:04 UTC

Permalink

Post by Eliezer Croitoru
Can you verify please using a debug 11,9 that squid is not altering the request in any form?
Such as mentioned at: http://bugs.squid-cache.org/show_bug.cgi?id=4253

Thanks for this. I've compared the headers and the original contains:
Upgrade: websocket
Connection: Upgrade

Unfortunately, since Squid doesn't support websockets I think there's no
way around this - by the time we see the request and can identify it as
Skype we've already bumped it so we're committed to pass it through
Squid's HTTP engine. :(
--
- Steve Hill
Technical Director
Opendium Limited http://www.opendium.com

Direct contacts:
Instant messager: xmpp:***@opendium.com
Email: ***@opendium.com
Phone: sip:***@opendium.com

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

Support contacts:
Email: ***@opendium.com
Phone: +44-1792-825748 / sip:***@opendium.com

Alex Rousskov

2016-07-07 17:15:31 UTC

Permalink

Post by Steve Hill
Upgrade: websocket
Connection: Upgrade
Unfortunately, since Squid doesn't support websockets I think there's no
way around this

Squid can be taught to recognize HTTP upgrades to unsupported protocols
and, with admin permission, switch to tunnel mode. This requires
development, but much less development than full WebSockets support. We
have already built the foundation for this via on_unsupported_protocol.

Alex.

Eliezer Croitoru

2016-07-07 21:38:06 UTC

Permalink

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: ***@ngtech.co.il

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

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

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