RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

[tim.j.culhane]

Hi,

Just to say that you can get the -Fpic flag  by using the  'shared' argument
to  the Configure script.   The following works for me:

./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1
--openssldir=/opt/openssl/1.1.1 -lrt -m64 shared zlib

Regards,

Tim


-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Thursday 16 April 2020 18:16
To: openssl-users@openssl.org
Subject: RE: building a PIC enabled version of openssl 1.0.2k on Sparc 10

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> Behalf Of tim.j.culh...@gmail.com
> Sent: Thursday, April 16, 2020 08:36
>
> I'm building a PIC enabled shared library in my server which links 
> against openssl 1.0.2k libssl.a library on Sparc 10.
>
> When compiling  I see the below errors.
>
> I  originally built  the 1.0.2k version of openssl with the following 
> configure  arguments:
>
> ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k 
> --openssldir=/opt/openssl/1.0.2k -lrt -m64
>
> Do I need to  pass in  the  -fPIC flag as well, and if so  how do I do
that.

I believe you do, though our use case is different - we build OpenSSL as a
PIC archive library, which we then linked into a shared object. If you're
building OpenSSL as a shared object (well, a pair of shared objects, for
libcrypto and libssl), then you may be able to do that with the appropriate
Configure options.

My teams have switched to 1.1.1, so I don't have a 1.0.2 build handy to
check.

> I appended it to the end of the  configure  line I  show above  but 
> there was no sign of PIC in any of the top level makefiles produced.

For 1.0.2, we edited the Configure file. We kept a log of the purposes of
our changes, and looked at the Configure diffs for each new 1.0.2 release so
we could port the relevant changes back to our Configure.

We haven't had to do that with 1.1.1; its Configure is more flexible.

--

Michael Wojcik
Distinguished Engineer, Micro Focus

building a PIC enabled version of openssl 1.0.2k on Sparc 10

[tim.j.culhane]

Hi,

I'm building a PIC enabled shared library in my server which links against
openssl 1.0.2k libssl.a library on Sparc 10.

When compiling  I see the below errors.

I  originally built  the 1.0.2k version of openssl with the following
configure  arguments:

./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.0.2k
--openssldir=/opt/openssl/1.0.2k -lrt -m64

Do I need to  pass in  the  -fPIC flag as well, and if so  how do I do that.

I appended it to the end of the  configure  line I  show above  but there
was no sign of PIC in any of the top level makefiles produced.


Thanks,

Tim

gcc -shared -static-libgcc -m64 -o libsncrssl1.0-openssl1.0.x.so
.objects/sha1_pic.o .objects/sha256_pic.o .objects/tls_openssl_pic.o
.objects/olog_signature_pic.o .objects/utils_pic.o .objects/rsa_sha_pic.o
.objects/rsa_sha1_pic.o .objects/rsa_sha256_pic.o
.objects/ed25519_sha256_pic.o -L/opt/openssl/1.0.2k/lib -lssl -lcrypto
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .text (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_L44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_H44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations based on the ABS44 coding model can not be used in building a
shared object
ld: fatal: relocation error: R_SPARC_M44: file
/opt/openssl/1.0.2k/lib/libssl.a(s23_srvr.o): symbol .rodata1 (section):
relocations 

RE: building openssl 1.1.1 for Solaris 10

[tim.j.culhane]

Hi again,

I ran the gmake  and it fails with the below  ld errors.

Is this the  known issue mentioned previously with building openssl on Sparc
or is it caused by something else?

Thanks,

Tim



${LDCMD:-cc} -xarch=v9 -xstrconst -Xa -xO5 -xdepend -m64 -L. -mt \
-o apps/openssl apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o
apps/crl.o apps/crl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o
apps/dsaparam.o
apps/ec.o apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o
apps/gendsa.o apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o
apps/openssl.o apps/pass
wd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o apps/pkeyparam.o
apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o apps/req.o apps/rsa.o
apps/
rsautl.o apps/s_client.o apps/s_server.o apps/s_time.o apps/sess_id.o
apps/smime.o apps/speed.o apps/spkac.o apps/srp.o apps/storeutl.o apps/ts.o
apps/veri
fy.o apps/version.o apps/x509.o \
apps/libapps.a -lssl -lcrypto -lsocket -lnsl -ldl -lpthread
cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
SCRYPT_PARAMS_it: relocation bound to a symbol with STV_PROTECTED visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: symbol
PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
Undefined first referenced
symbol in file
clock_gettime ./libcrypto.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:2228: apps/openssl] Error 2

-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Monday 6 April 2020 16:58
To: openssl-users@openssl.org
Subject: RE: building openssl 1.1.1 for Solaris 10

> From: tim.j.culh...@gmail.com [mailto:tim.j.culh...@gmail.com]
> Sent: Monday, April 06, 2020 09:15
>
> I'm using  gcc 4.9.2
>
>
> So, should I just ignore that warning and let the gmake continue?

Yes, that's what I would recommend. If it bugs you, you could always
experiment with changing it, and if you find a version that works better you
could submit a PR to the OpenSSL team; but everyone else seems to have
decided to live with the warnings.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

RE: building openssl 1.1.1 for Solaris 10

[tim.j.culhane]

Hi,

I'm using  gcc 4.9.2


So, should I just ignore that warning and let the gmake continue?

Tim


-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Monday 6 April 2020 15:31
To: openssl-users@openssl.org
Subject: RE: building openssl 1.1.1 for Solaris 10

> From: tim.j.culh...@gmail.com [mailto:tim.j.culh...@gmail.com]
> Sent: Monday, April 06, 2020 06:35
> To: Michael Wojcik; openssl-users@openssl.org
> Subject: RE: building openssl 1.1.1 for Solaris 10
>
> Ok, attempting to build openssl 1.1.1e  now.
>
> As prompted by the config script  I'm  running Configure as  follows:
>
> ./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1
> --openssldir=/opt/openssl/1.1.1
>
> That completes successfully.  However, when I then run gmake I see  
> warnings like the below:
>
>
> cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit 
> programs
>
> How can I configure the makefiles so they use  '-m64'.

As far as I know you can't, except by editing Configurations/10-main.conf
(one of the inputs to the Configure script). The -xarch=... flags are
hard-coded there.

Personally I wouldn't worry about it. -xarch is deprecated, but it still
works. (And -m64 is not, as I understand it, exactly equivalent to -xarch
anyway. I'm a bit suspicious of that warning from cc; I'd think you'd want
-mcpu=... as well as -m64. But I haven't looked at the Sun C compiler
options for some years.)

What version of the C compiler are you using? Note these comments in
10-main.conf:

# SC4.0 doesn't pass 'make test', upgrade to SC5.0 or SC4.2.
# SC4.2 is ok, better than gcc even on bn as long as you tell it -xarch=v8 #
SC5.0 note: Compiler common patch 107357-01 or later is required!

Some people prefer to use gcc on Solaris for this reason.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

RE: building openssl 1.1.1 for Solaris 10

[tim.j.culhane]

Hi,

Ok, attempting to build openssl 1.1.1e  now.

As prompted by the config script  I'm  running Configure as  follows:

./Configure solaris64-sparcv9-cc --prefix=/opt/openssl/1.1.1
--openssldir=/opt/openssl/1.1.1

That completes successfully.  However, when I then run gmake I see  warnings
like the below:


cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs

How can I configure the makefiles so they use  '-m64'.

I tried passing  '-m64' as an argument to the Configure script but that
didn't make any difference.

Regards,

Tim


-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Friday 3 April 2020 23:17
To: openssl-users@openssl.org
Subject: RE: building openssl 1.1.1 for Solaris 10

> From: tim.j.culh...@gmail.com [mailto:tim.j.culh...@gmail.com]
> Sent: Friday, April 03, 2020 15:21
>
> Just wondering if there is a  man page  or similar on openssl.org  
> which describes the steps.

As I noted before, INSTALL and NOTES.TXT. Those are in the root of the
OpenSSL source distribution.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

RE: building openssl 1.1.1 for Solaris 10

[tim.j.culhane]

No, not run into that issue.

Just wondering if there is a  man page  or similar on openssl.org  which
describes the steps.

Tim


-Original Message-
From: openssl-users  On Behalf Of Michael
Wojcik
Sent: Friday 3 April 2020 19:49
To: openssl-users@openssl.org
Subject: RE: building openssl 1.1.1 for Solaris 10

> From: Quanah Gibson-Mount [mailto:qua...@symas.com]
> Sent: Friday, April 03, 2020 12:06
>
> --On Friday, April 3, 2020 6:31 PM + Michael Wojcik 
>  wrote:
>
> >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> >> Behalf Of tim.j.culh...@gmail.com
> >> Sent: Friday, April 03, 2020 10:49
> >>
> >> Are there instructions  somewhere for building and installing 
> >> openssl
> >> 1.1.1 from source for Solaris 10?
> >
> > You mean beyond what's in INSTALL and NOTES.UNIX? What is your 
> > specific issue?
>
> They may have run into 
> 
> which the OpenSSL project seems disinclined to fix.

Perhaps, but we have no way of knowing that. That's why specific questions
are important.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

building openssl 1.1.1 for Solaris 10

[tim.j.culhane]

Hi,

Are there instructions  somewhere for building and installing openssl 1.1.1
from source for Solaris 10?

Many thanks,

Tim

RE: building OpenSSL 1.1.1 with -DPURIFY

[tim.j.culhane]

Hi all,

Glad to report that using the latest 1.1.1 stable build from git, all tests 
pass successfully and also my issue with the valgrind issues is resolved.

Many thanks for your prompt help.

Tim


-Original Message-
From: Dr. Matthias St. Pierre  
Sent: Wednesday 9 October 2019 22:58
To: tim.j.culh...@gmail.com; 'Tomas Mraz' ; 
openssl-users@openssl.org
Subject: AW: building OpenSSL 1.1.1 with -DPURIFY

Hi Tim,

> However, when I run the tests there appears to be failures.
>
> Extract of the make test output  below:
>
>
> ../test/recipes/20-test_enc.t ..
> Dubious, test returned 1 (wstat 256, 0x100) Failed 1/172 subtests

Your test failure looks like issue
https://github.com/openssl/openssl/issues/9866

which was fixed by Tomas in commit
https://github.com/openssl/openssl/commit/86ed78676c660b553696cc10c682962522dfeb6c

The easiest way to obtain the fix is to update to the current head of the 
1.1.1. stable branch.
https://github.com/openssl/openssl/commits/OpenSSL_1_0_1-stable

Regards,
Matthias



Dr. Matthias St. Pierre
Senior Software Engineer
matthias.st.pie...@ncp-e.com
Phone: +49 911 9968-0
 www.ncp-e.com

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg North American HQ: NCP engineering Inc. • 678 Georgia Ave. • 
Sunnyvale, CA 94085 East Coast Office: NCP engineering Inc. • 601 Cleveland 
Str., Suite 501-25 • Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich 
Registry Court: Lower District Court of Nuremberg Commercial register No.: HRB 
7786 Nuremberg, VAT identification No.: DE 133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged or confidential information. 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
are not the intended recipient, please immediately contact the sender by reply 
e-mail and delete the original message and destroy all copies thereof.

RE: building OpenSSL 1.1.1 with -DPURIFY

[tim.j.culhane]

Hi Tomás

I've downloaded and build openssl 1.1.1d.

However, when I run the tests there appears to be failures.

Extract of the make test output  below:


../test/recipes/20-test_enc.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/172 subtests

Test summary shows:


Test Summary Report
---
../test/recipes/20-test_enc.t(Wstat: 256 Tests: 172 Failed: 
1)
  Failed test:  171
  Non-zero exit status: 1
Files=155, Tests=1457, 97 wallclock secs ( 1.74 usr  0.17 sys + 85.00 cusr 
21.23 csys = 108.14 CPU)
Result: FAIL
gmake[1]: *** [_tests] Error 1
gmake[1]: Leaving directory `/root/openssl-1.1.1d'
gmake: *** [tests] Error 2


Is this something I need to resolve  before installing 1.1.1d and if so how can 
I resolve the test failures?

Thanks,

Tim

-Original Message-
From: Tomas Mraz  
Sent: Wednesday 9 October 2019 14:30
To: tim.j.culh...@gmail.com; openssl-users@openssl.org
Subject: Re: building OpenSSL 1.1.1 with -DPURIFY

On Wed, 2019-10-09 at 11:37 +0100, tim.j.culh...@gmail.com wrote:
> Hi,
> 
> I've built  OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server.
> 
> My application  links with the libraries  contained in this build.
> 
> When running tests for my application under valgrind I'm seeing lots 
> of errors like the  below:

You can either try 1.1.1d or the patch from
https://github.com/openssl/openssl/pull/9217

It should solve the problem.

--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb [You'll know 
whether the road is wrong if you carefully listen to your conscience.]

building OpenSSL 1.1.1 with -DPURIFY

[tim.j.culhane]

Hi,

I've built  OpenSSL 1.1.1c locally on my 64 bit CentOS 7 server.

My application  links with the libraries  contained in this build.

When running tests for my application under valgrind I'm seeing lots of
errors like the  below:

Use of uninitialised value of size 8
at 0x4C30DDF: memset (vg_replace_strmem.c:1252)
by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2CACFD: bn_lshift_fixed_top (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BCC61: bn_div_fixed_top (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2C054E: int_bn_mod_inverse (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BC0B5: BN_BLINDING_create_param (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3BDAB0: RSA_setup_blinding (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C276A: rsa_ossl_private_encrypt (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB37A716: EVP_DigestSignFinal (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xAFC4413: tls_construct_cert_verify (in
/opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766)
by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846)
by 0x5A890E: run_smtp_server (receiver.c:1367)
by 0x5A55A2: smtp_recv_thread (receiver.c:326)
by 0x73158F: generic_worker_thread (threads.c:301)
by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so)
by 0x61A502C: clone (in /usr/lib64/libc-2.17.so)
  Uninitialised value was created by a stack allocation
at 0xB3B5000: rand_drbg_get_nonce (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)

 Conditional jump or move depends on uninitialised value(s)
at 0x4C30DE5: memset (vg_replace_strmem.c:1252)
by 0xB389872: CRYPTO_zalloc (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2C3BDA: bn_expand2 (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2CACFD: bn_lshift_fixed_top (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BCC61: bn_div_fixed_top (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BD081: BN_div (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2C054E: int_bn_mod_inverse (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2BC0B5: BN_BLINDING_create_param (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3BDAB0: RSA_setup_blinding (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C276A: rsa_ossl_private_encrypt (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB37A716: EVP_DigestSignFinal (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xAFC4413: tls_construct_cert_verify (in
/opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766)
by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846)
by 0x5A890E: run_smtp_server (receiver.c:1367)
by 0x5A55A2: smtp_recv_thread (receiver.c:326)
by 0x73158F: generic_worker_thread (threads.c:301)
by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so)
by 0x61A502C: clone (in /usr/lib64/libc-2.17.so)
  Uninitialised value was created by a stack allocation
at 0xB3B5000: rand_drbg_get_nonce (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)


Conditional jump or move depends on uninitialised value(s)
at 0xB2C4070: bn_correct_top (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB2C5397: BN_mod_mul_montgomery (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C2704: rsa_ossl_private_encrypt (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB3C4FE2: pkey_rsa_sign (in /opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xB37A716: EVP_DigestSignFinal (in
/opt/openssl/1.1.1/lib/libcrypto.so.1.1)
by 0xAFC4413: tls_construct_cert_verify (in
/opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFBB526: state_machine (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAFA6937: SSL_do_handshake (in /opt/openssl/1.1.1/lib/libssl.so.1.1)
by 0xAD64C2C: sncr_tls_negotiation_ex (tls_openssl.c:1766)
by 0xAD64D84: sncr_tls_negotiation (tls_openssl.c:1846)
by 0x5A890E: run_smtp_server (receiver.c:1367)
by 0x5A55A2: smtp_recv_thread (receiver.c:326)
by 0x73158F: generic_worker_thread (threads.c:301)
by 0x546BDD4: start_thread (in /usr/lib64/libpthread-2.17.so)
by 0x61A502C: clone (in /usr/lib64/libc-2.17.so)
  Uninitialised value was created by a stack allocation
at 0xB3E2363: sha256_block_data_order_avx2 (in

FW: how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN

[tim.j.culhane]

Hi,

Anybody have any suggestions on my below query.

I've not made myself clear please let me know  what extra info  would help.

Thanks,

Tim


-Original Message-
From: tim.j.culh...@gmail.com  
Sent: Wednesday 21 August 2019 12:41
To: openssl-users@openssl.org
Subject: how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN

Hi all,

I'm writing tests to verify how our mail server handles tls errors returned
from the OpenSSL library when verifying a certificate during tls
negotiation.

The test works by sending a message to a source mail server which then
relays the message  to the destination mail server.
The operation of relaying the message is done over a secure connection using
port 465.

I want to reproduce a scenario where  when the source mailserver opens a
connection to the destination server and carries out a tls negotiation that
the error returned is X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN.

However, no matter what way I try it I always get the similar but different
error:

X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT


The OpenSSL library version I'm using is 1.1.1c running on a CentOS 7
server.


My current steps are as follows:

Create our own root CA  public/private key pair

Then set up  two intermediate certs:

For the  first intermediate cert  create its CA  and private key.
Sign it using the root CA's key.

Do the same thin for the second intermediate key  but sign it with the first
intermediate key.

I then generate a certificate request  for each of the mail servers .
I self sign the certificates and generate the server certificates.
I append the intermediate certificates to the  file containing the host
certificate.
These are then installed on each server.


I copy various options of  the root CA certificate and the  intermediate
certificates into the CACertificates directory of my source mail server.
These will be used when the  mail server  attempts to negotiate a secure
connection to the destination server.

However, no matter what I try I don't get the
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN returned.

As an experiment I ran the command:

Openssl verify -verbose -untrusted  

And that does reproduce  the  correct error.


Any idea how I can get OpenSSL to return my dsired error?

Hopefully my above description makes sense.

Many thanks,

Tim

how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN

[tim.j.culhane]

Hi all,

I'm writing tests to verify how our mail server handles tls errors returned
from the OpenSSL library when verifying a certificate during tls
negotiation.

The test works by sending a message to a source mail server which then
relays the message  to the destination mail server.
The operation of relaying the message is done over a secure connection using
port 465.

I want to reproduce a scenario where  when the source mailserver opens a
connection to the destination server and carries out a tls negotiation that
the error returned is X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN.

However, no matter what way I try it I always get the similar but different
error:

X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT


The OpenSSL library version I'm using is 1.1.1c running on a CentOS 7
server.


My current steps are as follows:

Create our own root CA  public/private key pair

Then set up  two intermediate certs:

For the  first intermediate cert  create its CA  and private key.
Sign it using the root CA's key.

Do the same thin for the second intermediate key  but sign it with the first
intermediate key.

I then generate a certificate request  for each of the mail servers .
I self sign the certificates and generate the server certificates.
I append the intermediate certificates to the  file containing the host
certificate.
These are then installed on each server.


I copy various options of  the root CA certificate and the  intermediate
certificates into the CACertificates directory of my source mail server.
These will be used when the  mail server  attempts to negotiate a secure
connection to the destination server.

However, no matter what I try I don't get the
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN returned.

As an experiment I ran the command:

Openssl verify -verbose -untrusted  

And that does reproduce  the  correct error.


Any idea how I can get OpenSSL to return my dsired error?

Hopefully my above description makes sense.

Many thanks,

Tim

RE: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation

[tim.j.culhane]

Ok, great thanks.

-Original Message-
From: Matt Caswell  
Sent: Monday 15 April 2019 14:45
To: tim.j.culh...@gmail.com; openssl-users@openssl.org
Subject: Re: Best way of preventing denial of service attacks by way of secure 
client-initiated renegotiation



On 15/04/2019 14:41, tim.j.culh...@gmail.com wrote:
> Hi Matt,
> 
> Many thanks for your informative reply.
> 
> So it seems the best approach is to  upgrade to a version of OpenSSL  
> supporting the SSL_OP_NO_RENGOTIATION option.
> 
> If this option is enabled will it  still allow server-initiated secure  
> renegotiations if TLS 1.3 is being used?
> 
> The docs suggests that only  client side renegotiation requests are disabled 
> in TLS 1.3.

Renegotiation does not exist as a concept in TLSv1.3 so this option has no 
impact in TLSv1.3.

Matt


> 
> Tim
> 
> 
> -Original Message-
> From: openssl-users  On Behalf Of 
> Matt Caswell
> Sent: Monday 15 April 2019 13:44
> To: openssl-users@openssl.org
> Subject: Re: Best way of preventing denial of service attacks by way 
> of secure client-initiated renegotiation
> 
> 
> 
> On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote:
>> I'm not sure if this means  renegotiation has failed?  Either way the 
>> connection remains open.  Presumably if a client issued a large 
>> number of renegotiations like this the server could become overwhelmed.
> 
> No - renegotiation was successful.
> 
>> Note that I got the same results if I remove the 
>> -legacy_renegotiation option, so I don't think  this has any impact?
> 
> The legacy_renegotiation option does something different to what you 
> think it does. This option allows "insecure" renegotiation as opposed 
> to the later (and
> default) "secure" renegotiation. This dates back to 2009 when a flaw in the 
> TLS protocol for renegotiation was discovered.
> 
>>
>> So, I suppose I firstly need to know if the results from testssl.sh 
>> and from my own investigations point to a potential security risk by 
>> way of a DoS attack?
> 
> Over the years there have been many attacks against renegotiation. They've 
> all been fixed, however since this is a common attack vector and many 
> applications don't need this feature it is often recommended that it is 
> disabled.
> 
> 
>> If so, what is the best way to prevent this.
> 
> The best way is to upgrade to a recent version of OpenSSL and use the 
> SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and 
> above).
> 
> If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is 
> undocumented and unfortunately this method is no longer possible in OpenSSL 
> 1.1.0+ due to the opacity changes.
> 
> You can mark a particular SSL object (call it "s") so that it should not do 
> renegotiation like this:
> 
> s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
> 
> 
>> From what I've read online it isn't possible to disable 
>> client-initiated secure renegotiation in openssl.
>> Indeed, it could be argued that there are circumstances when it is 
>> perfectly valid for a client to renegotiate a connection  especially 
>> if it is a long-running connection.
>>
>> The only  way I could find of limiting such an attack was to track 
>> the number of renegotiation requests over a time and if we get a high 
>> number  in a short period  then close the connection.
>> I believe this can be done  in a callback function  set up via a call to:
>>
>> SSL_CTX_set_info_callback
> 
> I'd recommend against this approach. A number of applications took this route 
> due to a lack of a good alternative. However it can have unexpected 
> consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 
> (where a number of legitimate interactions happen post-handshake that can be 
> mistaken for renegotiations).
> 
> Matt
> 

RE: Best way of preventing denial of service attacks by way of secure client-initiated renegotiation

[tim.j.culhane]

Hi Matt,

Many thanks for your informative reply.

So it seems the best approach is to  upgrade to a version of OpenSSL  
supporting the SSL_OP_NO_RENGOTIATION option.

If this option is enabled will it  still allow server-initiated secure  
renegotiations if TLS 1.3 is being used?

The docs suggests that only  client side renegotiation requests are disabled in 
TLS 1.3.

Tim


-Original Message-
From: openssl-users  On Behalf Of Matt 
Caswell
Sent: Monday 15 April 2019 13:44
To: openssl-users@openssl.org
Subject: Re: Best way of preventing denial of service attacks by way of secure 
client-initiated renegotiation



On 15/04/2019 09:35, tim.j.culh...@gmail.com wrote:
> I'm not sure if this means  renegotiation has failed?  Either way the 
> connection remains open.  Presumably if a client issued a large number 
> of renegotiations like this the server could become overwhelmed.

No - renegotiation was successful.

> Note that I got the same results if I remove the -legacy_renegotiation 
> option, so I don't think  this has any impact?

The legacy_renegotiation option does something different to what you think it 
does. This option allows "insecure" renegotiation as opposed to the later (and
default) "secure" renegotiation. This dates back to 2009 when a flaw in the TLS 
protocol for renegotiation was discovered.

> 
> So, I suppose I firstly need to know if the results from testssl.sh 
> and from my own investigations point to a potential security risk by 
> way of a DoS attack?

Over the years there have been many attacks against renegotiation. They've all 
been fixed, however since this is a common attack vector and many applications 
don't need this feature it is often recommended that it is disabled.


> If so, what is the best way to prevent this.

The best way is to upgrade to a recent version of OpenSSL and use the 
SSL_OP_NO_RENGOTIATION option for this purpose (available from 1.1.0h and 
above).

If you *must* use OpenSSL 1.0.2 then there is a way to do it but it is 
undocumented and unfortunately this method is no longer possible in OpenSSL 
1.1.0+ due to the opacity changes.

You can mark a particular SSL object (call it "s") so that it should not do 
renegotiation like this:

s->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;


> From what I've read online it isn't possible to disable 
> client-initiated secure renegotiation in openssl.
> Indeed, it could be argued that there are circumstances when it is 
> perfectly valid for a client to renegotiate a connection  especially 
> if it is a long-running connection.
> 
> The only  way I could find of limiting such an attack was to track the 
> number of renegotiation requests over a time and if we get a high 
> number  in a short period  then close the connection.
> I believe this can be done  in a callback function  set up via a call to:
> 
> SSL_CTX_set_info_callback

I'd recommend against this approach. A number of applications took this route 
due to a lack of a good alternative. However it can have unexpected 
consequences if you later upgrade to OpenSSL 1.1.1 and start using TLSv1.3 
(where a number of legitimate interactions happen post-handshake that can be 
mistaken for renegotiations).

Matt

Best way of preventing denial of service attacks by way of secure client-initiated renegotiation

[tim.j.culhane]

Hi all,

A customer of ours was recently running security checks against our mail
server.  To do this they were running the testssl.sh script available at:

https://testssl.sh/

The test tool reports a potential DoS thread as a result of client-initiated
secure renegotiation as shown from the following line from the test tool's
output:


 Secure Client-Initiated Renegotiation VULNERABLE (NOT
ok), potential DoS threat

I have also reproduced  their findings in-house.

Our mail server is using version 1.0.2g of openssl  and  the client openssl
version was 1.0.2j.

In the testssl.sh script  it connects to the ssl port using TLS1.2  and the
legacy_renegotiation option.

When I do a similar  test in my test environment  I  get results like the
below:

 Issue  a connect request, pause for 1 second and then Send 'R'  to start a
renegotiation:

(echo -n; sleep 1; echo R) | openssl s_client -CAfile NightlyBuild-CA.cert
-crlf -tls1_2 -legacy_renegotiation -connect :465

Output is as follows:



CONNECTED(0003)
---
Certificate chain
 0 s:/C=ie/CN=something/CN=devimpala13.es.cpth.ie
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
---
Server certificate
-BEGIN CERTIFICATE-
MIIC0DCCAjmgAwIBAgIBATANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJBVTET
...
-END CERTIFICATE-
subject=/C=ie/CN=something/CN=devimpala13.es.cpth.ie
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH
A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA
+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms:
RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SH
A256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA
+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1297 bytes and written 445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID:
A1E559EAFC571033874C52C715E8CE3452751FB80AD843F4E051E77664F20FFE
Session-ID-ctx: 
Master-Key:
BE06E684D71B9B3349DBB057C433BB0C0C44717EF2157EAA912A896F43DF8E6E912A69B8258E
C9031CF2219F0F031C1B
Key-Arg   : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
 - 61 3a da 77 02 6c 7e 26-c1 98 84 ae 26 21 8f 1d
a:.w.l~&&!..
...
Start Time: 1555315404
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---
220 devimpala13.es.cpth.ie ESMTP Service ready
RENEGOTIATING
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
depth=0 C = ie, CN = something, CN = devimpala13.es.cpth.ie
verify return:1
DONE

So, as you can see the  initial connection is successful.   The
renegotiation  begins and  it returns:

verify return:1

I'm not sure if this means  renegotiation has failed?  Either way the
connection remains open.  Presumably if a client issued a large number of
renegotiations like this the server could become overwhelmed.

Note that I got the same results if I remove the -legacy_renegotiation
option, so I don't think  this has any impact?

So, I suppose I firstly need to know if the results from testssl.sh and from
my own investigations point to a potential security risk by way of a DoS
attack?

If so, what is the best way to prevent this.
>From what I've read online it isn't possible to disable client-initiated
secure renegotiation in openssl.
Indeed, it could be argued that there are circumstances when it is perfectly
valid for a client to renegotiate a connection  especially if it is a
long-running connection.

The only  way I could find of limiting such an attack was to track the
number of renegotiation requests over a time and if we get a high number  in
a short period  then close the connection.
I believe this can be done  in a callback function  set up via a call to:

SSL_CTX_set_info_callback


So, is the above information correct or is there a better way of preventing
this sort of attack.  Do we really need to allow a limited form of
client-based secure renegotiation?

If preventing an attack by way of monitoring the number of renegotiations
over time is the only good approach, do you have any code examples in C as
to how to implement this?

Many thanks,

Tim