[squid-users] Problem with ssl_choose_client_version:inappropriate fallback on some sites when using TLS1.2

Wed Sep 18 19:55:40 UTC 2019

Hi Amos

Thank you for your help.

On Tue, 17 Sep 2019 at 07:26, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> ...
> >     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
>
> I suspect it might have something to do with these ECDSA keys.
>
> You do not have Elliptic-Curves enabled on the https_port client-facing
> connection. So the TLS extensions associated are likely not to be
> compatible between the client and the server connections Squid is
> attempting to bridge between.
>
I generated a dhparams file using the command:
openssl dhparam -out dhparams.pem 2048
and then I configured the port with the following options:
https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept
tls-dh=prime256v1:/etc/squid/dhparams.pem
options=SINGLE_ECDH_USE,SINGLE_DH_USE

But this still gives this in the log when I connect:
2019/09/18 08:19:44 kid1| ERROR: negotiating TLS on FD 17:
error:1425F175:SSL routines:ssl_choose_client_version:inappropriate
fallback (1/-1/0)

I have also tried restricting the cipher to the same cipher that works
for the ubuntu connection and I get the same error:
openssl s_client -tls1_2  -CAfile squid.crt -cipher
ECDHE-RSA-AES128-GCM-SHA256  -connect www.google.com:443

With this restriction, the client hello to squid is:
Handshake Protocol: Client Hello
    Handshake Type: Client Hello (1)
    Length: 156
    Version: TLS 1.2 (0x0303)
    Random: e52eb8a54705dc32774c5832694dd4567cd9b0f34556ebf3…
    Session ID Length: 0
    Cipher Suites Length: 4
    Cipher Suites (2 suites)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
    Compression Methods Length: 1
    Compression Methods (1 method)
    Extensions Length: 111
    Extension: server_name (len=19)
    Extension: ec_point_formats (len=4)
    Extension: supported_groups (len=12)
    Extension: session_ticket (len=0)
    Extension: encrypt_then_mac (len=0)
    Extension: extended_master_secret (len=0)
    Extension: signature_algorithms (len=48)
The proxied hello to google is identical to the above.
The server hello from google is:
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 63
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 59
            Version: TLS 1.2 (0x0303)
            Random: 5d81da909e779d7e67f2663d6563236721b0906d09dacf02…
            Session ID Length: 0
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
            Compression Method: null (0)
            Extensions Length: 19
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: ec_point_formats (len=2)
            Extension: session_ticket (len=0)
    TLSv1.2 Record Layer: Handshake Protocol: Certificate
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 2537
        Handshake Protocol: Certificate
            Handshake Type: Certificate (11)
            Length: 2533
            Certificates Length: 2530
            Certificates (2530 bytes)
                Certificate Length: 1422
                Certificate:
3082058a30820472a0030201020210556630a312faeab908…
(id-at-commonName=www.google.com,id-at-organizationName=Google
LLC,id-at-localityName=Mountain
View,id-at-stateOrProvinceName=California,id-at-countryName=US)
                Certificate Length: 1102
                Certificate:
3082044a30820332a003020102020d01e3b49aa18d8aa981…
(id-at-commonName=GTS CA 1O1,id-at-organizationName=Google Trust
Services,id-at-countryName=US)
    TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 300
        Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 296
            EC Diffie-Hellman Server Params
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 4
        Handshake Protocol: Server Hello Done

If you have any further suggestions as to how/where I should debug I
would be extremely grateful.

John

On Tue, 17 Sep 2019 at 07:26, Amos Jeffries <squid3 at treenet.co.nz> wrote:
>
>
> On 15/09/19 10:41 pm, John Sweet-Escott wrote:
> > Hi All
> >
> > We are trying to run Squid 4.8, compiled with OpenSSL 1.1.1 (see [1]) on
> > Ubuntu 18.04 as a transparent proxy for the purpose of egress filtering
> > of HTTPS traffic using SNI (see config in [2]). It it works correctly
> > when contacting some addresses (e.g. https://www.ubuntu.com) but not
> > others (e.g. https://www.google.com). When we contact
> > https://www.google.com using TLS1.2 we get the error in the logs:
> > 2019/09/15 10:33:09 kid1| ERROR: negotiating TLS on FD 19:
> > error:1425F175:SSL routines:ssl_choose_client_version:inappropriate
> > fallback (1/-1/0)
> ...
> >     Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
>
> I suspect it might have something to do with these ECDSA keys.
>
> You do not have Elliptic-Curves enabled on the https_port client-facing
> connection. So the TLS extensions associated are likely not to be
> compatible between the client and the server connections Squid is
> attempting to bridge between.
>
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users