Hide Forgot
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:
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.
(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
That works, but why was this changed, since this wasn't needed in RHEL5?
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