Bug 807749 - curl doesn't work with RC4-SHA over SSL
curl doesn't work with RC4-SHA over SSL
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: curl (Show other bugs)
6.2
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Kamil Dudka
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-28 11:33 EDT by Strahinja Kustudic
Modified: 2012-03-31 15:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-31 15:41:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Strahinja Kustudic 2012-03-28 11:33:18 EDT
Description of problem:
curl doesn't work with a SSL connection which are using RC4-SHA as the cypher.

Version-Release number of selected component (if applicable):
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

How reproducible:
Always

Steps to Reproduce:
Run command:
curl -v https://api2.boku.com/billing/request
  
Actual results:
* About to connect() to api2.boku.com port 443 (#0)
* Trying 98.129.210.123... connected
* Connected to api2.boku.com (98.129.210.123) port 443 (#0)
* Initializing NSS with certpath: /etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Error in TLS handshake, trying SSLv3...
> GET /billing/request HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-unknown-linux-gnu) libcurl/7.19.7 NSS/3.12.7.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: api2.boku.com
> Accept: */*
>
* Connection died, retrying a fresh connect
* Closing connection #0
* Issue another request to this URL: 'https://api2.boku.com/billing/request' [^]
* About to connect() to api2.boku.com port 443 (#0)
* Trying 98.129.210.123... connected
* Connected to api2.boku.com (98.129.210.123) port 443 (#0)
* TLS disabled due to previous handshake failure
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error


Expected results:
Running this same command on RHEL5 works:
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
* Server certificate:
* subject: /O=*.boku.com/OU=Domain Control Validated/CN=*.boku.com
* start date: 2011-02-17 20:44:08 GMT
* expire date: 2014-02-17 20:44:08 GMT
* subjectAltName: api2.boku.com matched
* issuer: /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go [^] Daddy Secure Certification Authority/serialNumber=07969287
* SSL certificate verify ok.
> GET /billing/request HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: api2.boku.com
> Accept: */*
>
< HTTP/1.0 200 OK
< Content-Type: text/xml; charset=utf-8
< Cache-Control: max-age=1
< Content-Length: 161
< Server: Jetty(6.1.18)
< X-Cache: MISS from http01.local-paymo.net
< X-Cache-Lookup: MISS from http01.local-paymo.net:80
< Via: 1.0 http01.local-paymo.net:80 (squid/2.6.STABLE21)
< Connection: close
<?xml version='1.0' encoding='UTF-8' ?>
<billing-request>
    <result-code>32</result-code>
    <result-msg>Bad Bind Credentials</result-msg>
</billing-request>
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

Additional info:
Comment 2 Strahinja Kustudic 2012-03-29 07:59:37 EDT
From the changes in https://rhn.redhat.com/errata/RHBA-2012-0430.html I was hoping this would be fixed, but it's not. The exact same result like before.
Comment 3 Kamil Dudka 2012-03-30 15:52:01 EDT
(In reply to comment #0)
> curl doesn't work with a SSL connection which are using RC4-SHA as the cypher.

They are not enabled by default.  You can override it by the --cipher option:

curl --cipher rsa_rc4_128_sha https://api2.boku.com/billing/request
Comment 4 Strahinja Kustudic 2012-03-31 07:43:10 EDT
That works, but why was this changed, since this wasn't needed in RHEL5?
Comment 5 Kamil Dudka 2012-03-31 15:41:21 EDT
The default set of enabled cipher suites is configured to conform with current U.S. export regulations related to software products with encryption features.

http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1098841

Note You need to log in before you can comment on or make changes to this bug.