Skype, SSL bump and go.trouter.io

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Skype, SSL bump and go.trouter.io

Steve Hill

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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

Eliezer Croitoru
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: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Steve Hill
Sent: Wednesday, July 6, 2016 5:47 PM
To: [hidden email]
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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

Steve Hill
On 06/07/16 20:44, Eliezer Croitoru wrote:

> 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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

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

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: [hidden email]


-----Original Message-----
From: Steve Hill [mailto:[hidden email]]
Sent: Thursday, July 7, 2016 11:45 AM
To: Eliezer Croitoru; [hidden email]
Subject: Re: [squid-users] Skype, SSL bump and go.trouter.io

On 06/07/16 20:44, Eliezer Croitoru wrote:

> 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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

Steve Hill
On 07/07/16 11:07, Eliezer Croitoru wrote:

> 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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

Alex Rousskov
On 07/07/2016 10:12 AM, Steve Hill wrote:

> 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


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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Skype, SSL bump and go.trouter.io

Eliezer Croitoru
In reply to this post by Steve Hill
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: [hidden email]


-----Original Message-----
From: squid-users [mailto:[hidden email]] On Behalf Of Steve Hill
Sent: Wednesday, July 6, 2016 5:47 PM
To: [hidden email]
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:[hidden email]
    Email:            [hidden email]
    Phone:            sip:[hidden email]

Sales / enquiries contacts:
    Email:            [hidden email]
    Phone:            +44-1792-824568 / sip:[hidden email]

Support contacts:
    Email:            [hidden email]
    Phone:            +44-1792-825748 / sip:[hidden email]
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users