Disable SSLv3 In cURL

curlopensslpoodlessltls

I'm having a problem connecting to a website that is hosted with CloudFlare using cURL. When I try to connect to the website with HTTPS (using curl -v https://www.xxxxxx.com), it says:

* About to connect() to www.xxxxxx.com port 443 (#0)
*   Trying 2400:cb00:2048:1::681c:116e...
* Connected to www.xxxxxx.com (2400:cb00:2048:1::681c:116e) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Error in TLS handshake, trying SSLv3...
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.xxxxxx.com
> Accept: */*
>
* Connection died, retrying a fresh connect
* Closing connection 0
* Issue another request to this URL: 'https://www.xxxxxx.com'
* About to connect() to www.xxxxxx.com port 443 (#1)
*   Trying 2400:cb00:2048:1::681c:116e...
* Connected to www.xxxxxx.com (2400:cb00:2048:1::681c:116e) port 443 (#1)
* TLS disabled due to previous handshake failure
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286 (SSL_ERROR_NO_CYPHER_OVERLAP)
* Cannot communicate securely with peer: no common encryption algorithm(s).
* Closing connection 1
curl: (35) Cannot communicate securely with peer: no common encryption algorithm(s).

I contacted CloudFlare about this issue and they say its because cURL is trying to connect using SSLv3 and they disabled it because of the POODLE vulnerability. I'm able to connect with cURL v7.38.0 on FreeBSD 10 no problems, but not with cURL v7.29.0 on CentOS 6.5.

If it is because it's trying to connect to SSLv3, then how do I disable SSLv3 on cURL? Or is it something else?

Best Answer

It looks like this problem is caused by the version of cURL not supporting ECC 256 bit SSL certificates and the ECDSA signature algorithm (which is used by CloudFlare). You can test to see if your version of cURL supports this encryption by running:

curl -1IsS --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com

If you get the following, then your cURL is out of date:

curl: (59) Unknown cipher in list: ecdhe_ecdsa_aes_128_sha

Otherwise, if it connects and doesn't display an error then it is up to date.

Since CentOS seems to thoroughly screen updates before they are applied to their packages, it's hard to say when this will be fixed. The ONLY way to get around this is by updating cURL, passing -k or --insecure won't work.

Related Solutions

CURL/wget – SSLv3, TLS handshake, CERT hangs

curl -v --trace-time https://www.google.de

21:50:34.054955 * About to connect() to www.google.de port 443
21:50:34.056574 *   Trying 74.125.39.104... connected
21:50:34.104587 * Connected to www.google.de (74.125.39.104) port 443
21:50:34.313259 * successfully set certificate verify locations:
21:50:34.313349 *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
21:50:34.313758 * SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using RC4-SHA
21:50:34.418541 * Server certificate:
21:50:34.418631 *        subject: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
21:50:34.418726 *        start date: 2011-10-26 00:00:00 GMT
21:50:34.418799 *        expire date: 2013-09-30 23:59:59 GMT
21:50:34.418902 * SSL: certificate subject name 'www.google.com' does not match target host name 'www.google.de'
21:50:34.419000 * Closing connection #0
21:50:34.419124 * SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'www.google.com' does not match target host name 'www.google.de'

It seems you are not able to verify the certificate since you are missing the ca-bundle.crt. This belongs (in CentOS 5) to the openssl-rpm.

Ssh – How to disable SSLv3 in an OpenSSH SSH server to avoid POODLE

This is not an issue for OpenSSH since it doesn't make use of SSL.

excerpt - What is the difference between SSL vs SSH? Which is more secure?

They differ on the things which are around the tunnel. SSL traditionally uses X.509 certificates for announcing server and client public keys; SSH has its own format. Also, SSH comes with a set of protocols for what goes inside the tunnel (multiplexing several transfers, performing password-based authentication within the tunnel, terminal management...) while there is no such thing in SSL, or, more accurately, when such things are used in SSL they are not considered to be part of SSL (for instance, when doing password-based HTTP authentication in a SSL tunnel, we say that it is part of "HTTPS", but it really works in a way similar to what happens with SSH).

Conceptually, you could take SSH and replace the tunnel part with the one from SSL. You could also take HTTPS and replace the SSL thing with SSH-with-data-transport and a hook to extract the server public key from its certificate. There is no scientific impossibility and, if done properly, security would remain the same. However, there is no widespread set of conventions or existing tools for that.

As further evidence I'd direct you to RFC 4253, which discusses the "The Secure Shell (SSH) Transport Layer Protocol". This is SSH's own custom transport layer, it does not use the same one that HTTPS/SSL uses.

This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.

Lastly this Q&A from the security SE site titled: SSL3 “Poodle” Vulnerability had this to say about the POODLE attack.

excerpt

The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:

inject data of his own before and after the secret value that he wants to obtain;

inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of his own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.

So there is no action that needs to be taken for OpenSSH against this particular threat.

Best Answer

Related Solutions

CURL/wget – SSLv3, TLS handshake, CERT hangs

Ssh – How to disable SSLv3 in an OpenSSH SSH server to avoid POODLE

References

More reading

Related Question