test/heartbleed_test.c

Found that strndup would not work. I had to add #if !HAVE_STRNDUP #include #include #include #include /* Find the length of STRING, but scan at most MAXLEN characters. If no '\0' terminator is found in that many characters, return MAXLEN. */ size_t strnlen (const char *string, size_t ma

Help trying to understand a failure condition

I'm working on signing (and then of course verifying) some data using OpenSSL. I'm getting an occasional failure on the verifying part and I'm trying to figure out why. (Either my software is faulty or there is something worse going on.) I've used valgrind to attempt to point me at a problem a

[openssl.org #319]

I had to reduce our keys to 4096 to be able to use client authentication with Apache. I hope this bug will be fixed. At least root CA and intermediate CAs can be longer. Marc Fauser __ OpenSSL Project

Re: test/heartbleed_test.c

On 20 May 2014 06:40, The Doctor,3328-138 Ave Edmonton AB T5Y 1M4,669-2000,473-4587 wrote: > Found that strndup would not work. > > I had to add > > #if !HAVE_STRNDUP > > #include > #include > #include > #include > > /* Find the length of STRING, but scan at most MAXLEN characters. >If no

[openssl.org #3360] Error building openssl with TLS_DEBUG

Hello, when we try to build openssl when TLS_DEBUG is on, we get an error: t1_enc.c: In function ‘tls1_mac’: t1_enc.c:1045: error: ‘mac_sec’ undeclared (first use in this function) t1_enc.c:1045: error: (Each undeclared identifier is reported only once t1_enc.c:1045: error: for each function it a

[openssl.org #3361] [PATCH] inadequate buffer size in ssl3_send_certificate_request

Hello, Our UC-KLEE tool found an out-of-bounds write bug in ssl3_send_certificate_request (ssl/s3_srvr.c) caused by allocating an insufficiently large buffer. It appears that NETSCAPE_HANG_BUG is defined to append the 4-byte ServerDone message to the CertificateRequest message, but the necessa

[openssl.org #3362] [PATCH] use-after-free bug in dtls1_buffer_record (ssl/d1_pkt.c)

Hello, Our UC-KLEE tool found a use-after-free bug in dtls1_buffer_record (ssl/d1_pkt.c) affecting OpenSSL 1.0.1 (and probably other branches). If the call to ssl3_setup_buffers() (line 255 in the 1.0.1 HEAD) fails, the new item is freed, causing a dangling pointer to remain in the record queue

Re: test/heartbleed_test.c

On 20 May 2014 15:17, Ken Goldman wrote: > On 5/20/2014 7:24 AM, Ben Laurie wrote: >> >> >> There is already a strndup replacement: BUF_strndup(). Switching to >> use that would be better. > > > However > > - if that function points to strndup, don't you still have the problem if > strndup doesn't

Re: test/heartbleed_test.c

On 5/20/2014 7:24 AM, Ben Laurie wrote: There is already a strndup replacement: BUF_strndup(). Switching to use that would be better. However - if that function points to strndup, don't you still have the problem if strndup doesn't exist? - if that function is a reimplementation of strndup

Re: Help trying to understand a failure condition

Sorry for this, after a lot more googling, I found this is intentional and adding the -DPURIFY option resolves this type of uninitialized data access. --Mark On 5/19/14, 6:22 PM, Mark Hatle wrote: I'm working on signing (and then of course verifying) some data using OpenSSL. I'm getting an occ

[openssl.org #3352] export session id and master key in NSS keylog format

This is a pretty cool patch! Martin sent me some instructions on how to get this working with wireshark, which I have reproduced for reference at the end. This worked for me using Wireshark 1.10.6 With regards to the patch itself, it is the idiom of many of the OpenSSL command line apps to take a