search

timkay / aws

Easy command line access to Amazon EC2, S3, SQS, ELB, and SDB
http://timkay.com/aws/
424 stars 123 forks source link

The sanity check fails if using a curl compiled with NSS library (not OpenSSL or GnuTLS). #88

Closed mariovaldez closed 9 years ago

mariovaldez commented 9 years ago

Latest versions of CentOS, RedHat Linux and Fedora have curl compiled with NSS, not OpenSSL. The aws command fails with:

sanity-check:  Your curl doesn't seem to support SSL.  Try using --http

The sanity check done using:

curl -q --cipher RC4-SHA -s  --include https://connection.s3.amazonaws.com/test

fails (with an exit code 59 meaning "Couldn't use specified SSL cipher") because the cipher string for NSS is different than the string for OpenSSL or GnuTLS (which use "RC4-SHA"). For versions compiled with NSS the cipher string should be "rsa_rc4_128_sha". A working check would be:

curl -q --cipher rsa_rc4_128_sha -s --include https://connection.s3.amazonaws.com/test

I think the solution would be to test with RC4-SHA and retry with rsa_rc4_128_sha if it fails, or try to detect if curl uses NSS. The version command shows the library used:

curl --version
curl 7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

for a version with OpenSSL and:

curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.15.4 zlib/1.2.7 libidn/1.28 libssh2/1.4.3

for a version with NSS.

Regards,

MValdez.

mariovaldez commented 9 years ago

Oh, I see this is caused by a change to explicitly specify a cipher for a broken version of libcurl with OpenSSL, right? But this causes not only the sanity check to fail when using curl+NSS, but all secure connections will fail.

As a side note, this affects Centos 6 and 7, RHEL 6 and 7, and Fedora 19 (at least).

timkay commented 9 years ago

Is there an easy way to tell which library is used by curl?

I am inclined to back off the RC4-SHA flag as causing more problems than it solves. Your thoughts?

mariovaldez commented 9 years ago

Parsing the result of "curl --version" is the only way I know (" NSS/" for NSS and " OpenSSL/" for OpenSSL, but I don't know what it will show if compiled with GnuTLS).

Regarding the use of the RC4-SHA for the cipher parameter, the original curl bug (1340, duplicate of 1329) was considered invalid because it happened only for some servers which insisted on using insecure ciphers. The problem is commented in the following page (in the section titled "SSL ciphers"): https://github.com/bagder/curl/blob/master/docs/SSL-PROBLEMS explaining that current versions of curl have some insecure ciphers disabled by default.

If this happens with Amazon servers, then the only option is to try to detect the SSL library used and set the ciphers parameter. But if Amazon servers today don't have this problem, I think the cipher parameter is not necessary.

I have compiled curl 7.40.0 with OpenSSL and tested with the S3 test URL, getting:

./curl-7.40.0/src/curl -q -s --include https://connection.s3.amazonaws.com/test
....
aws sanity-check succeeded!

If I get the SSL information:

./curl-7.40.0/src/curl -v --include https://connection.s3.amazonaws.com/test
...
* SSL connection using TLSv1.1 / ECDHE-RSA-AES128-SHA
...
aws sanity-check succeeded!

So, the test Amazon test URL seems to work fine with the latest version of curl (which have disabled the same ciphers than the one reported in the curl bug report).

timkay commented 9 years ago

Mario, I backed off the RC4-SHA default. Thanks for your great help!