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: elie...@ngtech.co.il -----Original Message----- From: Steve Hill [mailto:st...@opendium.com] Sent: Thursday, July 7, 2016 11:45 AM To: Eliezer Croitoru; squid-users@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:st...@opendium.com Email: st...@opendium.com Phone: sip:st...@opendium.com Sales / enquiries contacts: Email: sa...@opendium.com Phone: +44-1792-824568 / sip:sa...@opendium.com Support contacts: Email: supp...@opendium.com Phone: +44-1792-825748 / sip:supp...@opendium.com _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
