Hello, Eric Christensen proposed removed SSL 3.0 from the DEFAULT crypto policy in F21, due to the POODLE attack. I experimented a bit, and noticed (again) that openssl cannot set the supported versions via a cipher string, and since NSS is still work in progress, it would actually mean that this setting would only apply to gnutls. Also Tomas Mraz noticed quite few mail clients that still use SSL 3.0 only, meaning SSL 3.0 is not completely dead yet and may cause compatibility issues for Fedora servers that use these strings.
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
regards, Nikos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, Nov 19, 2014 at 03:58:36PM +0100, Nikos Mavrogiannopoulos wrote:
Hello, Eric Christensen proposed removing SSL 3.0 from the DEFAULT crypto policy in F21, due to the POODLE attack. I experimented a bit, and noticed (again) that openssl cannot set the supported versions via a cipher string, and since NSS is still work in progress, it would actually mean that this setting would only apply to gnutls. Also Tomas Mraz noticed quite few mail clients that still use SSL 3.0 only, meaning SSL 3.0 is not completely dead yet and may cause compatibility issues for Fedora servers that use these strings.
You can't disable SSLv3 in OpenSSL why? AFAIK that functionality has been available for a while.
There are two parts to the POODLE vulnerability: SSLv3 being nearly broken and the downgrade attack. The downgrade attack, only valid on HTTP but we've also found the problem in Thunderbird, involves an attacker downgrading a connection to SSLv3 from TLS. SSLv3, itself, is now considered weak. With a few minor exceptions we've not found any current programs that only support SSLv3.
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
This year has seen every SSL/TLS implementation having some sort of spotlight on it. EVERY SINGLE ONE. From OpenSSL and NSS to whatever that Microsoft vulnerability was that was open for a couple of decades, there hasn't been an implementation that has remained safe. Security moves fast and crypto, as of recent times, has moved faster. Recommended settings from a month ago may not be safe settings tomorrow. Luckily with the release cycle of Fedora we can mostly keep up with the changes. I've been very impressed with the development teams from OpenSSL and Mozilla with their ability to roll out new settings for their products within days of these issues going public. SSLv3 is turned off my default in Firefox now. Red Hat has either disabled SSLv3 for their products or is working on doing so (for software we've identified) and we're working to do the same thing in Fedora to help protect users.
Bottom line, if you're still using SSLv3 it's LEGACY and shouldn't be DEFAULT.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Red Hat, Inc - Product Security
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Wed, 2014-11-19 at 11:19 -0500, Eric H. Christensen wrote:
On Wed, Nov 19, 2014 at 03:58:36PM +0100, Nikos Mavrogiannopoulos wrote:
Hello, Eric Christensen proposed removing SSL 3.0 from the DEFAULT crypto policy in F21, due to the POODLE attack. I experimented a bit, and noticed (again) that openssl cannot set the supported versions via a cipher string, and since NSS is still work in progress, it would actually mean that this setting would only apply to gnutls. Also Tomas Mraz noticed quite few mail clients that still use SSL 3.0 only, meaning SSL 3.0 is not completely dead yet and may cause compatibility issues for Fedora servers that use these strings.
You can't disable SSLv3 in OpenSSL why? AFAIK that functionality has been available for a while.
The only disable SSL 3.0 in openssl is via the SSL_OP_NO_SSLv3 flag which cannot be set via a cipher string, and that is the only factor crypto-policies can control.
A way to fix that is by adding a new cipher string for that. If no-one adds that, we plan to propose such a patch once our patches for custom cipher strings are accepted.
regards, Nikos
[0]. https://github.com/openssl/openssl/pull/192 https://github.com/openssl/openssl/pull/193
On 2014-11-19 09:58, Nikos Mavrogiannopoulos wrote:
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
In Mozilla's infrastructure, our recommendation is to disable SSLv3 by default everywhere, and only enable it when the service explicitly needs backward compatibility with very old clients.
In our guidelines, the default level 'intermediate' disables SSLv3. https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
We found that a small number of services need backward compatibility: * mozilla.org, because we still see traffic coming from Windows XP pre-sp3 * supporting sites of mozilla.org for the same reason * irc.mozilla.org, because of very old IRC clients
These follow the 'old' configuration guidelines, which enables SSLv3.
My experience is that no service needs SSLv3 by default. If a service needs SSLv3, operators should be able to detect it, and configure it. Having logs that indicate a handshake failure because the client did not support the required protocols is a great help to operators.
- Julien
On Wed, 2014-11-19 at 11:29 -0500, Julien Vehent wrote:
On 2014-11-19 09:58, Nikos Mavrogiannopoulos wrote:
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
In Mozilla's infrastructure, our recommendation is to disable SSLv3 by default everywhere, and only enable it when the service explicitly needs backward compatibility with very old clients.
I understand, but please read the rest of my mail. The issue here is that we cannot via system-wide crypto policies disable SSLv3 in NSS (not until [0] is included to NSS), and openssl as well because it provides no cipher string to achieve that goal. So the question is does it matter to disable SSLv3 from the global settings, if that would only affect gnutls tools, which is a minority in Fedora?
regards, Nikos
[0]. https://bugzilla.mozilla.org/show_bug.cgi?id=1009429
regards, Nikos
On Thursday 20 November 2014 09:46:00 Nikos Mavrogiannopoulos wrote:
On Wed, 2014-11-19 at 11:29 -0500, Julien Vehent wrote:
On 2014-11-19 09:58, Nikos Mavrogiannopoulos wrote:
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
In Mozilla's infrastructure, our recommendation is to disable SSLv3 by default everywhere, and only enable it when the service explicitly needs backward compatibility with very old clients.
I understand, but please read the rest of my mail. The issue here is that we cannot via system-wide crypto policies disable SSLv3 in NSS (not until [0] is included to NSS), and openssl as well because it provides no cipher string to achieve that goal. So the question is does it matter to disable SSLv3 from the global settings, if that would only affect gnutls tools, which is a minority in Fedora?
Aren't there other parts of the policies which are not enforced? I mean signature algorithms on certificates and in TLS1.2 (EC)DHE key exchange? Key sizes?
We probably should document which parts and with which libraries are actually enforced, but the actual policy should state the desired outcome (in this case: SSLv3 disabled).
On Thu, 2014-11-20 at 13:39 +0100, Hubert Kario wrote:
With that in mind, does it make sense to update the policies to remove SSL 3.0, or should we wait until F22?
In Mozilla's infrastructure, our recommendation is to disable SSLv3 by default everywhere, and only enable it when the service explicitly needs backward compatibility with very old clients.
I understand, but please read the rest of my mail. The issue here is that we cannot via system-wide crypto policies disable SSLv3 in NSS (not until [0] is included to NSS), and openssl as well because it provides no cipher string to achieve that goal. So the question is does it matter to disable SSLv3 from the global settings, if that would only affect gnutls tools, which is a minority in Fedora?
Aren't there other parts of the policies which are not enforced? I mean signature algorithms on certificates and in TLS1.2 (EC)DHE key exchange? Key sizes?
We probably should document which parts and with which libraries are actually enforced, but the actual policy should state the desired outcome (in this case: SSLv3 disabled).
I tend to agree, could you or Eric fill a bug report against crypto-policy. As we are pretty late on time it will have to be accepted as blocker.
regards, Nikos
security@lists.fedoraproject.org
-
Eric Christensen -
Hubert Kario -
Julien Vehent -
Nikos Mavrogiannopoulos