> Recommendation: protect the rest of the private key material.
Yes, we missed some important fields.
"Dang" is a word that comes to mind. At least, one I can use in polite company.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
On Sat, Apr 12, 2014 at 09:02:50PM -0400, Salz, Rich wrote:
> > Would you please elaborate on how it differs from what you've been
> > using in production?
>
> Local platform issues, mainly. Conceptually, nothing different about
> the security.
>
Hello Rich et al.
I believe Akamai's secure mal
> Would you please elaborate on how it differs from what you've been using in
> production?
Local platform issues, mainly. Conceptually, nothing different about the
security.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
[From: openssl-users]
On Fri, Apr 11, 2014, Salz, Rich wrote:
> This patch is a variant of what we've been using to help protect
> customer keys for a decade.
Would you please elaborate on how it differs from what you've been using
in production?
> OpenSSL is important to us, and this is the fi
> It would be appreciated if you cared to contribute back your own custom
> secure_malloc allocator.
We did. See
http://marc.info/?l=openssl-users&m=139723710923076&w=2
and
http://marc.info/?l=openssl-users&m=139723972124003&w=2
--
Principal Security Engineer
Akamai Technology
Cambri
On Fri, Apr 11, 2014 at 05:51:17PM -0500, Reini Urban wrote:
> On 04/11/2014 04:13 PM, Carlos Alberto Lopez Perez wrote:
> >Probably this blog post provides more information about what Akamai has
> >been doing related to this issue:
> >
> >https://blogs.akamai.com/2014/04/heartbleed-update.html
>
On 04/11/2014 04:13 PM, Carlos Alberto Lopez Perez wrote:
Probably this blog post provides more information about what Akamai has
been doing related to this issue:
https://blogs.akamai.com/2014/04/heartbleed-update.html
It would be appreciated if you cared to contribute back your own custom
sec
On 10/04/14 18:46, Salz, Rich wrote:
> We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our only complaint
> is that the BUF is misspelled :)
>
> Theo can be obnoxious. This should not be news to most folks.
>
> /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Ca
On Fri, Apr 11, 2014 at 5:17 AM, Salz, Rich wrote:
> Karma has a sense of humor.
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile?f=h;rev=1.29
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile.diff?r1=1.29;r2=1.30;f=h
>
> Two people reviewed the c
Karma has a sense of humor.
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile?f=h;rev=1.29
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/ssl/Makefile.diff?r1=1.29;r2=1.30;f=h
Two people reviewed the change (the ok line) and they got the -D flag wrong for
nearly an
Hey,
> His patch was not against -current.
>
> http://elandsys.com/~logan/openssl_fix.diff
>
> Please find it here:
>
> diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
> index b9e45c7..61b017f 100644
> --- a/ssl/s3_pkt.c
> +++ b/ssl/s3_pkt.c
> @@ -1334,8 +1334,6 @@ start:
> {
> s->rstate=SSL_ST_READ_
> Read what Ted wrote. There's is a use after free if you
> -DOPENSSL_NO_BUF_FREELISTS It would have been spotted by OpenBSD's malloc.
I was commenting on Theo, not Ted.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
On Thu, Apr 10, 2014 at 12:46:23PM -0400, Salz, Rich wrote:
> We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our only complaint
> is that the BUF is misspelled :)
>
> Theo can be obnoxious. This should not be news to most folks.
Read what Ted wrote. There's is a use after free if yo
On Thu, Apr 10, 2014 at 9:08 PM, Viktor Dukhovni
wrote:
> On Thu, Apr 10, 2014 at 12:46:23PM -0400, Salz, Rich wrote:
>
>> We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our
>> only complaint is that the BUF is misspelled :)
>
> Apparently, this introduces a problem when free() actually
On Thu, Apr 10, 2014 at 12:46:23PM -0400, Salz, Rich wrote:
> We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our
> only complaint is that the BUF is misspelled :)
Apparently, this introduces a problem when free() actually wipes
freed memory, rather than just putting it on the free list
On Thu, Apr 10, 2014 at 8:46 PM, Salz, Rich wrote:
> We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our only complaint
> is that the BUF is misspelled :)
>
> Theo can be obnoxious. This should not be news to most folks.
>
> /r$
It appears that my previous mail got stuck somew
We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our only complaint is
that the BUF is misspelled :)
Theo can be obnoxious. This should not be news to most folks.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
On Thu, 10 Apr 2014 17:49:52 +0200
Carlos Alberto Lopez Perez wrote:
> What's the stance of openssl developers on this? Will you get rid of
> this wrapper?
What would make even more sense: Build openssl with a safe malloc
implementation.
I've no idea how practical this is, but there's something
On Thu, Apr 10, 2014 at 7:49 PM, Carlos Alberto Lopez Perez
wrote:
> ""OpenSSL has exploit mitigation countermeasures to make sure its
> exploitable"" http://article.gmane.org/gmane.os.openbsd.misc/211963
>
> Leaving aside the personal (and questionable) opinions from Theo about
> OpenSSL develope
19 matches
Mail list logo
