Error in curl after version 7.50.1 and not before with FTPS TLSV1.0 with client certificate

[lpmd2000]

Hi,

We are trying to connect to a ftps server with tlsv1.0 with a client certificate. Before version 7.50.0 everything was OK. But after 7.50.1 we have an error saying "error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security"

We were exepecting to connect sucessfully as before, wat could be wrong.

The problema occurs on version curl 7.50.1 and after.

curl -v -u ftps0004:**** --tlsv1.0 --ftp-method nocwd --cacert d:\filebroker\certificates\verisignCA3.cer --cert "d:\temp\pedro_quaresma.pem" --cert-type "PEM" ftps://gateway.coface.com/

Operation System windows 2012.
I have atached two log files one, with version 7.50 and the other one (failing) with 7.51.

best regards,
Luis

Connect_not_OK_7.51.txt
Connect_OK_7.50.txt

[jay]

I can't reproduce this. I've tried various curls both before and after and 7.50.1 built against OpenSSL since that's what you seem to be using, and the results are a consistent (and expected in my case) handshake failure almost certainly due to lack of client cert. What is the curl -V for each, and are you sure you are using the same command line for both curls? I can get pretty much the same early abort as you but only if I omit --tlsv1.0 :

• error:1407742F:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert insufficient security

[lpmd2000]

Hi jay,
Thanks for your response.
I have attached new print screens. At the first line is the curl -V option and then the response from each version of curl.
Has you can see the 7.50 is working and the 7.50.1 is not working.

best regards.

moderator edit: requested github remove images from aws due to sensitive information @jay

[jay]

I requested github remove your screenshots from their servers (and they did) because even though you tried to wipe out your password it could still be reconstructed in at least one. I suggest you change your password.

Also please don't give us screenshots just post the curl -V data in and for additional information you can post it in or attach text files.

Looking at your two curls the one that works to make the connections is built against OpenSSL 1.0.2 and the one that doesn't work to make the connections is built against OpenSSL 1.1.0. So I think that could be something. Also OpenSSL 1.0.2 connection uses
SSL connection using TLSv1.0 / DES-CBC3-SHA
Which may not be available in OpenSSL 1.1.0.

I would capture the packets in Wireshark of a failed connection using the curl w/ OpenSSL 1.1.0. There is a chance that even though it sets TLSv1.0 that version of OpenSSL can't do it, or it's a bug in curl that for some reason it isn't being set.

[lpmd2000]

Hi Jay,
Thanks for your advice's. I have attached the curl -V in text and the wireshark captures with the error connection.
best regards.
Coface_wireshark.zip
curl_7_50_0.txt
curl_7_50_1.txt

[jay]

Thanks. To sum up:

curl -v --tlsv1.0 ftps://gateway.coface.com

Working:

curl 7.50.0 (i386-pc-win32) libcurl/7.50.0 OpenSSL/1.0.2h zlib/1.2.8 WinIDN libssh2/1.7.0 nghttp2/1.13.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 

Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

SSL connection using TLSv1.0 / DES-CBC3-SHA

Not working:

curl 7.50.1 (i386-pc-win32) libcurl/7.50.1 OpenSSL/1.1.0 zlib/1.2.8 WinIDN libssh2/1.7.0 nghttp2/1.14.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 

Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

TLSv1.1 Record Layer: Handshake Protocol: Client Hello
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 142
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 138
        Version: TLS 1.0 (0x0301)
        Random
            GMT Unix Time: Jul 12, 2094 01:28:06.000000000 Eastern Daylight Time
            Random Bytes: 6af34cf75e429532ac10ede24673bd6d63bec3baaa3875a5...
        Session ID Length: 0
        Cipher Suites Length: 40
        Cipher Suites (20 suites)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
            Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
            Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
            Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
            Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
            Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
            Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
            Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
            Cipher Suite: TLS_DHE_RSA_WITH_SEED_CBC_SHA (0x009a)
            Cipher Suite: TLS_DHE_DSS_WITH_SEED_CBC_SHA (0x0099)
            Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
            Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
            Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
            Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
            Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
            Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

In the not-working case the cipher suites sent for TLS v1.0 include various AES, CAMELLIA and SEED but do not include 3DES. AFAICT some 3DES is required for TLS v1.0 and 1.1 so the question is why it isn't being sent. For reference here are all the required ciphers based on TLS version:

TLS v1.0, RFC 2246 section 9:

9. Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

TLS v1.1, RFC 4346 section 9:

9. Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher
   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

TLS v1.2, RFC 5246 section 9:

9.  Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
   definition).

curl uses a default cipher list when built against OpenSSL. Based on your output your curls use this default list.
https://github.com/curl/curl/blob/master/lib/vtls/openssl.h#L122-L123
https://github.com/curl/curl/blob/master/lib/vtls/openssl.c#L2042-L2049

#define DEFAULT_CIPHER_SELECTION \
  "ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH"

AFAICT from the OpenSSL 1.1.0 cipher manpage none of those disable 3DES. (Note @STRENGTH is sort by strength/keylen, and only affects order).

You could try --cipher 3DES regardless of TLS version but I will guess your OpenSSL 1.1 wasn't built with it since according to this blog post they disabled it by default in OpenSSL 1.1.

And someone tell me what this means from the RFCs:
"In the absence of an application profile standard specifying otherwise"

So who is responsible here for ensuring 3DES is sent for TLS v1.x ? My interpretation of these RFCs is unless TLS v1.2 was explicitly requested the 3DES mandatory ciphers should be sent. Is OpenSSL breaking the RFCs by not including 3DES by default any longer? Shouldn't it be built in, even if it's not in the default cipher lists or ALL, so that an application like curl can include it for TLSv1.x?

/cc @richsalz @levitte

[richsalz]

The real-world has moved beyond the RFC's and 3DES is really bad. If you want it you need to configure with enable-weak-ciphers and put "@SECLEVEL=0" on your cipher string.

[jay]

I should have read that blog post all the way through. It looks like 3DES has various weaknesses and the post describes one specific serious one sweet32, which is why it is disabled now in OpenSSL 1.1. I'm not sure what to do in a case like this.

[richsalz]

If you need to interop and require 3DES, see my advice above.

[jay]

Ok, but I am curious though what is the disadvantage of leaving it built in even if it is disabled by default, that way apps could get that interop without users having to rebuild OpenSSL? Have any other apps reported something similar?

[richsalz]

At this point it becomes a discussion more appropriate for the openssl-users mailing list, https://mta.openssl.org to join.

[jay]

Ok I understand, thanks.

@lpmd2000 to connect to that server using curl w/OpenSSL 1.1 you would first need to rebuild OpenSSL 1.1 with 3DES support as Rich mentioned earlier. If you don't have any problems using OpenSSL 1.0.2 there is a contributor pre-built curl with OpenSSL 1.0.2k on the downloads page Win32, from Darren Owen.

bedae9315a24420d5bbf80e95930cad1d3345b908d670220cbf83a287b9db99f
curl_7_53_1_openssl_nghttp2_x86.7z

Remove the included ca-bundle.crt and download the latest cacert.pem and rename it curl-ca-bundle.crt, or use your own ca bundle.

e62a07e61e5870effa81b430e1900778943c228bd7da1259dd6a955ee2262b47
cacert.pem (Wed Jan 18 04:12:05 2017 GMT)