[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANO=Ty2FD92Oj-ebOJ=dJnO-+Y1zxNJNwW6HUR5mXH+8G64_ag@mail.gmail.com>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
