#1430 "Unknown SSL protocol error" - regression in curl 7.35 and later

[Nowaker]

https://jira.atlashost.eu/ doesn't work with curl, but works in any browser, or with wget.

root@nwkr-desktop ~ # curl --version
curl 7.38.0 (x86_64-unknown-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1i zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP 
root@nwkr-desktop ~ # curl https://jira.atlashost.eu/
curl: (35) Unknown SSL protocol error in connection to jira.atlashost.eu:443

Last version that works:

root@nwkr-desktop ~ # curl --version 
curl 7.34.0 (x86_64-unknown-linux-gnu) libcurl/7.34.0 OpenSSL/1.0.1i zlib/1.2.8 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP 
root@nwkr-desktop ~ # curl -I https://jira.atlashost.eu/ 2>/dev/null | head -n 1
HTTP/1.1 500 Internal Server Error

OpenSSL string with ciphers:

EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!MD5:!SSLv2:!aNULL:!eNULL:!LOW:!3DES:!EXP:!PSK:!SRP:!DSS

In nodejs 0.10 this string results in only TLS_RSA_WITH_RC4_128_SHA being available. I force-disabled weaker ciphers, so it's not possible to use them at all (e.g. TLS_RSA_WITH_DES_CBC_SHA). My guess is curl has those weak ciphers on its accept list but apparently doesn't have the TLS_RSA_WITH_RC4_128_SHA. This cipher is OK (but not perfect) and if it's the only supported cipher by the server, curl should stick to it.

Consult SSL Labs: https://www.ssllabs.com/ssltest/analyze.html?d=jira.atlashost.eu

Let me know how I can help you.

[Tigran Gabrielyan]

I have a similar issue with 7.38.0.

With 7.38.0 I get the following SSL error, however, with previous versions, I get the correct response back (an unauthorized message).

curl -v -XPOST https://api.demo.globalgatewaye4.firstdata.com/transaction/

• Hostname was NOT found in DNS cache
• Trying 54.191.215.216...
• Connected to api.demo.globalgatewaye4.firstdata.com (54.191.215.216) port 443 (#0)
• successfully set certificate verify locations:
• CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
• SSLv3, TLS handshake, Client hello (1):
• SSLv3, TLS alert, Server hello (2):
• error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
• Closing connection 0
  curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

[Nowaker]

This is not the same problem, please report a different issue for clarity.

[Daniel Stenberg]

Nowaker: your handshake fails simply because the site insits on using an RC4 cipher and we disable such ciphers by default now.

See https://github.com/bagder/curl/blob/master/docs/SSL-PROBLEMS for more details on that.

To work around this problem, provide a list to --cipher that includes RC4. Just using "--ciphers ALL" makes the handshake succeed but is probably overly permisssive.

[Nowaker]

@Daniel, thanks for your reply. The problem is TLS_RSA_WITH_RC4_128_SHA is the strongest available cipher on node 0.10. If I don't enforce it, curl will happily use even weaker cipher than it. I'll prepare more details for you soon.

[Daniel Stenberg]

I don't understand. In curl we set this selection to openssl by default: "ALL!EXPORT!EXPORT40!EXPORT56!aNULL!LOW!RC4"

You can get the RC4 ciphers back by simply cutting off "!RC4" from the right side of the cipher list: 'ALL!EXPORT!EXPORT40!EXPORT56!aNULL!LOW'

RC4 is not considered a secure cipher these days.

[Daniel Stenberg]

No further response, closing.

[kenorb]

This was fixed in recent curl (>7.40), so upgrade it.