8:58 a.m.
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
10:19 a.m.
-----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(a)redhat.com - sparks(a)fedoraproject.org
097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBCgAGBQJUbMMGAAoJEB/kgVGp2CYvq0gL/R+wiH4eXa9tT2MdoGlP3+sc
MUqYJTCAxTKQQhO00X9Ql2twGMuvOwr8rSaZ7D1jqLe272YnkiGHF693J/E6uzpo
BVl0IBFWhLSQ/zztOJ1dMAdpqsC/3A/RLM94JzrP7C7fK8690peYJRNAA+o0nn17
GbB2B5QmOUKg3GnJ155MyBryXNYkJYTwSfQQahm3UMaZgHQfLrBEF3e7PedcFk22
EmYMuSuvUZrS/rcWQMCox17V701XM2t0s6I1ZVbcKMIv34cVYp74tGyFE9iNq5KD
1sqVOv1HF43Nr3z470Vi787ihSEeVziC2TG+bsEPDVto9XFAHoOiOFQ4gv77bhQF
EgIez/UYhXGtnMnhXSyQep5jbv3aDNcSp/0OLY8ugoc+W488ovf/f5GCbingEIb9
7kVM1Px6LusfAmNhhBzz0oOEPbJK4GABKgB/hxNZYWGnd4IlL6/vsrNJP/wpxr/0
NENI63UgqlNAp4sn8tRPKMv+DWnNbGomkQRJdeJ21g==
=mpip
-----END PGP SIGNATURE-----
2:54 a.m.
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
10:29 a.m.
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
2:46 a.m.
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
6:39 a.m.
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).
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
7:11 a.m.
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
3442
days inactive
3443
days old
security@lists.fedoraproject.org
7 comments
4 participants
participants (4)
-
Eric Christensen -
Hubert Kario -
Julien Vehent -
Nikos Mavrogiannopoulos