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

Vieri rentorbuy at yahoo.com
Fri Sep 30 11:36:24 UTC 2016


Hi,

----- Original Message -----
> From: Amos Jeffries <squid3 at treenet.co.nz>
>
> Squid mimics the client details when contacting the server. So you would

> get the same problem (though maybe different description) if going

> directly without the proxy.


If I try connecting to https://www.google.com with this client and going directly without proxy then I have no problem whatsoever. I'm sure any Windows XP user still out there with IE8 can confirm that a direct connection to https://www.google.com still works fine. I hit the issue only when using Squid.


So from the squid server I ran:

# nmap --script ssl-enum-ciphers google.com
[...]
| ssl-enum-ciphers:
|   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
|     compressors:
|
|   TLSv1.1:
|     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
|     compressors:
|
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - strong
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|     compressors:
|
|_  least strength: strong


So if TLS 1.0 is supported by Google then the Windows XP clients should be able to connect.


Can a cipher issue trigger the error message "Handshake with SSL server failed: error:1409F07F:SSL routines:ssl3_write_pending:bad write retry"?

I ran:

# 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


# openssl s_client -connect google.com:443 -tls1
[...]
SSL-Session:
Protocol  : TLSv1
Cipher    : ECDHE-RSA-AES128-SHA

[...]

I also tried the following on the Squid server:

# curl --tlsv1.0 --trace trace.log https://www.google.com && grep "SSL connection using" trace.log[...]
== Info: SSL connection using TLSv1.0 / ECDHE-RSA-AES128-SHA
[...]

>From the Windows XP IE8 client I connected to this web site to quickly see all the supported protocols and ciphers:
https://www.ssllabs.com/ssltest/viewMyClient.html
I can see TLS 1.0 support 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 


On a Windows 7 IE8 client with no Squid proxy issues I can see the following list of ciphers:

TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)  128 
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)  128 
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)  256 
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)  256 
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE 128 
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)  112 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)   Forward Secrecy  128 
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy  128 
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy  256 
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy  128 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)   Forward Secrecy  128 
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)   Forward Secrecy  256 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)   Forward Secrecy  256 
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy  128 
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy  256 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x40)   Forward Secrecy2  128 
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32)   Forward Secrecy2  128 
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x6a)   Forward Secrecy2  256 
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x38)   Forward Secrecy2  256 
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)   Forward Secrecy2  112 
TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE 128 


I suppose that the Windows XP client successfully connects to https://www.google.com because it uses TLS_RSA_WITH_3DES_EDE_CBC_SHA (when NOT using Squid). Am I right? Is there a way I can confirm that?


So, back on the squid server I checked the openssl ciphers for one that is supported by the Windows XP system. I searched for the oepnssl cipher name from the RFC cipher name at https://testssl.sh/openssl-rfc.mappping.html.

I found the following:
TLS_RSA_WITH_3DES_EDE_CBC_SHA = DES-CBC3-SHA
The other "strong" cipher supported by Windows XP seems to be:
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA


# curl --tlsv1.0 --ciphers SRP-RSA-3DES-EDE-CBC-SHA --trace trace.log https://www.google.com
curl: (35) error:140740B5:SSL routines:SSL23_CLIENT_HELLO:no ciphers available


So I tried these commands on the Squid server:

# openssl s_client -connect google.com:443 -tls1 -cipher DES-CBC3-SHA
[...]
SSL-Session:
Protocol  : TLSv1
Cipher    : DES-CBC3-SHA

[...]
(that went well)


# openssl s_client -connect google.com:443 -tls1 -cipher EDH-DSS-DES-CBC3-SHA

CONNECTED(00000003)
3072018108:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
3072018108:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:


So this failed. Why?
Is google wrongly advertising the supported cipher (I doubt it)?

I have OpenSSL 1.0.2d 9 Jul 2015 and Squid 3.5.14.

How do I know if Squid is also trying to use the same cipher EDH-DSS-DES-CBC3-SHA instead of DES-CBC3-SHA?

I tried setting debug_options rotate=1 ALL,5 but found nothing related to the cipher in the log:

# tail -n 1000000 /var/log/squid/cache.log | grep "10.215.144.47" | grep -i cipher

> To get around this you require the latest Squid version (with> peek-and-splice feature) doing the "bump" action on these clients

> traffic so that it can upgrade the TLS/SSL handshake and use some
> ciphers etc the server will accept on their connections.

I'm already using sslbump with squid 3.5. As posted in my first message I have:
https_port 3130 tproxy ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=16MB cert=/etc/ssl/squid/proxyserver.pem

How can I tell which TLS/cipher versions Squid is using? What exactly should I search for in the log?

I tried this while connecting from the Windows XP client:
# watch -n 1 "tail -n 10000 /var/log/squid/cache.log | grep clientNegotiateSSL"
2016/09/30 13:19:06.633 kid1| 83,2| client_side.cc(3796) clientNegotiateSSL: clientNegotiateSSL: New session 0x870088d8 on FD 151 (10.215.144.47:1649)
2016/09/30 13:19:06.633 kid1| 83,3| client_side.cc(3800) clientNegotiateSSL: clientNegotiateSSL: FD 151 negotiated cipher RC4-MD5
2016/09/30 13:19:06.633 kid1| 83,5| client_side.cc(3816) clientNegotiateSSL: clientNegotiateSSL: FD 151 has no certificate.


Why is Squid negotiating cipher RC4-MD5 which is reported "insecure" and unsupported by the google web site?


I finally tried this on the Squid server:

# openssl s_client -connect google.com:443 -tls1 -cipher RC4-MD5
CONNECTED(00000003)
3071960764:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
3071960764:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:


If I watch the Squid log when performing a connection to google from a Windows 7 IE8 with no issues, I get this:
2016/09/30 13:30:55.266 kid1| 83,2| client_side.cc(3764) clientNegotiateSSL: clientNegotiateSSL: Session 0x8331ee98 reused on FD 40 (10.215.144.48:21962)
2016/09/30 13:30:55.266 kid1| 83,3| client_side.cc(3800) clientNegotiateSSL: clientNegotiateSSL: FD 40 negotiated cipher AES256-GCM-SHA384
2016/09/30 13:30:55.267 kid1| 83,5| client_side.cc(3816) clientNegotiateSSL: clientNegotiateSSL: FD 40 has no certificate.


Any more ideas?

Vieri


More information about the squid-users mailing list