Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Mar 2016 20:59:39 +0300
From: gremlin@...mlin.ru
To: oss-security@...ts.openwall.com
Subject: Re: CVE's for SSLv2 support

On 2016-03-01 10:33:17 -0700, Kurt Seifried wrote:

 > https://tools.ietf.org/html/rfc6176
 > TL;DR: SSLv2 needs to be shot.

Yes, with SSLv3 and TLS 1.0 being the next.

 > Now we have yet another significant SSLv2 problem, DROWN, bad
 > enough in fact that Red Hat has now disabled SSLv2 in OpenSSL
 > by default (already done in NSS/GnuTLS), so from my vendor
 > perspective, we're treating SSLv2 support as a security problem,
 > the solution of which is to remove said support.

The problem is more wide, as it's in the use of insecure algorithms.

 > But more generally, should we look at assigning CVE's for
 > support of SSLv2, much like we would for products supporting
 > DES or other known insecure cryptographic algorithms, hashes,
 > digests and protocols? My personal vote is for yes.

Yes. Including, but not limited to:
1. RSA keys of less than 4096 bits (a minimum of 8192 should be
recommended).
2. Non-EC discrete logarithm based algos (DSA, old GOST 34.10-94).
2. EC-based algos with keys of less than 256 bits (as for me, I'd
consider 1024 bits to be an absolute minimum: chips are cheap, but
the energy is still expensive).
3. Symmetric ciphers in any mode other than CFB or counter-based.
4. Symmetric ciphers with key size of less than 256 bits.
5. Hash functions of less than 256 bits.


-- 
Alexey V. Vissarionov aka Gremlin from Kremlin
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ