Date: Tue, 1 Mar 2016 17:31:50 -0700 From: Kurt Seifried <kseifried@...hat.com> To: Bob Beck <beck@...nbsd.org> Cc: oss-security <oss-security@...ts.openwall.com>, CVE ID Requests <cve-assign@...re.org> Subject: Re: Re: CVE's for SSLv2 support On Tue, Mar 1, 2016 at 2:23 PM, Bob Beck <beck@...nbsd.org> wrote: > On Tue, Mar 1, 2016 at 12:12 PM, <cve-assign@...re.org> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > 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. > > > What.. like... I have an embedded high value device that only supports > TELNET to access it.. OMG please give me a CVE? > > replace SSLV2 in the above sentence with telnet or ssh v1 for that > matter and you have the same issue. > That is a perfect example actually. Telnet makes no security claims, explicit, implied or otherwise. It's a simple clear text protocol. In fact if you want to secure it you can use SSL enabled Telnet (in fact I remember fighting with it prior to the wide spread existence of SSH and then OpenSSH). SSL and TLS both makes explicit and implicit claims about security, most notably at a minimum: 1) the SSL/TLS protocols encrypt the and the data cannot be read by an attacker 2) the SSL/TLS protocols ensure the data is not altered in transit by an attacker without detection Additionally depending on how you configure the servers there are claims that you are talking to the correct server/client (e.g. using certificates) but that is not germane to this discussion. SSLv2 is obviously NOT capable of ensuring claim #1 (that data is encrypted and cannot be read by an attacker), due to a wide variety of issues, and I have no doubt more will be found if people keep looking. Hence my thinking is that ANY and ALL use of SSLv2 is CVE worthy, especially when considering that many devices/manufacturers are less than transparent about their configurations/security issues. -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert@...hat.com
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ