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

Tue Oct 4 11:07:47 UTC 2016

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?

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?

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?

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?

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"?

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?

7) Squid uses openssl, right?

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?

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.

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?

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.

Thanks,

Vieri