Hi!
Since openssl 1.0.0 the STORE support has been removed from build by
default. To enable the STORE functionallity I need to turn
"experimental-store" flag on and edit some .pl files.
Why the STORE was removed from a build by default?
Will the STORE support be returned to build by default in fu
Rather than standalone tests, a patch to s_client seems like it would be most
useful: -sslv3, -state, and the other flags for example.
Anyone working on this? Like -heartbleed=N/M (# of bytes to request/# to
actually send)
/r$
--
Principal Security Engineer
Akamai Technology
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
On Thu, Apr 10, 2014 at 03:33:09PM -0400, Steven Kneizys wrote:
> But from what I am reading it seems like we have
> a patched version but that the problem isn't fully fixed.
The specific problem is fully fixed. The ongoing discussion is
about structural improvements to the code to make similar
On 04/10/2014 05:36 PM, Kurt Roeckx wrote:
> ...
>>
>> While I'm not one of the OpenSSL committers, I've had the honor and
>> privilege of being close enough to some of the action to have an
>> appreciation for the heavy burden of responsibility they carry.
>>
>> IMHO user community contributions,
On Thu, Apr 10, 2014 at 04:40:13PM -0400, Steve Marquess wrote:
> On 04/10/2014 03:22 PM, Kurt Roeckx wrote:
> > Hi,
> >
> > I've seen many examples of patches being submitted but never
> > getting applied. For some problems there are actually multiple
> > people submitting a patch for the same i
On 04/10/2014 03:22 PM, Kurt Roeckx wrote:
> Hi,
>
> I've seen many examples of patches being submitted but never
> getting applied. For some problems there are actually multiple
> people submitting a patch for the same issue, and none of them
> getting applied.
>
> What is the problem getting t
I am reading come conflicting advice out there about the state of the fix.
Some
folks want the official fix in now! But from what I am reading it seems
like we have
a patched version but that the problem isn't fully fixed. I am trying to
decide if
some of the unimplemented bug-fixes submitted ar
Daniel Kahn Gillmor wrote:
On 04/08/2014 11:08 PM, Chris Hill wrote:
SSH and SSL/TLS are simply different protocols (doh). They may share some
similar underlying crypto implementations, but as of their respective RFCs,
they are just different protocols. The TLS Heartbeat TLS extension would
n
Hi,
I've seen many examples of patches being submitted but never
getting applied. For some problems there are actually multiple
people submitting a patch for the same issue, and none of them
getting applied.
What is the problem getting them applied? Not enough people to do
the reviewing? Peopl
Looking at the heartbeat code, I notice that neither of the process
heartbeat functions check whether RAND_pseudo_bytes returned success when
it is generating the heartbeat padding.
I don't know if there are real-world scenarios where this could happen, but
if so, I believe this would "bleed" 16 b
On Thu, Apr 10, 2014 at 9:43 PM, Kurt Roeckx wrote:
> On Thu, Apr 10, 2014 at 09:20:57PM +0400, Loganaden Velvindron wrote:
>> >
>> > 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
>> > @@ -
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 09:20:57PM +0400, Loganaden Velvindron wrote:
> >
> > 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_HE
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 8:36 PM, Loganaden Velvindron
wrote:
> Hi All,
>
> Ted Ugnast (of OpenBSD) wrote an interesting blog entry:
Deep apologies to Ted. I got his name wrong. It's Ted Unangst.
(And thanks to Otto for bringing this to my attention :-))
>
> I'm quoting here for people who need
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
Hi All,
Ted Ugnast (of OpenBSD) wrote an interesting blog entry:
I'm quoting here for people who need the essential information:
"
On line 1059, we find a call to ssl3_release_read_buffer after we have
read the header, which will free the current buffer.
if (type == rr->type) /* SSL3_RT_APPLICA
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
My last was a little premature. In order to prevent misbehavior in the
case where some field elements are less than 4 limbs long (including a
crash when dealing with the point at infinity), the following change
should also be applied.
Cheers
AGL
patch
Description: Binary data
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
""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 developers, I think he is right about that this malloc wrapper
looks quite bad.
Prob
+1!
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
-Original Message-
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Nikos Mavrogiannopoulos via RT
Sent: Thursday, April 10, 2014 2:25 AM
Cc: openssl-dev@openssl.org
Subject: [op
---
ssl/d1_both.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index d8bcd58..2c06fc2 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -679,8 +679,8 @@ dtls1_reassemble_fragment(SSL *s, struct hm_header_st*
msg_hdr, int *ok)
it
28 matches
Mail list logo
