Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Mar 2016 12:25:24 -0700
From: Kurt Seifried <>
To: CVE ID Requests <>
Cc: oss-security <>
Subject: Re: CVE's for SSLv2 support

On Tue, Mar 1, 2016 at 12:12 PM, <> wrote:

> Hash: SHA256
> > If a crypto library (e.g. OpenSSL, NSS) supports AND enables SSLv2 by
> > default should it receive a CVE?
> There's no general answer to that question. CVE ID assignments are not
> based on outsiders making guesses about the expectations of a product's
> customers. For example, there might be a crypto library intended for
> communication on isolated networks to high-value embedded devices that
> support only SSLv2, and cannot and will not ever be updated.
I guess my confusion is: what would be the downside to assigning a CVE in
such a case, such a "false positive" would be easily explained ("yes we
support SSLv2, but only for use on closed network"[1]) but more to the
point by drawing a line in the sand of "SSLv2 is worth a CVE" we'd be much
more easily able to track which products are using SSLv2 by default (and
thus putting us at risk). From your web page "CVE is a dictionary of
publicly known information security vulnerabilities and exposures."

Does SSLv2 not pretty much exactly fit this definition now?

[1] which begs the question why they're even using SSLv2 but I digress =)


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact:

Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.