Re: [Nolug] SSL bug

From: Jerry Wilborn <jerrywilborn_at_gmail.com>
Date: Wed, 9 Apr 2014 19:33:29 -0500
Message-ID: <CAK2QZfQGdruUXVvnTZ042WweuvmcZxDg9hXsHOEXeKZDgsi-vg@mail.gmail.com>

Theo has some very pointed thoughts on this subject:
http://article.gmane.org/gmane.os.openbsd.misc/211963 Specifically "OpenSSL
is not developed by a responsible team."

Reminds me of the old bind and sendmail exploit days.

The guy who discovered the bug (
http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3)
says "Heap allocation patterns make private key exposure unlikely for
#heartbleed #dontpanic."
https://twitter.com/neelmehta/statuses/453625474879471616

Jerry Wilborn
jerrywilborn@gmail.com

On Wed, Apr 9, 2014 at 2:21 PM, John Souvestre <johns@sstar.com> wrote:

> P.S.
>
>
>
> An interesting note I just read:
>
>
>
> >>> However, if you are using certificates (wildcard certificates,
> certificates with alternative names) on your [safe, non-affected] server
> that are shared with other software (e.g. apache web servers) that might be
> using buggy OpenSSL versions, the private key could potentially have been
> leaked by that other software. In that case, it's better to consider
> re-generating the private key and obtaining a new certificate.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* owner-nolug@stoney.kellynet.org [mailto:
> owner-nolug@stoney.kellynet.org] *On Behalf Of *John Souvestre
> *Sent:* Wed, April 09, 2014 2:17 pm
>
> *To:* nolug@nolug.org
> *Subject:* RE: [Nolug] SSL bug
>
>
>
> Sorry, I sent that too quickly…
>
>
>
> I meant to add: The CA cert itself wouldn’t be compromised but from what
> I gather some of the CA’s are considering invalidating their certs as a
> practical solution. This will server to protect all those depending on
> that CA cert (including those who didn’t have the OpenSSL flaw), will help
> to keep the cert reject list small, and allow admins to remove it on user
> machines which would help protect applications which don’t validate the
> cert chain fully.
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* John Souvestre [mailto:johns@sstar.com <johns@sstar.com>]
> *Sent:* Wed, April 09, 2014 2:12 pm
> *To:* 'nolug@nolug.org'
> *Subject:* RE: [Nolug] SSL bug
>
>
>
> Ø So no current public CA that claims to be following the security
> standards, could have a CA certificate compromised, unless they were
> quite negligent.
>
>
>
> I believe you are incorrect about this.
>
>
>
> https://www.schneier.com/blog/archives/2014/04/heartbleed.html
>
>
>
>
>
> John
>
> John Souvestre - New Orleans LA
>
>
>
> *From:* owner-nolug@stoney.kellynet.org [
> mailto:owner-nolug@stoney.kellynet.org <owner-nolug@stoney.kellynet.org>] *On
> Behalf Of *Jimmy Hess
> *Sent:* Wed, April 09, 2014 8:37 am
> *To:* nolug@nolug.org
> *Subject:* Re: [Nolug] SSL bug
>
>
>
> On Wed, Apr 9, 2014 at 8:00 AM, Joey Kelly <joey@joeykelly.net> wrote:
>
> On 04/09/2014 04:27 AM, Ron Johnson wrote:
> > Do CA certificates need to be recreated?
>
>
>
> It is impossible without having violated basic Crypto 101 key hygene
> rules.
>
> So no current public CA that claims to be following the security
> standards, could have a CA certificate compromised, unless they were
> quite negligent.
>
>
>
> Should never issue certificates that have a Policy definition/Extended key
> usage allowing the certificate to be used for both Key agreement/Data
> encipherment AND for Certificate signing (or CRL Signing).
>
>
>
> CA signing keys should never be loaded onto a webserver.
>
> Always sign a separate certificate that has a different key from the
> certificate signing key.
>
>
>
>
>
>
>
>
>
>
>
>
>
> If you created them with a vulnerable OpenSSL version, then yes. I've
> got one to redo myself.
>
>
>
> --
> Joey Kelly
> Minister of the Gospel and Linux Consultant
> http://joeykelly.net
> 504-239-6550
>
> ___________________
> Nolug mailing list
> nolug@nolug.org
>
>
>
>
>
> --
> -Mysid
>

___________________
Nolug mailing list
nolug@nolug.org
Received on 04/09/14

This archive was generated by hypermail 2.2.0 : 04/15/14 EDT