[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Mar 2016 21:16:05 -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 9:03 PM, Bob Beck <beck@...nbsd.org> wrote:
> > 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
>
> When used correctly.. SSLv2 is not.
> >
> > 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.
>
> While you certainly won't see me defending SSLv2 (I think we were the
> first to delete it outright)
> there are many other things that currently fall into that category..
> I'm agreeing with your sentiment
> but if you are to consider usage of SSLv2 as CVE worthy, then you will
> need to do the same for SSH version 1,
> among other things. So while I certainly appreciate and even agree
> with your sentiment, it seems rather timed
> politically based on a decision made by one implementaiton of SSL/TLS
> that reflects a decision made by most other
> implementations long ago. So far from me to say what CVE's should
> and shouldn't be used for and issued for, but
> if this is the road we're going down can I please have permission to
> use your above quoted paragraph
> with s/SSLv2/SSH V1/g to request a CVE for *usage or support* of SSH
> version 1? You said it perfectly.
>
I would be totally fine with that, SSH protocol v1 is long overdue for
"needs to be taken out back and shot along with whoever enabled it by
default". From OpenSSH's sshd_config:
# The default requires explicit activation of protocol 1
I think that says it all.
--
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.
