Re: [openssl-users] Openssl FIPS uses /dev/urandom by default?

[John Foley]

Entropy collection is outside the FIPS boundary.  If you don't want to
modify the code, you can pass in -DDEVRANDOM using CFLAGS and set it to
whatever value you desire.  For instance, maybe you have a hardware
device mapped to /dev/entropy that provides sufficient random data to
seed the DRBG. 


On 11/12/2015 11:35 AM, Ethan Rahn wrote:
> xxiao,
>
> Are you sure you can't modify that? My understanding of FIPS mode is
> that you cannot modify the FIPS code canister, which entropy sources
> are not a part of.
>
> Cheers,
>
> Ethan
>
> On Thu, Nov 12, 2015 at 8:08 AM, xxiao8  > wrote:
>
> in e_os.h I saw
> ==
> #ifndef DEVRANDOM
>
> /* set this to a comma-separated list of 'random' device files to
> try out.
>
> * My default, we will try to read at least one of these files */
>
> #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom"
>
> # endif
> ==
> this basically sets /dev/urandom as the default which really is
> not FIPS-friendly, is there a way to override this during
> compilation to set the default to /dev/random instead? I'm not
> supposed to modify the source code as it will invalidate
> openssl-FIPS certificate.
>
> Thanks,
> xxiao
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] Key Deriviation Function Tests for TLS

[John Foley]

On 09/23/2015 08:16 AM, Steve Marquess wrote:
> John, let me elaborate on my comment above by noting that the Cisco
> contribution includes a bunch of FIPS specific code for which there is
> no counterpart on the master branch (i.e. no place to put it). A
> version which worked on master with all the FIPS stuff stripped out
> and with tests via evp_test would be a lot more interesting. -Steve M. 
Hi Steve,

We can certainly submit a pull request on the master branch.  It'll take
a little time to prepare that.  IMHO, there is value in accepting this
pull request on the FIPS branch as well.  There are OpenSSL users doing
private label FIPS validations that would benefit.  Pull request 368
contains the FIPS vector processing utility for KDF.  None of the FIPS
vector processing utilities reside in master.  The pull request we
prepare for master isn't going to include the KDF vector processing utility.

Please let me know whether we should proceed with preparing a pull
request on master.

Thanks,
John
 

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

Re: [openssl-users] Key Deriviation Function Tests for TLS

[John Foley (foleyj)]

Pull request 368 has KDF support for FIPS:  
https://github.com/openssl/openssl/pull/368


I've already updated libsrtp to use this API for FIPS compliance. We would like 
to contribute to other downstream projects as well.  But it would help if 
OpenSSL accepted this pull request.


-- Original message--

From: Philip Bellino

Date: Tue, Sep 22, 2015 10:38 AM

To: openssl-users@openssl.org;

Subject:[openssl-users] Key Deriviation Function Tests for TLS


Hello,

In pursuit of FIPS validation using OpenSSL 1.0.2a/ FIPS 2.0.9, we are required 
by our testing lab to perform KDF tests for TLS (see document NIST SP800-135, 
Rev 1 section 4.2).



Could you please point us to where the source for the KDF TLS test(s) are 
available.

Thank you,
Phil Bellino


[E-Banner]


MRV Communications is a global supplier of packet and optical solutions that 
power the world's largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to whom they are addressed and may contain 
confidential and/or privileged information. If you are not the intended 
recipient, immediately advise the sender, delete this message and any 
attachments and note that any distribution, or copying of this message, or any 
attachment, is prohibited.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Extended key usage keyAgreement bit in certificate

[John Foley]

The following commit changed the behavior of checking the extended key
usage bits in a server certificate when using X509_PURPOSE_SSL_SERVER:

http://marc.info/?l=openssl-cvsm=132759007026375w=2

This commit was put into 1.0.2 on April 6, 2012.  Therefore, 1.0.1 and
1.0.2 behave differently in this regard.  When using 1.0.2, the server
certificate needs to include the keyAgreement bit.  Otherwise the client
will reject the server certificate when checking the purpose
(X509_PURPOSE_SSL_SERVER).

Does this behavior in 1.0.2 comply with RFC 5246?  Reading section 7.4.2
on pages 47/48, the server certificate should include the keyAgreement
bit when using DH key exchange cipher suites.  The wording on page 48 is: 

  DH_DSS Diffie-Hellman public key; the keyAgreement bit
  DH_RSA MUST be set if the key usage extension is
 present.

Given there's no other mention of using the keyAgreement bit in RFC
5246, does this imply the keyAgreement bit doesn't need to be set when
not using a DH cipher suite?  Given the commit noted above will always
check the keyAgreement bit, and the logic in v3_purp.c is unaware of the
negotiated cipher suite,  would this be considered a bug?  If not, would
it be appropriate to back-port this commit to 1.0.1 so that we would
have consistent behavior between 1.0.1 and 1.0.2?



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

Re: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes

[John Foley]

Well, since you're using the fips-ecp tarball, you'll need to include
no-ec2m when configuring OpenSSL 1.0.2a.  But this isn't why you're
seeing a fork error from fipsld.

I'm using Ubuntu 14.04 (Is there a 14.4?) and don't see any issue. 
However, I'm not setting CC, FIPSLD and FIPSDIR.  You shouldn't have to
set these.  Also, you're not doing a make depend after the config for
OpenSSL 1.0.2a. 

Here's a summary of the procedure that worked for me:

wget --no-check-certificate
https://www.openssl.org/source/openssl-1.0.2a.tar.gz
wget --no-check-certificate
https://www.openssl.org/source/openssl-fips-ecp-2.0.9.tar.gz
tar -xzvf openssl-fips-ecp-2.0.9.tar.gz
cd openssl-fips-ecp-2.0.9/
./config fipscanisteronly no-asm --prefix=/nobackup/tmp/x88/fips
make
make install
cd ..
tar -xzvf openssl-1.0.2a.tar.gz
cd openssl-1.0.2a/
./config fips no-ec2m no-asm --with-fipsdir=/nobackup/tmp/x88/fips
make depend
make clean
make




On 06/05/2015 09:23 AM, OpenSSL Curious wrote:
 REPOSTING TO PUSH TO OFFICIAL GROUP
 I was wondering if someone has seen this issue before. I am guessing the
 problem is on my side because  can replicate it on Debian 8 and Ubuntu 14.4. 

 I am using OpenSSL 1.0.2a and the crypto module from OpenSSL ecp 2.0.9 

 env settings 
 CC=/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld 
 FIPSLD_CC=/usr/bin/gcc 
 FIPSDIR=/usr/local/ssl/fips-2.0 

 for building fips canister 
 ./config fipscanisterbuild no-asm 
 make 
 make install 

 using ./config fips no-asm 
 make 
 make install 

 This seemed to be pretty straight forward. I think i created the
 fipscanister.o correctly. Everything compiled and linked for the canister. I
 liked it to a small test app that worked. 

 I then tried to build openssl, it fine but on the last linking step the
 linker just keep forking processes out of control on both OSs until i got a
 message that the linker cannot fork any new processes. Any pointers would be
 appreciated. 

 /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: 174:
 /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: Cannot
 fork 
 ../Makefile.shared:164: recipe for target 'link_app.' failed 
 make[2]: *** [link_app.] Error 2 
 make[2]: Leaving directory
 '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' 
 Makefile:153: recipe for target 'openssl' failed 
 make[1]: *** [openssl] Error 2 
 make[1]: Leaving directory
 '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' 
 Makefile:285: recipe for target 'build_apps' failed 
 make: *** [build_apps] Error 1 
 mssluser@debian8:~/workspace/libs/openssl-1.0.2a$ 



 --
 View this message in context: 
 http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58471.html
 Sent from the OpenSSL - User mailing list archive at Nabble.com.
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



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

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Not sure. 

Are you using blocking or non-blocking IO? 
Have you tried SSL_MODE_AUTO_RETRY?
Do you notice a different return value from SSL_read() after a zero byte
read compared to other errors?



On 05/06/2015 07:12 PM, Bryan Call wrote:
 Do you know if there is a way from preventing a call to
 SSL_get_error() after getting a 0 byte read from SSL_read()?  This is
 the main issue I am facing with the OpenSSL error locking right now.

 -Bryan




 On May 1, 2015, at 6:49 AM, Salz, Rich rs...@akamai.com
 mailto:rs...@akamai.com wrote:

 Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging
 errors.  It appears your application is generating a lot of errors
 for some reason.  Never tried it myself, but you probably can't
 disable this lock with multiple threads running.  You should take a
 look at the error log to identify the cause of the errors.  Then
 resolve the issue, whatever it may be. 

 I have a rewrite of the error-stack stuff that halves the number of
 locks.  If you want to try it, drop me a line.
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



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

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

Re: [openssl-users] openssl-1.0.2-stable-SNAP-20150504 error

[John Foley]

That's the same symptom I see on 32-bit systems.  It appears to be
caused by 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.


On 05/04/2015 09:21 AM, The Doctor wrote:
 This also occured in openssl-1.0.2-stable-SNAP-20150503


 Script started on Mon May  4 07:06:41 2015
 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ egrep bsdi 
 Confi 
 gure
 bsdi-elf-gcc, gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 
 -march=i486 -Wall::(unknown)::-ldl:BN_LLONG ${x86_gcc_des} 
 ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 debug-bsdi-x86-elf,   gcc3:-DPERL5 -DL_ENDIAN -DTERMIOS 
 -fomit-frame-pointer -O2 -Wall -g::${BSDthreads}::-lgmp -ldl -lm 
 -lc:THIRY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_des} 
 ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak  make 
 test 
 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak  make 
 test
 sh: mak: command not found
 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ ^k^ke
 make  make test
 making all in crypto...
 making all in crypto/objects...
 making all in crypto/md4...
 making all in crypto/md5...
 making all in crypto/sha...
 making all in crypto/mdc2...
 making all in crypto/hmac...
 making all in crypto/ripemd...
 making all in crypto/whrlpool...
 making all in crypto/des...
 making all in crypto/aes...
 making all in crypto/rc2...
 making all in crypto/rc4...
 making all in crypto/rc5...
 making all in crypto/idea...
 making all in crypto/bf...
 making all in crypto/cast...
 making all in crypto/camellia...
 making all in crypto/seed...
 making all in crypto/modes...
 making all in crypto/bn...
 making all in crypto/ec...
 making all in crypto/rsa...
 making all in crypto/dsa...
 making all in crypto/ecdsa...
 making all in crypto/dh...
 making all in crypto/ecdh...
 making all in crypto/dso...
 making all in crypto/engine...
 making all in crypto/buffer...
 making all in crypto/bio...
 making all in crypto/stack...
 making all in crypto/lhash...
 making all in crypto/rand...
 making all in crypto/err...
 making all in crypto/evp...
 making all in crypto/asn1...
 making all in crypto/pem...
 making all in crypto/x509...
 making all in crypto/x509v3...
 making all in crypto/conf...
 making all in crypto/txt_db...
 making all in crypto/pkcs7...
 making all in crypto/pkcs12...
 making all in crypto/comp...
 making all in crypto/ocsp...
 making all in crypto/ui...
 making all in crypto/krb5...
 making all in crypto/cms...
 making all in crypto/pqueue...
 making all in crypto/ts...
 making all in crypto/jpake...
 making all in crypto/srp...
 making all in crypto/store...
 making all in crypto/cmac...
 if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
 libcrypto.so.1.0.0);  fi
 [ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT 
 -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
 -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
 fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
 making all in ssl...
 if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then  (cd ..; make 
 libssl.so.1.0.0);  fi
 [ -z  ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS 
 -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT 
 -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g 
 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND 
 -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS 
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
 -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  
 -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c 
 fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
 making all in engines...
 echo 

 making all in engines/ccgost...
 making all in apps...
 making all in test...
 making all in tools...
 testing...
 making all in apps...
 ../util/shlib_wrap.sh ./destest
 Doing cbcm
 Doing ecb
 Doing ede ecb
 Doing cbc
 Doing desx cbc
 Doing ede cbc
 Doing pcbc
 Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
 Doing ofb
 Doing ofb64
 Doing ede_ofb64
 Doing cbc_cksum
 Doing quad_cksum
 input word alignment test 0 1 2 3
 output word alignment test 0 1 2 3
 fast crypt test 
 ../util/shlib_wrap.sh ./ideatest
 ecb idea ok
 cbc idea ok
 cfb64 idea ok
 ../util/shlib_wrap.sh ./shatest
 test 1 ok
 test 2 ok
 test 3 ok
 ../util/shlib_wrap.sh ./sha1test
 test 1 ok
 test 2 ok
 test 3 ok
 ../util/shlib_wrap.sh ./sha256t
 Testing SHA-256 ... passed.
 

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Yes, if you never call FIPS_mode_set(), the POST will never run.  I'll
defer to the experts on your other questions.


On 05/01/2015 05:10 PM, Bryan Call wrote:
 So can I assume the FIPS POST has completed if I never call FIPS_mode_set() 
 in the code?  I was confused about that.

 When we call SSL_read() and get a 0 byte return we call SSL_get_error() to 
 see if there was an error not not.  Maybe there is a more efficient handle 
 this, like looking at the shutdown flag?

0   The read operation was not successful. The reason may either be a
clean shutdown due to a close notify alert sent by the peer (in
which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
possible, that the peer simply shut down the underlying transport
and the shutdown is incomplete. Call SSL_get_error() with the
return value ret to find out, whether an error occurred or the
connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).

 When we call SSL_accept we also call SSL_get_error() to see we need to read 
 or write.  Is there a more efficient way to tell if we need to read or write?

If the underlying BIO is non-blocking, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept() to
continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the return value of
SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The calling process then must repeat the call after taking appropriate
action to satisfy the needs of SSL_accept().  The action depends on the
underlying BIO. When using a non-blocking socket, nothing is to be
done, but select() can be used to check for the required condition.
When using a buffering BIO, like a BIO pair, data must be written into
or retrieved out of the BIO before being able to continue.


 Thank you...

 -Bryan




 On May 1, 2015, at 5:34 AM, John Foley fol...@cisco.com wrote:

 Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It 
 appears your application is generating a lot of errors for some reason.  
 Never tried it myself, but you probably can't disable this lock with 
 multiple threads running.  You should take a look at the error log to 
 identify the cause of the errors.  Then resolve the issue, whatever it may 
 be.  



 On 04/30/2015 06:52 PM, Bryan Call wrote:
 This is for Apache Traffic Server and we have no knobs for turning on/off 
 FIPS.  I am thinking about always disabling FIPS right now and that would 
 happen before we create the threads. 

 I was able to get rid of all the FIPS lock connection with the changes you 
 recommend (Big Thanks!).  The big one now is type 1.  I am printing out the 
 log every time the contention total is mod 1M.  Are there any tricks I can 
 do for type 1 locks?

 [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - 
 total contention: 400 waiting: 1 file: pmeth_lib.c line: 185 type: 10
 [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - 
 total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
 [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - 
 total contention: 400 waiting: 0 file: ex_data.c line: 304 type: 2
 [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - 
 total contention: 1200 waiting: 5 file: err.c line: 446 type: 1
 [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - 
 total contention: 100 waiting: 0 file: rand_lib.c line: 212 type: 19

 -Bryan


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


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

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. 
It appears your application is generating a lot of errors for some
reason.  Never tried it myself, but you probably can't disable this lock
with multiple threads running.  You should take a look at the error log
to identify the cause of the errors.  Then resolve the issue, whatever
it may be. 



On 04/30/2015 06:52 PM, Bryan Call wrote:
 This is for Apache Traffic Server and we have no knobs for turning
 on/off FIPS.  I am thinking about always disabling FIPS right now and
 that would happen before we create the threads. 

 I was able to get rid of all the FIPS lock connection with the changes
 you recommend (Big Thanks!).  The big one now is type 1.  I am
 printing out the log every time the contention total is mod 1M.  Are
 there any tricks I can do for type 1 locks?

 [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for
 lock - total contention: 400 waiting: 1 file: pmeth_lib.c line:
 185 type: 10
 [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for
 lock - total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
 [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for
 lock - total contention: 400 waiting: 0 file: ex_data.c line: 304
 type: 2
 *[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for
 lock - total contention: 1200 waiting: 5 file: err.c line: 446
 type: 1*
 [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for
 lock - total contention: 100 waiting: 0 file: rand_lib.c line: 212
 type: 19

 -Bryan



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

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

The changes to SSL_locking_callback() look good.  But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much. 
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.


On 04/30/2015 09:49 PM, Bryan Call wrote:
 (plain text and removed most of the history)

 John if you don’t mind reviewing my change to Apache Traffic Server.  It 
 seems to be working very well.  Thank you again!

 https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=iocore/net/SSLUtils.cc;h=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09

 -Bryan




 On Apr 30, 2015, at 3:52 PM, Bryan Call bc...@apache.org wrote:

 This is for Apache Traffic Server and we have no knobs for turning on/off 
 FIPS.  I am thinking about always disabling FIPS right now and that would 
 happen before we create the threads. 

 I was able to get rid of all the FIPS lock connection with the changes you 
 recommend (Big Thanks!).  The big one now is type 1.  I am printing out the 
 log every time the contention total is mod 1M.  Are there any tricks I can 
 do for type 1 locks?

 [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - 
 total contention: 400 waiting: 1 file: pmeth_lib.c line: 185 type: 10
 [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - 
 total contention: 1100 waiting: 2 file: err.c line: 469 type: 1
 [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - 
 total contention: 400 waiting: 0 file: ex_data.c line: 304 type: 2
 [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - 
 total contention: 1200 waiting: 5 file: err.c line: 446 type: 1
 [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - 
 total contention: 100 waiting: 0 file: rand_lib.c line: 212 type: 19

 -Bryan

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

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

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Correct.  Locks 39/40 are only useful while the POST is running.  Once
the POST completes, the POST status never changes again unless the POST
runs again.  The only way to run the POST is by invoking
FIPS_mode_set(1).  But there should be no reason to invoke
FIPS_mode_set(1) more than once unless you want to provide some sort of
run-time FIPS mode toggle capability. 

You're asking in the context of Apache, right?  Apache just has a global
FIPS on/off knob in the config.  If set, FIPS is enabled for the
lifetime of the process and never disabled/re-enabled. You would invoke
FIPS_mode_set(1) once prior to spinning up the worker threads. 
Therefore, the POST would be finished prior to any multi-threaded
processing.



On 04/29/2015 01:53 PM, Bryan Call wrote:
 Can I safely assume that if I call FIPS_mode_set(0) and get a
 successful return value then I don’t need to lock when there are
 callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)?

 -Bryan




 On Apr 28, 2015, at 10:22 AM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1)
 has returned with a successful return value. 

 In the future, this may change if/when OpenSSL does another FIPS
 validation.  CMVP has changed the implementation guidance that
 requires the POST to run automatically without user intervention. 
 Any future FIPS validations would be subject to the new rules. 
 Hence, the behavior of FIPS_mode_set() may change in the future if
 OpenSSL decides to pursue another validation.



 On 04/28/2015 12:43 PM, Bryan Call wrote:
 What do you mean by “FIPS POST has completed”?

 -Bryan




 On Apr 24, 2015, at 4:17 PM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 Some of the algorithms still invoke the FIPS flavor of the
 algorithm even when FIPS is disabled.  For example, this code is
 from EVP_DigestUpdate().

 int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
 {
 #ifdef OPENSSL_FIPS
 return FIPS_digestupdate(ctx, data, count);
 #else
 return ctx-update(ctx, data, count);
 #endif
 }

 In 1.0.1, locks 39 and 40 are:

 # define CRYPTO_LOCK_FIPS39
 # define CRYPTO_LOCK_FIPS2   40

 You should try adding some logic to skip the lock in your lock
 handler when the lock ID is 39 or 40. Again, it should be safe to
 not lock on these two as long as the FIPS POST has completed.



 On 04/24/2015 05:56 PM, Bryan Call wrote:
 In my last email I ran the benchmark on Fedora 21 (big mistake).  
 Here are the results when running it back on the 28/56 core RHEL
 6.5 server showing contention in a different place (fips).  Is
 there a reason it would be calling into the FIPS code to get a
 lock of FIPS is not enabled?

 Contention log:
 [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention
 for lock - total contention: 70662 waiting: 16 file: fips.c line:
 471 type: 40
 [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention
 for lock - total contention: 71605 waiting: 2 file: fips.c line:
 107 type: 39


 Line in in fips that see the contention the most:
 [bcall@bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d '
 ' | sort | uniq -c | sort -rn
  875379 471
  288338 107
  275472 127


 Different lock types and their contention frequency (multiple
 benchmarks):
  875379 40   - in fips.c
  563810 39  - also in fips.c
  440518 1
   44145 18
   17447 2
   11356 10
1377 19
 687 12
 532 25
 302 33
 239 9
  58 16
  40 21
  32 11
  19 3
   1 14


 Code to diable FIPS and log:
 #ifdef OPENSSL_FIPS
 int mode = FIPS_mode();
 Debug(ssl, FIPS_mode: %d, mode);
 mode = FIPS_mode();
 if (mode) {
   FIPS_mode_set(0);
   Debug(ssl, FIPS_mode: %d, mode);
 }
 #endif

 [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl)
 FIPS_mode: 0

 -Bryan




 On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 When you create the private key given to SSL_CTX, be sure to
 instantiate a private key for each thread as well.  If you share
 the same key across all threads, this can introduce contention.

 Here are the type 1  2 locks:

 # define CRYPTO_LOCK_ERR 1
 # define CRYPTO_LOCK_EX_DATA 2

 Have you checked the OpenSSL error log to see what errors are
 being generated?

 Also, if you disable FIPS, does the thread contention still occur?



 On 04/24/2015 01:36 PM, Bryan Call wrote:
 We are using a single SSL_CTX across all the threads, so I will
 create multiple SSL_CTX per thread.  I implemented dynlock
 callbacks yesterday, but I didn’t see them being used in the
 tests I did.  I also added atomic counters to see what type of
 locks are having contention (see logs below):

 Most of the lock contention seems to be around type 2 and type 1
 locks when calling our lock callback.  In the FIPS/POST and
 SSL_CTX recommendations, in your previous email, what types

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1)
has returned with a successful return value. 

In the future, this may change if/when OpenSSL does another FIPS
validation.  CMVP has changed the implementation guidance that requires
the POST to run automatically without user intervention.  Any future
FIPS validations would be subject to the new rules.  Hence, the behavior
of FIPS_mode_set() may change in the future if OpenSSL decides to pursue
another validation.



On 04/28/2015 12:43 PM, Bryan Call wrote:
 What do you mean by “FIPS POST has completed”?

 -Bryan




 On Apr 24, 2015, at 4:17 PM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 Some of the algorithms still invoke the FIPS flavor of the algorithm
 even when FIPS is disabled.  For example, this code is from
 EVP_DigestUpdate().

 int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
 {
 #ifdef OPENSSL_FIPS
 return FIPS_digestupdate(ctx, data, count);
 #else
 return ctx-update(ctx, data, count);
 #endif
 }

 In 1.0.1, locks 39 and 40 are:

 # define CRYPTO_LOCK_FIPS39
 # define CRYPTO_LOCK_FIPS2   40

 You should try adding some logic to skip the lock in your lock
 handler when the lock ID is 39 or 40. Again, it should be safe to not
 lock on these two as long as the FIPS POST has completed.



 On 04/24/2015 05:56 PM, Bryan Call wrote:
 In my last email I ran the benchmark on Fedora 21 (big mistake).  
 Here are the results when running it back on the 28/56 core RHEL 6.5
 server showing contention in a different place (fips).  Is there a
 reason it would be calling into the FIPS code to get a lock of FIPS
 is not enabled?

 Contention log:
 [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for
 lock - total contention: 70662 waiting: 16 file: fips.c line: 471
 type: 40
 [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for
 lock - total contention: 71605 waiting: 2 file: fips.c line: 107
 type: 39


 Line in in fips that see the contention the most:
 [bcall@bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' '
 | sort | uniq -c | sort -rn
  875379 471
  288338 107
  275472 127


 Different lock types and their contention frequency (multiple
 benchmarks):
  875379 40   - in fips.c
  563810 39  - also in fips.c
  440518 1
   44145 18
   17447 2
   11356 10
1377 19
 687 12
 532 25
 302 33
 239 9
  58 16
  40 21
  32 11
  19 3
   1 14


 Code to diable FIPS and log:
 #ifdef OPENSSL_FIPS
 int mode = FIPS_mode();
 Debug(ssl, FIPS_mode: %d, mode);
 mode = FIPS_mode();
 if (mode) {
   FIPS_mode_set(0);
   Debug(ssl, FIPS_mode: %d, mode);
 }
 #endif

 [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0

 -Bryan




 On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 When you create the private key given to SSL_CTX, be sure to
 instantiate a private key for each thread as well.  If you share
 the same key across all threads, this can introduce contention.

 Here are the type 1  2 locks:

 # define CRYPTO_LOCK_ERR 1
 # define CRYPTO_LOCK_EX_DATA 2

 Have you checked the OpenSSL error log to see what errors are being
 generated?

 Also, if you disable FIPS, does the thread contention still occur?



 On 04/24/2015 01:36 PM, Bryan Call wrote:
 We are using a single SSL_CTX across all the threads, so I will
 create multiple SSL_CTX per thread.  I implemented dynlock
 callbacks yesterday, but I didn’t see them being used in the tests
 I did.  I also added atomic counters to see what type of locks are
 having contention (see logs below):

 Most of the lock contention seems to be around type 2 and type 1
 locks when calling our lock callback.  In the FIPS/POST and
 SSL_CTX recommendations, in your previous email, what types of
 locks would those help with?

 Log output:
 [Apr 24 10:21:24.339] Server {0xb31} ERROR: SSLUtils.cc
 http://sslutils.cc/:178 (SSL_locking_callback) contention for
 lock - total contention: 3938 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c
 line: 496 type: 2
 [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: SSLUtils.cc
 http://sslutils.cc/:178 (SSL_locking_callback) contention for
 lock - total contention: 1350 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c line:
 343 type: 1


 -Bryan




 On Apr 23, 2015, at 4:46 PM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 Looking at your call stack, it appears you're testing with FIPS
 mode enabled.  There's a lock in FIPS_selftest_failed() that's
 used to ensure the crypto algorithms inside the FIPS boundary are
 not utilized until after the POST has completed and passed.
 Unfortunately this lock remains installed for the lifetime of the
 process.  We've seen thread contention in this area when using
 OpenSSL.  One work

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Some of the algorithms still invoke the FIPS flavor of the algorithm
even when FIPS is disabled.  For example, this code is from
EVP_DigestUpdate().

int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx, data, count);
#endif
}

In 1.0.1, locks 39 and 40 are:

# define CRYPTO_LOCK_FIPS39
# define CRYPTO_LOCK_FIPS2   40

You should try adding some logic to skip the lock in your lock handler
when the lock ID is 39 or 40. Again, it should be safe to not lock on
these two as long as the FIPS POST has completed.



On 04/24/2015 05:56 PM, Bryan Call wrote:
 In my last email I ran the benchmark on Fedora 21 (big mistake).  
 Here are the results when running it back on the 28/56 core RHEL 6.5
 server showing contention in a different place (fips).  Is there a
 reason it would be calling into the FIPS code to get a lock of FIPS is
 not enabled?

 Contention log:
 [Apr 24 21:35:09.731] Server {0x7f5529ccd700} ERROR: contention for
 lock - total contention: 70662 waiting: 16 file: fips.c line: 471 type: 40
 [Apr 24 21:35:09.732] Server {0x7f55299ca700} ERROR: contention for
 lock - total contention: 71605 waiting: 2 file: fips.c line: 107 type: 39


 Line in in fips that see the contention the most:
 [bcall@bm77 trafficserver]$ grep fips.c diags.log | cut -f 19 -d ' ' |
 sort | uniq -c | sort -rn
  875379 471
  288338 107
  275472 127


 Different lock types and their contention frequency (multiple benchmarks):
  875379 40   - in fips.c
  563810 39  - also in fips.c
  440518 1
   44145 18
   17447 2
   11356 10
1377 19
 687 12
 532 25
 302 33
 239 9
  58 16
  40 21
  32 11
  19 3
   1 14


 Code to diable FIPS and log:
 #ifdef OPENSSL_FIPS
 int mode = FIPS_mode();
 Debug(ssl, FIPS_mode: %d, mode);
 mode = FIPS_mode();
 if (mode) {
   FIPS_mode_set(0);
   Debug(ssl, FIPS_mode: %d, mode);
 }
 #endif

 [Apr 24 21:43:45.860] Server {0x7f7628146800} DEBUG: (ssl) FIPS_mode: 0

 -Bryan




 On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 When you create the private key given to SSL_CTX, be sure to
 instantiate a private key for each thread as well.  If you share the
 same key across all threads, this can introduce contention.

 Here are the type 1  2 locks:

 # define CRYPTO_LOCK_ERR 1
 # define CRYPTO_LOCK_EX_DATA 2

 Have you checked the OpenSSL error log to see what errors are being
 generated?

 Also, if you disable FIPS, does the thread contention still occur?



 On 04/24/2015 01:36 PM, Bryan Call wrote:
 We are using a single SSL_CTX across all the threads, so I will
 create multiple SSL_CTX per thread.  I implemented dynlock callbacks
 yesterday, but I didn’t see them being used in the tests I did.  I
 also added atomic counters to see what type of locks are having
 contention (see logs below):

 Most of the lock contention seems to be around type 2 and type 1
 locks when calling our lock callback.  In the FIPS/POST and SSL_CTX
 recommendations, in your previous email, what types of locks would
 those help with?

 Log output:
 [Apr 24 10:21:24.339] Server {0xb31} ERROR: SSLUtils.cc
 http://sslutils.cc/:178 (SSL_locking_callback) contention for
 lock - total contention: 3938 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c
 line: 496 type: 2
 [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: SSLUtils.cc
 http://sslutils.cc/:178 (SSL_locking_callback) contention for
 lock - total contention: 1350 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c
 line: 343 type: 1


 -Bryan




 On Apr 23, 2015, at 4:46 PM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 Looking at your call stack, it appears you're testing with FIPS
 mode enabled.  There's a lock in FIPS_selftest_failed() that's used
 to ensure the crypto algorithms inside the FIPS boundary are not
 utilized until after the POST has completed and passed.
 Unfortunately this lock remains installed for the lifetime of the
 process.  We've seen thread contention in this area when using
 OpenSSL.  One work-around is to modify your handler that you pass
 to SSL_locking_callback() to not lock when the lock ID is
 CRYPTO_LOCK_FIPS.  But you would only want to disable this
 particular lock ID after the POST has completed.

 If the above doesn't help, another item to check is whether you're
 instantiating an SSL_CTX for each thread.  I've seen some
 developers use a single SSL_CTX for multiple threads.  This results
 in a single instance of the server cert and private key being
 shared across all the threads.  This results in thread contention
 on the asymmetric key operations associated with the cert and
 private key (e.g. RSA).  Be sure that each thread instantiates it's
 own SSL_CTX and certificate/private

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

When you create the private key given to SSL_CTX, be sure to instantiate
a private key for each thread as well.  If you share the same key across
all threads, this can introduce contention.

Here are the type 1  2 locks:

# define CRYPTO_LOCK_ERR 1
# define CRYPTO_LOCK_EX_DATA 2

Have you checked the OpenSSL error log to see what errors are being
generated?

Also, if you disable FIPS, does the thread contention still occur?



On 04/24/2015 01:36 PM, Bryan Call wrote:
 We are using a single SSL_CTX across all the threads, so I will create
 multiple SSL_CTX per thread.  I implemented dynlock callbacks
 yesterday, but I didn’t see them being used in the tests I did.  I
 also added atomic counters to see what type of locks are having
 contention (see logs below):

 Most of the lock contention seems to be around type 2 and type 1 locks
 when calling our lock callback.  In the FIPS/POST and SSL_CTX
 recommendations, in your previous email, what types of locks would
 those help with?

 Log output:
 [Apr 24 10:21:24.339] Server {0xb31} ERROR: SSLUtils.cc
 http://SSLUtils.cc:178 (SSL_locking_callback) contention for lock -
 total contention: 3938 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/ex_data.c line:
 496 type: 2
 [Apr 24 10:21:24.754] Server {0xb10a000} ERROR: SSLUtils.cc
 http://SSLUtils.cc:178 (SSL_locking_callback) contention for lock -
 total contention: 1350 waiting: 1 file:
 /SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/err/err_def.c
 line: 343 type: 1


 -Bryan




 On Apr 23, 2015, at 4:46 PM, John Foley fol...@cisco.com
 mailto:fol...@cisco.com wrote:

 Looking at your call stack, it appears you're testing with FIPS mode
 enabled.  There's a lock in FIPS_selftest_failed() that's used to
 ensure the crypto algorithms inside the FIPS boundary are not
 utilized until after the POST has completed and passed. Unfortunately
 this lock remains installed for the lifetime of the process.  We've
 seen thread contention in this area when using OpenSSL.  One
 work-around is to modify your handler that you pass to
 SSL_locking_callback() to not lock when the lock ID is
 CRYPTO_LOCK_FIPS.  But you would only want to disable this particular
 lock ID after the POST has completed.

 If the above doesn't help, another item to check is whether you're
 instantiating an SSL_CTX for each thread.  I've seen some developers
 use a single SSL_CTX for multiple threads.  This results in a single
 instance of the server cert and private key being shared across all
 the threads.  This results in thread contention on the asymmetric key
 operations associated with the cert and private key (e.g. RSA).  Be
 sure that each thread instantiates it's own SSL_CTX and
 certificate/private key.

 Lastly, add some debugs to count the locks by lock ID in your lock
 handler.  There are about 40 different lock IDs defined in
 crypto/crypto.h.  You'll need to identify which lock is causing the
 thread contention.  Once you know that, then you can look in the code
 to see where that lock is used and troubleshoot from there.



 On 04/23/2015 07:23 PM, Bryan Call wrote:
 I was running a benchmark on a 28 core (56 hyper-threaded) server
 that is running 84 threads in the process and I am seeing a lot of
 lock contention.  I saw a lot of lock contention in the calls to
 SSL_get_error() ssl3_accept().  I am running RHEL 6.5
 and openssl-1.0.1e-30.el6_6.7.x86_64.  We have
 used SSL_locking_callback() to setup pthread mutex locks, but
 haven’t setup dynlocks yet.  Would dynlocks help in this scenario?


 Output from perf:
 Samples: 1M of event 'cycles', Event count (approx.): 602783506611
 - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ◆
 - _spin_lock ▒

   * + 48.05% futex_wait_setup ▒
   * + 47.79% futex_wake ▒
   * + 1.20% tcp_v4_rcv ▒
   * + 0.98% task_rq_lock ▒
   * + 0.64% double_lock_balance ▒

 + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ▒
 + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ▒
 + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x000e5200 ▒
 + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ▒
 + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ▒
 + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ▒
 + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ▒
 + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ▒
 + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ▒
 + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ▒
 + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock

 pstack of the process (only a couple of the interesting threads):
 Thread 1 (Thread 0x7f1fba151800 (LWP 1106)):
 #0 0x7f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0
 #1 0x7f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0
 #2 0x7f1fbaae63d7 in pthread_mutex_lock () from
 /lib64/libpthread.so.0
 #3 0x0072822f in SSL_locking_callback(int, int, char const*,
 int) ()
 #4

Re: [openssl-users] Performance problems with OpenSSL and threading

[John Foley]

Looking at your call stack, it appears you're testing with FIPS mode
enabled.  There's a lock in FIPS_selftest_failed() that's used to ensure
the crypto algorithms inside the FIPS boundary are not utilized until
after the POST has completed and passed. Unfortunately this lock remains
installed for the lifetime of the process.  We've seen thread contention
in this area when using OpenSSL.  One work-around is to modify your
handler that you pass to SSL_locking_callback() to not lock when the
lock ID is CRYPTO_LOCK_FIPS.  But you would only want to disable this
particular lock ID after the POST has completed.

If the above doesn't help, another item to check is whether you're
instantiating an SSL_CTX for each thread.  I've seen some developers use
a single SSL_CTX for multiple threads.  This results in a single
instance of the server cert and private key being shared across all the
threads.  This results in thread contention on the asymmetric key
operations associated with the cert and private key (e.g. RSA).  Be sure
that each thread instantiates it's own SSL_CTX and certificate/private key.

Lastly, add some debugs to count the locks by lock ID in your lock
handler.  There are about 40 different lock IDs defined in
crypto/crypto.h.  You'll need to identify which lock is causing the
thread contention.  Once you know that, then you can look in the code to
see where that lock is used and troubleshoot from there.



On 04/23/2015 07:23 PM, Bryan Call wrote:
 I was running a benchmark on a 28 core (56 hyper-threaded) server that
 is running 84 threads in the process and I am seeing a lot of lock
 contention.  I saw a lot of lock contention in the calls to
 SSL_get_error() ssl3_accept().  I am running RHEL 6.5
 and openssl-1.0.1e-30.el6_6.7.x86_64.  We have
 used SSL_locking_callback() to setup pthread mutex locks, but haven’t
 setup dynlocks yet.  Would dynlocks help in this scenario?


 Output from perf:
 Samples: 1M of event 'cycles', Event count (approx.): 602783506611
 - 48.04% [ET_NET 0] [kernel.kallsyms] [k] _spin_lock ◆
 - _spin_lock ▒

   * + 48.05% futex_wait_setup ▒
   * + 47.79% futex_wake ▒
   * + 1.20% tcp_v4_rcv ▒
   * + 0.98% task_rq_lock ▒
   * + 0.64% double_lock_balance ▒

 + 3.94% [ET_NET 0] libcrypto.so.1.0.1e [.] bn_mul_mont ▒
 + 1.93% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_usub ▒
 + 1.80% [ET_NET 0] libcrypto.so.1.0.1e [.] 0x000e5200 ▒
 + 1.49% [ET_NET 0] libcrypto.so.1.0.1e [.] sha256_block_data_order ▒
 + 0.97% [ET_NET 0] libcrypto.so.1.0.1e [.] gcm_ghash_clmul ▒
 + 0.85% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_lock ▒
 + 0.84% [ET_NET 0] libcrypto.so.1.0.1e [.] aesni_ctr32_encrypt_blocks ▒
 + 0.74% [ET_NET 0] libc-2.12.so [.] malloc ▒
 + 0.72% [ET_NET 0] libc-2.12.so [.] memcpy ▒
 + 0.57% [ET_NET 0] libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery ▒
 + 0.51% [ET_NET 0] libpthread-2.12.so [.] pthread_mutex_unlock

 pstack of the process (only a couple of the interesting threads):
 Thread 1 (Thread 0x7f1fba151800 (LWP 1106)):
 #0 0x7f1fbaaeb264 in __lll_lock_wait () from /lib64/libpthread.so.0
 #1 0x7f1fbaae6508 in _L_lock_854 () from /lib64/libpthread.so.0
 #2 0x7f1fbaae63d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
 #3 0x0072822f in SSL_locking_callback(int, int, char const*,
 int) ()
 #4 0x0031d2ae7f03 in ?? () from /usr/lib64/libcrypto.so.10
 #5 0x0031d2ae7d8c in ?? () from /usr/lib64/libcrypto.so.10
 #6 0x0031d2ae80ab in ERR_get_state () from /usr/lib64/libcrypto.so.10
 #7 0x0031d2ae8557 in ?? () from /usr/lib64/libcrypto.so.10
 #8 0x0031d2e424a9 in SSL_get_error () from /usr/lib64/libssl.so.10
 #9 0x007249ef in
 SSLNetVConnection::load_buffer_and_write(long, long, long,
 MIOBufferAccessor, int) ()
 #10 0x007389df in write_to_net_io(NetHandler*,
 UnixNetVConnection*, EThread*) ()
 #11 0x00738523 in write_to_net(NetHandler*,
 UnixNetVConnection*, EThread*) ()
 #12 0x00731922 in NetHandler::mainNetEvent(int, Event*) ()
 #13 0x004f6d48 in Continuation::handleEvent(int, void*) ()
 #14 0x0075877a in EThread::process_event(Event*, int) ()
 #15 0x00758c84 in EThread::ex

 Thread 56 (Thread 0x7f1fb0ecd700 (LWP 1172)):
 #0 0x7f1fbaae77d9 in pthread_mutex_unlock () from
 /lib64/libpthread.so.0
 #1 0x00728265 in SSL_locking_callback(int, int, char const*,
 int) ()
 #2 0x0031d2b57402 in ?? () from /usr/lib64/libcrypto.so.10
 #3 0x0031d2b574bd in FIPS_selftest_failed () from
 /usr/lib64/libcrypto.so.10
 #4 0x0031d2ae9f1c in EVP_DigestInit_ex () from
 /usr/lib64/libcrypto.so.10
 #5 0x0031d2a7977e in HMAC_Init_ex () from /usr/lib64/libcrypto.so.10
 #6 0x0031d2a79c29 in ?? () from /usr/lib64/libcrypto.so.10
 #7 0x0031d2af7a42 in EVP_PKEY_CTX_ctrl () from
 /usr/lib64/libcrypto.so.10
 #8 0x0031d2ae9ffb in EVP_DigestInit_ex () from
 /usr/lib64/libcrypto.so.10
 #9 0x0031d2af952a in ?? () from /usr/lib64/libcrypto.so.10
 #10 0x0031d2e34cf2 

Re: [openssl-users] Building libcrypto/libssl without symbolic link

[John Foley]

Are you packaging libcrypto.so into the APK yourself?  The Android OS
comes with it's own resident copy of libcrypto.  You can leverage this
from your app without having to package libcrypto into your
application.  This assumes the version of libcrypto that comes with
Android meets your needs.  Given the various flavors of Android out in
the wild, this may limit what your application can do with libcrypto.

If you're packaging libcrypto into your APK, one problem I've seen in
Android is the System.LoadLibrary() call will use the host resident copy
of libcrypto instead of the one packaged in the APK.  One way to get
around this is to hack the linker step in the OpenSSL makefile to rename
libcrypto to something different.  You'll need to make sure the -soname
option on the linker step is consistent with whatever you name the
library.  For instance, you can name it libcryptoX.so, and pass in this
same name to the -soname option.  Confirm that it works using objdump to
view the ELF header.  The soname will be in the ELF header.  Then
package libcryptoX.so into your APK and use this name with the
System.LoadLibrary() call.



On 04/22/2015 09:41 AM, Shanku Roy wrote:
 Am cross compiling the FIPS enabled version for Android; In Android, some 
 apps are having trouble loading their bundled libcrypto library when the 
 binary is named as *.so.1.0.0 instead of libcrypto.so as platform library.

  
 - Original Message -
 From: Viktor Dukhovni openssl-us...@dukhovni.org
 To: openssl-users@openssl.org
 Cc: 
 Sent: Tuesday, April 21, 2015 11:47 PM
 Subject: Re: [openssl-users] Building libcrypto/libssl without symbolic link

 On Wed, Apr 22, 2015 at 12:12:45AM +, Shanku Roy wrote:
 lrw-r--r-- root root  2015-04-10 02:33 libcrypto.so - 
 libcrypto.so.1.0.0
 -rw-r--r-- root root  1988088 2015-04-10 02:27 libcrypto.so.1.0.0

 Is there any configure option in OpenSSL build scripts to not generate
 the symbolic links and rather generate actual binary as
 libcrypto.so/libssl.so from the build process like following:
 The library soname is part of the ABI.  What platform are you
 building for where it would not be appropriate to encode the ABI
 compatibility name into the library name?



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

Re: [openssl-users] Fwd: Itanium problem

[John Foley]

I'm impressed you were able to do a FIPS build for Windows x64.  I
didn't think this was possible.  ;-)

This looks like the hash that FINGERPRINT_premain() spits out when the
signature hasn't been embedded into the binary.  You may want to confirm
the signature is embedded during the build process.



On 04/16/2015 04:31 PM, Rongliang Lei wrote:

 I used Fips module 2.0.9 and OpenSSL 1.0.1M. It built fine in windows
 for x64,win32 and Itanium. However, it only runs fine for x64 and
 Win32. For Itanium system, my executable exits immediately right after
 it runs, and it generated with follow sequence
 d375fa8a9fd9d8f90fede1f1a9e548132d63230f. I tried dynamic load the
 libeay32.dll  or ssleay32.dll. It has same problem. Any idea about
 this issue?



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

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

Do you see the same stack trace when simply using the random number
generator:

./openssl rand 64

What if you simply use SHA1:

./openssl sha1 somefile



On 04/14/2015 12:17 PM, John Unsworth wrote:

 Is no-one interested at all about this problem? Or do I need to send
 it to another place?

  

 Regards,

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *John Unsworth
 *Sent:* 10 April 2015 14:54
 *To:* openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
 broken

  

 I have compiled 1.0.1m in the same way and that works fine using asm.

  

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *John Unsworth
 *Sent:* 10 April 2015 12:21
 *To:* openssl-users@openssl.org
 *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

  

 I have an application that runs quite happily using OpenSSL 1.0.1h on
 Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause
 problems.

  

 1 When building 1.0.2 using

  

 ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32
 -xldscope=hidden

  

 openssl s_client crashes on start:

  

 -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250

 Segmentation Fault (core dumped)

 -bash-3.00$ pstack core

 core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250

 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4,
 44) + 8

 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530

 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c

 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138

 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88

 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94

 0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8

 00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108

  

 2 So I then rebuilt adding no-asm flag. It manages to connect but
 negotiation fails with an error:

  

 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad
 record mac:s3_pkt.c:1456:SSL alert number 20

 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
 failure:s23_lib.c:177:

  

 This is against the server that is still running 1.0.1h and can be
 successfully connected with openssl built with 1.0.1h.

  

 Note that the 64 bit build seems to work perfectly. Unfortunately for
 historical reasons we need to use the 32 bit version.

  

 The 32 bit builds that we use on Windows and Linux also work
 perfectly. Is it something to do with byte order?

  

 Regards,

 John.

  

  



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

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

How about the ./openssl sha1 command?  Does that bomb too?

It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from the
1.0.1 source into the 1.0.2 source.  Then clean, configure, compile and
try again.  There were changes to this file between 1.0.1 and 1.0.2. 
Perhaps a bug was introduced.  I'm assuming this script generates the
SHA source for your target platform. 



On 04/15/2015 09:56 AM, John Unsworth wrote:

 core 'core' of 24243:   ./openssl rand 64

 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018, ffbfe01c,
 44) + 8

 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530

 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650, 2c0644) + 38c

 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70, 13000) + 138

 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88

 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8

 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8

 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

  

 Regards,

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *John Foley
 *Sent:* 15 April 2015 13:31
 *To:* openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
 broken

  

 Do you see the same stack trace when simply using the random number
 generator:

 ./openssl rand 64

 What if you simply use SHA1:

 ./openssl sha1 somefile


 On 04/14/2015 12:17 PM, John Unsworth wrote:

 Is no-one interested at all about this problem? Or do I need to
 send it to another place?

  

 Regards,

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
 *On Behalf Of *John Unsworth
 *Sent:* 10 April 2015 14:54
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
 is broken

  

 I have compiled 1.0.1m in the same way and that works fine using asm.

  

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
 *On Behalf Of *John Unsworth
 *Sent:* 10 April 2015 12:21
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
 broken

  

 I have an application that runs quite happily using OpenSSL 1.0.1h
 on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a
 cause problems.

  

 1 When building 1.0.2 using

  

 ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32
 -xldscope=hidden

  

 openssl s_client crashes on start:

  

 -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250

 Segmentation Fault (core dumped)

 -bash-3.00$ pstack core

 core 'core' of 468: ./openssl s_client -connect
 eos.es.cpth.ie:4250

 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0,
 ffbfebc4, 44) + 8

 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530

 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630,
 2c0624) + 38c

 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50,
 13000) + 138

 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88

 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94

 0001328c do_cmd   (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8

 00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3e78) + 108

  

 2 So I then rebuilt adding no-asm flag. It manages to connect but
 negotiation fails with an error:

  

 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert
 bad record mac:s3_pkt.c:1456:SSL alert number 20

 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
 failure:s23_lib.c:177:

  

 This is against the server that is still running 1.0.1h and can be
 successfully connected with openssl built with 1.0.1h.

  

 Note that the 64 bit build seems to work perfectly. Unfortunately
 for historical reasons we need to use the 32 bit version.

  

 The 32 bit builds that we use on Windows and Linux also work
 perfectly. Is it something to do with byte order?

  

 Regards,

 John.

  

  




 ___

 openssl-users mailing list

 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

  



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

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

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

Looks like the crash is in SHA-512 this time, not SHA-1.  There's a
separate perl script to generate that assembly code.  Try the 1.0.1
version of sha512-sparcv9.pl.

The output from your rand command is valid.  You can use the -base64
option if you want something more readable.



On 04/15/2015 11:13 AM, John Unsworth wrote:

 That seems to have fixed the crash.

  

 -bash-3.00$ ./openssl rand 64

 zÔòMÉÜOvá¯@ét†Å�­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$

  

 Not sure about the output though.

  

 However negotiation causes a core:

  

 -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250

 CONNECTED(0004)

 depth=0 CN = jusworth-lt4.eu.cp.net

 verify error:num=20:unable to get local issuer certificate

 verify return:1

 depth=0 CN = jusworth-lt4.eu.cp.net

 verify error:num=21:unable to verify the first certificate

 verify return:1

 Segmentation Fault (core dumped)

 -bash-3.00$ pstack core

 core 'core' of 12587:   ./openssl s_client -connect eos.es.cpth.ie:4250

 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588, 30c050,
 64f98fa7) + 8

 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100,
 2f8ea0) + 1cc

 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10,
 a42e0, 2f8ae0) + 90

 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0

 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638) + 648

 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588

 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c

 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374

 0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8

 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108

  

 Regards,

 John

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *John Foley
 *Sent:* 15 April 2015 15:10
 *To:* openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
 broken

  

 How about the ./openssl sha1 command?  Does that bomb too?

 It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl from
 the 1.0.1 source into the 1.0.2 source.  Then clean, configure,
 compile and try again.  There were changes to this file between 1.0.1
 and 1.0.2.  Perhaps a bug was introduced.  I'm assuming this script
 generates the SHA source for your target platform. 


 On 04/15/2015 09:56 AM, John Unsworth wrote:

 core 'core' of 24243:   ./openssl rand 64

 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018,
 ffbfe01c, 44) + 8

 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530

 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650,
 2c0644) + 38c

 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70,
 13000) + 138

 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88

 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8

 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98) + b8

 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98, 2b4afc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

  

 Regards,

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
 *On Behalf Of *John Foley
 *Sent:* 15 April 2015 13:31
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
 is broken

  

 Do you see the same stack trace when simply using the random
 number generator:

 ./openssl rand 64

 What if you simply use SHA1:

 ./openssl sha1 somefile



 On 04/14/2015 12:17 PM, John Unsworth wrote:

 Is no-one interested at all about this problem? Or do I need
 to send it to another place?

  

 Regards,

 John.

  

 *From:*openssl-users
 [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *John
 Unsworth
 *Sent:* 10 April 2015 14:54
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit
 build is broken

  

 I have compiled 1.0.1m in the same way and that works fine
 using asm.

  

 John.

  

 *From:*openssl-users
 [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *John
 Unsworth
 *Sent:* 10 April 2015 12:21
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
 is broken

  

 I have an application that runs quite happily using OpenSSL
 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and
 1.0.2a cause problems.

  

 1 When building 1.0.2 using

Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken

[John Foley]

This appears to be a different problem than the crash in SHA.  Since
you're seeing a bad record mac, it appears the TLS handshake has made
it through the ChangeCipherSpec message.  Do you know which cipher suite
is being negotiated?  If it's AES, it may be worth trying a 3DES cipher
suite.  If the issue is in the AES layer, one of the 3DES cipher suites
should work.

By the way, have you run a 'make test' after building OpenSSL?  Are all
the test suites passing?  If not, which one is failing?



On 04/15/2015 12:26 PM, John Unsworth wrote:

 Still exactly the same crash. And even if these assembly code problems
 can be fixed there is still the negotiation error after compiling with
 no-asm.

  

 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad
 record mac:s3_pkt.c:1456:SSL alert number 20

 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake
 failure:s23_lib.c:177:

  

 John.

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *John Foley
 *Sent:* 15 April 2015 16:45
 *To:* openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
 broken

  

 Looks like the crash is in SHA-512 this time, not SHA-1.  There's a
 separate perl script to generate that assembly code.  Try the 1.0.1
 version of sha512-sparcv9.pl.

 The output from your rand command is valid.  You can use the -base64
 option if you want something more readable.


 On 04/15/2015 11:13 AM, John Unsworth wrote:

 That seems to have fixed the crash.

  

 -bash-3.00$ ./openssl rand 64

 zÔòMÉÜOvá¯@ét†Å�­EÙ^±Q!þ\‰b_¨ëYŸÁµiT-n߇ñ¬“B+Õ9kx©î%hRÈz-bash-3.00$

  

 Not sure about the output though.

  

 However negotiation causes a core:

  

 -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250

 CONNECTED(0004)

 depth=0 CN = jusworth-lt4.eu.cp.net

 verify error:num=20:unable to get local issuer certificate

 verify return:1

 depth=0 CN = jusworth-lt4.eu.cp.net

 verify error:num=21:unable to verify the first certificate

 verify return:1

 Segmentation Fault (core dumped)

 -bash-3.00$ pstack core

 core 'core' of 12587:   ./openssl s_client -connect
 eos.es.cpth.ie:4250

 000ed408 sha512_block_data_order (30e538, 30c050, 71a, 30e588,
 30c050, 64f98fa7) + 8

 0009fb30 ssl3_digest_cached_records (2f8ae0, 6, 2f8ea0, 14, 100,
 2f8ea0) + 1cc

 000980ec ssl3_get_certificate_request (2f8ae0, 2f8ea0, 2f8ea0, 10,
 a42e0, 2f8ae0) + 90

 00093ad8 ssl3_connect (2f8ae0, 0, 1180, 1000, 1130, ) + 6c0

 000aa2b8 ssl23_get_server_hello (2f8ae0, 16, 3, 3, 2f8ea0, 301638)
 + 648

 000a9198 ssl23_connect (2f8ae0, 0, 3000, 2b4d64, 2b3d78, 1) + 588

 000aa60c ssl23_write (2f8ae0, 2f0270, 0, 3000, ff247c94, a8c10) + 4c

 0004ee64 s_client_main (0, 0, 1, 2b4d64, 2f8ae0, 2f4280) + 7374

 0001328c do_cmd   (2eb3c8, 3, ffbffad0, 2b4638, 13e64, 2b3d78) + b8

 00012f08 main (4, ffbffacc, 2eb3c8, 29fc00, 2b3d78, 2b49dc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3d78) + 108

  

 Regards,

 John

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org]
 *On Behalf Of *John Foley
 *Sent:* 15 April 2015 15:10
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build
 is broken

  

 How about the ./openssl sha1 command?  Does that bomb too?

 It might be interesting to copy crypto/sha/asm/sha1-sparcv9.pl
 from the 1.0.1 source into the 1.0.2 source.  Then clean,
 configure, compile and try again.  There were changes to this file
 between 1.0.1 and 1.0.2.  Perhaps a bug was introduced.  I'm
 assuming this script generates the SHA source for your target
 platform. 



 On 04/15/2015 09:56 AM, John Unsworth wrote:

 core 'core' of 24243:   ./openssl rand 64

 000e9ce8 sha1_block_data_order (2ec298, 2ec2f4, 4, ffbfe018,
 ffbfe01c, 44) + 8

 00226160 ssleay_rand_add (ffbfe114, 1, 20, ffbfdfec, 0, 14) + 530

 00227048 RAND_poll (4, ffbfe100, ffbfe120, ffbfe120, 2c0650,
 2c0644) + 38c

 00226c00 ssleay_rand_status (c734, 0, 2b9f7c, 2c05cc, 2a0e70,
 13000) + 138

 00065eb4 app_RAND_load_file (ffbfe418, 2d5238, 0, 2800, 0, 1) + 88

 00077cb8 rand_main (0, 0, ff242b30, 0, 0, 0) + 4b8

 0001328c do_cmd   (2eb4e8, 2, ffbffae0, 2b4728, 13e64, 2b3e98)
 + b8

 00012f08 main (3, ffbffadc, 2eb4e8, 2a, 2b3e98,
 2b4afc) + 3a4

 00012a08 _start   (0, 0, 0, 0, 0, 2b3e98) + 108

  

 Regards,

 John.

  

 *From:*openssl-users
 [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *John
 Foley
 *Sent:* 15 April 2015 13:31
 *To:* openssl-users@openssl.org mailto:openssl

Re: [openssl-users] FW: Getting Apache to Recognize New OpenSSL Install

[John Foley]

Have you recompiled Apache?  Or did you only recompile OpenSSL 1.0.2a? 
There is no binary compatibility between 0.9.8 and 1.0.2.  You'll need
to recompile Apache if you haven't done this.  Or, possibly a newer
Apache binary (2.4.12) would work with your OpenSSL 1.0.2a build.





On 04/06/2015 03:50 PM, Cathy Fauntleroy wrote:

 I’ve posed the same question on the Apache user forum but have not
 received any responses.

  

 Thanks…

 */Cathy /***

  

 *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
 Behalf Of *Jeremy Farrell
 *Sent:* Monday, April 6, 2015 1:55 PM
 *To:* openssl-users@openssl.org
 *Subject:* Re: [openssl-users] FW: Getting Apache to Recognize New
 OpenSSL Install

  

 There might be people on the OpenSSL list who can answer this, but
 your question is really about Apache configuration or installation.
 You'll probably get more knowledgable answers on an Apache list.

 Regards,
jjf

 On 06/04/2015 17:04, Cathy Fauntleroy wrote:

 A follow-up question…Should I have installed Apache 2.2.25 with no
 OpenSSL (instead of the one I did install with OpenSSL 0.9.8)? 
 I’m thinking that perhaps with the no ssl install, Apache would
 more easily recognize my OpenSSL 1.0.2 instance.  I appreciate
 your thoughts and suggestions.

  

 Thanks…


 */Cathy Fauntleroy,/* *Security+*

 *Van Dyke Technology Group*

 *Email:**  cathy.fauntle...@vdtg.com
 mailto:cathy.fauntle...@vdtg.com*

 *Office:  (443) 832-4768*

  

 *From:* openssl-users [mailto:openssl-users-boun...@openssl.org]
 *On Behalf Of *Cathy Fauntleroy
 *Sent:* Monday, April 6, 2015 11:35 AM
 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org
 *Subject:* [openssl-users] Getting Apache to Recognize New OpenSSL
 Install

  

 Hello Users,

  

 I am in need of some assistance/documentation.  My current setup
 is:  Windows 2008 R2, Apache 2.2.25 w/OpenSSL 0.9.8.  I need to
 enable TLS1.1, 1.2 but understand that 0.9.8 does not support
 those protocols.  So, I installed OpenSSL 1.0.2a and made system
 environment mappings to the CNF and CFG files.  The install was
 successful but Apache is not recognizing the updated OpenSSL
 version.  I am not very familiar with the intricacies of
 configuring this product.  Can anyone tell me how (or point me to
 documentation) I can get Apache to recognize the updated OpenSSL
 installation?

  

 Thanks…

  




 ___

 openssl-users mailing list

 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



 -- 
 J. J. Farrell
 w: +44 161 493 4838


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

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

Re: [openssl-users] OpenSSL Compile Issues (and general knowledge questions)

[John Foley]

The 'make depend' regenerates the dependencies for the makefiles. The 
dependencies will change depending on the configuration options you've 
passed to OpenSSL.  If you're new to using GNU make, here's a decent 
explanation:


http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/

Your second question reflects a problem in the test/testssl script. This 
script is largely unaware of most configuration options (e.g. no-ssl3).  
This script is attempting to run the SSL3 unit tests even though you 
have omitted support for SSL3 in the library.  You may want to open a 
bug in the OpenSSL request tracker 
(https://www.openssl.org/support/rt.html).






On 03/27/2015 03:14 PM, Lesley Kimmel wrote:

All;

I'm an administrator/engineer responsible for compiling Apache with 
OpenSSL supporting FIPS mode. I've got a good process down that 
generally works. However, I am looking for a little help on some 
details because I am not a developer and am not about digging through 
the source code to figure out these issues.


a) I don't typically run 'make depend' and things seem to work. 
However, the OpenSSL compile wiki directs to run this command. What 
will this do for me?
b) I know that I can disable SSLv2 and SSLv3 via Apache itself but I 
see that there are options (no-ssl2, no-ssl3) that can be used during 
compilation of OpenSSL which will presumably disable them altogether. 
However, when compiling this way the 'make test' always fails with 
some useless error. For example, when compiling just with 'no-ssl2' I 
get the following:


../util/shlib_wrap.sh ./evp_extra_test
PASS
test SSL protocol
test ssl3 is forbidden in FIPS mode
*** IN FIPS MODE ***
Available compression methods:
  NONE
139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls 
allowed in fips mode:ssl_lib.c:1716:
139934033385128:error:140A9129:SSL routines:SSL_CTX_new:only tls 
allowed in fips mode:ssl_lib.c:1716:

test ssl2 is forbidden in FIPS mode
Testing was requested for a disabled protocol. Skipping tests.
make[1]: *** [test_ssl] Error 1
make[1]: Leaving directory `/opt/apache_stage/httpd/srclib/openssl/test'
make: *** [tests] Error 2

Is this expected behavior? Is there any way to disable SSLv2/3 while 
still passing the tests? I feel that passing the tests is pretty 
important to my confidence in the final product.



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


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

Re: [openssl-users] FIPS Linux kernel documentation ?

[John Foley]

We looked at this very briefly a couple of years ago.  In theory, there 
may be a way to achieve the goal as a loadable kernel module (a.k.a. 
device driver).  The idea would be to have a kernel module that provides 
crypto support.  This kernel module would be the FIPS object module, 
with the FIPS boundary drawn around the kernel module.  This would be 
loaded at run time like any other device driver when FIPS mode needed to 
be enabled.


There is likely some kernel work required to allow the ciphers in the 
kernel module to be injected into the crypto flow within the kernel.  
The other issue is getting the kernel to automatically run the FIPS 
integrity test on the module at load time.




On 03/26/2015 10:57 AM, Steve Marquess wrote:

On 03/25/2015 06:26 PM, jone...@teksavvy.com wrote:

On Wed, 25 Mar 2015 17:03:04 -0400
Steve Marquess marqu...@openssl.com wrote:


I wasn't aware the Linux kernel (the real one, not proprietary
commercial derivatives) had a FIPS mode. Please enlighten me.

It could very well be that the word 'mode' is not the right one.
'option' would perhaps be better.  This article from 2009 sets the
foundation:

http://www.guerilla-ciso.com/archives/793

I wonder, 6 years later, what the kernel fips option implies.  Maybe I
could try to contact Neil Horman andéor look into the sources.

That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS
doesn't get you any closer to FIPS 140-2 validated kernel cryptography.

Unfortunately FIPS 140-2 validation conflicts rather violently with open
source software (and with software engineering best practice in general,
for that matter). Even if some benevolent benefactor ponied up the
quarter megabuck it would take to do an open source based kernel crypto
validation, it would be fossilized code obsolete before the validation
was even approved. Linux got to be as good as it is due to constant
refinement and improvement; FIPS validation presumes that it is possible
to write perfect code in one shot and that the environment that code
runs in never changes.

-Steve M.



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

Re: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases

[John Foley]

We maintain our own derivative of OpenSSL and haven't had any
significant issues due to the code reformat.  We simply run the reformat
script on our downstream derivative.  We can then generate patch files
of our changes and reapply them to new OpenSSL releases.  It was fairly
straight forward.

IMHO, the code reformat was long overdue.  The prior lack of consistent
coding style was an abomination, making the code more difficult to read
and maintain.  Sometimes taking a step forward results in some pain. 
This was a good investment for the future.

+1 for the reformat.



On 03/18/2015 06:45 AM, Jakob Bohm wrote:
 On 18/03/2015 10:14, Matt Caswell wrote:
 On 18/03/15 07:59, Jakob Bohm wrote:
 (Resend due to MUA bug sending this to -announce)

 On 16/03/2015 20:05, Matt Caswell wrote:
 Forthcoming OpenSSL releases
 

 The OpenSSL project team would like to announce the forthcoming release
 of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf.

 These releases will be made available on 19th March. They will fix a
 number of security defects. The highest severity defect fixed by these
 releases is classified as high severity.
 Just for clarity in preparing to use the forthcoming
 update:

 Has the 1.0.1m source code been mangled by the script that
 made it near-impossible to port local changes to 1.0.2, or
 will it retain the same code formatting as in the rest of
 the 1.0.1 series?

 Similarly, will 1.0.0r be mangled or will it retain the
 same code formatting as in the rest of the 1.0.0 series?

 Similarly, will 0.9.8zf be mangled or will it retain the
 same code formatting as in the rest of the 0.9.8 series?
 I prefer the term improved over mangled! ;-)

 The answer is, yes, all branches (including 1.0.1, 1.0.0 and 0.9.8) have
 been reformatted according to the new coding style.

 It is perfectly possible, if a little fiddly, to reformat your local
 patches to the new style. I have done so myself for a number of my own
 patches. I included some outline instructions on how to do it in my
 recent blog post on the reformat:

 https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/
 Long read, and lots of internal details of how your script
 doesn't even work for yourown code...

 However the patch rebasing instructions are *completely
 useless* for those of us whomaintain private patches
 against releases tarballs.  We *don't* have any of this
 in a clone of your gitand we *have no way* to access
 intermediary git steps from your partially botched
 freeze-reformat-unfreeze-other-work-oopsmorereformat-
 other-work sequence.

 I guess each of us will have to spend weeks (or more)
 manually recreating all our hard work before we can apply
 whatever security fixes are hidden in tomorrows tarball.

 And it also seems that it is nearly impossible to turn the
 changes into a reviewable patch that can be applied to an
 existing tree, like the various distributions (on and off
 the vendor-sec lists) will need to.

 So let's all hope one of the vendors will do your job for
 you and transform the new releases into patches against
 the previous tarballs, before the embargo is lifted
 tomorrow, or soon after.


 Enjoy

 Jakob
 -- 
 Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
 Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
 This public discussion message is non-binding and may contain errors.
 WiseMo - Remote Service Management for PCs, Phones and Embedded 


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

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

Re: [openssl-users] Reg : SCEP using OPENSSL

[John Foley]

If it fits your needs, you may want to look into using EST (RFC 7030)
instead of SCEP.  EST is the replacement for SCEP.  The SCEP draft was
never ratified.  The libest open source project implements RFC 7030 and
uses OpenSSL.  It's available at https://github.com/cisco/libest.



On 03/17/2015 12:01 AM, Sindhu S. (sins) wrote:

 Hi all,

 I need guidance in understanding as to how SCEP server can be used 
 integrated with OpenSSL.
 My understanding is that SCEP can be used to enroll devices  then it
 communicates to Certificate Authority that generate certificates.
 Can some one point me in right direction ? Basically i am trying to
 achieve following: Using SCEP to enroll devices  then generate
 Certificates usingCA.

  

 Any reference to opensource SCEP will be helpful…

 I’m also exploring few opensource SCEP implementation, like openscep,
 sscep, autosscep.. etc….

 https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif

 Thanks,

 Sindhu



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

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

Re: [openssl-users] FIPS mode uses /dev/urandom ?

[John Foley]

You don't even need to modify e_os.h.  You can just pass in a new value
for DEVRANDOM using the gcc -D compiler option.  For instance, maybe you
have a hardware device mapped to a Linux device file called
/dev/entropy1.  You can override DEVRANDOM to use this device without
modifying any OpenSSL code.




On 03/12/2015 12:06 PM, Alberto Roman Linacero wrote:
 Well... I'm just trying, for the test, to do something like:

 debian:~/openssl# strace -xe trace=file,read,write,close
 /usr/local/ssl/bin/openssl rand 10
 [...]
 open(/dev/urandom, O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
 read(3, 
 \xa9\xea\xf3\x6e\x08\x14\xe7\xeb\x11\x9c\x72\x64\x69\x54\x0d\x96\x43\x34\x68\x25\xe3\x45\x8b\xe8\xe6\x36\xde\x9b\x33\x3a\x6a\xe2,
 32) = 32
 close(3)= 0

 I know that it will have poor performance, and in fact I don't want to
 do this... but we're going to pass SP800 56b and they are asking us to
 use blocking to be sure that the entropy generated before the openssl
 seed is enough (256 entropy bits).

 My understanding of how OpenSSL seeds DRBGs is as follows:

 When initialization function is called, first the non-approved
 hash-based DRBG that is part of the baseline library is seeded. This
 DRBG is seeded according to library's settings (in e_os.h DEVRANDOM),
 and it defaults to /dev/urandom. After that approved FIPS-mode DRBG
 with 256-bit AES-CTR is seeded by calling the bytes() method. This
 way, output of the first non-approved DRBG is used to seed FIPS-mode
 DRBG. This is why module settings (e_os.h DEVRANDOM) are ignored.

 So, I'm not sure if I'm thinking it fine, or if I could change e_os.h
 to do that and still being FIPS certified, or...

 Alberto.


 2015-03-11 21:10 GMT+01:00 Tom Francis thomas.francis...@pobox.com:
 On Mar 11, 2015, at 11:40 AM, Alberto Roman Linacero 
 aro...@alienvault.com wrote:

 Dear all, I'm doing an strace to the FIPS validated version of
 openssl, and I'm seeing that is uses /dev/urandom. I thought that the
 FIPS validated module always use /dev/random, isn't this the case, or
 am I doing something wrong?.

 If it uses /dev/urandom, is it possible/advisable to change it to
 /dev/random (how?), and still the module being FIPS validated?
 It would depend on what code is reading from /dev/urandom.  If it’s the FIPS 
 Object Module that’s doing the reading, then no, absolutely not.  If it’s 
 the FIPS-capable OpenSSL that reads from /dev/urandom, you can probably 
 change it.  But I’m curious as to why you would want to do this.  Most 
 systems with /dev/random and /dev/urandom are similar to Linux, in that 
 /dev/urandom is the preferred source for “random data”, including when 
 seeding a PRNG (which is how it’s used by OpenSSL).  And because /dev/random 
 can block, you might have ridiculously poor performance (and worse, it’ll be 
 unpredictably poor performance, i.e. sometimes it’ll work great, and other 
 times it’ll be horrible, and you never which you’ll get).  This page, 
 http://www.2uo.de/myths-about-urandom/ , is specific to Linux, but at a 
 high-level, It’s also true for AIX, HP-UX, Solaris, FreeBSD, and NetBSD 
 (OpenBSD is more complex).  I’m not about other UNIX-like systems, as I 
 stopped using those before any of them ever provided such devices. :)

 TOM

 Thanks for your help in advance and best regards,
 Alberto.
 ___
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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




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

[openssl-users] Blank pages in FIPS 2.0 user guide

[John Foley]

Appendix E.2 in the FIPS 2.0 users guide
(https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
pages on pages 134-136.  Is this intentional?  It appears the iOS build
instructions starting on page 133 are incomplete. 
 

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

Re: [openssl-users] Blank pages in FIPS 2.0 user guide

[John Foley]

Are the current iOS build instructions documented anywhere else?  We
haven't built for iOS in several years, at which time xCode was still
using gcc.  It appears xCode now uses clang and the signature embedding
no longer works.  Looking at the following commit...

https://github.com/openssl/openssl/commit/7447e65fccc95fa2ee97b40e43dc46f97e7b958b

It appears OpenSSL may support the newer clang tool chain.  But the old
build steps we use to follow no longer embed the signature properly. 
Can anyone comment if the following steps are current:

https://github.com/GotoHack/iOS-openSSL-FIPS




On 02/20/2015 12:30 PM, Steve Marquess wrote:
 On 02/20/2015 10:52 AM, John Foley wrote:
 Appendix E.2 in the FIPS 2.0 users guide
 (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
 pages on pages 134-136.  Is this intentional?  It appears the iOS build
 instructions starting on page 133 are incomplete. 
 John, I can tell you without looking that there are no intentionally
 blank pages in the FIPS User Guide.

 I am seriously remiss in updating that document. Among other things the
 build process for iOS has changed significantly as of 2.0.9, thanks to
 some elegant work by Andy Polyakov.

 It's on my list... a long list unfortunately. At the moment any spare
 time I have available for FIPS issues is spent addressing yet another
 existential threat to the open source based validations.

 -Steve M.



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

Re: 1.0.2 VC-WIN32 build failure?

[John Foley]

Tried again using the 20140613 snapshot and it's now working.  Thanks
for committing the fix yesterday.


On 06/12/2014 11:35 AM, John Foley wrote:
 Using the 201406012 snapshot on the 1.0.2 branch, I'm seeing an error
 while trying to build for the VC-WIN32 target.  The compiler is VS2010. 
 Can anyone confirm this is the correct build procedure?

 perl Configure VC-WIN32
 ms\do_nasm.bat
 nmake -f ms\ntdll.mak


 The error is:

 cl /Fotmp32dll\cryptlib.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2
 -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo
 -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
 -D_CRT_SECURE_NO_DEPRECATE -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 -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I.
 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE
 -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL 
 -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\cryptlib.c cryptlib.c
 C:\temp\102\openssl-1.0.2-stable-SNAP-20140612\tmp32dll\e_os.h(62) :
 fatal error
  C1083: Cannot open include file: 'openssl/opensslconf.h': No such file
 or directory
 NMAKE : fatal error U1077: 'c:\Program Files (x86)\Microsoft Visual
 Studio 10.0\VC\BIN\cl.EXE' : return code '0x2'
 Stop.


 Also of interest, the following error occurred during the Configure script:

 C:\temp\102\openssl-1.0.2-stable-SNAP-20140612perl util\mkdef.pl 32
 libeay  1ms\libeay32.def
 Warning: BUF_strnlen does not have a number assigned
 Warning: X509_VERIFY_PARAM_set_hostflags does not have a number assigned

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

1.0.2 VC-WIN32 build failure?

[John Foley]

Using the 201406012 snapshot on the 1.0.2 branch, I'm seeing an error
while trying to build for the VC-WIN32 target.  The compiler is VS2010. 
Can anyone confirm this is the correct build procedure?

perl Configure VC-WIN32
ms\do_nasm.bat
nmake -f ms\ntdll.mak


The error is:

cl /Fotmp32dll\cryptlib.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2
-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo
-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-D_CRT_SECURE_NO_DEPRECATE -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 -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I.
-DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE
-DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL 
-DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\cryptlib.c cryptlib.c
C:\temp\102\openssl-1.0.2-stable-SNAP-20140612\tmp32dll\e_os.h(62) :
fatal error
 C1083: Cannot open include file: 'openssl/opensslconf.h': No such file
or directory
NMAKE : fatal error U1077: 'c:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\BIN\cl.EXE' : return code '0x2'
Stop.


Also of interest, the following error occurred during the Configure script:

C:\temp\102\openssl-1.0.2-stable-SNAP-20140612perl util\mkdef.pl 32
libeay  1ms\libeay32.def
Warning: BUF_strnlen does not have a number assigned
Warning: X509_VERIFY_PARAM_set_hostflags does not have a number assigned
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Anyone implementing RFC 7030: Enrollment over Secure Transport (EST)?

[John Foley]

We plan to publish an open source EST stack in the near future.  This
will support both client-side and server-side capabilities.  The code
will be hosted here:

https://github.com/cisco/libest

I've also recently setup an EST test server, which is available here:

http://ec2-54-204-91-178.compute-1.amazonaws.com/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

0.9.8z?

[John Foley]

There were several commits to the 0_9_8 trunk after the 0.9.8y release
last week that appear to be related to CVE-2013-0169.  Will there be a
forthcoming 0.9.8z release as a result?  Or are these commits not needed
to mitigate CVE-2013-0169?

Thank you.

attachment: foleyj.vcf

Maintenance releases on 0.9.8

[John Foley]

Now that 1.0.1 has been released, will there be any future maintenance
releases on the 0.9.8 branch?  For instance, will any vulnerabilities
found in the future be addressed on 0.9.8?  Or is the 0.9.8 branch
effectively end of life at this time?

Thank you.

attachment: foleyj.vcf

AES-CCM mode in 1.0.1-beta2

[John Foley]

Looking at OpenSSL_add_all_ciphers() in crypto/evp/c_allc.c, AES-CCM
mode is not in the list of ciphers added.  Has this cipher intentionally
been omitted, or is this a bug?


attachment: foleyj.vcf

CertificateVerify message size hard-coded to 514 bytes

[John Foley]

Does anyone know why the CertificateVerify message is still limited to a
max size of 514 bytes? 

http://www.mail-archive.com/openssl-dev@openssl.org/msg13520.html

Is there any risk with increasing this to 4096 bytes?

Thank you.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Support for ECDH-RSA cipher suites in 0.9.8

[John Foley]

None of the ECDH-RSA cipher suites appear to work in 0.9.8r.  Yet they
work in 1.0.0.  Is this expected?

Looking at s3_lib.c, all the older DH-RSA cipher suites are disabled
(SSL_CIPHER-valid=0).  But the ECDH-RSA ciphers listed in s3_lib.c are
enabled.  This leads to the following questions:

1.  Is it a bug that the ECDH-RSA cipher suites are not working?
2.  Or, is it a bug that the ECDH-RSA cipher suites are enabled?

Any help would be very appreciated.

Thank you.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

IPv6 support with OCSP

[John Foley]

Does the OpenSSL OCSP stack support IPv6 in version 0.9.8r?

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

ECDH-RSA key exchange support (rfc 4492)

[John Foley]

Is there a known bug with ECDH_RSA key exchange cipher suites in
0.9.8r?  For instance, using cipher suite ECDH-RSA-AES128-SHA in 0.9.8r
does not work.  But it does work in 1.0.0d.  This is tested using the
following command:

ssltest -tls1 -cert servercert.pem -key serverkey.pem -cipher
ECDH-RSA-AES128-SHA

The certificate is an ECC cert signed by an RSA root.  Here's the output
from the cert:

Certificate:
Data:
Version: 1 (0x0)
Serial Number:
a5:30:9a:82:45:80:65:61
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
Validity
Not Before: Aug 10 18:57:37 2011 GMT
Not After : Sep  9 18:57:37 2011 GMT
Subject: C=AU, ST=Some-State, L=ok, O=dd, OU=ee, CN=ff
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key:
pub:
04:a5:79:81:29:ba:0f:49:32:f2:e6:11:47:db:7b:
25:ed:4a:3f:b2:96:ad:93:a4:5a:3f:35:f4:c9:85:
f1:f3:eb:15:86:c8:01:b7:c0:11:92:5a:48:63:73:
1a:2a:30:e3
ASN1 OID: prime192v1
Signature Algorithm: sha1WithRSAEncryption
21:b2:20:f1:c6:c8:e5:e6:8e:66:ec:a3:3c:ac:25:eb:61:6f:
cd:7c:e7:e8:c1:c5:1a:7c:26:9b:2e:2d:22:f4:30:bc:97:23:
55:2a:eb:c6:d8:ee:14:36:55:55:24:19:32:17:10:13:e5:3a:
aa:1d:94:c6:37:80:e4:25:79:87:bb:ec:11:a4:8c:79:db:7f:
70:a9:e2:2b:38:38:c8:fa:36:b1:8f:06:fe:d0:ba:b4:05:82:
f4:c5:87:e7:ca:5a:a5:49:6c:2b:9b:8e:87:f8:c2:7e:d3:b0:
58:db:3c:f6:ff:06:04:f7:26:27:0f:18:86:af:cc:91:f7:f0:
f9:ff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

FIPS statically linked canister

[John Foley]

Section 4.2.1 of the FIPS User Guide states...

Per the conditions of the FIPS 140­2 validation only two configuration
commands may
be used:
./config fipscanisterbuild
or
./config fipscanisterbuild no­asm


However, section 4.2.2 states...

Note that  fipscanister.o can either be statically linked into an
application binary executable,
or statically linked into a shared library.


This leads to the question of how we would build a statically linked
OpenSSL library, such as using the following configuration...

./config fipscanisterbuild -static

My question is using the -static option to build the library a valid
option for FIPS mode?  If not, why does section 4.2.2 state the canister
can be statically linked?

Thank you.






__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org