openssl failing to download remote certificate
I tried openssl to download a remote cert on my181.svr.us.cyber.net Below are the 3 steps to generate self sign certificate. 1)To generate keys: /opt/boksm/lib/openssl genrsa -des3 -out server2.key 2048 -config /usr/sfw/lib/webmin/acl/openssl.cnf 2)To generate CSR /opt/boksm/lib/openssl req -new -key server2.key -out server2.csr -config /usr/sfw/lib/webmin/acl/openssl.cnf 3)To generate certificate view plaincopy to clipboardprint? /opt/boksm/lib/openssl x509 -req -days 365 -in server2.csr -signkey server2.key -out server2.crt /opt/boksm/lib/openssl x509 -req -days 365 -in server2.csr -signkey server2.key -out server2.crt And then used view plaincopy to clipboardprint? /opt/boksm/lib/openssl s_client -connect my181.svr.us.cyber.net:12201 -key server2.key -cert server2.crt -CAfile ca.crt /opt/boksm/lib/openssl s_client -connect my181.svr.us.cyber.net:12201 -key server2.key -cert server2.crt -CAfile ca.crt To connect view plaincopy to clipboardprint? /opt/boksm/lib/openssl s_client -connect my181.svr.us.cyber.net:12201 -key server2.key -cert server2.crt -CAfile ca.crt /opt/boksm/lib/openssl s_client -connect my181.svr.us.cyber.net:12201 -key server2.key -cert server2.crt -CAfile ca.crt view plaincopy to clipboardprint? Enter pass phrase for server2.key: ** 15959:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:765: 15959:error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib:by_file.c:280: CONNECTED(0004) depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:0 15959:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1060:SSL alert number 48 15959:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Enter pass phrase for server2.key: ** 15959:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:765: 15959:error:0B084009:x509 certificate routines:X509_load_cert_crl_file:PEM lib:by_file.c:280: CONNECTED(0004) depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 verify error:num=20:unable to get local issuer certificate verify return:0 15959:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1060:SSL alert number 48 15959:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: Not sure what I am doing wrong. Can you please help figure out? -- View this message in context: http://old.nabble.com/openssl-failing-to-download-remote-certificate-tp32723099p32723099.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Secure plaintext-derived filename [was: HMAC with RSA Key]
4. Truncate the string to your desired file name length, but not so short that accidental collisions become likely (Example to keep up to 16000 file names likely different, use file names with 2 * log2(16000)=2*14=28 bits minimum). Where can I learn more about this formula? I think it does not work well for small number of files and I wonder why it isn't something like log2(n)+20 or 2*log2(n)+10 or so? oki, Steffen End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Secure plaintext-derived filename [was: HMAC with RSA Key]
On 10/26/2011 3:01 PM, Steffen DETTMER wrote: 4. Truncate the string to your desired file name length, but not so short that accidental collisions become likely (Example to keep up to 16000 file names likely different, use file names with 2 * log2(16000)=2*14=28 bits minimum). Where can I learn more about this formula? I think it does not work well for small number of files and I wonder why it isn't something like log2(n)+20 or 2*log2(n)+10 or so? Google Birthday paradox, the formula I gave is a rough and not very precise variant. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Issue with Connection Reset
Please help! Many thanks! Info: Connection to SQL Server 2008 R2 database (cluster install) We're seeing the connection reset while testing from multiple sources and applications - it seems like the server is not responding with an SSL certificate during the handshake, here's the output from OpenSSL's s_client (error 104 indicates a connection reset): OpenSSL s_client -host 10.0.5.31 -port 1433 -prexit CONNECTED(0003) write:errno=104 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 118 bytes --- New, (NONE), Cipher is (NONE) Compression: NONE Expansion: NONE --- More info from the log... Calling ELMS WebService program to feedLeads Oct 18, 2011 12:36:01 PM com.microsoft.sqlserver.jdbc.TDSChannel enableSSL INFO: java.security path: /usr/local/fisher/web/jdk1.6.0_24/jre/lib/security Security providers: [SUN version 1.6, SunRsaSign version 1.5, SunJSSE version 1.6, SunJCE version 1.6, SunJGSS version 1.0, SunSASL version 1.5, XMLDSig version 1.0, SunPCSC version 1.6] SSLContext provider info: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) SSLContext provider services: [SunJSSE: KeyFactory.RSA - sun.security.rsa.RSAKeyFactory aliases: [1.2.840.113549.1.1, OID.1.2.840.113549.1.1] , SunJSSE: KeyPairGenerator.RSA - sun.security.rsa.RSAKeyPairGenerator aliases: [1.2.840.113549.1.1, OID.1.2.840.113549.1.1] , SunJSSE: Signature.MD2withRSA - sun.security.rsa.RSASignature$MD2withRSA aliases: [1.2.840.113549.1.1.2, OID.1.2.840.113549.1.1.2] , SunJSSE: Signature.MD5withRSA - sun.security.rsa.RSASignature$MD5withRSA aliases: [1.2.840.113549.1.1.4, OID.1.2.840.113549.1.1.4] , SunJSSE: Signature.SHA1withRSA - sun.security.rsa.RSASignature$SHA1withRSA aliases: [1.2.840.113549.1.1.5, OID.1.2.840.113549.1.1.5, 1.3.14.3.2.29, OID.1.3.14.3.2.29] , SunJSSE: Signature.MD5andSHA1withRSA - com.sun.net.ssl.internal.ssl.RSASignature , SunJSSE: KeyManagerFactory.SunX509 - com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509 , SunJSSE: KeyManagerFactory.NewSunX509 - com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$X509 , SunJSSE: TrustManagerFactory.SunX509 - com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl$SimpleFactory , SunJSSE: TrustManagerFactory.PKIX - com.sun.net.ssl.internal.ssl.TrustManagerFactoryImpl$PKIXFactory aliases: [SunPKIX, X509, X.509] , SunJSSE: SSLContext.SSL - com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: SSLContext.SSLv3 - com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: SSLContext.TLS - com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: SSLContext.TLSv1 - com.sun.net.ssl.internal.ssl.SSLContextImpl , SunJSSE: SSLContext.Default - com.sun.net.ssl.internal.ssl.DefaultSSLContextImpl , SunJSSE: KeyStore.PKCS12 - com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore ] java.ext.dirs: /usr/local/fisher/web/jdk1.6.0_24/jre/lib/ext:/usr/java/packages/lib/ext com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: Connection reset. at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:1352) at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1533) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1042) at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:817) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:700) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:842) at java.sql.DriverManager.getConnection(DriverManager.java:582) at java.sql.DriverManager.getConnection(DriverManager.java:185) at LeadAssignment.main(Unknown Source) Caused by: java.io.IOException: Connection reset at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.ensureSSLPayload(IOBuffer.java:594) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.readInternal(IOBuffer.java:664) at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.read(IOBuffer.java:656) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.readInternal(IOBuffer.java:851) at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.read(IOBuffer.java:839) at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293) at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) at
AES key wrap feature unavailable in FIPS mode OpenSSL?
Hello,
Has the AES key wrap feature been removed from the nightly OpenSSL in FIPS
mode?
I have built a FIPS-capable OpenSSL using the following:
ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20111025.tar.gz
ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-20111025.tar.gz
When I call AES_set_encrypt_key(), while in FIPS mode, I get the following
abort:
.\crypto\aes\aes_misc.c(73): OpenSSL internal error, assertion failed: Low level
API call to cipher AES forbidden in FIPS mode!
I can see that this is intentional per crypto\aes\aes_misc.c:
67 /* FIPS wrapper functions to block low level AES calls in FIPS mode */
68
69 int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
70 AES_KEY *key)
71 {
72 #ifdef OPENSSL_FIPS
73 fips_cipher_abort(AES);
74 #endif
75 return private_AES_set_encrypt_key(userKey, bits, key);
76 }
No such abort occurs with a FIPS-capable OpenSSL using the following:
http://openssl.org/source/openssl-0.9.8r.tar.gz
http://openssl.org/source/openssl-fips-1.2.3.tar.gz
Is there an alternate way to do AES key wrap using the nightly OpenSSL in FIPS
mode?
Thanks,
Bill
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: FIPS-capable OpenSSL that works on Windows NT
On Oct 25, 2011, at 4:17 AM, Dr. Stephen Henson wrote: On Mon, Oct 24, 2011, Bill Durant wrote: On Oct 24, 2011, at 4:00 PM, Dr. Stephen Henson wrote: On Mon, Oct 24, 2011, Bill Durant wrote: Hello Steve: I downloaded ftp://openssl.org/snapshot/openssl-fips-2.0-test-20111023.tar.gz and http://openssl.org/source/openssl-0.9.8r.tar.gz. I am getting the following compile errors. Any ideas on what I am doing wrong? You can't use OpenSSL 0.9.8 with the test 2.0 tarball. You have to use and OpenSSL 1.0.1 snapshot. Hello Steve, Thank you for the clarification. Now I am unable to get past 'nmake -f ms\nt.mak' Attached is the build log. I downloaded the following: ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20111024.tar.gz ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-20111024.tar.gz. I am getting the following compilation error. Any ideas on how to fix it? Thanks. C:\ cd openssl-fips-2.0-test-20111024 C:\ ms\do_fips no-asm ... ... *** FIPS BUILD SUCCESS* *** C:\ cd ..\openssl-1.0.1-stable-SNAP-20111024 C:\ perl Configure VC-WIN32 fips --with-fipslibdir=..\openssl-fips-2.0-test-20111024\out32dll --prefix=..\openssl-1.0.1-stable-SNAP-20111024-fips-static no-idea no-mdc2 no-rc5 no-asm ... ... C:\ ms\do_nasm ... ... C:\ nmake -f ms\nt.mak ... ... cl /Fotmp32\o_fips.obj -Iinc32 -Itmp32 /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -WX -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -Isrocalslips-2.0/include -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE /Zl /Zi /Fdtmp32/lib -c .\crypto\o_fips.c o_fips.c crypto\o_fips.c(60) : fatal error C1083: Cannot open include file: 'openssl/fips.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Set the FIPSDIR environment variable to a location where you want the module installed before you call ms\do_fips and then don't include the --with-fipslibdir option to Configure. Hello Steve, That worked perfectly. Thanks. I am now able to produce a working FIPS-capable OpenSSL that works on Windows NT. Thanks! Bill 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 Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES key wrap feature unavailable in FIPS mode OpenSSL?
On 10/26/2011 9:43 PM, Bill Durant wrote:
Hello,
Has the AES key wrap feature been removed from the nightly OpenSSL in FIPS mode?
I have built a FIPS-capable OpenSSL using the following:
ftp://ftp.openssl.org/snapshot/openssl-1.0.1-stable-SNAP-20111025.tar.gz
ftp://ftp.openssl.org/snapshot/openssl-fips-2.0-test-20111025.tar.gz
When I call AES_set_encrypt_key(), while in FIPS mode, I get the following
abort:
.\crypto\aes\aes_misc.c(73): OpenSSL internal error, assertion failed: Low level
API call to cipher AES forbidden in FIPS mode!
I can see that this is intentional per crypto\aes\aes_misc.c:
67 /* FIPS wrapper functions to block low level AES calls in FIPS mode */
68
69 int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
70 AES_KEY *key)
71 {
72 #ifdef OPENSSL_FIPS
73 fips_cipher_abort(AES);
74 #endif
75 return private_AES_set_encrypt_key(userKey, bits, key);
76 }
Note: This looks buggy to me. If fips_cipher_abort() is a
function/macro which never returns, then
the return line should be in a #else conditional so compilers don't
waste memory creating code to
actually do the call.
No such abort occurs with a FIPS-capable OpenSSL using the following:
http://openssl.org/source/openssl-0.9.8r.tar.gz
http://openssl.org/source/openssl-fips-1.2.3.tar.gz
Is there an alternate way to do AES key wrap using the nightly OpenSSL in FIPS
mode?
More to the point: Is the FIPS module limited to a subset of the FIPS
approved modes of operation?
Can it do the NIST specified (badly designed!) key wrap mode, which
unnecessarily helps attackers by including a MAC of the wrapped key?
Can it do traditional modes (ECB, CBC, CFB, OFB)?
Can it do the new FIPS modes (CTR, GCM)?
Can it do the various modes from the modes workshop days (ABC, XCBC,
the flawed CBC-MAC etc.)?
Can the key and/or IV be set directly?
Can the key and/or IV be set to the output of an approved RNG?
Can the key and/or IV be set from a decrypted wrapped key?
Can the key and/or IV be set from the output of an approved hash algorithm?
Can the key and/or IV be set from one of the approved DH variants, with
all of
the parametric variations permitted?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 10/8/11 1:16 AM, Michael Sierchio wrote: On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webbkw...@teradactyl.com wrote: My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. Your understanding is flawed - while in the scenario you mention there is no binding of a client identity to a public key, SSLv3/TLS are not vulnerable to MITM - no third party can manipulate the stream without being detected. Yes, thank you. Upon further investigation I find that not using client certs means that the server cannot prove the identity of the client. So I think that the attack I am looking at is more of a client impersonation, where a rouge client pretends to be the real client. All it takes (I think) is for the rouge client to have enough information about the server (e.g. our application installed) and be able to present itself to the server as the client under attack. Since the server cannot distinguish, then the rouge client could use our application to manipulate the server. It seems that the only way to help prevent this is to use client certificates to prove the identity of the client. The problem I am having with this is that managing certs for a few servers is easy, while managing it for 1000's of clients is not. I'm looking for the way around this and still keep things secure, but maybe there is not? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 7 Oct 2011, at 7:40 PM, Kristen J. Webb wrote: I'm exploring the security of TLS for TCP/IP connections. I would like to establish TLS connections using server certificates (managing client certs via external or internal PKI is painful). My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. My question is, if multiple servers are used, can this attack (and possibly others) be avoided? Example: initiate_server: TLS connect with client initiate_server: send encrypted data over TLS to client (including target_server:port) initiate server: TLS connect with target_server initiate_server: send encrypted data over TLS to target_server (including listen port, client, etc) client: attempt TLS connection to target_server:port target_server: accept TLS connection from client client/target_server: verify additional encrypted data (from initiate_server) to establish a connection If I understand this, you're trying to use 'initiate_server' to introduce the other two machines to each other, and relying on those two machines' server certificates to allow initiate_server to verify that it's talking to the right machine? I see two problems with this. One is that initiate_server isn't authenticated to the other machines--- evil_server could connect to target_server, give it fake encrypted data and client info, and then impersonate the client. The other problem is that this isn't really avoiding having a certificate on the client machine. If you have a trustowrthy certificate on client, which initiate_server can use to authenticate the connection, why not use that certificate as a client certificate when client connects to target_server (and eliminate the role of initiate_server entirely)? Apologies if I don't understand your original motivation, but I don't see how the introducer scheme helps you any. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: strong TLS connections
On 10/26/11 6:35 PM, Wim Lewis wrote: On 7 Oct 2011, at 7:40 PM, Kristen J. Webb wrote: I'm exploring the security of TLS for TCP/IP connections. I would like to establish TLS connections using server certificates (managing client certs via external or internal PKI is painful). My understanding is that a TLS connection with a server cert only identifies the server to the client. This leads to a MiTM attack, where the mitm can impersonate the client because the server has not verified the client. My question is, if multiple servers are used, can this attack (and possibly others) be avoided? Example: initiate_server: TLS connect with client initiate_server: send encrypted data over TLS to client (including target_server:port) initiate server: TLS connect with target_server initiate_server: send encrypted data over TLS to target_server (including listen port, client, etc) client: attempt TLS connection to target_server:port target_server: accept TLS connection from client client/target_server: verify additional encrypted data (from initiate_server) to establish a connection If I understand this, you're trying to use 'initiate_server' to introduce the other two machines to each other, and relying on those two machines' server certificates to allow initiate_server to verify that it's talking to the right machine? Not exactly, I was trying to develop a method where the transaction could occur securely w/o a client certificate. I am beginning to believe that this is not possible. The original idea I had is starting to look like a twisted/reverse way that Kerberos does these things (I have implemented GSSAPI using host principles, which takes the need of the client cert out of the process). I see two problems with this. One is that initiate_server isn't authenticated to the other machines--- evil_server could connect to target_server, give it fake encrypted data and client info, and then impersonate the client. I was assuming that the clients (and servers) would have the longer term trust of the initiate_server via a PEM file that has it's identity. The other problem is that this isn't really avoiding having a certificate on the client machine. If you have a trustowrthy certificate on client, which initiate_server can use to authenticate the connection, why not use that certificate as a client certificate when client connects to target_server (and eliminate the role of initiate_server entirely)? Yeah, I wish I did not need to manage the client certificates. I am interested in setting up a local CA for client certs. One of my stumbling blocks is how to manage the install of a new client with libssl.so, but not openssl installed (so openssl req not there). Apologies if I don't understand your original motivation, but I don't see how the introducer scheme helps you any. If my understanding is up to speed you need to manage client certs to do this right. Which brings me to my next set of questions about how to manage this from install to revocation. Having an app that can use certs, it appears, is nothing compared with how to deploy it and manage those certs ;) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Mr. Kristen J. Webb Teradactyl LLC. PHONE: 1-505-242-1091 EMAIL: kw...@teradactyl.com VISIT: http://www.teradactyl.com Home of the True incremental Backup System __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1 example with SRP
Is there no one that can help me get a simple SRP test case working? Or should I conclude SRP is broken in OpenSSL 1.0.1? From the output below, it appears the client and server support no less than 9 ciphers in common. Why then do I get the no shared cipher error? I rebuilt the library with -DCIPHER_DEBUG and now get the following output from the handshake: --- server: openssl s_server -cipher SRP -nocert -tls1 -accept 57784 -debug SRP-DSS-AES-256-CBC-SHA SRP-RSA-AES-256-CBC-SHA SRP-AES-256-CBC-SHA SRP-DSS-3DES-EDE-CBC-SHA SRP-RSA-3DES-EDE-CBC-SHA SRP-3DES-EDE-CBC-SHA SRP-DSS-AES-128-CBC-SHA SRP-RSA-AES-128-CBC-SHA SRP-AES-128-CBC-SHA ACCEPT read from 0x7e6f30 [0x7ec523] (5 bytes = 5 (0x5)) - 16 03 01 00 55U read from 0x7e6f30 [0x7ec528] (85 bytes = 85 (0x55)) - 01 00 00 51 03 01 4e a8-bf bb 5d 89 f9 aa ae 3f ...Q..N...]? 0010 - 5f df fd dd 70 1c 4d c1-91 09 94 84 47 2f 8e a7 _...p.M.G/.. 0020 - 99 d3 fe 73 6a e1 00 00-14 c0 22 c0 21 c0 20 c0 ...sj..!. . 0030 - 1c c0 1b c0 1a c0 1f c0-1e c0 1d 00 ff 01 00 00 0040 - 14 00 0c 00 0c 0a 53 79-73 74 65 6d 55 73 65 72 ..SystemUser 0050 - 00 00 23 ..# 0055 - SPACES/NULS Server has 9 from 7df600: 77e0e8:SRP-DSS-AES-256-CBC-SHA 77e090:SRP-RSA-AES-256-CBC-SHA 77e038:SRP-AES-256-CBC-SHA 77ded8:SRP-DSS-3DES-EDE-CBC-SHA 77de80:SRP-RSA-3DES-EDE-CBC-SHA 77de28:SRP-3DES-EDE-CBC-SHA 77dfe0:SRP-DSS-AES-128-CBC-SHA 77df88:SRP-RSA-AES-128-CBC-SHA 77df30:SRP-AES-128-CBC-SHA Client sent 9 from 7df960: 77e0e8:SRP-DSS-AES-256-CBC-SHA 77e090:SRP-RSA-AES-256-CBC-SHA 77e038:SRP-AES-256-CBC-SHA 77ded8:SRP-DSS-3DES-EDE-CBC-SHA 77de80:SRP-RSA-3DES-EDE-CBC-SHA 77de28:SRP-3DES-EDE-CBC-SHA 77dfe0:SRP-DSS-AES-128-CBC-SHA 77df88:SRP-RSA-AES-128-CBC-SHA 77df30:SRP-AES-128-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0002:0188:0084]77e0e8:SRP-DSS-AES-256-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0001:0188:0084]77e090:SRP-RSA-AES-256-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0004:0188:0084]77e038:SRP-AES-256-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0002:0188:0084]77ded8:SRP-DSS-3DES-EDE-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0001:0188:0084]77de80:SRP-RSA-3DES-EDE-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0004:0188:0084]77de28:SRP-3DES-EDE-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0002:0188:0084]77dfe0:SRP-DSS-AES-128-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0001:0188:0084]77df88:SRP-RSA-AES-128-CBC-SHA rt=1 rte=1 dht=1 ecdht=1 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0 0:[0400:0004:0188:0084]77df30:SRP-AES-128-CBC-SHA write to 0x7e6f30 [0x7f5fd0] (7 bytes = 7 (0x7)) - 15 03 01 00 02 02 28 ..( ERROR 18446741324916266428:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1306: shutting down SSL CONNECTION CLOSED --- Client: openssl s_client -srpuser SystemUser -srppass stdin -tls1 -cipher SRP -connect localhost:57784 -debug SRP-DSS-AES-256-CBC-SHA SRP-RSA-AES-256-CBC-SHA SRP-AES-256-CBC-SHA SRP-DSS-3DES-EDE-CBC-SHA SRP-RSA-3DES-EDE-CBC-SHA SRP-3DES-EDE-CBC-SHA SRP-DSS-AES-128-CBC-SHA SRP-RSA-AES-128-CBC-SHA SRP-AES-128-CBC-SHA CONNECTED(0003) write to 0x7d23a0 [0x7f22e3] (90 bytes = 90 (0x5A)) - 16 03 01 00 55 01 00 00-51 03 01 4e a8 bf bb 5d U...Q..N...] 0010 - 89 f9 aa ae 3f 5f df fd-dd 70 1c 4d c1 91 09 94 ?_...p.M 0020 - 84 47 2f 8e a7 99 d3 fe-73 6a e1 00 00 14 c0 22 .G/.sj. 0030 - c0 21 c0 20 c0 1c c0 1b-c0 1a c0 1f c0 1e c0 1d .!. 0040 - 00 ff 01 00 00 14 00 0c-00 0c 0a 53 79 73 74 65 ...Syste 0050 - 6d 55 73 65 72 00 00 23- mUser..# 005a - SPACES/NULS read from 0x7d23a0 [0x7edd83] (5 bytes = 5 (0x5)) - 15 03 01 00 02. read from 0x7d23a0 [0x7edd88] (2 bytes = 2 (0x2)) - 02 28 .( 18446741324916266428:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1227:SSL alert number 40 18446741324916266428:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:592: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher:
