Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Michel]

Hi Matt, 

Thanks for the suggestion.

This is what was printed to stderr :
OPENSSL_INIT: ossl_init_base: Setting up stop handlers
OPENSSL_INIT: ossl_init_add_all_ciphers: openssl_add_all_ciphers_internal()
OPENSSL_INIT: ossl_init_add_all_digests: openssl_add_all_digests_internal()
OPENSSL_INIT: ossl_init_ssl_base: Adding SSL ciphers and digests
OPENSSL_INIT: ossl_init_ssl_base: SSL_COMP_get_compression_methods()
OPENSSL_INIT: ossl_init_ssl_base: SSL_add_ssl_module()
OPENSSL_INIT: ossl_init_load_ssl_strings: ERR_load_SSL_strings()
OPENSSL_INIT: ossl_init_async: async_init()
OPENSSL_INIT: ossl_init_load_crypto_strings:
err_load_crypto_strings_intern()
OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state
OPENSSL_INIT: ossl_init_thread_start: marking thread for err_state
OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)
OPENSSL_INIT: ssl_library_stop: SSL_COMP_free_compression_methods()
OPENSSL_INIT: ssl_library_stop: ERR_free_strings()
OPENSSL_INIT: OPENSSL_cleanup: ERR_free_strings()
OPENSSL_INIT: OPENSSL_INIT_library_stop: CRYPTO_cleanup_all_ex_data()
OPENSSL_INIT: OPENSSL_INIT_library_stop: EVP_cleanup()
OPENSSL_INIT: OPENSSL_INIT_library_stop: CONF_modules_free()
OPENSSL_INIT: OPENSSL_INIT_library_stop: RAND_cleanup()

Shouldn't there be at least another line with ERR_remove_thread_state() (one
for each thread) ?
This test program launch 1 server thread and 1 client thread.
Both of them have OPENSSL_thread_stop() in their [pre-]exit member function.

Michel.

-Message d'origine-
De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Matt
Caswell
Envoyé : mercredi 17 février 2016 17:23
À : openssl-dev@openssl.org
Objet : Re: [openssl-dev] memory leaks detected using libSSL 1.1

> Am I missing anything else ?

That should be sufficient (although the OPENSSL_cleanup() should not be
required).

You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g.

perl Configure your-platform-here -DOPENSSL_INIT_DEBUG

This should print out some debugging information to stderr every time the
init functions attempt to do something interesting. In particular when you
call OPENSSL_thread_stop() you should see the following printed
out:

OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Salz, Rich]

Yes, thanks, I was being dumb :(
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung via RT]

Am 17.02.2016 um 19:51 schrieb Salz, Rich:
>
>>*header = c;
>> +header++;
>
> Header isn't used after that assignment.  How does this line change anything?

The call to load_iv() that occurs next, has as its first argument 
header_pp which is a pointer to header:

char **header_pp = 

Inside load_iv() this pointer is named fromp and is immediately being 
dereferenced:

from = *fromp;

so "from" is an alias to "header", it contains the same address as 
"header". When being dereferenced, "from" will return the same char, 
that "header" points to.

Now in load_iv() "from" is used to iterate over the IV hex chars:

 for (i = 0; i < num; i++) {
 if ((*from >= '0') && (*from <= '9'))
 v = *from - '0';
 else if ((*from >= 'A') && (*from <= 'F'))
 v = *from - 'A' + 10;
 else if ((*from >= 'a') && (*from <= 'f'))
 v = *from - 'a' + 10;
 else {
 PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS);
 return (0);
 }
 from++;
 to[i / 2] |= v << (long)((!(i & 1)) * 4);
 }

Since *from == *header == ',' at the beginning of the loop, this bombs. 
"header" needs to be incremented to actually point to the beginning of 
the IV.

I hope this is understandable. It took me a moment as well to 
understand, how "from" in load_iv() relates to "header" in 
PEM_get_EVP_CIPHER_INFO().

I checked the patch with the reproduction case before posting and also 
added some debug logging to the "from" loop to double check.

Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung]

Am 17.02.2016 um 19:51 schrieb Salz, Rich:



   *header = c;
+header++;


Header isn't used after that assignment.  How does this line change anything?


The call to load_iv() that occurs next, has as its first argument 
header_pp which is a pointer to header:


char **header_pp = 

Inside load_iv() this pointer is named fromp and is immediately being 
dereferenced:


from = *fromp;

so "from" is an alias to "header", it contains the same address as 
"header". When being dereferenced, "from" will return the same char, 
that "header" points to.


Now in load_iv() "from" is used to iterate over the IV hex chars:

for (i = 0; i < num; i++) {
if ((*from >= '0') && (*from <= '9'))
v = *from - '0';
else if ((*from >= 'A') && (*from <= 'F'))
v = *from - 'A' + 10;
else if ((*from >= 'a') && (*from <= 'f'))
v = *from - 'a' + 10;
else {
PEMerr(PEM_F_LOAD_IV, PEM_R_BAD_IV_CHARS);
return (0);
}
from++;
to[i / 2] |= v << (long)((!(i & 1)) * 4);
}

Since *from == *header == ',' at the beginning of the loop, this bombs. 
"header" needs to be incremented to actually point to the beginning of 
the IV.


I hope this is understandable. It took me a moment as well to 
understand, how "from" in load_iv() relates to "header" in 
PEM_get_EVP_CIPHER_INFO().


I checked the patch with the reproduction case before posting and also 
added some debug logging to the "from" loop to double check.


Regards,

Rainer
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Salz, Rich]

>   *header = c;
> +header++;

Header isn't used after that assignment.  How does this line change anything?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Salz, Rich via RT]

>   *header = c;
> +header++;

Header isn't used after that assignment.  How does this line change anything?


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3628] [PATCH] NDEBUG macro and redundant strings

[Rich Salz via RT]

fixed in 90fddb380977fa4f0a5de75b8fa889f29e34 pushed to master, thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3628
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4310] Fix various no-XXX build options

[Rich Salz via RT]

fixed with commit 1288f26 pushed to master. thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4310
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4320] [Patch] OpenSSL 1.1.0-pre3: "unable to load Key" error in PEM_get_EVP_CIPHER_INFO()

[Rainer Jung via RT]

Change

https://github.com/openssl/openssl/commit/33a6d5a0e565e08758bcb6af456ec657c3a7a76a

introduced a bug in crypto/pem/pem_lib.c function 
PEM_get_EVP_CIPHER_INFO(). One line was removed that is actually needed.

The following patch fixes it:

--- crypto/pem/pem_lib.c 2016-02-15 19:08:07.0 +0100
+++ crypto/pem/pem_lib.c  2016-02-17 18:45:14.092815000 +0100
@@ -537,6 +537,7 @@
  *header = '\0';
  cipher->cipher = enc = EVP_get_cipherbyname(dekinfostart);
  *header = c;
+header++;

  if (enc == NULL) {
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, 
PEM_R_UNSUPPORTED_ENCRYPTION);


While you are at it, the following is a small improvement which is used 
in similar ways close to this place:

--- crypto/pem/pem_lib.c.orig 2016-02-17 18:45:14.092815000 +0100
+++ crypto/pem/pem_lib.c  2016-02-17 19:15:19.901402000 +0100
@@ -509,6 +509,7 @@
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_NOT_ENCRYPTED);
  return (0);
  }
+header += 9;
  for (; (*header != '\n') && (*header != '\0'); header++) ;
  if (*header == '\0') {
  PEMerr(PEM_F_PEM_GET_EVP_CIPHER_INFO, PEM_R_SHORT_HEADER);



How to reproduce the bug:

OpenSSL> dsaparam -out dsa-test 2048
Generating DSA parameters, 2048 bit long prime
This could take some time
...

OpenSSL> gendsa -out dsa-test.pem -aes128 dsa-test
Generating DSA key, 2048 bits
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:

OpenSSL> dsa -in dsa-test.pem -text
read DSA key
unable to load Private Key
4280523828:error:09065067:PEM routines:load_iv:bad iv chars:pem_lib.c:568:
unable to load Key
error in dsa

The same happens e.g. when using -des or -des3 instead of -aes128.

Without incrementing the header pointer, the parsing of the line

DEK-Info: AES-128-CBC,CBFAADAF91039DF800391FB382CAC3B9

proceeds at the comma, instead of the hex string and bombs out.

Thanks and Regards,

Rainer


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4320
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[Salz, Rich]

> It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
> to work "out of the box".

That will be great.
 
> I would like to see what we can do in the way of automated testing,
> though. It should be possible to at least have Travis-CI make
> libcrypto.so for the Linux target, with the 'no-everything' options
> that UEFI uses. It's a blunt instrument, but would have caught quite a
> few of the things I've just fixed, I think.

I think UEFI is important and would be willing to add a build to our travis.  
Make a PR :)

/r$

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[David Woodhouse]

On Tue, 2016-02-09 at 02:57 +, Long, Qin wrote:
>  these two weeks.>
> 
> David, I agree it's really horrid to include those _lcl.h to meet
> EDK2 API requirement.  I am thinking it's better to re-design some
> APIs to align the new opaque structure style. E.g. replacing the
> HmacSha1GetContextSize() with HmacSha1ContextNew()... It should be
> feasible. 

That sounds ideal; thanks.

In the meantime, I've sorted out everything we need on the OpenSSL
side. A bunch has been merged today (thanks, Rich and Matt), and we are
now down to the following four RT tickets and associated pull requests:

 RT4175: Fix regression using PKCS7_verify() with Authenticode
 https://github.com/openssl/openssl/pull/694
(https://github.com/openssl/openssl/pull/695 for 1.0.2)

 RT4309: Define PRIu64 for UEFI build
 https://github.com/openssl/openssl/pull/696
 
 RT4310: Fix breakage of various no-xxx configuration options in HEAD 
 https://github.com/openssl/openssl/pull/697

 RT3628: Allow filenames to be eliminated from compiled library
 https://github.com/openssl/openssl/pull/698

It looks like we're in fairly good shape for the OpenSSL 1.1.0 release
to work "out of the box".

I would like to see what we can do in the way of automated testing,
though. It should be possible to at least have Travis-CI make
libcrypto.so for the Linux target, with the 'no-everything' options
that UEFI uses. It's a blunt instrument, but would have caught quite a
few of the things I've just fixed, I think.

> In addition, I would like to retire the IntrinsicLib in CryptoPkg.
> This library is designed to satisfy the link requirement when
> integrating openssl in EDKII environment. Some code segments in
> OpenSSL will produce the intrinsic functions. E.g.  in the function
> load_iv() in Pem_lib.c: 
> for (i = 0; i < num; i++)
> to[i] = 0;
> I think it's better to update this to the direct memset(). What's
> your opinion?

I am not keen. 

If you don't want the compiler to 'spot' that certain patterns in C
code can be replaced with intrinsic functions, then ask it nicely not
to do that. Do *not* just attempt to tweak the code so that today's
compiler doesn't happen to spot anything it can replace, in the
*current* phase of the moon. That way lies madness.

Isn't this what -ffreestanding (or is it -fno-builtins) is for?

How does this work elsewhere in the EDK2 code base? Surely you can't play 
whack-a-mole with *every* piece of code  that the compiler might decide to swap 
for an intrinsic memset/memcpy/etc., including all structure assignments?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ECDH engine

[Blumenthal, Uri - 0553 - MITLL]

Yea, my nice email server decided that it needed to re-send that piece. ;)

But there have been changes since our conversation in January. I’d greatly
appreciate if you could take a look at the current Github master of
openssl/libp11 (it now has subsumed engine_pkcs11, and integrated ECDH
support) and check if it alleviates the need for your ECDH engine.


-- 
Regards,
Uri Blumenthal

From:  openssl-dev  on behalf of Alexander
Gostrer 
Reply-To:  openssl-dev 
Date:  Wednesday, February 17, 2016 at 11:32
To:  openssl-dev 
Subject:  Re: [openssl-dev] ECDH engine

> Hi Uri,
> 
> On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL
>  wrote:
>>> When I started to write the ECDSA code for engine_pkcs11  in 2011 the code
>>> to support the method hooks was not
>>> in the code. So I used internal OpenSSL header files to copy the
>>> ECDSA_METHOD  and replace the function needed.
>>> Look for "BUILD_WITH_ECS_LOCL_H" in libp11.  Not until 1.0.2 did OpenSSL
>>> support the needed calls to hook ECDSA.
>>> They did not add the hooks for ECDH.
>> 
>> I am missing one thing here. Hopefully you can help me understanding it.
>> 
>> OpenSSL-1.0.2 currently supports ECDH, as I observe by running
>> openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey
>> /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1
>> 
>> 
>> So clearly there is working code available inside OpenSSL that does what is
>> needed. The only issue then is to add code to libp11 to access that code.
>> 
>> Am I correct? If not, could you please point at where/what I’m mistaken in?
>> 
>>> If you can't wait then you have to do it your self.  *YOU* could do the same
>>> thing for ECDH. But your code would only
>>> be good for 1.0.2 because the whole way of doing EC methods changes in 1.1.
>> 
>> That’s perfectly OK, because if my tea leaves reading is correct,
>> OpenSSL-1.0.2 will be around for several years at least. And most of the
>> package providers such as Macports won’t move their packages to OpenSSL-1.1
>> for probably that long. So making 1.0.2 working with ECDH now will definitely
>> make sense for me.
>> 
>> In fact, I think making libp11 compliant with OpenSSL-1.1 now is an
>> overreach, because this effort (unlike work on 1.0.2) is highly unlikely to
>> bring benefits to users for a few years.
>> 
>>> I believe Alexander said he had changes to OpenSSL, which is another
>>> approach. 
>>> He has said there were here:
>>> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches
>> 
>> I see that the actual patch is very small. And the only meaningful (for me)
>> change is adding a new method EC_generate_key(). I would like to understand
>> why this method is needed – is it only to allow OpenSSL to generate key pair
>> on the token? Alexander, could you comment please?
>  
> I was already responding to it. Here is the copy-paste from my previous
> response:
> In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key pair
> for ECDH and sends the public key in the server key exchange message (see
> ssl3_send_server_key_exchange(SSL *s) function). It does not use the private
> key until it gets the client public key in the
> "ssl3_send_server_key_exchange(SSL *s)". Just then it calls the
> "ECDH_compute_key()" with the client public key and the server private key
> generated much earlier. If I do not call this new function (EC_generate_key())
> then the openssl sends a software-generated ephemeral key to the client.
> Adding this function was the simplest way to fix the problem. On client
> everything happens in the same function so it wasn't a problem.
>  
>> 
>>> You could also hire someone who could do more then: "test it and offer minor
>>> enhancements".
>> 
>> First, I cannot. Second, I don’t think (and haven’t seen any evidence to the
>> contrary yet) that anything more is needed. Especially seeing the minuscule
>> amount of changes Alexander had to do to OpenSSL, and I’m not even sure I
>> need those if I don’t insist on being able to generate new key pair on the
>> token using only OpenSSL.
>> 
>>> (And not me. I am taking the 1.1 approach to getting ECDH. working in
>>> engine.) 
>> 
>> :-)  OK, I withdraw my unexpressed and unformulated offer. Consider yourself
>> un-asked.  :-)
>> 
>> 
>>> 




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4319] openssl-1.1.0-pre3 Configure does not set cflags correctly on Solaris10 x64

[Kiyoshi KANAZAWA via RT]

Configure does not set cflags correctly on Solaris10 x64.
In Configurations/10-main.conf line 75, it is written as
 cflags   => add_before("-m64 -Wall -DL_ENDIAN"),
but, it is not set to CFLAGS.
Make does not generate 64-bits code (-m64 is not used).

Configure log is attached.



% ./Configure solaris64-x86_64-gcc
% make
  :
gcc -I. -I.. -I../include -Iinclude  -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_THREADS -DOPENSSL_IA32
_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM
 -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1
305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines\""  -pthread -D
FILIO_H -O3   -c -o cryptlib.o cryptlib.c
  :
/opt/perl5/bin/perl x86_64cpuid.pl elf > x86_64cpuid.s
gcc -I. -I.. -I../include -Iinclude  -DDSO_DLFCN -DHAVE_DLFCN_H 
-DOPENSSL_THREADS -DOPENSSL_IA32
_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM
 -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1
305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines\""  -pthread -D
FILIO_H -O3 -c  -o x86_64cpuid.o x86_64cpuid.s
x86_64cpuid.s: Assembler messages:
x86_64cpuid.s:15: Error: bad register name `%rdi)'
x86_64cpuid.s:16: Error: bad register name `%rsi'
x86_64cpuid.s:18: Error: bad register name `%r8d'
x86_64cpuid.s:20: Error: bad register name `%r8d'
x86_64cpuid.s:30: Error: bad register name `%rdx'
x86_64cpuid.s:31: Error: bad register name `%rdx'
x86_64cpuid.s:39: Error: bad register name `%rbx'
x86_64cpuid.s:42: Error: bad register name `%rdi)'
x86_64cpuid.s:44: Error: bad register name `%r11d'
x86_64cpuid.s:49: Error: bad register name `%r9d'
x86_64cpuid.s:52: Error: bad register name `%r9d'
x86_64cpuid.s:55: Error: bad register name `%r9d'
x86_64cpuid.s:60: Error: bad register name `%r10d'
x86_64cpuid.s:63: Error: bad register name `%r10d'
x86_64cpuid.s:66: Error: bad register name `%r10d'
x86_64cpuid.s:74: Error: bad register name `%r10d'
x86_64cpuid.s:77: Error: bad register name `%r9d'
x86_64cpuid.s:78: Error: bad register name `%r9d'
x86_64cpuid.s:80: Error: bad register name `%r10d'
x86_64cpuid.s:85: Error: `movzbq' is only supported in 64-bit mode
  :


Best Regards,

--- Kiyoshi 

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4319
Please log in as guest with password guest if prompted



Configure.log
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] ECDH engine

[Alexander Gostrer]

Hi Uri,

On Wed, Jan 27, 2016 at 9:25 AM, Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> When I started to write the ECDSA code for engine_pkcs11  in 2011 the code
> to support the method hooks was not
> in the code. So I used internal OpenSSL header files to copy the
> ECDSA_METHOD  and replace the function needed.
> Look for "BUILD_WITH_ECS_LOCL_H" in libp11.  Not until 1.0.2 did OpenSSL
> support the needed calls to hook ECDSA.
> They did not add the hooks for ECDH.
>
>
> I am missing one thing here. Hopefully you can help me understanding it.
>
> OpenSSL-1.0.2 currently supports ECDH, as I observe by running
>
> openssl pkeyutl -derive -inkey /tmp/derive.29494.priv.pem -peerkey
> /tmp/derive.29494.token.pub.pem -out /tmp/derive.29494.shared1
>
> So clearly there is working code available inside OpenSSL that does what
> is needed. The only issue then is to add code to libp11 to access that
> code.
>
> Am I correct? If not, could you please point at where/what I’m mistaken in?
>
> If you can't wait then you have to do it your self.  *YOU* could do the
> same thing for ECDH. But your code would only
> be good for 1.0.2 because the whole way of doing EC methods changes in
> 1.1.
>
>
> That’s perfectly OK, because if my tea leaves reading is correct,
> OpenSSL-1.0.2 will be around for several years at least. And most of the
> package providers such as Macports won’t move their packages to OpenSSL-1.1
> for probably that long. So making 1.0.2 working with ECDH now will
> definitely make sense for me.
>
> In fact, I think making libp11 compliant with OpenSSL-1.1 now is an
> overreach, because this effort (unlike work on 1.0.2) is highly unlikely to
> bring benefits to users for a few years.
>
> I believe Alexander said he had changes to OpenSSL, which is another
> approach.
> He has said there were here:
> https://github.com/AtmelCSO/cryptoauth-openssl-engine/tree/master/patches
>
>
> I see that the actual patch is very small. And the only meaningful (for
> me) change is adding a new method EC_generate_key(). I would like to
> understand why this method is needed – is it only to allow OpenSSL to
> *generate* key pair on the token? Alexander, could you comment please?
>

I was already responding to it. Here is the copy-paste from my previous
response:
In the TLS-1.2 protocol (sl_srvr.c) the server generates an ephemeral key
pair for ECDH and sends the public key in the server key exchange message
(see ssl3_send_server_key_exchange(SSL *s) function). It does not use the
private key until it gets the client public key in the
"ssl3_send_server_key_exchange(SSL *s)". Just then it calls the
"ECDH_compute_key()" with the client public key and the server private key
generated much earlier. If I do not call this new function (EC_generate_
key()) then the openssl sends a software-generated ephemeral key to the
client. Adding this function was the simplest way to fix the problem. On
client everything happens in the same function so it wasn't a problem.


>
> You could also hire someone who could do more then: "test it and offer
> minor enhancements".
>
>
> First, I cannot. Second, I don’t think (and haven’t seen any evidence to
> the contrary yet) that anything more is needed. Especially seeing the
> minuscule amount of changes Alexander had to do to OpenSSL, and I’m not
> even sure I need those if I don’t insist on being able to generate new key
> pair on the token using only OpenSSL.
>
> (And not me. I am taking the 1.1 approach to getting ECDH. working in
> engine.)
>
>
> :-)  OK, I withdraw my unexpressed and unformulated offer. Consider
> yourself un-asked.  :-)
>
>
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] memory leaks detected using libSSL 1.1

[Matt Caswell]

On 16/02/16 23:25, Michel wrote:
> Hi Matt,
> 
> Yes I am linking statically and I read the man about OPENSSL_init_crypto(),
> thanks.
> However I still have leaks reported.
> :-(
> 
> What I have changed to adapt to v1.1 is calling OPENSSL_thread_stop() in
> each thread before it leaves,
> instead of ERR_remove_thread_state( NULL ), 
> and I am calling OPENSSL_cleanup() before the main thread returns.
> Am I missing anything else ?

That should be sufficient (although the OPENSSL_cleanup() should not be
required).

You could try compiling OpenSSL with OPENSSL_INIT_DEBUG defined, e.g.

perl Configure your-platform-here -DOPENSSL_INIT_DEBUG

This should print out some debugging information to stderr every time
the init functions attempt to do something interesting. In particular
when you call OPENSSL_thread_stop() you should see the following printed
out:

OPENSSL_INIT: ossl_init_thread_stop: ERR_remove_thread_state(NULL)

Matt

> 
> Now I have 2 tests programs, almost identical, one is linked against v1.0.2
> and the other against v1.1.
> The former (1.0.2) doesn't report any leak but the later (1.1) always report
> leaks.
> 
> I tried lots of modifications to the 1.1 version in order to understand what
> is happening, 
> but the only thing I noticed is leaks occur if at some point the program go
> to the OpenSSL error subsystem,
> like in the 2 reports below.
> 
> Can you please help in this matter ?
> 
> Detected memory leaks!
> Dumping objects ->
> {7453} normal block at 0x00895440, 8 bytes long.
>  Data: <> 00 00 00 00 01 00 00 00 
> {5460} normal block at 0x00871B98, 12 bytes long.
>  Data: < e  > C8 19 87 00 00 00 00 00 B4 65 01 00 
> {5459} normal block at 0x008719C8, 400 bytes long.
>  Data: <> 00 00 00 00 84 1B 00 00 00 00 00 00 00 00 00 00 
> {5457} normal block at 0x00871900, 64 bytes long.
>  Data: <> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
> {5455} normal block at 0x0086D7E8, 96 bytes long.
>  Data: <`   > 00 19 87 00 60 CB 05 01 80 CB 05 01 08 00 00 00 
> Object dump complete.
> 
> WARNING: Visual Leak Detector detected memory leaks!
> -- Block 5450 at 0x0086D7E8: 96 bytes --
>   Leak Hash: 0xE1A21867, Count: 1, Total 96 bytes
>   Call Stack (TID 6956):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\lhash\lhash.c (116): TestsTLS-11.exe!lh_new()
> + 0xB bytes
> e:\openssl-1.1.git\crypto\err\err_lcl.h (2):
> TestsTLS-11.exe!lh_ERR_STATE_new() + 0x10 bytes
> e:\openssl-1.1.git\crypto\err\err.c (321):
> TestsTLS-11.exe!int_thread_get() + 0xF bytes
> e:\openssl-1.1.git\crypto\err\err.c (369):
> TestsTLS-11.exe!int_thread_set_item() + 0x9 bytes
> e:\openssl-1.1.git\crypto\err\err.c (884):
> TestsTLS-11.exe!ERR_get_state() + 0xC bytes
> e:\openssl-1.1.git\crypto\err\err.c (581):
> TestsTLS-11.exe!ERR_put_error() + 0x5 bytes
> e:\openssl-1.1.git\crypto\pem\pem_lib.c (702):
> TestsTLS-11.exe!PEM_read_bio() + 0x15 bytes
> e:\openssl-1.1.git\crypto\pem\pem_info.c (117):
> TestsTLS-11.exe!PEM_X509_INFO_read_bio() + 0x19 bytes
> e:\openssl-1.1.git\crypto\x509\by_file.c (249):
> TestsTLS-11.exe!X509_load_cert_crl_file() + 0xF bytes
> e:\openssl-1.1.git\crypto\x509\by_file.c (113):
> TestsTLS-11.exe!by_file_ctrl() + 0xF bytes
> e:\openssl-1.1.git\crypto\x509\x509_lu.c (117):
> TestsTLS-11.exe!X509_LOOKUP_ctrl() + 0x1F bytes
> e:\openssl-1.1.git\crypto\x509\x509_d2.c (92):
> TestsTLS-11.exe!X509_STORE_load_locations() + 0x13 bytes
> e:\openssl-1.1.git\ssl\ssl_lib.c (3344):
> TestsTLS-11.exe!SSL_CTX_load_verify_locations() + 0x14 bytes
> p:\mes programmes\shared\ocrypto-11\tls.cpp (410):
> TestsTLS-11.exe!OTLS::TLSCtx::LoadTrustedCertsFile() + 0x12 bytes
> p:\mes programmes\tests\_testsshared\teststls-11\tlscltsetup.cpp (99):
> TestsTLS-11.exe!TLSCltConfig::Setup() + 0x26 bytes
> p:\mes programmes\tests\_testsshared\teststls-11\clttasks.cpp (90):
> TestsTLS-11.exe!CltThread::Main() + 0x17 bytes
> p:\mes programmes\shared\sthread.cpp (17):
> TestsTLS-11.exe!SThread::Run() + 0xE bytes
> f:\dd\vctools\crt\crtw32\startup\threadex.c (359):
> TestsTLS-11.exe!_threadstartex()
> 
> 
> -- Block 5452 at 0x00871900: 64 bytes --
>   Leak Hash: 0x188D6136, Count: 1, Total 64 bytes
>   Call Stack (TID 6956):
> ntdll.dll!RtlAllocateHeap()
> f:\dd\vctools\crt\crtw32\misc\dbgmalloc.c (56): TestsTLS-11.exe!malloc()
> + 0x15 bytes
> e:\openssl-1.1.git\crypto\mem.c (138): TestsTLS-11.exe!CRYPTO_malloc() +
> 0x9 bytes
> e:\openssl-1.1.git\crypto\mem.c (158): TestsTLS-11.exe!CRYPTO_zalloc() +
> 0x11 bytes
> e:\openssl-1.1.git\crypto\lhash\lhash.c 

[openssl-dev] [openssl.org #4318] [PATCH] Fix OSSL_SSIZE_MAX for UEFI build

[Rich Salz via RT]

checked into master at 21b80f9 thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4318
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl-SNAP-20160216 issues

[The Doctor]

On Tue, Feb 16, 2016 at 10:42:21AM +0100, Richard Levitte wrote:
> In message <20160216090030.ga11...@doctor.nl2k.ab.ca> on Tue, 16 Feb 2016 
> 02:00:30 -0700, The Doctor  said:
> 
> doctor> In the make test I am getting
> doctor> 
> doctor> What can do to see why these tests are failing?
> 
> You can do this:
> 
> HARNESS_VERBOSE=yes make test
> 
> Fair warning, that's a *lot* of output

Just like openssl 1.0.X  but it helps


> 
> If you want to be selective, you can pick specific tests into the
> TESTS variable, like this:
> 
> HARNESS_VERBOSE=yes make test TESTS='tesl_ssl test_packet'
> 
> The words in that variable are taken from the test recipes, it's the
> {name} part in nn-{name}.t, so for the recipe file
> ../test/recipes/70-test_clienthello.t, the name to put into the TESTS
> variable is test_clienthello.
>

All right what about

../test/recipes/70-test_packet.t ..
1..1
test_PACKET_buf_init() failed
not ok 1 - running packettest

#   Failed test 'running packettest'
#   at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
# Looks like you failed 1 test of 1.
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
../test/recipes/70-test_sslcertstatus.t ...
1..1
Failed creating proxy socket (localhost,4453): Address already in use
# Looks like your test exited with 48 before it could output anything.
Dubious, test returned 48 (wstat 12288, 0x3000)
Failed 1/1 subtests 

../test/recipes/90-test_networking.t ..
1..2
Proxy connection failed: Failed creating proxy socket (127.0.0.1,4453): Address 
already in use

not ok 1 - Trying IPv4

#   Failed test 'Trying IPv4'
#   at ../test/recipes/90-test_networking.t line 90.
Proxy started on port 4453 

Something seems to be stuck.
 
 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Broadcasting the truth for 25 years
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4318] [PATCH] Fix OSSL_SSIZE_MAX for UEFI build

[David Woodhouse via RT]

Commit e634b448c ("Defines OSSL_SSIZE_MAX") introduced a definition of
OSSL_SSIZE_MAX which broke the UEFI build. Fix that by making UEFI take
the same definition as Ultrix (ssize_t == int).
---
 include/openssl/e_os2.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index 1a1fe3e..8cf6c84 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -269,7 +269,7 @@ extern "C" {
 #  endif
 # endif
 
-# if defined(__ultrix) && !defined(ssize_t)
+# if (defined(__ultrix) || defined(OPENSSL_SYS_UEFI)) && !defined(ssize_t)
 #  define ossl_ssize_t int
 #  define OSSL_SSIZE_MAX INT_MAX
 # endif
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4318
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4315] [PATCH] Fix UEFI build in crypto/init.c

[Rich Salz via RT]

Fixed in master with commit c7b7938 thank you!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4315
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4317] openssl-1.1.0-pre3 make error with Configure option "zlib-dynamic"

[Kiyoshi KANAZAWA via RT]

Openssl-1.1.0-pre3 make fails with Configure option "zlib-dynamic".
Without "zlib-dynamic", make & make check passed.
With "zlib", make & make check also passed.

Tried on Solaris10 x86, with #4314 fix.


% ./Configure solaris-x86-gcc threads shared zlib-dynamic no-ssl3
% make
  :
gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS -DOPENSSL_PIC 
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DRMD160_ASM -DAES_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DOPENSSLDIR="/opt/openssl/ssl" 
-DENGINESDIR="/opt/openssl/lib/engines" -fPIC -pthread -DFILIO_H -O3 
-fomit-frame-pointer -DWHIRLPOOL_ASM -R /opt/openssl/lib -o openssl openssl.o 
asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o 
dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o 
nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o 
prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o 
smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o 
opt.o s_cb.o s_socket.o app_rand.o -L.. -lssl -L.. -lcrypto -lsocket -lnsl -ldl
Undefined   first referenced
 symbol in file
BIO_f_zlib  ../libcrypto.so
ld: fatal: symbol referencing errors. No output written to openssl
collect2: error: ld returned 1 exit status
../Makefile.shared:412: recipe for target 'link_app.solaris' failed




Best regards,

--- Kiyoshi 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4317
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4315] [PATCH] Fix UEFI build in crypto/init.c

[David Woodhouse via RT]

We don't have atexit() in the EDK2 environment. Firmware never exits.
---
 crypto/init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/crypto/init.c b/crypto/init.c
index 25e3dc7..c7eff8b 100644
--- a/crypto/init.c
+++ b/crypto/init.c
@@ -270,7 +270,9 @@ static void ossl_init_base(void)
 fprintf(stderr, "OPENSSL_INIT: ossl_init_base: Setting up stop 
handlers\n");
 #endif
 ossl_init_setup_thread_stop();
+#ifndef OPENSSL_SYS_UEFI
 atexit(OPENSSL_cleanup);
+#endif
 OPENSSL_cpuid_setup();
 base_inited = 1;
 }
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4315
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4316] Build failure with OPENSSL_NO_DES or OPENSSL_NO_AES defined

[Michele Cicciotti via RT]

Affected version: 1.0.2f

crypto/cms/cms_kari.c calls EVP_des_ede3_wrap without checking whether 
OPENSSL_NO_DES is defined, and EVP_aes_XXX_wrap without checking if 
OPENSSL_NO_AES is defined. See the attached patch for the fix

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4316
Please log in as guest with password guest if prompted

--- crypto/cms/cms_kari.c
+++ crypto/cms/cms_kari.c
@@ -402,13 +402,22 @@
  * DES3 wrap otherwise use AES wrap similar to key size.
  */
 if (EVP_CIPHER_type(cipher) == NID_des_ede3_cbc)
+#ifdef OPENSSL_NO_DES
+return 0;
+#else
 kekcipher = EVP_des_ede3_wrap();
-else if (keylen <= 16)
+#endif
+else
+#ifdef OPENSSL_NO_AES
+return 0;
+#else
+if (keylen <= 16)
 kekcipher = EVP_aes_128_wrap();
 else if (keylen <= 24)
 kekcipher = EVP_aes_192_wrap();
 else
 kekcipher = EVP_aes_256_wrap();
+#endif
 return EVP_EncryptInit_ex(ctx, kekcipher, NULL, NULL, NULL);
 }
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4313] [PATCH] Fix build for !IMPLEMENTED code path in CRYPTO_secure_free()

[Rich Salz via RT]

commit 6a78ae2821e89a8838714496524fd39d9d21fb1b is in master now, thanks!
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4313
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4314] openssl-1.1.0-pre3 make error on Solaris 10 x86

[Rich Salz via RT]

fixed in mater.
commit 29620124ff1624af5411d8d2998fdd7b102a5d48
Author: Richard Levitte 
Date: Tue Feb 16 10:27:16 2016 +0100

On solaris, the variable name sun clashes, use s_un instead

For orthogonality, we change sin -> s_in and sin6 -> s_in6 as well.

Reviewed-by: Matt Caswell 

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4314
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content

[Salz, Rich via RT]

> If you say that removing the #ifdef instead of removing the whole code block
> that it contained was a mistake, then I shall take you at your word and 
> refrain
> from harping on *too* much about how naughty it was to have a functional
> change hidden away in a commit which simply entitled itself "Memory leak
> fixes", without even any acknowledgement of the change in the body of the
> commit comment :)

Feel free to dock my pay :)

Looks good.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4314] openssl-1.1.0-pre3 make error on Solaris 10 x86

[Kiyoshi KANAZAWA via RT]

Hello,

Openssl-1.1.0-pre3 make fails on Solaris 10 x86, such as
make[2]: Entering directory '/tmp/openssl-1.1.0-pre3/crypto/bio'
gcc -I.. -I../.. -I../modes -I../include -I../../include  -DDSO_DLFCN 
-DHAVE_DLFCN_H -DOPENSSL_T
HREADS -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPE
NSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM 
-DAES_ASM -DVPAES_A
SM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR=
"\"/usr/local/lib/engines\"" -fPIC  -pthread -DFILIO_H -O3 -fomit-frame-pointer 
-DWHIRLPOOL_ASM 
  -c -o bss_fd.o bss_fd.c
bio_lcl.h:60:24: error: expected identifier or '(' before numeric constant
 struct sockaddr_un sun;
    ^
In file included from bss_fd.c:61:0:
bio_lcl.h:62:1: warning: no semicolon at end of struct or union [enabled by 
default]
 };


This happens because "sun" is #defined as 1 on Solaris.
On the other hand, the same name is used in crypto/bio/bio_lcl.h,
    53  union bio_addr_st {
    54  struct sockaddr sa;
    55  # ifdef AF_INET6
    56  struct sockaddr_in6 sin6;
    57  # endif
    58  struct sockaddr_in sin;
    59  # ifdef AF_UNIX
    60  struct sockaddr_un sun;
    61  # endif
    62  };
    63  #endif


Best regards,

--- Kiyoshi 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4314
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL 1.1.0 and OCSP stapling with status_request_v2 (RFC 6961)

[Salz, Rich]

A GitHub Pull Request to do this would be very helpful.

We have a month and the team is busy...
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4313] [PATCH] Fix build for !IMPLEMENTED code path in CRYPTO_secure_free()

[David Woodhouse via RT]

Commit 05c7b1631 ("Implement the use of heap manipulator implementions")
added 'file' and 'line' arguments to CRYPTO_free() and friends, but neglected
to fix up the !IMPLEMENTED case within CRYPTO_secure_free(). Add the missing
arguments there too.
---
 crypto/mem_sec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/mem_sec.c b/crypto/mem_sec.c
index be3bb9a..fdda487 100644
--- a/crypto/mem_sec.c
+++ b/crypto/mem_sec.c
@@ -138,7 +138,7 @@ void CRYPTO_secure_free(void *ptr, const char *file, int 
line)
 sh_free(ptr);
 UNLOCK();
 #else
-CRYPTO_free(ptr);
+CRYPTO_free(ptr, file, line);
 #endif /* IMPLEMENTED */
 }
 
-- 
2.5.0

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4313
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content

[David Woodhouse]

On Tue, 2015-12-08 at 12:56 +, Salz, Rich via RT wrote:
> I think that instead of the #ifdef being removed, the if() test
> should be removed. This was my mistake.

Like this, then... 

https://github.com/openssl/openssl/pull/694 for HEAD
https://github.com/openssl/openssl/pull/695 for 1.0.2

If you say that removing the #ifdef instead of removing the whole code
block that it contained was a mistake, then I shall take you at your
word and refrain from harping on *too* much about how naughty it was to
have a functional change hidden away in a commit which simply entitled
itself "Memory leak fixes", without even any acknowledgement of the
change in the body of the commit comment :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

From 5e95ba001efb38963a06e1447fde21f06355468d Mon Sep 17 00:00:00 2001
From: David Woodhouse 
Date: Wed, 17 Feb 2016 11:34:14 +
Subject: [PATCH] RT4175: Fix regression using PKCS7_verify() with Authenticode

Authenticode uses an extended PKCS#7 format, where the embedded data are
not directly the data to be verified; instead an Authenticode-specific
data structure (SpcIndirectDataContent) is embedded, which describes
the various files covered by the Authenticode signature.

In this case, we need to allow PKCS7_verify() to be called with external
data even though PKCS7_get_detached() is not true.

This always used to work; there was a "sanity" check for external data
being passed to PKCS7_verify() with a non-detached PKCS#7 signature, but
it was always #ifdef'd out.

It was broken in HEAD by commit 55500ea7c ("GH354: Memory leak fixes") and
in 1.0.2 by cherry-picking that same commit to become c8491de39.
---
 crypto/pkcs7/pk7_smime.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/crypto/pkcs7/pk7_smime.c b/crypto/pkcs7/pk7_smime.c
index ed5268f..87279a3 100644
--- a/crypto/pkcs7/pk7_smime.c
+++ b/crypto/pkcs7/pk7_smime.c
@@ -279,12 +279,6 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
 return 0;
 }
 
-/* Check for data and content: two sets of data */
-if (!PKCS7_get_detached(p7) && indata) {
-PKCS7err(PKCS7_F_PKCS7_VERIFY, PKCS7_R_CONTENT_AND_DATA_PRESENT);
-return 0;
-}
-
 sinfos = PKCS7_get_signer_info(p7);
 
 if (!sinfos || !sk_PKCS7_SIGNER_INFO_num(sinfos)) {
-- 
2.5.0



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4175] Add new macro or PKCS7 flag to disable the check for both data and content

[David Woodhouse via RT]

On Tue, 2015-12-08 at 12:56 +, Salz, Rich via RT wrote:
> I think that instead of the #ifdef being removed, the if() test
> should be removed. This was my mistake.

Like this, then... 

https://github.com/openssl/openssl/pull/694 for HEAD
https://github.com/openssl/openssl/pull/695 for 1.0.2

If you say that removing the #ifdef instead of removing the whole code
block that it contained was a mistake, then I shall take you at your
word and refrain from harping on *too* much about how naughty it was to
have a functional change hidden away in a commit which simply entitled
itself "Memory leak fixes", without even any acknowledgement of the
change in the body of the commit comment :)

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4175
Please log in as guest with password guest if prompted

>From 5e95ba001efb38963a06e1447fde21f06355468d Mon Sep 17 00:00:00 2001
From: David Woodhouse 
Date: Wed, 17 Feb 2016 11:34:14 +
Subject: [PATCH] RT4175: Fix regression using PKCS7_verify() with Authenticode

Authenticode uses an extended PKCS#7 format, where the embedded data are
not directly the data to be verified; instead an Authenticode-specific
data structure (SpcIndirectDataContent) is embedded, which describes
the various files covered by the Authenticode signature.

In this case, we need to allow PKCS7_verify() to be called with external
data even though PKCS7_get_detached() is not true.

This always used to work; there was a "sanity" check for external data
being passed to PKCS7_verify() with a non-detached PKCS#7 signature, but
it was always #ifdef'd out.

It was broken in HEAD by commit 55500ea7c ("GH354: Memory leak fixes") and
in 1.0.2 by cherry-picking that same commit to become c8491de39.
---
 crypto/pkcs7/pk7_smime.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/crypto/pkcs7/pk7_smime.c b/crypto/pkcs7/pk7_smime.c
index ed5268f..87279a3 100644
--- a/crypto/pkcs7/pk7_smime.c
+++ b/crypto/pkcs7/pk7_smime.c
@@ -279,12 +279,6 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
 return 0;
 }
 
-/* Check for data and content: two sets of data */
-if (!PKCS7_get_detached(p7) && indata) {
-PKCS7err(PKCS7_F_PKCS7_VERIFY, PKCS7_R_CONTENT_AND_DATA_PRESENT);
-return 0;
-}
-
 sinfos = PKCS7_get_signer_info(p7);
 
 if (!sinfos || !sk_PKCS7_SIGNER_INFO_num(sinfos)) {
-- 
2.5.0



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Richard Levitte via RT]

May I suggest that you use EVP_CIPHER_set_asn1_iv() and/or
EVP_CIPHER_get_asn1_iv()? With a temporary ASN1_TYPE to which you assign
gcp->iv, that should be perfectly possible, no?

Cheers,
Richard

Vid Ons, 17 Feb 2016 kl. 09.53.04, skrev beld...@gmail.com:
> Dear Richard,
>
> I am not sure it will not break the compatibility.
> Both implementations of the GOST ciphers require access to this field.
>
> On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT 
> wrote:
>
> > Hi,
> >
> > I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
> > thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in
> > essence,
> > it's a EVP private store of the IV that was given at EVP_CipherInit().
> >
> > If you want to retain a copy of the original IV, I suggest you have one in
> > GOSTs structure and take a copy of the IV given to the init() function.
> >
> > Thank you for the reminder, I meant to deal with this further. oiv should
> > really not be publically accessible at all, not even as a constant.
> >
> > Cheers,
> > Richard
> >
> > Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > > Hello,
> > >
> > > After making the EVP_CIPHER_CTX struct opaque I found that there is a
> > > missing non-const accessor to the oiv member. It is used in GOST engine
> > > when we set the cipher parameters from the ASN1 parameters.
> > >
> > > Thank you!
> > >
> >
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> > Please log in as guest with password guest if prompted
> >
> >
>
>


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky via RT]

Dear Richard,

I am not sure it will not break the compatibility.
Both implementations of the GOST ciphers require access to this field.

On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT 
wrote:

> Hi,
>
> I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
> thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in
> essence,
> it's a EVP private store of the IV that was given at EVP_CipherInit().
>
> If you want to retain a copy of the original IV, I suggest you have one in
> GOSTs structure and take a copy of the IV given to the init() function.
>
> Thank you for the reminder, I meant to deal with this further. oiv should
> really not be publically accessible at all, not even as a constant.
>
> Cheers,
> Richard
>
> Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > Hello,
> >
> > After making the EVP_CIPHER_CTX struct opaque I found that there is a
> > missing non-const accessor to the oiv member. It is used in GOST engine
> > when we set the cipher parameters from the ASN1 parameters.
> >
> > Thank you!
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Dmitry Belyavsky]

Dear Richard,

I am not sure it will not break the compatibility.
Both implementations of the GOST ciphers require access to this field.

On Wed, Feb 17, 2016 at 12:42 PM, Richard Levitte via RT 
wrote:

> Hi,
>
> I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
> thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in
> essence,
> it's a EVP private store of the IV that was given at EVP_CipherInit().
>
> If you want to retain a copy of the original IV, I suggest you have one in
> GOSTs structure and take a copy of the IV given to the init() function.
>
> Thank you for the reminder, I meant to deal with this further. oiv should
> really not be publically accessible at all, not even as a constant.
>
> Cheers,
> Richard
>
> Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> > Hello,
> >
> > After making the EVP_CIPHER_CTX struct opaque I found that there is a
> > missing non-const accessor to the oiv member. It is used in GOST engine
> > when we set the cipher parameters from the ASN1 parameters.
> >
> > Thank you!
> >
>
>
> --
> Richard Levitte
> levi...@openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
> Please log in as guest with password guest if prompted
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4267] Missing accessor to the EVP_CIPHER_CTX member oiv

[Richard Levitte via RT]

Hi,

I'm sorry, the oiv field is EVP private. Sure, it's been accessible (and
thoroughly misused in some cases) when EVP_CIPHER_CTX was open, but in essence,
it's a EVP private store of the IV that was given at EVP_CipherInit().

If you want to retain a copy of the original IV, I suggest you have one in
GOSTs structure and take a copy of the IV given to the init() function.

Thank you for the reminder, I meant to deal with this further. oiv should
really not be publically accessible at all, not even as a constant.

Cheers,
Richard

Vid Sat, 23 Jan 2016 kl. 09.40.19, skrev beld...@gmail.com:
> Hello,
>
> After making the EVP_CIPHER_CTX struct opaque I found that there is a
> missing non-const accessor to the oiv member. It is used in GOST engine
> when we set the cipher parameters from the ASN1 parameters.
>
> Thank you!
>


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4267
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL 1.1.0 and OCSP stapling with status_request_v2 (RFC 6961)

[Jouni Malinen]

It looks like there are some upcoming use cases that would need to be
able to use OCSP stapling to verify both the server certificate and the
intermediate CA certificate that issued that server certificate. This
would require support for RFC 6961 extensions to OCSP stapling. Since
the actual OCSP stapling processing is currently done outside the
OpenSSL library, the changes to allow this to be used on the TLS client
side would be pretty minimal for the library.

The current API does not allow this to be done since the
SSL_set_tlsext_status_type() function allows only one value
(TLSEXT_STATUSTYPE_ocsp = 1) to be used. It would be nice if OpenSSL
1.1.0 would make it possible to use the ocsp_multi(2) value in
status_request_v2(17) ClientHello extension. Other than the different
extension type and status type values (and listing both ocsp and
ocsp_multi types), the contents on that extension is identical to the
existing status_request case.

Since the OCSP stapling response is processed outside the library
handshake processing, a minimal support for this within OpenSSL would
not need other changes there than just accepting ocsp_multi(2) in
addition to the current TLSEXT_STATUSTYPE_ocsp(1). More could obviously
be added later to help parsing in applications, but that is not critical
for OpenSSL 1.1.0 to enable this functionality.

Would there be interest in getting at least the minimal changes in place
before the beta release so that OpenSSL 1.1.0 could be used to implement
ocsp_multi support for TLS client?

As far as the TLS messages are concerned, these are the changes needed
for the use cases I'm thinking of:

Building ClientHello:

Add status_request_v2 extension with minimal contents:
00 11 00 07 00 05 02 00 00 00 00

This is very similar to status_request extension that can currently be
added:
00 05 00 05 01 00 00 00 00

Parsing ServerHello:
Accept status_request_v2 extension

Parsing CertificateStatus:
Accept certificate status type ocsp_multi(2)

-- 
Jouni MalinenPGP id EFC895FA
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] OpenSSL version 1.1.0 pre release 3 published

[Dmitry Belyavsky]

Dear Rich,


> Just to emphasize one important point:  Our next release is planned to be
> Beta-1, in about a month.  After that, no new API's or features will be
> added to OpenSSL 1.1
>
>
If so, could you take a look at RT#4267?

Thank you!

-- 
SY, Dmitry Belyavsky
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev