http://tools.ietf.org/html/rfc5246 indicates that clients should negotiate SSL/TLS protocols from strongest down to weakest.

RHEL-7 (lib)curl does not enable TLS > 1.0 by default.  Please use the --tlsv1 option of curl to negotiate the highest TLS version supported by client/server.

(In reply to Kamil Dudka from comment #3)
> RHEL-7 (lib)curl does not enable TLS > 1.0 by default.  Please use the
> --tlsv1 option of curl to negotiate the highest TLS version supported by
> client/server.

I can see curl does not enable TLS > 1.0 by default, however the issue (as denoted by this bug) is that this is against the RFC, for how a client should act.

What is the justification for curl doing this?

(In reply to Eric Rich from comment #4)
> What is the justification for curl doing this?

Compatibility.  We prefer not to change the default behavior in Enterprise Linux while we allow applications to use new features if explicitly requested. This is not specific to libcurl.  NSS (the library used by libcurl to implement TLS) itself does not negotiate TLS > 1.0 by default.  Please refer to the following bugs for details:

    bug #1012136 comment #23

    bug #994599 comment #7

(In reply to Kamil Dudka from comment #5)
> (In reply to Eric Rich from comment #4)
> > What is the justification for curl doing this?
> 
> Compatibility.  We prefer not to change the default behavior in Enterprise
> Linux while we allow applications to use new features if explicitly
> requested. This is not specific to libcurl.  NSS (the library used by
> libcurl to implement TLS) itself does not negotiate TLS > 1.0 by default. 
> Please refer to the following bugs for details:

I have to argue for the customer on this one. The Protocol (not the RFC) is designed so that a negotiation is done when determining the protocol. 

So server who only allow or implement older protocols (SSLv3), can work with newer clients (or clients who support newer protocols).

In short the argument that bug #1012136 comment #23, and bug #994599 comment #7 makes is that a server admin is allowing a protocol on there server that is not 100% implemented or not properly implemented, so we should have clients use lower less secure protocols (unless they explicitly state to use something stronger). 

With this said defaulting to SSLv3 makes curl vulnerable to https://access.redhat.com/articles/1232123 so I am marking this a security bug.

(In reply to Eric Rich from comment #6)
> In short the argument that bug #1012136 comment #23, and bug #994599 comment
> #7 makes is that a server admin is allowing a protocol on there server that
> is not 100% implemented or not properly implemented, so we should have
> clients use lower less secure protocols (unless they explicitly state to use
> something stronger).

Not sure I understand your comment.  There are servers out there that you can connect with curl using the default configuration, but you cannot connect them with the --tlsv1 option.  Yes, this is caused by bugs in server implementations, not in RFCs.  Still customers expect curl to connect those servers after a minor update of RHEL.

> With this said defaulting to SSLv3 makes curl vulnerable to
> https://access.redhat.com/articles/1232123 so I am marking this a security
> bug.

Nope, curl does not default to SSLv3.  It enables both TLS 1.0 and SSL 3.0 by default.  See also bug #1154060.

(In reply to Kamil Dudka from comment #7)
> (In reply to Eric Rich from comment #6)
> Nope, curl does not default to SSLv3.  It enables both TLS 1.0 and SSL 3.0
> by default.  See also bug #1154060.

Then why do I see a protocol error (on SSLv3) when I run the command: 

    curl -IL https://$(hostname) -v

If TLS 1.0 is enabled, curl should prefer it over SSLv3 as the httpd server configuration is presenting TLSv1.[0|1|2] protocols. 

This is the argument for a bug in curl. If curl enables both TLS 1.0 and SSL 3.0 this error would not occur, because the RFC (for TLS) would have been followed and curl would have negotiated a TLSv1 connection over the SSLv3 connection (that is disabled/not presented on the server). 

bug #1154060 can not be possible if bug #1012136 comment #23, and bug #994599 comment #7 comments stand as these bugs state the curl should only be defaulting to SSLv3. Simply having an option to force a higher protocol is ensuring the curl negotiates the strongest protocol.

Based on my review of these bugs it seems that the messaging and direction on what should be done to resolve this is not clear. The argument our customer(s) is/are making is that our client tools are not following the RFC - or the specification for how tools should operate, and that this should be addressed.

(In reply to Eric Rich from comment #8)
> If TLS 1.0 is enabled, curl should prefer it over SSLv3 as the httpd server
> configuration is presenting TLSv1.[0|1|2] protocols. 

RHEL-7 curl sends TLSv1 Client Hello by default.  You can check it by wireshark.

> This is the argument for a bug in curl. If curl enables both TLS 1.0 and SSL
> 3.0 this error would not occur, because the RFC (for TLS) would have been
> followed and curl would have negotiated a TLSv1 connection over the SSLv3
> connection (that is disabled/not presented on the server).

Could you please expose your testing server for me to repeat the bug?

> bug #1154060 can not be possible if bug #1012136 comment #23, and bug
> #994599 comment #7 comments stand as these bugs state the curl should only
> be defaulting to SSLv3. Simply having an option to force a higher protocol
> is ensuring the curl negotiates the strongest protocol.

There must be some misunderstanding.  None of the above bugs says anything about curl defaulting to SSLv3.  Bug #1154060 asks for disabling an out-of-protocol _fallback_ to SSLv3, which is exactly what happens in your case -- see the messages "Error in TLS handshake, trying SSLv3..." and "TLS disabled due to previous handshake failure" in the verbose output of curl (comment #0).

> Based on my review of these bugs it seems that the messaging and direction
> on what should be done to resolve this is not clear. The argument our
> customer(s) is/are making is that our client tools are not following the RFC
> - or the specification for how tools should operate, and that this should be
> addressed.

I believe that curl (without additional options) is compliant with the TLS 1.0 specification.  The implementation of TLS 1.2 came after RHEL-7 GA, thus needs to be explicitly enabled by the application.

Thank you for granting me the access to your testing server!  I believe it is just a mistake in the configuration of Apache what prevents curl from connecting without --tlsv1 (or --tlsv1.2).

You need to replace the line:

    SSLProtocol TLSv1 TLSv1.1 TLSv1.2

... by the line:

    SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

... in your /etc/httpd/conf.d/ssl.conf and restart the httpd service.

(In reply to Kamil Dudka from comment #13)
> Thank you for granting me the access to your testing server!  I believe it
> is just a mistake in the configuration of Apache what prevents curl from
> connecting without --tlsv1 (or --tlsv1.2).
> 
> You need to replace the line:
> 
>     SSLProtocol TLSv1 TLSv1.1 TLSv1.2
> 
> ... by the line:
> 
>     SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
> 
> ... in your /etc/httpd/conf.d/ssl.conf and restart the httpd service.

It seems you are correct!

re-opening this as switching the protocol's on the server size in this way helps fix the issue as httpd can now offer any of the TLS protocol version and curl can then (as a client) select TLSv1.0. 

However if I make the following change: 

    SSLProtocol +TLSv1.2

curl still give me the same error (as before). Again caused because the client is defaulting to only TLSv1 or SSLv3 as the strongest protocol it supports. 

The same configuration on RHEL 6 works. IE: curl can connect to a server only presenting at TLSv1.2 connection (with out the -1 flag).

(In reply to Eric Rich from comment #15)
> re-opening this as switching the protocol's on the server size in this way
> helps fix the issue as httpd can now offer any of the TLS protocol version
> and curl can then (as a client) select TLSv1.0. 
> 
> However if I make the following change: 
> 
>     SSLProtocol +TLSv1.2

Not a change really.  It is exactly what Apache read from your original configuration (stated in comment #0), isn't it?

> curl still give me the same error (as before). Again caused because the
> client is defaulting to only TLSv1 or SSLv3 as the strongest protocol it
> supports.

... which is the expected default behavior.  We are not going to change the default behavior in RHEL-7 (unless Security Response insists on the change).

> The same configuration on RHEL 6 works. IE: curl can connect to a server
> only presenting at TLSv1.2 connection (with out the -1 flag).

This is not supposed to work.  Please file a separate bug report against RHEL-6 with the precise NVR of libcurl and nss* packages, and steps to reproduce.

(In reply to Kamil Dudka from comment #16)
> Not a change really.  It is exactly what Apache read from your original
> configuration (stated in comment #0), isn't it?

Yes this is fundamentaly what I had in comment #0 because httpd does:

> In: httpd/modules/ssl/ssl_engine_config.c:

> 1338        if (action == '-') {
> 1339            *options &= ~thisopt;
> 1340        }
> 1341        else if (action == '+') {
> 1342            *options |= thisopt;
> 1343        }
> 1344        else {
> 1345            *options = thisopt;
> 1346        }

So it picks the last item in the list. 
 
> ... which is the expected default behavior.  We are not going to change the
> default behavior in RHEL-7 (unless Security Response insists on the change).

So it is expected that curl does not follow the RFC for negotiating the protocol from highest to lowest.
 
> This is not supposed to work.  Please file a separate bug report against
> RHEL-6 with the precise NVR of libcurl and nss* packages, and steps to
> reproduce.

Steps are the same as those listed here, however why would I file a bug for a RHEL product that is following the RFC as it should?

(In reply to Eric Rich from comment #17)
> So it is expected that curl does not follow the RFC for negotiating the
> protocol from highest to lowest.

RHEL-7 libcurl does follow RFC but not necessarily the latest one.

> Steps are the same as those listed here, however why would I file a bug for
> a RHEL product that is following the RFC as it should?

It would be an unintended change in behavior, which we normally avoid in RHEL.  Anyway, you have not shown us yet that your statement about RHEL-6 is correct.

(In reply to Kamil Dudka from comment #18)

> RHEL-7 libcurl does follow RFC but not necessarily the latest one.

So RHEL-7 libcurl follows the TLSv1 RFC but not the TLSv1.2 RFC, is this what you are saying? 

> It would be an unintended change in behavior, which we normally avoid in
> RHEL.  Anyway, you have not shown us yet that your statement about RHEL-6 is
> correct.

It seems my testing on RHEL6 was a bit flawed, as I tried on a fresh system today and curl on RHEL 6 only  negotiations on protocols from TLSv1 down to SSLv2 
   - Note: [which v2 and v3 are often disabled] leaving you with only TLSv1

The same behavior is what we are seeing on RHEL 7. However where curl on RHEL 7 differs its that it allows for TLSv1.1 and TLSv1.2 connections to be specified on the command line (RHEL 6 does not - from what I can tell). 

As this is the case I will move this to an RFE for RHEL 7 libcurl to follow the latest protocol versions RFC.

*** Bug 1183171 has been marked as a duplicate of this bug. ***

This bug makes it so that admins can't set up an https yum repo that disables SSL protocols worse than TLS 1.2, which might be required for security. This is because yum uses libcurl and there's no way to pass the --tlsv1 option through yum.

------- Comment From edmondsw.com 2015-04-07 13:49 EDT-------
bug # 1171318 doesn't appear to be public, but if that's for nss not using TLS 1.2 by default then it definitely needs to be fixed. TLS 1.0 should no longer be considered secure (e.g. BEAST if you use CBC ciphers, Bar Mitzvah if you use RC4) and will be disabled by more and more servers.

Hello Red Hat / Kamil,
... can you please provide your thoughts about comment #28 and comment #29 
in this Red Hat bugzilla ..?
As outlined we think that the required usage of TLS 1.2 will become more and more mandatory (e.g. also for FIPS 140-2 compliance ...)
and therefore please provide your thoughts how this issue can be resolved
as soon as possible 
and whether you think that this issue could also be resolved with an RHN update
earlier than RHEL7.2 ..? 
Please advise as soon as possible ...
Thanks in advance for your support.

(In reply to Hanns-Joachim Uhl from comment #31)
> Hello Red Hat / Kamil,
> ... can you please provide your thoughts about comment #28

I believe that globally switching the default TLS version of curl/nss is not the only way to make yum speak TLS 1.2.  We can either introduce a yum option to enable TLS 1.2, or introduce another way to enable it explicitly.  The first option would probably imply update of the python-pycurl and python-urlgrabber packages.  The second option could be a documented environment variable or a configuration file somewhere on the file system.

Note that I am speaking purely about technical matters of the issue.  However, I am not the one to decide which approach will be taken in the end.

> and comment #29 in this Red Hat bugzilla ..?

See CVE-2011-3389 and CVE-2015-2808 for details.

> As outlined we think that the required usage of TLS 1.2 will become more and
> more mandatory (e.g. also for FIPS 140-2 compliance ...)
> and therefore please provide your thoughts how this issue can be resolved
> as soon as possible 
> and whether you think that this issue could also be resolved with an RHN
> update earlier than RHEL7.2 ..?

Switching the default in RHEL-7.2 is currently being evaluated by Product Management.  From engineering point of view, switching the default would be a tiny patch but there is a high risk of regression the patch could introduce.  In my personal opinion, switching the default TLS version before RHEL-7.2 is very unlikely to happen.

------- Comment From edmondsw.com 2015-04-10 15:12 EDT-------
Kamil, there isn't a single default, is there? I was expecting curl/nss would simply add TLS to a list of what is used by default (e.g. try TLS 1.2 first, then TLS 1.1...). I don't think we're suggesting you make TLS 1.2 the one and only default. If you just add it to the list, how would that involve a high risk of regression?

It has already been said privately, so reposting here for public...

The problem are so-called TLS intolerant servers.  If a client tells it supports TLS 1.2, the server simply closes the connection with no response about what TLS versions it supports.  You can read some details e.g. here:

http://blog.nexcess.net/2014/04/04/tls-1-2-and-openssl-1-0-1e-frequently-asked-questions/
http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx
http://www.ietf.org/mail-archive/web/tls/current/msg10657.html

There might be applications out there that use libcurl to securely communicate with such servers using TLS 1.0.  If we change the default to use TLS 1.2, those application will stop working after update of libcurl.

When I wrote http://blog.nexcess.net/2014/04/04/tls-1-2-and-openssl-1-0-1e-frequently-asked-questions/ , we had two clients who were having issues with two different API providers. A third client had problems, but it was with the same API provider as one of the first two clients. The blog posting was written as an explanation for any future problems we might see so we can refer clients or API providers to it for an explanation.

The two API providers that were having problems were both because the ClientHello was > 255 bytes due to openssl 1.0.1e adding a bunch more ciphers to its list. One API provider confirmed the problem was with their F5 BigIP device (https://www.imperialviolet.org/2013/10/07/f5update.html) and updated it. The other API provider confirmed the problem was on their end, but provided no technical details. The API provider that provided no technical details was also intolerant to TLSv1.2 which was incorrectly attributed as part of the problem, since we didn't realize libcurl was making TLSv1.0 connections at the time (we were debugging using 'openssl s_client' on the command line). Both API providers have resolved the issues.

The problem we're now seeing is the one Hanns-Joachim Uhl described in comment #31, some API providers are disabling TLSv1.0 and only supporting TLSv1.1 and TLSv1.2. Previously we could point out that the API providers weren't following the TLS RFC and they'd fix the problem on their end. Now the API providers point out to us that we're not following the TLS RFC and we have to fix it on our end.

In Ivan Ristic's 2013 message (https://www.ietf.org/mail-archive/web/tls/current/msg10657.html) 0.9% of servers he tested were intolerant to TLSv1.2. I'd guess that is even lower now given most people have had to update openssl and/or re-examine how they have TLS set up with heartbleed and the other recent CVEs. I think for the tiny minority of servers out there that are still TLS intolerant, the burden should be placed on them to follow the RFC rather than RHEL forcing use of an older version of TLS unless an application has been modified to request a newer version.

curl-7.29.0-19.el7.x86_64
curl-7.37.0-13.fc21.x86_64

This problem is becoming far more common, affecting all of the newer sites issued served by Cloudflare SSL.  Both RHEL7 and Fedora 21 curl are affected.

# curl -v https://sslspdy.com
* About to connect() to sslspdy.com port 443 (#0)
*   Trying 192.184.89.66...
* Connected to sslspdy.com (192.184.89.66) 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: sslspdy.com
> Accept: */*
> 
* Connection died, retrying a fresh connect
* Closing connection 0
* Issue another request to this URL: 'https://sslspdy.com'
* About to connect() to sslspdy.com port 443 (#1)
*   Trying 192.184.89.66...
* Connected to sslspdy.com (192.184.89.66) 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).

curl-7.29.0-19.el7.x86_64
curl-7.37.0-13.fc21.x86_64

Workaround:
# curl -v --ciphers ecdhe_ecdsa_aes_128_sha https://sslspdy.com

Warren,

The problem you're describing is a different problem caused when a site has an ECC SSL certificate, see bug #1185708 . The bug is for Fedora but RHEL has the same problem.

------- Comment From chavez.com 2015-10-16 16:01 EDT-------
I finally found someone with a RHEL 7.2 setup. It does look like this is resolved there. :)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-2159.html

*** Bug 1314162 has been marked as a duplicate of this bug. ***