[squid-users] FW: squid tproxy ssl-bump and Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)

Tue Oct 4 12:06:02 UTC 2016

On 5/10/2016 12:07 a.m., Vieri wrote:
> Hi,
> 
>>> Whatever the reason, for an end-user like me it seems that the XP
>>> client is able to negotiate TLS correctly with Google and
>>> presumably using the cipher DES-CBC3-SHA (maybe after failing
>>> with RC4-MD5 on a first attempt), whereas Squid immediately fails
>>> with RC4-MD5. It doesn't ever seem to try DES-CBC3-SHA even
>>> though it's available in openssl.
>> 
>> ... in this case it might be. But not for the reasons stated. The 
>> problem known so far is that RC4-MD5 cipher. Why it is not being
>> used by your OpenSSL library.
>> 
>> That could bear some further investigation. There may be things you
>> need to enable in the config passed to OpenSSL, or a different
>> build of the library needed. Something along those lines - Im just
>> guessing here.
> 
> Thanks for your reply.
> 
> I don't fully understand your point. I hope you don't mind if I try
> to make a quick recap here below:
> 
> 1) www.google.com ONLY allows the following ciphers for TLS V 1.0
> (which is the highest TLS version for WinXP IE8):
> 
> TLSv1.0: ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - strong 
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - strong 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong 
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong TLS_RSA_WITH_AES_128_CBC_SHA -
> strong TLS_RSA_WITH_AES_256_CBC_SHA - strong
> 
> Correct?
> 

Insufficient data. Assuming true ...

> 2) According to https://www.ssllabs.com/ssltest/viewMyClient.html the
> Windows XP IE8 client supports: TLS 1.0 and the following cipher
> list: TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE 128 
> TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE 128 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)  112 TLS_RSA_WITH_DES_CBC_SHA
> (0x9)   WEAK 56 TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64)   INSECURE
> 56 TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)   WEAK 56 
> TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3)   INSECURE 40 
> TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6)   INSECURE 40 
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)   Forward Secrecy2  112 
> TLS_DHE_DSS_WITH_DES_CBC_SHA (0x12)   WEAK 56 
> TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x63)   WEAK 56
> 
> of which the least weak are:
> 
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
> 
> Does that sound correct?
> 

Insufficient data. Assuming true ...

> 3) I'm deducing from the previous two points that the only eligible
> cipher is TLS_RSA_WITH_3DES_EDE_CBC_SHA because it's the only cipher
> supported by both google.com and WinXP&IE8.
> 
> Right?
> 

Yes. Qualified by above assumptions.

> 4) According to https://testssl.sh/openssl-rfc.mappping.html the
> openssl cipher name equivalent for TLS_RSA_WITH_3DES_EDE_CBC_SHA is
> DES-CBC3-SHA.
> 
> Correct?

Yes.

> 
> 5) So if all the previous points are correct, now I'm assuming that
> if I run openssl at the command line on the same system where Squid
> is running then I can "reproduce" what the WinXP client "wants". I
> run the following:
> 
> # openssl s_client -connect google.com:443 -tls1 -cipher
> DES-CBC3-SHA [...] SSL-Session: Protocol  : TLSv1 Cipher    :
> DES-CBC3-SHA [...] (that went well)
> 
> I also run this other command:
> 
> # curl --tlsv1.0 --ciphers DES-CBC3-SHA https://www.google.com
> --trace trace.log
> 
> The trace.log file contains lines such as: == Info: Cipher selection:
> DES-CBC3-SHA Handshake OK and web page is accessed.
> 
> Is it correct to assume at this point that the current openssl build
> on this system is "OK" as far as supporting "Win XP TLS 1.0 ciphers
> to access at least google.com"?

Yes. The build is capable of it. That is one of 3 conditions that must
be met for it to work.

The other two being:

* whether it is enabled in the library config.
 - OpenSSL library has its own conf file somewhere.
 - it is possible that curl and other tools whose primary design purpose
is communication (not testing) override the library normal defaults for
their own use, or re-try certain things after failures. That needs to be
eliminated to be sure.

* that the squid.conf settings combine with those library settings to
cause it to be (or stay) enabled.

> 
> 6) I don't understand why you say that my openssl library does not
> use RC4-MD5 (did I understand your sentence correctly?). Why should
> the RC4-MD5 cipher be used in the first place? Who is requesting it?
> If it's the Windows XP client then it should obviously be discarded
> since google.com does not support it. So maybe this is what IE8 on XP
> does: it first tries RC4-MD5 and when that fails, it goes for
> DES-CBC3-SHA. In any case, when the WinXP client uses Squid as MITM,
> Squid *IS* using the RC4-MD5 cipher *AND* my openssl library *does*
> support this cipher as shown in the following command:
> 
> # openssl ciphers 
> ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DH-RSA-SEED-SHA:DH-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:KRB5-IDEA-CBC-SHA:KRB5-IDEA-CBC-MD5:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DH-RSA-DES-CBC3-SHA:DH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DH-RSA-DES-CBC-SHA:DH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5
>
>  Am I right?
> 
Yes. Sorry. I should have written DES-CBC3-SHA instead.

> 7) Squid uses openssl, right?
> 

For SSL-Bump in current Squid releases. Yes.

> 8) If the previous point is true then shouldn't I assume that Squid
> should have the same features as the ones I can "reproduce" by
> running the openssl commands as in the above examples? In other
> words, shouldn't Squid "support" both RC4-MD5 and DES-CBC3-SHA?
> 

No. see the answer to (5).

> 9) If all the previous points are true then: a) I'm lucky b) I'd like
> to know if the issue is simply the fact that Squid is unable to do
> anything with WinXP&IE8 clients that wrongly ask to use a cipher
> that's not supoprted by a given web site. Since it's MITM, Squid
> can't negotiate another cipher I suppose. But then again, like I said
> before, I don't know how the internals work.

Squid has to decrypt and re-encrypt the two TCP connections data.
That adds the third set of ciphers (those supported by Squid \w OpenSSL)
to the sets which must overlap.

So far we can assume that it is either a Squid bug relaying the
available cipher list between the two remote endpoints. Or that the set
of ciphers available to Squid does not include the DES-CBC3-SHA one.

To test that last detail you probably need to setup a normal https_port
with SSL and see if you can connect to it with TLSv1.0 and only that
cipher in curl. That will eliminate any possible server details
polluting the test result.

> 
> 10) I'm not stating that "working TLS behaviour is a bug in Squid".
> I'm merely assuming that if some modern TLS 1.2 clients can connect
> seemlessly with Squid in a MITM scenario (intercepted ssl-bump) then
> the same should happen with older TLS 1.0 clients when connecting to
> sites that supoprt both the protocol and the ciphers.
> 
> Is that an incorrect assumption?

"should" is determined by that 3-way cipher set combo (amongst other
protocol feature 3-way combos). The fact that the library can be
configured independent of any application using it throws a rather big
spanner into the expected behaviour logics.

> 
> If the WinXP client is faulty because it doesn't abide to the
> standard protocol then I'll assume it can't be used with Squid as
> MITM and force users to browse with FF or upgrade their OS.

Sorry, what I was trying to get across was that one endpoint not
following the protocol properly is when bumping *does* work.

So throwing blame at anyone when it "fails" without a bug being clearly
in evidence is the wrong thing to do. It is usually a sign that
everybody is actually doing "The Right Thing".

So far your tests are showing that it is about a 50/50 chance of being a
bug in Squid versus a Squid/OpenSSL misconfiguration somewhere.

Amos