Re: Race Condition

[Dr Paul Dale]

I did confuse things, apologies.
One day I’ll learn that I shouldn’t answer questions late on a Friday evening 
after a long week.

Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 15 Jun 2019, at 5:33 am, Viktor Dukhovni  
> wrote:
> 
>> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale  wrote:
>> 
>> The SSL sessions are not thread safe.  It is up to the calling application 
>> to ensure that this race condition does not occur.
> 
> Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).
> 
> -- 
>   Viktor.
> 

Re: Race Condition

[Viktor Dukhovni]

> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale  wrote:
> 
> The SSL sessions are not thread safe.  It is up to the calling application to 
> ensure that this race condition does not occur.

Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).

-- 
Viktor.

Re: failing in reproducing .so files

[Salz, Rich via openssl-users]

If you are adding new functions to the library, you need to
1A   Make sure there is a prototype in one of the existing OpenSSL 
header files;
OR
1B   If your prototype is in a new header file, you will have to edit 
Configurations/unix-Makefile.tmpl to pick up that file.

2  Run configure

3.Do “make update”  Verify that the previous steps worked by 
looking for your new function(s) being declared in util/libcrypto.num

4.Run make

This could be documented somewhere; anyone want to copy this email into a new 
issue?

Re: failing in reproducing .so files

[Kyle Hamilton]

Log into a different terminal window, run top.  Figure out if it's
infinitely looping, if it's getting stuck in a syscall (which sounds likely
-- if it is the case, you need to figure out why, which could be as simple
as a needed fsck or a required kernel update to address a bug), or if you
can kill -9 it when it gets in that state.

You can also try compiling your code on a different machine.  If it fails
there, try a different distribution of your OS (if available).  If these
all fail, it could be something that the OpenSSL team might need to address
in the script.

Good luck.

-Kyle H

On Fri, Jun 14, 2019, 13:13 Giovanni Fontana 
wrote:

> A little bit further...with my problem in trying to build a tailored
> version of openSSL.
>
> If I do make I get at the end of building (trying to make .map file
> before the .so files )
>
>  creating test/libtestutil.a
> ranlib test/libtestutil.a || echo Never mind.
> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
> Error: EVP_PKEY_get0_TUV does not have a number assigned
> Makefile:762: recipe for target 'libcrypto.map' failed
> make[1]: *** [libcrypto.map] Error 25
> make[1]: Leaving directory
> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
> Makefile:172: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
> EVP_PKEY_get0_RSA (),
> Usually with a function that *does not have a number assigned *it could
> be ok to do a *make update*, but when I run a *make update* it stopped
> after a small while without concluding the action (and no more commands I
> can run in that terminal window).
> Here the log:
>
> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
> < apps/openssl.cnf > apps/openssl-vms.cnf )
> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > crypto/objects/obj_mac.new && \
> mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > include/openssl/obj_mac.h )
> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
> include/openssl/obj_mac.h \
> > crypto/objects/obj_dat.h )
> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
> crypto/objects/obj_mac.num \
> crypto/objects/obj_xref.txt \
> > crypto/objects/obj_xref.h )
> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
> > crypto/conf/conf_def.h )
> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
> > crypto/asn1/charmap.h )
> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
> crypto/objects/obj_dat.h \
> > fuzz/oids.txt )
> ( b=`pwd`; set -e; cd .; \
>   /usr/bin/perl util/ck_errf.pl -strict -internal; \
>   /usr/bin/perl -I$b util/mkerr.pl  -internal )
>
>
>
>
> ... as I said the compilation is OK for each file (even the one with
> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>
> Kind regards
> Giovanni Fontana
>
>
>
>
> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton 
> ha scritto:
>
>> In the unmodified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>
>> In the modified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>
>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>> ${PAGER:more}
>>
>> Take note of the differences in output, and use that to determine what
>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>> when you need to capture why something is failing.)
>>
>> Good luck.
>>
>> -Kyle H
>>
>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>> giovanni.fontan...@gmail.com> wrote:
>>
>>> The unmodified version works. As I said, it's sure the issue is on what
>>> I added, but info from the building logs is not sufficient to figure out
>>> what is the issue there. So as result of the building I have just:
>>>
>>>- libcrypto.a
>>>- libssl.a
>>>- libcrypto.map
>>>
>>>
>>> so what is missing are the following files:
>>>
>>>- libssl.map
>>>- libcrypto.so
>>>- libssl.so
>>>
>>>
>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
>>> aerow...@gmail.com> ha scritto:
>>>
 Can you try building an unmodified version of the tarball, and see if
 it has a problem?

 -Kyle

 On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
 giovanni.fontan...@gmail.com> wrote:

> Hello Kurt,
>
>
>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>x86_64-linux-gnu-thread-multi
>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
>
> I guess is something from what I added since the original OPENSSL I'm
> able to build, as well as other i

Re: failing in reproducing .so files

[Giovanni Fontana]

...I just tried once more and (after a make clean) I run again a make
update, but it is stopped always in the same place. No more commands in
that specific terminal.
After that opening a new terminal and run the make, of course, I get the
same error again (Error: EVP_PKEY_get0_TUV does not have a number assigned).


Il giorno ven 14 giu 2019 alle ore 20:16 Dmitry Belyavsky 
ha scritto:

> It's worth trying to run make update before running make.
>
> пт, 14 июн. 2019 г., 20:13 Giovanni Fontana  >:
>
>> A little bit further...with my problem in trying to build a tailored
>> version of openSSL.
>>
>> If I do make I get at the end of building (trying to make .map file
>> before the .so files )
>>
>>  creating test/libtestutil.a
>> ranlib test/libtestutil.a || echo Never mind.
>> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
>> Error: EVP_PKEY_get0_TUV does not have a number assigned
>> Makefile:762: recipe for target 'libcrypto.map' failed
>> make[1]: *** [libcrypto.map] Error 25
>> make[1]: Leaving directory
>> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
>> Makefile:172: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>>
>>
>> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
>> EVP_PKEY_get0_RSA (),
>> Usually with a function that *does not have a number assigned *it could
>> be ok to do a *make update*, but when I run a *make update* it stopped
>> after a small while without concluding the action (and no more commands I
>> can run in that terminal window).
>> Here the log:
>>
>> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
>> < apps/openssl.cnf > apps/openssl-vms.cnf )
>> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
>> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
>> crypto/objects/objects.txt \
>> crypto/objects/obj_mac.num \
>> > crypto/objects/obj_mac.new && \
>> mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
>> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
>> crypto/objects/objects.txt \
>> crypto/objects/obj_mac.num \
>> > include/openssl/obj_mac.h )
>> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
>> include/openssl/obj_mac.h \
>> > crypto/objects/obj_dat.h )
>> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
>> crypto/objects/obj_mac.num \
>> crypto/objects/obj_xref.txt \
>> > crypto/objects/obj_xref.h )
>> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
>> > crypto/conf/conf_def.h )
>> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
>> > crypto/asn1/charmap.h )
>> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
>> crypto/objects/obj_dat.h \
>> > fuzz/oids.txt )
>> ( b=`pwd`; set -e; cd .; \
>>   /usr/bin/perl util/ck_errf.pl -strict -internal; \
>>   /usr/bin/perl -I$b util/mkerr.pl  -internal )
>>
>>
>>
>>
>> ... as I said the compilation is OK for each file (even the one with
>> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>>
>> Kind regards
>> Giovanni Fontana
>>
>>
>>
>>
>> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton <
>> aerow...@gmail.com> ha scritto:
>>
>>> In the unmodified directory:
>>> $ make clean
>>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>>
>>> In the modified directory:
>>> $ make clean
>>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>>
>>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>>> ${PAGER:more}
>>>
>>> Take note of the differences in output, and use that to determine what
>>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>>> when you need to capture why something is failing.)
>>>
>>> Good luck.
>>>
>>> -Kyle H
>>>
>>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>>> giovanni.fontan...@gmail.com> wrote:
>>>
 The unmodified version works. As I said, it's sure the issue is on what
 I added, but info from the building logs is not sufficient to figure out
 what is the issue there. So as result of the building I have just:

- libcrypto.a
- libssl.a
- libcrypto.map


 so what is missing are the following files:

- libssl.map
- libcrypto.so
- libssl.so


 Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
 aerow...@gmail.com> ha scritto:

> Can you try building an unmodified version of the tarball, and see if
> it has a problem?
>
> -Kyle
>
> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
> giovanni.fontan...@gmail.com> wrote:
>
>> Hello Kurt,
>>
>>
>>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>x86_64-linux-gnu-thread-multi
>>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>
>>
>> I guess is something from what I added since the original OPENSSL I'm
>> able to build, as well as o

Re: failing in reproducing .so files

[Dmitry Belyavsky]

It's worth trying to run make update before running make.

пт, 14 июн. 2019 г., 20:13 Giovanni Fontana :

> A little bit further...with my problem in trying to build a tailored
> version of openSSL.
>
> If I do make I get at the end of building (trying to make .map file
> before the .so files )
>
>  creating test/libtestutil.a
> ranlib test/libtestutil.a || echo Never mind.
> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
> Error: EVP_PKEY_get0_TUV does not have a number assigned
> Makefile:762: recipe for target 'libcrypto.map' failed
> make[1]: *** [libcrypto.map] Error 25
> make[1]: Leaving directory
> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
> Makefile:172: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
> EVP_PKEY_get0_RSA (),
> Usually with a function that *does not have a number assigned *it could
> be ok to do a *make update*, but when I run a *make update* it stopped
> after a small while without concluding the action (and no more commands I
> can run in that terminal window).
> Here the log:
>
> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
> < apps/openssl.cnf > apps/openssl-vms.cnf )
> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > crypto/objects/obj_mac.new && \
> mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
> crypto/objects/objects.txt \
> crypto/objects/obj_mac.num \
> > include/openssl/obj_mac.h )
> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
> include/openssl/obj_mac.h \
> > crypto/objects/obj_dat.h )
> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
> crypto/objects/obj_mac.num \
> crypto/objects/obj_xref.txt \
> > crypto/objects/obj_xref.h )
> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
> > crypto/conf/conf_def.h )
> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
> > crypto/asn1/charmap.h )
> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
> crypto/objects/obj_dat.h \
> > fuzz/oids.txt )
> ( b=`pwd`; set -e; cd .; \
>   /usr/bin/perl util/ck_errf.pl -strict -internal; \
>   /usr/bin/perl -I$b util/mkerr.pl  -internal )
>
>
>
>
> ... as I said the compilation is OK for each file (even the one with
> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>
> Kind regards
> Giovanni Fontana
>
>
>
>
> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton 
> ha scritto:
>
>> In the unmodified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>
>> In the modified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>
>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>> ${PAGER:more}
>>
>> Take note of the differences in output, and use that to determine what
>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>> when you need to capture why something is failing.)
>>
>> Good luck.
>>
>> -Kyle H
>>
>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>> giovanni.fontan...@gmail.com> wrote:
>>
>>> The unmodified version works. As I said, it's sure the issue is on what
>>> I added, but info from the building logs is not sufficient to figure out
>>> what is the issue there. So as result of the building I have just:
>>>
>>>- libcrypto.a
>>>- libssl.a
>>>- libcrypto.map
>>>
>>>
>>> so what is missing are the following files:
>>>
>>>- libssl.map
>>>- libcrypto.so
>>>- libssl.so
>>>
>>>
>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
>>> aerow...@gmail.com> ha scritto:
>>>
 Can you try building an unmodified version of the tarball, and see if
 it has a problem?

 -Kyle

 On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
 giovanni.fontan...@gmail.com> wrote:

> Hello Kurt,
>
>
>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>x86_64-linux-gnu-thread-multi
>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
>
> I guess is something from what I added since the original OPENSSL I'm
> able to build, as well as other intermediate modifications. My issue is
> it looks like the log doesn't give so much info and also the *make
> update* doesn't complete his task.
>
> BR
> Giovanni
>
> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx 
> ha scritto:
>
>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION
>> scriptcollect2:
>>
>> There seems to be a problem generating the libcrypto.map file for
>> you. What does the file lo

Re: failing in reproducing .so files

[Giovanni Fontana]

A little bit further...with my problem in trying to build a tailored
version of openSSL.

If I do make I get at the end of building (trying to make .map file before
the .so files )

 creating test/libtestutil.a
ranlib test/libtestutil.a || echo Never mind.
/usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
Error: EVP_PKEY_get0_TUV does not have a number assigned
Makefile:762: recipe for target 'libcrypto.map' failed
make[1]: *** [libcrypto.map] Error 25
make[1]: Leaving directory
'/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
Makefile:172: recipe for target 'all' failed
make: *** [all] Error 2



...where EVP_PKEY_get0_TUV is a proprietary function similar to
EVP_PKEY_get0_RSA (),
Usually with a function that *does not have a number assigned *it could be
ok to do a *make update*, but when I run a *make update* it stopped after a
small while without concluding the action (and no more commands I can run
in that terminal window).
Here the log:

( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
< apps/openssl.cnf > apps/openssl-vms.cnf )
( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
crypto/objects/objects.txt \
crypto/objects/obj_mac.num \
> crypto/objects/obj_mac.new && \
mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
( cd .; /usr/bin/perl crypto/objects/objects.pl \
crypto/objects/objects.txt \
crypto/objects/obj_mac.num \
> include/openssl/obj_mac.h )
( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
include/openssl/obj_mac.h \
> crypto/objects/obj_dat.h )
( cd .; /usr/bin/perl crypto/objects/objxref.pl \
crypto/objects/obj_mac.num \
crypto/objects/obj_xref.txt \
> crypto/objects/obj_xref.h )
( cd .; /usr/bin/perl crypto/conf/keysets.pl \
> crypto/conf/conf_def.h )
( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
> crypto/asn1/charmap.h )
( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
crypto/objects/obj_dat.h \
> fuzz/oids.txt )
( b=`pwd`; set -e; cd .; \
  /usr/bin/perl util/ck_errf.pl -strict -internal; \
  /usr/bin/perl -I$b util/mkerr.pl  -internal )




... as I said the compilation is OK for each file (even the one with
EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?

Kind regards
Giovanni Fontana




Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton 
ha scritto:

> In the unmodified directory:
> $ make clean
> $ make 2>&1 | tee /tmp/openssl-working-build.log
>
> In the modified directory:
> $ make clean
> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>
> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
> ${PAGER:more}
>
> Take note of the differences in output, and use that to determine what
> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
> when you need to capture why something is failing.)
>
> Good luck.
>
> -Kyle H
>
> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana 
> wrote:
>
>> The unmodified version works. As I said, it's sure the issue is on what I
>> added, but info from the building logs is not sufficient to figure out what
>> is the issue there. So as result of the building I have just:
>>
>>- libcrypto.a
>>- libssl.a
>>- libcrypto.map
>>
>>
>> so what is missing are the following files:
>>
>>- libssl.map
>>- libcrypto.so
>>- libssl.so
>>
>>
>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton 
>> ha scritto:
>>
>>> Can you try building an unmodified version of the tarball, and see if it
>>> has a problem?
>>>
>>> -Kyle
>>>
>>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
>>> giovanni.fontan...@gmail.com> wrote:
>>>
 Hello Kurt,


- it's perl 5, version 26, subversion 1 (v5.26.1) built for
x86_64-linux-gnu-thread-multi
- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27


 I guess is something from what I added since the original OPENSSL I'm
 able to build, as well as other intermediate modifications. My issue is
 it looks like the log doesn't give so much info and also the *make
 update* doesn't complete his task.

 BR
 Giovanni

 Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx 
 ha scritto:

> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>
> There seems to be a problem generating the libcrypto.map file for
> you. What does the file look like? Which perl version are you
> using? Which libc do you use?
>
>
> Kurt
>
>

Re: RSA PSS RSAE Cert Generation

[Matt Caswell]

On 14/06/2019 13:28, Raja Ashok wrote:
> Hi All,
> 
> For using with TLS1.3, I am able to generate rsa_pss_pss cert (Both Public key
> and Signature of RSA_PSS OID) with the below script.
> 
> https://github.com/raja-ashok/sample_certificates/blob/master/RSA_PSS_PSS_Certs/gen_rsa_cert.sh
> 
> Can some one help me to find out the command for generating rsa_pss_rsae cert
> (Public key of rsaEncryption OID and Signature of RSA PSS OID) ?

It's not entirely clear to me what you are asking for. In your script you
generate a root certificate and a server certificate. Both the root and the
server certificate use the RSA PSS OID. The signature in the server certificate
will be PSS because the root is using the PSS OID.

If you want to generate a server certificate that uses the rsaEncryption OID
then just drop the "-sigopt rsa_padding_mode:pss" option from the command
generating the serv_req.pem file. The rsaEncryption OID is the default.

The signature in the certificate depends on the oid in the root certificate and
how you sign using it. Since your root uses the RSA PSS OID then the signature
in the server cert will still be PSS.

But I'm not sure that is what you are actually asking for. There is no such
thing as an "rsa_pss_rsae" certificate. I think you are confusing the sig algs
from TLSv1.3 with the certificate type. In order to use the "rsa_pss_rsae" sig
alg in TLSv1.3 all you need is an RSA certificate with the rsaEncryption OID. It
makes no difference what the signature in the certificate is (that is only
relevant for verifying the chain). As long as you use a cert with the
rsaEncryption OID in it, and you negotiate TLSv1.3, then any signatures
generated during the handshake will be PSS signatures using an rsa_pss_rsae sig 
alg.

Matt

Re: Race Condition

[Dr Paul Dale]

The SSL sessions are not thread safe.  It is up to the calling application to 
ensure that this race condition does not occur.


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 14 Jun 2019, at 8:09 pm, Serti Ayoub  wrote:
> 
> Hi,
> 
> We upgraded a code base from openssl 1.0.2 to openssl1.1.1b.
> The upgrade was straightforward and we manage to activate and use TLS1.3.
> OpenSSL is used to implement multi-threaded HTTPS server. 
> 
> While using TLS1.3 as the minimum version with option SSL_OP_NO_TICKET  the 
> app crash randomly due to a race condition in openssl, exactly when 2 threads 
> use the same SSL_SESSION*.
> 
> Some t
> 
> We don't install any session management callback and we keep session caching 
> mode to 2 ( SSL_SESS_CACHE_SERVER).
> 
> I made some debugging/tracing and I found that SSL_OP_NO_TICKET force openssl 
> to call lookup_sess_in_cache() function ( file ssl_sess.c )  
> 
> CRYPTO_THREAD_read_lock(s->session_ctx->lock);
> ret = lh_SSL_SESSION_retrieve(s->session_ctx->sessions, &data);
> if (ret != NULL) {
> /* don't allow other threads to steal it: */
> SSL_SESSION_up_ref(ret);
> }
> CRYPTO_THREAD_unlock(s->session_ctx->lock);
> 
> lh_SSL_SESSION_retriev() doesn't make any lock check in retrieved session and 
> lookup_sess_in_cache don't lock the session avec SSL_SESSION have a 
> CRYPT_RWLOCK member.
> 
> I can't provide a sample to reproduce the crash, it's totaly random.
>  
> Here example of thread call stack:
> 
> Thread1:
> libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET * pkt, 
> unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne 966  C
>   libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx, 
> int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx) 
> Ligne 715 C
>   libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context, 
> raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin) 
> Ligne 748C
>   libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) 
> Ligne 1883   C
>   libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE 
> wst) Ligne  C
>   libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s, 
> WORK_STATE wst) Ligne 1220   C
>   libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
>   libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434  
> C
>   libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
>   libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int * 
> recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned 
> __int64 * readbytes) Ligne 1270C
>   libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned 
> __int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473  C
>   libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64 
> len, unsigned __int64 * readbytes) Ligne 4498 C
>   libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned 
> __int64 num, unsigned __int64 * readbytes) Ligne 1754 C
>   libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766 
> C
> 
> Thread2:
>   libcrypto-1_1-x64.dll!CRYPTO_malloc(unsigned __int64 num, const char * 
> file, int line) Ligne 222C
>  libssl-1_1-x64.dll!tls1_save_u16(PACKET * pkt, wchar_t * * pdest, unsigned 
> __int64 * pdestlen) Ligne 1779C
>   libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET * 
> pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne 968  
>   C
>   libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx, 
> int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx) 
> Ligne 715 C
>   libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context, 
> raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin) 
> Ligne 748C
>   libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) 
> Ligne 1883   C
>   libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE 
> wst) Ligne  C
>   libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s, 
> WORK_STATE wst) Ligne 1220   C
>   libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
>   libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434  
> C
>   libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
>   libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int * 
> recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned 
> __int64 * readbytes) Ligne 1270C
>   libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned 
> __int64 len, int peek, unsigned __int64 * readby

RSA PSS RSAE Cert Generation

[Raja Ashok]

Hi All,

For using with TLS1.3, I am able to generate rsa_pss_pss cert (Both Public
key and Signature of RSA_PSS OID) with the below script.

https://github.com/raja-ashok/sample_certificates/blob/master/RSA_PSS_PSS_Certs/gen_rsa_cert.sh

Can some one help me to find out the command for generating rsa_pss_rsae
cert (Public key of rsaEncryption OID and Signature of RSA PSS OID) ?

Thanks in advance !
Raja Ashok

Re: Race Condition

[Matt Caswell]

On 14/06/2019 11:09, Serti Ayoub wrote:
> 
> I can't provide a sample to reproduce the crash, it's totaly random.
>  
> Here example of thread call stack:

Yes, this does look like a bug. My guess is most people don't hit this because
they don't set SSL_OP_NO_TICKET in TLSv1.3. The default behaviour is to use
stateless tickets which aren't shared between threads, so no race condition is
possible. However, with SSL_OP_NO_TICKET we use stateful tickets which means the
session objects *are* shared.

Session objects are supposed to be immutable after the initial handshake is
complete so that this sort of thing doesn't happen. Looks like that isn't the
case in the handling of supported groups. In reality there is no reason at all
to store the supported groups information in the session object since we don't
reuse that information from one session resume to another anyway so its just
misplaced in the session object.

Please try out this patch:

https://github.com/openssl/openssl/pull/9162

Matt

Race Condition

[Serti Ayoub]

Hi,

We upgraded a code base from openssl 1.0.2 to openssl1.1.1b.
The upgrade was straightforward and we manage to activate and use TLS1.3.
OpenSSL is used to implement multi-threaded HTTPS server.

While using TLS1.3 as the minimum version with option SSL_OP_NO_TICKET  the
app crash randomly due to a race condition in openssl, exactly when 2
threads use the same SSL_SESSION*.

Some t

We don't install any session management callback and we keep session
caching mode to 2 ( SSL_SESS_CACHE_SERVER).

I made some debugging/tracing and I found that SSL_OP_NO_TICKET force
openssl to call lookup_sess_in_cache() function ( file ssl_sess.c )

CRYPTO_THREAD_read_lock(s->session_ctx->lock);
ret = lh_SSL_SESSION_retrieve(s->session_ctx->sessions, &data);
if (ret != NULL) {
/* don't allow other threads to steal it: */
SSL_SESSION_up_ref(ret);
}
CRYPTO_THREAD_unlock(s->session_ctx->lock);

lh_SSL_SESSION_retriev() doesn't make any lock check in retrieved session
and lookup_sess_in_cache don't lock the session avec SSL_SESSION have a
CRYPT_RWLOCK member.

I can't provide a sample to reproduce the crash, it's totaly random.

Here example of thread call stack:

Thread1:
libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET *
pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne
966 C
  libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx,
int context, raw_extension_st * exts, x509_st * x, unsigned __int64
chainidx) Ligne 715 C
  libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context,
raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin)
Ligne 748 C
  libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne
1883 C
  libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE
wst) Ligne  C
  libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s,
WORK_STATE wst) Ligne 1220 C
  libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
  libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434 C
  libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
  libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int *
recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned
__int64 * readbytes) Ligne 1270 C
  libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned
__int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473 C
  libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64
len, unsigned __int64 * readbytes) Ligne 4498 C
  libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned
__int64 num, unsigned __int64 * readbytes) Ligne 1754 C
  libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766 C

Thread2:
  libcrypto-1_1-x64.dll!CRYPTO_malloc(unsigned __int64 num, const char *
file, int line) Ligne 222 C
 libssl-1_1-x64.dll!tls1_save_u16(PACKET * pkt, wchar_t * * pdest, unsigned
__int64 * pdestlen) Ligne 1779 C
  libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET *
pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne
968 C
  libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx,
int context, raw_extension_st * exts, x509_st * x, unsigned __int64
chainidx) Ligne 715 C
  libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context,
raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin)
Ligne 748 C
  libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne
1883 C
  libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE
wst) Ligne  C
  libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s,
WORK_STATE wst) Ligne 1220 C
  libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
  libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434 C
  libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
  libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int *
recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned
__int64 * readbytes) Ligne 1270 C
  libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned
__int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473 C
  libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64
len, unsigned __int64 * readbytes) Ligne 4498 C
  libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned
__int64 num, unsigned __int64 * readbytes) Ligne 1754 C
  libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766 C

SHA1_Init () is called through SSL_shutdown () in FIPS mode

[Chethan Kumar]

Hi all,

Need help in resolving an error or understanding the flow.
Openssl library we are using is FIPS capabled.
Openssl version is 1.0.2n with fips-2.0.16
Platform: Linux version 3.10.38-ltsi-WR6.0.0.11_standard (gcc version 4.8.1)
We have an application which uses libssl and libcrypto for its operations.
Application is crashing because of a call to SSL_shutdown().

Gdb trace is shown below.

(gdb) bt

#0  0x42926357 in raise () from /lib/libc.so.6

#1  0x42929962 in abort () from /lib/libc.so.6

#2  0x77453e7a in OpenSSLDie () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#3  0x7745d0d8 in SHA1_Init () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#4  0x774f75ee in init () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#5  0x774ee8e0 in EVP_DigestInit_ex () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#6  0x774ea1f9 in ssleay_rand_bytes () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#7  0x774ea413 in ssleay_rand_nopseudo_bytes () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#8  0x774eabd0 in RAND_bytes () from 
/home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#9  0x77654500 in tls1_enc () from 
/home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#10 0x77645eda in ssl3_dispatch_alert () from 
/home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#11 0x77644804 in ssl3_send_alert () from 
/home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#12 0x7764107e in ssl3_shutdown () from 
/home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#13 0x77662481 in SSL_shutdown () from 
/home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#14 0x088a300e in tcp_disconnect ()

#15 0x088a623f in soap_closesock ()

#16 0x08886929 in soap_serve___stg2__login(soap*) ()

#17 0x08865547 in soap_serve_request ()

#18 0x0885fdee in soap_serve ()

As far as I know, SHA1_Init() is restricted when FIPS is enabled.
I want to know, why SHA1_Init() was called even when FIPS is enabled.

Let me know, if any more information is required to resolve the issue.

Thanks in advance,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

Re: Shutting down openssl - is the correct thing to do nothing?

[Matt Caswell]

On 14/06/2019 09:17, Graham Leggett wrote:
> On 14 Jun 2019, at 09:41, Matt Caswell  > wrote:
> 
>> Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:
>>
>> #  define EVP_cleanup() while(0) continue
>>
>> There are one or two caveats around auto-init and auto-deinit of the library.
>> The documentation for it is here:
>>
>> https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html
> 
> Further to the above question, having read the documentation, it looks like 
> all
> of these init routines should be removed in v1.1.0 and above:

Mostly, but not quite. The library will automatically initialise itself with no
requirement to explicitly do so. However there are certain things that don't
happen automatically because they're not necessarily appropriate for all
applications. See comments below:

> 
> https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l398
> 
> CRYPTO_malloc_init();

This function doesn't exist at all in 1.1.0+.

> OPENSSL_malloc_init();

This is a no-op in 1.1.0+

> ERR_load_crypto_strings();
> SSL_load_error_strings();
> SSL_library_init();

These all happen automatically. There is no need to call them directly. They're
all macros for calling OPENSSL_init_crypto() explicitly with default
options...but since they are default options anyway there is no need to do this.

> ENGINE_load_builtin_engines();

This does NOT happen automatically. It is a non-default option in
OPENSSL_init_crypto(). You can get the same effect by calling
OPENSSL_init_crypto with the OPENSSL_INIT_ENGINE_ALL_BUILTIN option explicitly. 
See:

https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html

> OpenSSL_add_all_algorithms();

No need to call this one. Its a macro for calling OPENSSL_init_crypto()
explicitly with default options - but this will happen anyway.

> OPENSSL_load_builtin_modules();

This does NOT happen automatically if you are just using libcrypto. This is used
for initialising config file modules. libcrypto does not automatically load a
config file. If you call OPENSSL_init_crypto() explicitly with the
OPENSSL_INIT_LOAD_CONFIG option then it will load the config file and end up
calling the above function automatically as part of that.

In 1.1.1 a config file is loaded automatically for libssl users. So if you're a
1.1.1 libssl user then you don't need to call this function. A config file is
not loaded automatically for libssl in 1.1.0.

It is expected that in OpenSSL 3.0 loading a config file will happen
automatically in both libcrypto and libssl.

> 
> https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l133
> 
> CRYPTO_malloc_init();
> OPENSSL_malloc_init();
> ERR_load_crypto_strings();
> OpenSSL_add_all_algorithms();
> ENGINE_load_builtin_engines();

As above.

> ENGINE_register_all_complete();

This is the same as for ENGINE_load_builtin_engines(). It does NOT happen
automatically, but will get called if you use the
OPENSSL_INIT_ENGINE_ALL_BUILTIN option to OPENSSL_init_crypto.


Matt
> 
> Can you confirm I’ve interpreted this correctly?
> 
> Regards,
> Graham
> —
> 

Re: Shutting down openssl - is the correct thing to do nothing?

[Graham Leggett]

On 14 Jun 2019, at 09:41, Matt Caswell  wrote:

> Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:
> 
> #  define EVP_cleanup() while(0) continue
> 
> There are one or two caveats around auto-init and auto-deinit of the library.
> The documentation for it is here:
> 
> https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html 
> 

Further to the above question, having read the documentation, it looks like all 
of these init routines should be removed in v1.1.0 and above:

https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l398

CRYPTO_malloc_init();
OPENSSL_malloc_init();
ERR_load_crypto_strings();
SSL_load_error_strings();
SSL_library_init();
ENGINE_load_builtin_engines();
OpenSSL_add_all_algorithms();
OPENSSL_load_builtin_modules();

https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l133

CRYPTO_malloc_init();
OPENSSL_malloc_init();
ERR_load_crypto_strings();
OpenSSL_add_all_algorithms();
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();

Can you confirm I’ve interpreted this correctly?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Shutting down openssl - is the correct thing to do nothing?

[Matt Caswell]

On 14/06/2019 00:42, Graham Leggett wrote:
> Hi all,
> 
> I am currently reviewing the shutdown behaviour in both httpd’s mod_ssl and 
> apr’s apr-crypto-openssl modules.
> 
> Am I right in understanding that from openssl v1.1.0 and upwards, all the 
> following calls are no longer necessary, will be called automatically atexit 
> by the openssl library, and these can be removed from the code?
> 
> https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l329
> 
> FIPS_mode_set(0);
> OBJ_cleanup();
> CONF_modules_free();
> EVP_cleanup();
> ENGINE_cleanup();
> SSL_COMP_free_compression_methods();
> ERR_remove_thread_state(NULL);
> ERR_remove_state(0);
> ERR_free_strings();
> CRYPTO_cleanup_all_ex_data();
> 
> https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l114
> 
> ERR_free_strings();
> EVP_cleanup();
> ENGINE_cleanup();
> 

Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:

#  define EVP_cleanup() while(0) continue

There are one or two caveats around auto-init and auto-deinit of the library.
The documentation for it is here:

https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html

Matt