[squid-users] 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: eliezer at ngtech.co.il


-----Original Message-----
From: Steve Hill [mailto:steve at opendium.com] 
Sent: Thursday, July 7, 2016 11:45 AM
To: Eliezer Croitoru; squid-users at lists.squid-cache.org
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: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