cURL / Mailing Lists / curl-library / Single Mail


GnuTLS improvements [Re: weak cipher suites with OpenSSL, SecureTransport and... ?]

From: Fabian Frank <>
Date: Sun, 19 Jan 2014 00:59:41 -0800

On Jan 9, 2014, at 2:34 PM, Daniel Stenberg <> wrote:

> Left to do is then to build curl with other TLS backends and try it against to see if there are more flaws in this style.

GnuTLS has one bad cipher:
$ ./src/curl -k ''
gtls connect 1
{"given_cipher_suites":[SNIP],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{"TLS_DHE_DSS_WITH_RC4_128_SHA":["uses keys smaller than 128 bits in its encryption"]},"tls_version":"TLS 1.2","rating":"Bad}

After looking at the existing code, Ive found five problems in total:
 * the code does not prohibit usage of the insecure RC4 cipher (also seen in response above)
 * only the --sslv3 command line switch is honored, but not tlsv1, tlsv10, tlsv11 and tlsv12 (they were silently ignored)
 * the code only requests a desired cipher list if gnutls_priority_set_direct() is available and --sslv3 is requested
 * there is code to maintain compatibility between GnuTLS versions, but it has several inconsistencies:
  - cipher selection does not happen for older GnuTLS versions
  - certificate type selection does not happen for newer GnuTLS versions

The attached patch addresses all four issues and requests consistent settings both for newer and older GnuTLS versions. I also think it makes the code easier to understand, by combining the close-by but different ifdefs into one ifdef. Feedback is greatly appreciated and Im happy to send an updated version of the patch if necessary.

Even after this patch, cURL still does not honor --ciphers when running with GnuTLS. Id like to keep this out of the scope for this patch.


List admin:

Received on 2014-01-19