OPENSSL 1.0.1i
Good morning... I am using GCC 4.8.2 and AIX 5.3. I downloaded the file then compile... Here what I did: # ./Configure aix-gcc zlib fips (no problem) # make depend (no problem) # make (no problem) # make test (failed, here is...) test a^b%c implementations ../util/shlib_wrap.sh ./exptest done test elliptic curves ../util/shlib_wrap.sh ./ectest Curve defined by Weierstrass equation y^2 = x^3 + a*x + b (mod 0x17) a = 0x1 b = 0x1 A cyclic subgroup: point at infinity x = 0xD, y = 0x7 x = 0x5, y = 0x4 x = 0x11, y = 0x3 x = 0x11, y = 0x14 x = 0x5, y = 0x13 x = 0xD, y = 0x10 Generator as octet string, compressed form: 030D Generator as octet string, uncompressed form: 040D07 Generator as octet string, hybrid form: 070D07 A representation of the inverse of that generator in Jacobian projective coordinates: X = 0xC, Y = 0xF, Z = 0xA SEC2 curve secp160r1 -- Generator: x = 0x4A96B5688EF573284664698968C38BB913CBFC82 y = 0x23A628553168947D59DCC912042351377AC5FB32 verify degree ... ok verify group order ok long/negative scalar tests allowing precomputation ... ectest.c:261: ABORT make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. - So I guess it is bug? Let me know. Thanks. Tom __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl dgst and capi engine question
On Sun, Aug 03, 2014, Vladimir Simonov wrote: Hi all, I'm trying to use openssl command line utility to sign data file with key located in Windows Certificates Store. I generated 1024 bit dsa private key and certificate. Converted them to pkcs12 format and imported the certificate into WCS. openssl dsaparam -rand $ssl_sign_program -C -out $ssl_dsa_param 1024 openssl req -x509 -extensions v3_ca $passout_param -newkey dsa:$ssl_dsa_param -keyout $ssl_dsa_priv_key -days 365 -batch -out $ssl_dsa_cert openssl pkcs12 -export -out $ssl_dsa_priv_key_pkcs12 -inkey $ssl_dsa_priv_key -name KeyPKCS12 -in $ssl_dsa_cert$passin_param $passout_param I expected that below command will work openssl dgst -keyform ENGINE -engine capi -sign Company -passin pass:123 -hex -out sig.txt -sha1 data_file But it doesn't. Because capi engine doesn't implement pkey_meths and digests. I'm not sure what you're doing wrong because I just tested using the CAPI ENGINE and DSA and it worked fine on OpenSSL 1.0.1i. By default you have to pass a string which appears in the certificate to the sign argument. So if the certificate has CN=My Test DSA Key then DSA would work. Internally it uses CertFindCertificateInStore. You can test the key loading using the pkey utility: openssl pkey -engine capi -inform e -pubout -in DSA If this works it will output the public part of the key. The -passin argument isn't used by ENGINE based keys BTW. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OPENSSL 1.0.1i
On Thu, Aug 07, 2014, Spence, Thomas P CIV USAF (US) wrote: Good morning... I am using GCC 4.8.2 and AIX 5.3. I downloaded the file then compile... Here what I did: # ./Configure aix-gcc zlib fips (no problem) # make depend (no problem) # make (no problem) # make test (failed, here is...) test a^b%c implementations ../util/shlib_wrap.sh ./exptest done test elliptic curves ../util/shlib_wrap.sh ./ectest Curve defined by Weierstrass equation y^2 = x^3 + a*x + b (mod 0x17) a = 0x1 b = 0x1 A cyclic subgroup: point at infinity x = 0xD, y = 0x7 x = 0x5, y = 0x4 x = 0x11, y = 0x3 x = 0x11, y = 0x14 x = 0x5, y = 0x13 x = 0xD, y = 0x10 Generator as octet string, compressed form: 030D Generator as octet string, uncompressed form: 040D07 Generator as octet string, hybrid form: 070D07 A representation of the inverse of that generator in Jacobian projective coordinates: X = 0xC, Y = 0xF, Z = 0xA SEC2 curve secp160r1 -- Generator: x = 0x4A96B5688EF573284664698968C38BB913CBFC82 y = 0x23A628553168947D59DCC912042351377AC5FB32 verify degree ... ok verify group order ok long/negative scalar tests allowing precomputation ... ectest.c:261: ABORT make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. - So I guess it is bug? Let me know. Thanks. Should be fixed in the latest snapshot. That error wont otherwise affect the functionality of OpenSSL: it's just an EC test which fails because the FIPS module doesn't support it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl dgst and capi engine question
-Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, August 07, 2014 3:16 PM To: openssl-users@openssl.org Subject: Re: openssl dgst and capi engine question On Sun, Aug 03, 2014, Vladimir Simonov wrote: Hi all, I'm trying to use openssl command line utility to sign data file with key located in Windows Certificates Store. I generated 1024 bit dsa private key and certificate. Converted them to pkcs12 format and imported the certificate into WCS. openssl dsaparam -rand $ssl_sign_program -C -out $ssl_dsa_param 1024 openssl req -x509 -extensions v3_ca $passout_param -newkey dsa:$ssl_dsa_param -keyout $ssl_dsa_priv_key -days 365 -batch -out $ssl_dsa_cert openssl pkcs12 -export -out $ssl_dsa_priv_key_pkcs12 -inkey $ssl_dsa_priv_key -name KeyPKCS12 -in $ssl_dsa_cert$passin_param $passout_param I expected that below command will work openssl dgst -keyform ENGINE -engine capi -sign Company -passin pass:123 -hex -out sig.txt -sha1 data_file But it doesn't. Because capi engine doesn't implement pkey_meths and digests. . You can test the key loading using the pkey utility: openssl pkey -engine capi -inform e -pubout -in DSA If this works it will output the public part of the key. The -passin argument isn't used by ENGINE based keys BTW. Steve, thank you for hints! After your answer I've tried OpenSSL 1.0.1h 5 Jun 2014, earlier I used OpenSSL 1.0.1e 11 Feb 2013. And now openssl dgst -sign works as expected openssl dgst -keyform ENGINE -engine capi -sign Company -hex -sha1 Makefile DSA-SHA1(Makefile)= 302e0215009e06494518c8cbc4ae024e5a5e0641387e7717100215008fc4162abb6bf440d6b7d13b054a55f79ca58742 So now all is almost fine openssl dgst -keyform ENGINE -engine capi -sign Company -out sig -sha1 Makefile openssl dgst -keyform ENGINE -engine capi -prverify Company -signature sig Makefile Verified OK! But one, probably, small thing openssl dgst -keyform ENGINE -engine capi -verify Company -signature sig Makefile reports unable to load key file If I extract public key openssl pkey -engine capi -inform e -pubout -in Company pub_key result of openssl dgst -keyform ENGINE -engine capi -verify pub_key -signature sig Makefile is the same -unable to load key file Should it be possible to check signature using public key? Thank you again Vladimir __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl dgst and capi engine question
On Sun, Aug 03, 2014, Vladimir Simonov wrote: Hi all, I'm trying to use openssl command line utility to sign data file with key located in Windows Certificates Store. I generated 1024 bit dsa private key and certificate. Converted them to pkcs12 format and imported the certificate into WCS. openssl dsaparam -rand $ssl_sign_program -C -out $ssl_dsa_param 1024 openssl req -x509 -extensions v3_ca $passout_param -newkey dsa:$ssl_dsa_param -keyout $ssl_dsa_priv_key -days 365 -batch -out $ssl_dsa_cert openssl pkcs12 -export -out $ssl_dsa_priv_key_pkcs12 -inkey $ssl_dsa_priv_key -name KeyPKCS12 -in $ssl_dsa_cert$passin_param $passout_param I expected that below command will work openssl dgst -keyform ENGINE -engine capi -sign Company -passin pass:123 -hex -out sig.txt -sha1 data_file But it doesn't. Because capi engine doesn't implement pkey_meths and digests. . You can test the key loading using the pkey utility: openssl pkey -engine capi -inform e -pubout -in DSA If this works it will output the public part of the key. The -passin argument isn't used by ENGINE based keys BTW. Steve, thank you for hints! After your answer I've tried OpenSSL 1.0.1h 5 Jun 2014, earlier I used OpenSSL 1.0.1e 11 Feb 2013. And now openssl dgst -sign works as expected openssl dgst -keyform ENGINE -engine capi -sign Company -hex -sha1 Makefile DSA-SHA1(Makefile)= 302e0215009e06494518c8cbc4ae024e5a5e0641387e7717100215008fc4162abb6bf440d6b7d13b054a55f79ca58742 So now all is almost fine openssl dgst -keyform ENGINE -engine capi -sign Company -out sig -sha1 Makefile openssl dgst -keyform ENGINE -engine capi -prverify Company -signature sig Makefile Verified OK! But one, probably, small thing openssl dgst -keyform ENGINE -engine capi -verify Company -signature sig Makefile reports unable to load key file If I extract public key openssl pkey -engine capi -inform e -pubout -in Company pub_key result of openssl dgst -keyform ENGINE -engine capi -verify pub_key -signature sig Makefile is the same -unable to load key file Steve, sorry. It is my fault openssl dgst -verify pub_key -signature sig Makefile Verified OK ! If I understand correct there is no way to verify signature by public key directly from store. But it is ok for me. Thank you again Vladimir __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl 0.9.8 zb and DTLS reassemble fragment
Hi All, The following vulnerability fixes in 0.9.8 zb seems to be related to the DTLS reassemble fragment functionality that is introduced from 0.9.8 o version. CVE-2014-3505 -Avoid double free when processing DTLS packets CVE-2014-3506 -Fix DTLS handshake message size checks CVE-2014-3507 -Fix memory leak from zero-length DTLS fragments As per the https://www.openssl.org/news/vulnerabilities.html, all the versions of openssl 0.9.8. This includes the versions before 0.9.8 o where the DTLS reassemble fragment is not present. Can some one confirm if it is updated by mistake or is all the versions of 0.9.8 are affected with the above vulnerabilities too.. appreciate your quick response on this. regards, -Jaya.
Re: openssl dgst and capi engine question
On Thu, Aug 07, 2014, Vladimir Simonov wrote: On Sun, Aug 03, 2014, Vladimir Simonov wrote: Hi all, I'm trying to use openssl command line utility to sign data file with key located in Windows Certificates Store. I generated 1024 bit dsa private key and certificate. Converted them to pkcs12 format and imported the certificate into WCS. openssl dsaparam -rand $ssl_sign_program -C -out $ssl_dsa_param 1024 openssl req -x509 -extensions v3_ca $passout_param -newkey dsa:$ssl_dsa_param -keyout $ssl_dsa_priv_key -days 365 -batch -out $ssl_dsa_cert openssl pkcs12 -export -out $ssl_dsa_priv_key_pkcs12 -inkey $ssl_dsa_priv_key -name KeyPKCS12 -in $ssl_dsa_cert$passin_param $passout_param I expected that below command will work openssl dgst -keyform ENGINE -engine capi -sign Company -passin pass:123 -hex -out sig.txt -sha1 data_file But it doesn't. Because capi engine doesn't implement pkey_meths and digests. . You can test the key loading using the pkey utility: openssl pkey -engine capi -inform e -pubout -in DSA If this works it will output the public part of the key. The -passin argument isn't used by ENGINE based keys BTW. Steve, thank you for hints! After your answer I've tried OpenSSL 1.0.1h 5 Jun 2014, earlier I used OpenSSL 1.0.1e 11 Feb 2013. And now openssl dgst -sign works as expected openssl dgst -keyform ENGINE -engine capi -sign Company -hex -sha1 Makefile DSA-SHA1(Makefile)= 302e0215009e06494518c8cbc4ae024e5a5e0641387e7717100215008fc4162abb6bf440d6b7d13b054a55f79ca58742 So now all is almost fine openssl dgst -keyform ENGINE -engine capi -sign Company -out sig -sha1 Makefile openssl dgst -keyform ENGINE -engine capi -prverify Company -signature sig Makefile Verified OK! But one, probably, small thing openssl dgst -keyform ENGINE -engine capi -verify Company -signature sig Makefile reports unable to load key file If I extract public key openssl pkey -engine capi -inform e -pubout -in Company pub_key result of openssl dgst -keyform ENGINE -engine capi -verify pub_key -signature sig Makefile is the same -unable to load key file Steve, sorry. It is my fault openssl dgst -verify pub_key -signature sig Makefile Verified OK ! If I understand correct there is no way to verify signature by public key directly from store. But it is ok for me. That's correct: at least on the command line. Usually there's no need to as the public key is, err public and you can use OpenSSL's own public key handling to verify signatures. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Help diagnosing SSL connection problem needed
Your client is saying that it's failing the certificate verification of
the server certificate. It's probably not using the CAfile that you
passed to openssl s_client.
-Kyle H
On 8/5/2014 12:19 PM, Ted Byers wrote:
I have Perl code, which uses a library that in turn uses openssl for
HTTPS connections. I have been trying to use Wireshark to diagnose
this, but I have yet to find a way to have it tell me what steps in
the SSL handshaking are happening at a given time (client hello,
server hello, c.). Thus, I am having trouble seeing whether the
problem is in my client not doing something right or the server not
doing something right. I have not yet figured out how to have it
export everything in a capture file in plain text so that I could
copy/paste it in a note like this so you could see for yourself what
is happening.
I did get openssl s_client to connect properly, and here is the output
from that (sanitized of the server operator's ID):
ted@linux-jp04:~/Work/Projects/FirstData openssl s_client -CAfile
server-test.pem -cert client_test.pem -key client_test.key -connect
n.n.n.n:8443
CONNECTED(0003)
depth=1 C = LV, ST = Latvia, L = Riga, O = xx, CN =
server-test, emailAddress = webmas...@xx.xxx
verify return:1
depth=0 C = LV, O = FDL, CN = lv-rtps-proxy-test.ne.1dc.com
verify return:1
---
Certificate chain
0 s:/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
1
s:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
i:/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
---
Server certificate
-BEGIN CERTIFICATE-
DELETED
-END CERTIFICATE-
subject=/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
issuer=/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
---
Acceptable client certificate CA names
/C=LV/ST=Latvia/L=Riga/O=xx/CN=server-test/emailAddress=webmas...@xx.xxx
/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
---
SSL handshake has read 3690 bytes and written 3700 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: EDH-RSA-DES-CBC3-SHA
Session-ID:
53E0DE54D7D7E928F177883E10447786C15133386DA3F0489796845673C70DEA
Session-ID-ctx:
Master-Key: DELETED
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1407245906
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
closed
ted@linux-jp04:~/Work/Projects/FirstData
Now, here is the output I get from my Perl client (also sanitized):
$url = https://n.n.n.n:8443/
$scheme = https
$self-{ssl_set} = 0
$self-{ca_cert_dir} = .
$self-{ca_cert_file} = server-test.pem
$LWP::VERSION = 6.05
Setting cert dir and file if available
$self-{ssl_set} = 1
DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 26349088
DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:528: socket connected
DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is unknown
DEBUG: .../IO/Socket/SSL.pm:634: set socket to non-blocking to enforce
timeout=180
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26317968
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26323136
DEBUG: .../IO/Socket/SSL.pm:1539: scheme=www cert=26323136
DEBUG: .../IO/Socket/SSL.pm:1549: identity=n.n.n.n
cn=lv-rtps-proxy-test.ne.1dc.com alt=
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:1757: SSL connect attempt failed
DEBUG: .../IO/Socket/SSL.pm:653: fatal SSL error: SSL connect attempt
failed error:14090086:SSL
s_client output for server's certificate request message?
I'm trying to track down a client side issue with the use of HTTPS. I suspect it has something to do with a server misconfiguration and client side certificates. When running s_client: $ echo -e GET / HTTP/1.1\nHost:example.com\n | \ openssl s_client -connect example.com:443 -ssl3 -ign_eof -CAfile ca-cert.pem Is there a message displayed that documents the server requesting a client certificate? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: s_client output for server's certificate request message?
Usually you don't need to echo anything to get the acceptable client CA names list. -Kyle H On 8/7/2014 1:55 PM, Jeffrey Walton wrote: I'm trying to track down a client side issue with the use of HTTPS. I suspect it has something to do with a server misconfiguration and client side certificates. When running s_client: $ echo -e GET / HTTP/1.1\nHost:example.com\n | \ openssl s_client -connect example.com:443 -ssl3 -ign_eof -CAfile ca-cert.pem Is there a message displayed that documents the server requesting a client certificate? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME Cryptographic Signature
Re: s_client output for server's certificate request message?
On Thu, Aug 07, 2014, Jeffrey Walton wrote: I'm trying to track down a client side issue with the use of HTTPS. I suspect it has something to do with a server misconfiguration and client side certificates. When running s_client: $ echo -e GET / HTTP/1.1\nHost:example.com\n | \ openssl s_client -connect example.com:443 -ssl3 -ign_eof -CAfile ca-cert.pem Is there a message displayed that documents the server requesting a client certificate? If the server disconnects without completing the handshake you wont actually see the certificate request and session details. Try the -prexit option which tries to print out session details even if the handshake doesn't complete. OpenSSL 1.0.2 has a trace output to available if you compile OpenSSL with enable-ssl-trace and use the -trace option to s_client. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
stunnel 5.03 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Users, I have released version 5.03 of stunnel. The ChangeLog entry: Version 5.03, 2014.08.07, urgency: HIGH: * Security bugfixes - OpenSSL DLLs updated to version 1.0.1i. See https://www.openssl.org/news/secadv_20140806.txt * New features - FIPS autoconfiguration cleanup. - FIPS canister updated to version 2.0.6. - Improved SNI diagnostic logging. * Bugfixes - Compilation fixes for old versions of OpenSSL. - Fixed whitespace handling in the stunnel.init script. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 5e8196f913bf7460082c1c7e5d436fbfba7f65d56c60065e6ccf0df9057294ef stunnel-5.03-android.zip 803bc85fbc80f22d71b13d4180e2d51c02586b2cc611169961a2745e47e31c4f stunnel-5.03-installer.exe 9a1e369466fa756e6f48b11480a3338c1fa4717e6472871bf4a3a96c483edd03 stunnel-5.03.tar.gz Best regards, Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlPj3nMACgkQ/NU+nXTHMtGM3ACfdFm7k754Pzo1rhDkVb6rT5nO EEUAoJoSXbRPHu3jphxXYVA5SeJ05BXj =tFws -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: s_client output for server's certificate request message?
On Thu, Aug 7, 2014 at 4:57 PM, Kyle Hamilton aerow...@gmail.com wrote: Usually you don't need to echo anything to get the acceptable client CA names list. Thanks. In this case, its IIS 7.5 and its *not* using SNI (SNI is available in IIS 8). So I get a 400 bad request without the host header. Jeff On 8/7/2014 1:55 PM, Jeffrey Walton wrote: I'm trying to track down a client side issue with the use of HTTPS. I suspect it has something to do with a server misconfiguration and client side certificates. When running s_client: $ echo -e GET / HTTP/1.1\nHost:example.com\n | \ openssl s_client -connect example.com:443 -ssl3 -ign_eof -CAfile ca-cert.pem Is there a message displayed that documents the server requesting a client certificate? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Help diagnosing SSL connection problem needed
Hi Kyle, Thanks See below On Thu, Aug 7, 2014 at 4:47 PM, Kyle Hamilton aerow...@gmail.com wrote: Your client is saying that it's failing the certificate verification of the server certificate. It's probably not using the CAfile that you passed to openssl s_client. -Kyle H Actually, I can confirm that it is using the same CAfile that is used by my call to openssl s_client. But, it doesn't get that far, as it appears the server is not sending it's certificate. I assume Wireshark can be helpful, but I an very new to using it. Can you tell me how to tell it to look at any traffic on port 8443 (or between my workstation and a specific ip address), as well as to let me see the data in plain text rather than hex? Thanks Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: s_client output for server's certificate request message?
On Thu, Aug 7, 2014 at 5:29 PM, Dr. Stephen Henson st...@openssl.org wrote: On Thu, Aug 07, 2014, Jeffrey Walton wrote: I'm trying to track down a client side issue with the use of HTTPS. I suspect it has something to do with a server misconfiguration and client side certificates. When running s_client: $ echo -e GET / HTTP/1.1\nHost:example.com\n | \ openssl s_client -connect example.com:443 -ssl3 -ign_eof -CAfile ca-cert.pem Is there a message displayed that documents the server requesting a client certificate? If the server disconnects without completing the handshake you wont actually see the certificate request and session details. Try the -prexit option which tries to print out session details even if the handshake doesn't complete. OpenSSL 1.0.2 has a trace output to available if you compile OpenSSL with enable-ssl-trace and use the -trace option to s_client. Thanks Doctor. In the output below, there is a second certificate chain dumped after the session info. Would that be related to client certificates? I don't recall seeing that dump in the past. Is that what I am looking for if client certs are being requested by the server? Thanks again. ** riemann$ echo -e GET / HTTP/1.1\nHost:example.com\n | openssl s_client -connect example.com:443 -ssl3 -ign_eof -prexit -CAfile Equifax_Secure_Certificate_Authority.pem CONNECTED(0003) depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G2 verify return:1 depth=0 C = ES, ST = Malaga, L = Malaga, O = Example Co., CN = www.example.com, OU = Example Co. verify return:1 --- Certificate chain 0 s:/C=ES/ST=Malaga/L=Malaga/O=Example Co./CN=www.example.com/OU=Example Co. i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2 1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -BEGIN CERTIFICATE- MIIExjCCA66gAwIBAgIQeee0uwSySeNXOkI+BUoMMzANBgkqhkiG9w0BAQUFADBE MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2VvVHJ1c3QgSW5jLjEdMBsGA1UEAxMU ... doLsKI2R6RQA/7IcuTpKkvLF5wYKvmocPxYVg9FOoFvKV0wjWo6qlwsANPAVov+7 zFzZreROa7lBj8UH0IyYjLmBrbe1yMr/Cmg= -END CERTIFICATE- subject=/C=ES/ST=Malaga/L=Malaga/O=Example Co./CN=www.example.com/OU=Example Co. issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G2 --- No client certificate CA names sent --- SSL handshake has read 3417 bytes and written 489 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher: RC4-SHA Session-ID: 98338E39694619E0354A9784315259838AC48A16DDF7708AA275B43A2B83 Session-ID-ctx: Master-Key: BC233F93CEFEAC988058669EBD2614C377F754D661A357AD671D488388401475 B9EDB6C025114DD8C43C8939EF7D46AA Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1407447531 Timeout : 7200 (sec) Verify return code: 0 (ok) --- depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G2 verify return:1 depth=0 C = ES, ST = Malaga, L = Malaga, O = Example Co., CN = www.example.com, OU = Example Co. verify return:1 read R BLOCK HTTP/1.1 301 Moved Permanently Cache-Control: private Content-Type: text/html; charset=utf-8 Location: /Login/Login Server: Microsoft-IIS/7.5 X-AspNetMvc-Version: 3.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Thu, 07 Aug 2014 21:38:25 GMT Content-Length: 129 htmlheadtitleObject moved/title/headbody h2Object moved to a href=/Login/Loginhere/a./h2 /body/html ^C riemann$ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
1.0.1i breaks SRP
I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Any idea where to begin debugging this? Any and all help is appreciated. Norm Green Server Side: [ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned) [ 2] SSL call: ERR_load_crypto_strings with args: NONE (nothing returned) [ 3] SSL call: OpenSSL_add_all_ciphers with args: NONE (nothing returned) [ 4] SSL call: OpenSSL_add_all_digests with args: NONE (nothing returned) [ 5] SSL call: SSL_library_init with args: NONE result=1 [ 6] SSL call: RAND_status with args: NONE result=1 [ 7] SSL call: TLSv1_1_server_method with args: NONE result=0x7f1407999040 [ 8] SSL call: SSL_CTX_new with args: 0x7f1407999040 result=0x1f8a8e0 [ 9] SSL call: SSL_CTX_ctrl with args: 0x1f8a8e0 33 4 (NULL) result=4 [ 10] SSL call: SSL_CTX_set_verify with args: 0x1f8a8e0 0 (NULL) (nothing returned) [ 11] SSL call: SSL_CTX_set_cipher_list with args: 0x1f8a8e0 'SRP' result=1 [ 12] SSL call: SSL_CTX_set_srp_strength with args: 0x1f8a8e0 1024 result=1 [ 13] SSL call: BN_init with args: 0x7f14197a3a88 (nothing returned) [ 14] SSL call: BN_init with args: 0x7f14197a3aa0 (nothing returned) [ 15] SSL call: BN_init with args: 0x7f14197a3ab8 (nothing returned) [ 16] SSL call: BN_init with args: 0x7f14197a3ad0 (nothing returned) [ 17] SSL call: SRP_get_default_gN with args: '1024' result=0x7f14079adb50 [ 18] SSL call: BN_copy with args: 0x7f14197a3ab8 0x7f14079adaa0 result=0x7f14197a3ab8 [ 19] SSL call: BN_copy with args: 0x7f14197a3ad0 0x7f14079ad980 result=0x7f14197a3ad0 [ 20] SSL call: BN_bin2bn with args: 0x7fff686674c0 128 0x7f14197a3aa0 result=0x7f14197a3aa0 [ 21] SSL call: BN_bin2bn with args: 0x7fff686674c0 20 0x7f14197a3a88 result=0x7f14197a3a88 [ 22] SSL call: SSL_CTX_set_verify with args: 0x1f8a8e0 0 (NULL) (nothing returned) [ 23] SSL call: SSL_CTX_set_cipher_list with args: 0x1f8a8e0 'SRP' result=1 [ 24] SSL call: SSL_CTX_set_srp_cb_arg with args: 0x1f8a8e0 0x7f14197a3a80 result=1 [ 25] SSL call: SSL_CTX_set_srp_username_callback with args: 0x1f8a8e0 0x7f1418ab6d26 result=1 [ 26] SSL call: SSL_new with args: 0x1f8a8e0 result=0x1f8b680 [ 27] SSL call: SSL_set_fd with args: 0x1f8b680 5 result=1 [ 28] SSL call: SSL_get_fd with args: 0x1f8b680 result=5 [ 29] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 30] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 31] SSL call: SSL_get_error with args: 0x1f8b680 -1 result=1 error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1358: [ 32] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 33] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 34] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 35] SSL call: SSL_accept with args: 0x1f8b680 result=-1 [ 36] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 37] SSL call: SSL_accept with args: 0x1f8b680 result=-1 SSL_accept() failed after 4 tries [ 38] SSL call: SSL_free with args: 0x1f8b680 (nothing returned) [ 39] SSL call: SSL_CTX_free with args: 0x1f8a8e0 (nothing returned) Client Side: [ 1] SSL call: SSL_load_error_strings with args: NONE (nothing returned) [ 2] SSL call: ERR_load_crypto_strings with args: NONE (nothing returned) [ 3] SSL call: OpenSSL_add_all_ciphers with args: NONE (nothing returned) [ 4] SSL call: OpenSSL_add_all_digests with args: NONE (nothing returned) [ 5] SSL call: SSL_library_init with args: NONE result=1 [ 6] SSL call: RAND_status with args: NONE result=1 [ 7] SSL call: TLSv1_1_client_method with args: NONE result=0x76460a40 [ 8] SSL call: SSL_CTX_new with args: 0x76460a40 result=0x62f150 [ 9] SSL call: SSL_CTX_ctrl with args: 0x62f150 33 4 (NULL) result=4 [ 10] SSL call: SSL_CTX_set_verify with args: 0x62f150 0 (NULL) (nothing returned) [ 11] SSL call: SSL_CTX_set_cipher_list with args: 0x62f150 'SRP' result=1 [ 12] SSL call: SSL_CTX_set_srp_strength with args: 0x62f150 1024 result=1 [ 13] SSL call: SSL_CTX_set_srp_username with args: 0x62f150 'SystemUser' result=1 [ 14] SSL call: SSL_CTX_set_srp_password with args: 0x62f150 'swordfish' result=1 [ 15] SSL call: SSL_new with args: 0x62f150 result=0x62f990 [ 16] SSL call: SSL_set_fd with args: 0x62f990 6 result=1 [ 17] SSL call: SSL_get_fd with args: 0x62f990 result=6 [ 18] SSL call: ERR_clear_error with args: NONE (nothing returned) [ 19] SSL call: SSL_connect with args: 0x62f990 result=0 [ 20] SSL call: SSL_get_error with args: 0x62f990 0 result=1 error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL
Re: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Well maybe, maybe not. Just because a ciphersuite is included in the cipherlist doesn't mean it is included or could be selected. For example if you set a ciphersuite which uses ECDSA authentication it wont be selected if the server doesn't include an ECDSA certificate. That might be what is happening here: the ciphersuite is being (incorrectly) excluded either client or server side. Any idea where to begin debugging this? Any and all help is appreciated. Can you reproduce this with s_client and s_server? Can you try a 1.0.1i client versus a 1.0.1h server and vice-versa? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: I just upgraded our product to 1.0.1i and logins via SRP are now broken. Shown below are the SSL calls made from both the client and server. Everything worked perfectly under 1.0.1h. Bot sides set the cipher list to 'SRP' via calls to SSL_CTX_set_cipher_list(), so the no shared cipher complaint after line 31 on the server side is clearly bogus. Any idea where to begin debugging this? Any and all help is appreciated. Hmm... think I can reproduce it now. There is a problem with some ciphersuites. Looking into it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Help diagnosing SSL connection problem needed
From: owner-openssl-us...@openssl.org On Behalf Of Kyle Hamilton
Sent: Thursday, August 07, 2014 16:48
Your client is saying that it's failing the certificate verification of
the server certificate. It's probably not using the CAfile that you
passed to openssl s_client.
-Kyle H
On 8/5/2014 12:19 PM, Ted Byers wrote:
I have Perl code, which uses a library that in turn uses openssl for
HTTPS connections. I have been trying to use Wireshark to diagnose
this, but I have yet to find a way to have it tell me what steps in
the SSL handshaking are happening at a given time (client hello,
server hello, c.). Thus, I am having trouble seeing whether the
problem is in my client not doing something right or the server not
doing something right. I have not yet figured out how to have it
export everything in a capture file in plain text so that I could
copy/paste it in a note like this so you could see for yourself what
is happening.
About Wireshark: first make sure you have only the desired packets
displayed: filter the display unless you previously filtered the capture
or you were (very) lucky and nothing else happened during the capture.
For everything, which is a lot (usually too much), File / Print
plainText toFile (and specify filename), range: Allpackets Displayed,
format: summary on, details on all expanded, bytes off.
For just which handshake steps have occurred, same except details off.
I did get openssl s_client to connect properly, and here is the output
from that (sanitized of the server operator's ID):
ted@linux-jp04:~/Work/Projects/FirstData openssl s_client -CAfile
server-test.pem -cert client_test.pem -key client_test.key -connect
n.n.n.n:8443
snip except
Server certificate
-BEGIN CERTIFICATE-
DELETED
-END CERTIFICATE-
subject=/C=LV/O=FDL/CN=lv-rtps-proxy-test.ne.1dc.com
Now, here is the output I get from my Perl client (also sanitized):
$url = https://n.n.n.n:8443/
$scheme = https
$self-{ssl_set} = 0
$self-{ca_cert_dir} = .
$self-{ca_cert_file} = server-test.pem
$LWP::VERSION = 6.05
Setting cert dir and file if available
$self-{ssl_set} = 1
Are you setting the client keycert/chain? This doesn't indicate it.
The s_client command did provide them, and the server did request
a client cert; if the server *requires* client cert and client doesn't
provide one, the server will normally reject the connection.
DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 26349088
DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:528: socket connected
DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is
unknown
DEBUG: .../IO/Socket/SSL.pm:634: set socket to non-blocking to enforce
timeout=180
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
This appears to be sent CHello, nonblocking expect SHello,Cert...SDone
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:657: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:667: waiting for fd to become ready: SSL
wants a read first
These two look like partial reads therefore expecting more
DEBUG: .../IO/Socket/SSL.pm:687: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26317968
DEBUG: .../IO/Socket/SSL.pm:2384: ok=1 cert=26323136
Those look like verify-callback; verify of the cert looks okay.
DEBUG: .../IO/Socket/SSL.pm:1539: scheme=www cert=26323136
DEBUG: .../IO/Socket/SSL.pm:1549: identity=n.n.n.n
cn=lv-rtps-proxy-test.ne.1dc.com alt=
Those look like hostname check, which openssl doesn't do yet
(1.0.2 will) but your perl library probably adds. If you used an IP form
URL as indicated above https://a.b.c.d:8443/ and the cert has only
domainname as is common and indicated here, then this should fail.
It is requirement of HTTPS (and some other *S protocols but not
SSL/TLS by itself) that the authority field in the URL matches *a*
name in the cert. That doesn't necessarliy mean only one name;
the/a cert name can be a wildcard that matches multiple hostnames
but yours isn't; there can be multiple names in the cert using Subject
Alternative Names, but I take alt= here to mean yours doesn't.
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect - -1
DEBUG: .../IO/Socket/SSL.pm:1757: SSL
RE: Query on X509 certificate validation- EVP_VerifyUpdate EVP_VerifyFinal
From: owner-openssl-us...@openssl.org On Behalf Of Viktor Dukhovni
Sent: Monday, August 04, 2014 11:21
On Mon, Aug 04, 2014 at 05:43:47AM +, Mitra, Rituparna (STSD) wrote:
1. app1: sends a CGI POST request to app2 ? the POST request has
the
UN (username).
2. app2: does a CGI GET to receive the UN within app1?s POST
request.
3. app2: has app1?s x509 certificate already stored, since it has
to allow
SSO from app1 ? gets verification ctx from here.
4. app2: uses the UN (containing ! character) to form a hashdata,
5. app2: passes hashdata to EVP_VerifyUpdate(ctx, .. )
If you mean app2 hashes UN and passes that hash to VerifyUpdate, that's
wrong.
If you mean it passes the data *to be hashed*, that's good.
EVP_Verify{Init,Update,Final} does the hash of the data as part of verifying
a signature
just as EVP_Sign{Init,Update,Final} does the hash of the data to be signed.
In fact {Sign,Verify}{Init,Update} are just macros for Digest{Init,Update},
the PK operations are done only in Final.
6. app2: calls EVP_VerifyFinal -- this eventually fails during
public key
check (EVP_PKEY_verify), due to the ! character in UN
snip broader points
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: found half of it: EC key gen
From: owner-openssl-us...@openssl.org On Behalf Of dave Sent: Monday, August 04, 2014 15:50 I have it that the elliptic multiply is not standard. So I have been skip tracing though the code. It starts with ec_key.c, with EC_KEY_generate_key. This grabs the group or or the particular curves prime field size. It then uses this No, it uses the order of the generator or equivalently the subgroup generated by the generator and used for operations. For a curve over a prime field Zp the subgroup order is either slightly less than p or slightly less than p divided by a small integer called the cofactor (small meaning usually 2 or 4). For a curve over a binary (m-bit) field the order is somewhat less than 2^m, or that divided by a small cofactor. as the range for bn_rand_range. This is in bn_rand.c. In that it uses the first half which is bnrand. That grabs the time and shifts it around to start the process. Since the order or range is a large number It logically adds the current time (assuming available) to the entropy pool. Adding entropy is done by mixing bits in a fashion that should depend on both/all inputs in a complicated way, but I haven't looked recently. Using *only* the current time to seed random generation would not be secure, and is a common mistake by inexperienced people. in hex it looks like the output of the private key is also in hex. The private key is a large (integer) number. There are many ways of representing integers. Hex is a common way of representing large integers, because it can easily be broken up into, or formed from, 8-bit bytes or other power-of-2 size units that are common on modern computers. In particular when an EC private key is stored in the standard ASN.1 format defined in X9.62 and used in among others PKCS#8 and PKCS#12, the privatekey is stored as ASN.1 integer which some tools including openssl asn1parse show in hex. After that the generate key does the point multiply to make the public. Is there some other variable used here that I am missing? Doesn't sound like it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: found half of it: EC key gen
Thanks, OK I got the rest of the way through the tangled mess. The question is there someone out there that can skip trace through the subroutines that can put together a tight code set on how this works? One command walk through to start from the beginning to the end which is the key feedback. If there are some good c++ people out there that might want to spend a day on it I can pay for the time. Dave On 8/7/2014 6:58 PM, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of dave Sent: Monday, August 04, 2014 15:50 I have it that the elliptic multiply is not standard. So I have been skip tracing though the code. It starts with ec_key.c, with EC_KEY_generate_key. This grabs the group or or the particular curves prime field size. It then uses this No, it uses the order of the generator or equivalently the subgroup generated by the generator and used for operations. For a curve over a prime field Zp the subgroup order is either slightly less than p or slightly less than p divided by a small integer called the cofactor (small meaning usually 2 or 4). For a curve over a binary (m-bit) field the order is somewhat less than 2^m, or that divided by a small cofactor. as the range for bn_rand_range. This is in bn_rand.c. In that it uses the first half which is bnrand. That grabs the time and shifts it around to start the process. Since the order or range is a large number It logically adds the current time (assuming available) to the entropy pool. Adding entropy is done by mixing bits in a fashion that should depend on both/all inputs in a complicated way, but I haven't looked recently. Using *only* the current time to seed random generation would not be secure, and is a common mistake by inexperienced people. in hex it looks like the output of the private key is also in hex. The private key is a large (integer) number. There are many ways of representing integers. Hex is a common way of representing large integers, because it can easily be broken up into, or formed from, 8-bit bytes or other power-of-2 size units that are common on modern computers. In particular when an EC private key is stored in the standard ASN.1 format defined in X9.62 and used in among others PKCS#8 and PKCS#12, the privatekey is stored as ASN.1 integer which some tools including openssl asn1parse show in hex. After that the generate key does the point multiply to make the public. Is there some other variable used here that I am missing? Doesn't sound like it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper fix. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1i breaks SRP
Thanks for tracking it down so fast Steve. I will revert the mods in that commit and try it again tomorrow. Norm On 8/7/2014 7:21 PM, Dr. Stephen Henson wrote: On Thu, Aug 07, 2014, Norm Green wrote: Any idea where to begin debugging this? Any and all help is appreciated. The cause is incorrect handling of new SRP authentication type which was added to correct a bug where SRP authentication was incorrectly classified as NULL authhentication. A temporary workaround is to revert the addition of the SRP authentication type in commit 18c7f2fce8a82b13506cac7ca69fc333baf76408: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=18c7f2fce8a82b13506cac7ca69fc333baf76408 I'm working on the proper fix. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl-0.9.8za fips compliance
Hi All, Please let me know openssl-0.9.8za with -no-ec option is fips compliant or not. Thanks, Gayathri
Re: openssl-0.9.8za fips compliance
On Fri, Aug 8, 2014 at 1:11 AM, Gayathri Manoj gayathri.an...@gmail.com wrote: Please let me know openssl-0.9.8za with -no-ec option is fips compliant or not. No. If you want FIPS validated crypto, then you need one of the openssl-fips-*-tar.gz downloads. They produce the FIPS Object Module. openssl-0.9.8xxx is FIPS capable. It can use the validated cryptography if the FIPS Object Module is available. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
