RE: ssl handshake failure in 1.0.1 but not 1.0.0
From: Dave Thompson Yes, the server has a custom root cert that isn't installed on this machine. I am happy that the server cert is correct. For testing that's okay, but I hope in real use you are verifying. Otherwise an active attacker may be able to MITM your connections. Production environments do a peer verification. I disabled that for development purposes. The ServerHello does indeed contain the secure-renegotiation extension in one pcap and not the other. Assuming there isn't some really weird logic on the server that supports 5746 only sometimes, this might be due to the (much) larger cipherlist -- OpenSSL puts ERI-SCSV at the end of the cipherlist, so if the server can only handle maybe 32 or 50 or so entries in the cipherlist it might not see ERI in the default-ciphers case. You could experiment with intermediate size cipherlists -- my suggestion of forcing -tls1 by itself takes you down from 80 to 52 (because it implicitly disables the TLSv1.2-only SHA2 and GCM suites), or so does explicit -cipher DEFAULT:!TLSv1.2 . Removing more things you shouldn't want anyway goes lower e.g. DEFAULT:!TLSv1.2:!EXPORT:!LOW:!SRP:!kECDH should be 30. [snip] If the problem is the length of the ClientHello and/or cipherlist -- as is consistent with but not conclusively proven by what you've seen so far, and is somewhat similar to the fact that other servers have already been found to fail or hang *initial* negotiation when ClientHello = 256 bytes (although this server did *not* fail there), just using a shorter cipherlist should work. A few akRSA, one or two DHE-RSA and ECDHE-RSA because a server with RSA can still do akRSA unless KU prohibits, a few ECDHE-ECDSA and perhaps a few DHE-DSS -- maybe 20 total -- should handle any sane server. That's great, thank you for the detailed explanations. Your hunch that the problem lies with the length of the cipherlist seems to bear out; I removed some of the ciphers you suggested and the server still happily connects. It creates a Client Hello of 198 bytes which should also avoid the other problem you mention (that I haven't seen on this particular server). Thanks for all the help, Ben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
From: owner-openssl-users On Behalf Of Ben Arnold Sent: Friday, November 08, 2013 10:45 snip I have tried using s_client and it fails with the same handshake failure. Please see below. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. You're right of course, that is much more sensible. I have attached two pcap traces from s_connect, one success and one failure. From: Dave Thompson snip: server cert Yes, the server has a custom root cert that isn't installed on this machine. I am happy that the server cert is correct. For testing that's okay, but I hope in real use you are verifying. Otherwise an active attacker may be able to MITM your connections. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. I can reproduce the failure with s_client in the same manner. It looks (to me) like the server only asks for the client certificate once the GET command has been issued, the initial negotiation doesn't ask for it. I don't know the TLS protocol so that might be normal. Once I send the GET ... command it tries to Yes. More exactly, on the initial negotiation the server does not request client auth (and thus openssl doesn't obtain and send it). After curl or s_client/you sends the GET request, the server initiates renegotiation and does request client auth except in the case using 1.0.1 where it fails before getting to that point. Renegotiation is a standard capability of SSL/TLS and can be initiated by either client or server. Whether and when it is used depends on the applications using SSL/TLS. *For HTTPS*, it is not uncommon for webservers to allow connection without client auth that can access public resources but require renegotiation with client auth for private resources, and it certainly appears this particular webserver is doing that. renegotiate but fails. Looking at the output from s_client -state I see this during the first negotiation... --- No client certificate CA names sent --- SSL handshake has read 2884 bytes and written 639 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE And then I send GET /directory HTTP/1.1 and see... SSL_connect:SSL renegotiate ciphers SSL_connect:unknown state SSL_connect:failed in unknown state 16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:1156: From: Krzysztof Kwiatkowski Do you still see an error if you specify one cipher? f.e. AES256-SHA? I do get an error when using AES256-SHA, in fact a much earlier error as the server does not support that cipher, nor does it support AES-128-SHA. However I took the idea and if I add -cipher DES-CBC3-SHA (as selected by the server in the previous run) to s_connect then everything works OK, and if I add the same cipher selection to my program that that works too. When I do specify DES-CBC3-SHA, s_client also reports Secure Renegotiation IS supported This sounds important to me! :) Notice that the failure case reports renegotiation is NOT supported. To be exact it reports *secure* renegotiation is not supported. There are two slightly different renegotiation protocols, the original one (now usually called legacy or unsafe) which was found to be somewhat vulnerable to a MITM-splicing attack, and the updated RFC5746 one (sometimes called by the RFC#, but often just called secure). Client can detect from ServerHello whether the server supports RFC5746 (or at least claims to) and the display tells you that. The client can't determine if legacy renegotiation is supported except by trying it, and even then can't be 100% certain because it could fail for another reason. The ServerHello does indeed contain the secure-renegotiation extension in one pcap and not the other. Assuming there isn't some really weird logic on the server that supports 5746 only sometimes, this might be due to the (much) larger cipherlist -- OpenSSL puts ERI-SCSV at the end of the cipherlist, so if the server can only handle maybe 32 or 50 or so entries in the cipherlist it might not see ERI in the default-ciphers case. You could experiment with intermediate size cipherlists -- my suggestion of forcing -tls1 by itself takes you down from 80 to 52 (because it implicitly disables the TLSv1.2-only SHA2 and GCM suites), or so does explicit -cipher DEFAULT:!TLSv1.2 . Removing more things you shouldn't want anyway goes lower e.g. DEFAULT:!TLSv1.2:!EXPORT:!LOW:!SRP:!kECDH should be 30. Or you could try writing a Java SSL client, which allows you to position ERI-SCSV anywhere you want in the list (i.e. end of 80, end of 40, 40th of 80, etc, etc). The renegotiation ClientHello is longer than the initial one because of the session-id and
RE: ssl handshake failure in 1.0.1 but not 1.0.0
From: Viktor Dukhovni You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? It's a 2048 bit RSA SHA1 certificate, but I think Dave Thompson's right and it's not getting that far. I have tried using s_client and it fails with the same handshake failure. Please see below. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. You're right of course, that is much more sensible. I have attached two pcap traces from s_connect, one success and one failure. From: Dave Thompson To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a custom root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? Yes, the server has a custom root cert that isn't installed on this machine. I am happy that the server cert is correct. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. I can reproduce the failure with s_client in the same manner. It looks (to me) like the server only asks for the client certificate once the GET command has been issued, the initial negotiation doesn't ask for it. I don't know the TLS protocol so that might be normal. Once I send the GET ... command it tries to renegotiate but fails. Looking at the output from s_client -state I see this during the first negotiation... --- No client certificate CA names sent --- SSL handshake has read 2884 bytes and written 639 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE And then I send GET /directory HTTP/1.1 and see... SSL_connect:SSL renegotiate ciphers SSL_connect:unknown state SSL_connect:failed in unknown state 16444:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:.\ssl\s3_pkt.c:1156: From: Krzysztof Kwiatkowski Do you still see an error if you specify one cipher? f.e. AES256-SHA? I do get an error when using AES256-SHA, in fact a much earlier error as the server does not support that cipher, nor does it support AES-128-SHA. However I took the idea and if I add -cipher DES-CBC3-SHA (as selected by the server in the previous run) to s_connect then everything works OK, and if I add the same cipher selection to my program that that works too. When I do specify DES-CBC3-SHA, s_client also reports Secure Renegotiation IS supported This sounds important to me! :) Notice that the failure case reports renegotiation is NOT supported. So the question now is, how come negotiation *is* supported when I manually specify DES-CBC3-SHA and *not* supported when I leave default ciphers, when the server ends up picking DES-CBC3-SHA anyway. I have attached two pcap files, both captured using s_client - one with the default ciphers and one with -cipher DES_CBC3-SHA. I notice that the Client Hello is slightly different, when using all ciphers there are two extra extensions: ec_point_formats and elliptic_curves. Whether or not this is relevant I have no idea, I imagine not as they are likely omitted because DES isn't ECC. For now all the servers I need to talk to support DES-CBC3-SHA, this may not always be the case. Any idea how likely it is I will find a server that doesn't? Or is there something else I can set to make renegotiation supported without specifying the cipher. Thanks for all your suggestions so far, Ben s_client_default.pcap Description: s_client_default.pcap s_client_des_cbc3_sha.pcap Description: s_client_des_cbc3_sha.pcap
Re: ssl handshake failure in 1.0.1 but not 1.0.0
On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: I am using SSL_CTX_set_client_cert_cb to provide the client certificate when needed. I have a problem in that OpenSSL 1.0.1e does not trigger this callback for all websites that I expect it to, only some. Instead on the failing sites there is an SSL handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure, errno 0 Interestingly if I compile against 1.0.0k then there is no failure and the callback *is* triggered for all sites (that I have tried so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with tcpdump -s0 -w file ... and look with wireshark -r file. If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, November 07, 2013 11:02 On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: I am using SSL_CTX_set_client_cert_cb to provide the client certificate when needed. I have a problem in that OpenSSL 1.0.1e does not trigger this callback for all websites that I expect it to, only some. Instead on the failing sites there is an SSL handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? OP's log shows protocol hasn't reached the CertReq - ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP fixed it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a custom root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure, errno 0 Interestingly if I compile against 1.0.0k then there is no failure and the callback *is* triggered for all sites (that I have tried so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with tcpdump -s0 -w file ... and look with wireshark -r file. If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
Do you still see an error if you specify one cipher? f.e. AES256-SHA? On 2013-11-07 22:26, Dave Thompson wrote: From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, November 07, 2013 11:02 On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: I am using SSL_CTX_set_client_cert_cb to provide the client certificate when needed. I have a problem in that OpenSSL 1.0.1e does not trigger this callback for all websites that I expect it to, only some. Instead on the failing sites there is an SSL handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? OP's log shows protocol hasn't reached the CertReq - ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP fixed it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a custom root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure, errno 0 Interestingly if I compile against 1.0.0k then there is no failure and the callback *is* triggered for all sites (that I have tried so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with tcpdump -s0 -w file ... and look with wireshark -r file. If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-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
SSL handshake failure
Hi, openssl experts! It's required to transfer data to Apple Push service that is located at gateway.sandbox.push.apple.com:2195. I'm given the certificate and private key both included in Certificate_and_key.pem. Trying to connect: $ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -CAfile EntrustCA.pem -cert Certificate_and_key.pem Server's certificate is passed successfully (with CA included in EntrustCA.pem) but the error is following: 140735074831484:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1193:SSL alert number 46 140735074831484:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: I tried to google about alert 46, but found only that something wrong with client's certificate. Is it possible to get more details about failure? Below is some info that might probably be helpful. I read about X509v3 extensions just tonight, and it's not clear for me by far if extensions could relate to my problem: $ openssl verify -CAfile AppleCA.pem Certificate_and_key.pem . . . error 34 at 0 depth lookup:unhandled critical extension OK $ openssl x509 -in Certificate_and_key.pem -text -noout -purpose here are all extensions marked as critical: X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: critical Code Signing X509v3 Key Usage: critical Digital Signature . . . Certificate purposes: SSL client : No SSL client CA : No SSL server : No SSL server CA : No Netscape SSL server : No Netscape SSL server CA : No S/MIME signing : No S/MIME signing CA : No S/MIME encryption : No S/MIME encryption CA : No CRL signing : No CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes OCSP helper : Yes OCSP helper CA : No Time Stamp signing : No Time Stamp signing CA : No maybe, the SSL client : No line is related to connection failure? Much thanks in advance! -- WBR, Timur
Re: SSL handshake failure
On Sun, Nov 14, 2010, Timur Elzhov wrote: Hi, openssl experts! It's required to transfer data to Apple Push service that is located at gateway.sandbox.push.apple.com:2195. I'm given the certificate and private key both included in Certificate_and_key.pem. Trying to connect: $ openssl s_client -connect gateway.sandbox.push.apple.com:2195 -CAfile EntrustCA.pem -cert Certificate_and_key.pem Server's certificate is passed successfully (with CA included in EntrustCA.pem) but the error is following: 140735074831484:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1193:SSL alert number 46 140735074831484:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: I tried to google about alert 46, but found only that something wrong with client's certificate. Is it possible to get more details about failure? That's all the server sends back. Is that the correct certificate for that server? X509v3 Extended Key Usage: critical Code Signing Well the above extension would mean that certificate can only be used for code signing, not SSL client authentication. 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: www.harryanddavid.com SSL handshake failure error in non-blocking mode.
On Fri, Jan 13, 2006, Krishna M Singh wrote: I remember the SSL stack of Netscape and Firefox are OpenSSL variants. Does this mean the same has been fixed in their stacks or is it handled by the application itself?. Then you remember incorrectly. Netscape and Firefox use NSS which is not based on OpenSSL. Any pointers will be of great help. thanks a lot for going thru my long mail. The problem is that server, not the client. If the server handled this correctly it would recognize that the client supported TLS[*] but would negotiate SSLv3 instead. The server attempts to do this but messes up somewhere during the handshake or the internal session setup. Steve. [*] Well it wouldn't know it was TLS if it had no knowledge of TLS. It would simply appear to be a version of SSL higher than it could handle so it would use the version it could handle: SSLv3. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: www.harryanddavid.com SSL handshake failure error in non-blocking mode.
Hi Thank for the inputs. Disabling TLS removes the problem. Apart from that i tried following With the default configuration set and page accessed through Netscape 7.2 the web page is not accessible and when refreshed the page is accessible. Every time the browser is closed and reopened the same behaviour is noticed. The first time the Netscape sends version 3.1 and the next time on refresh it tries with version 3.0 and which works. Netscape is storing this information that this web server does not work with 3.1 and hence uses lower protocol version in next requests. In case of Firefox 1.5, the browser retries the web page with version 3.0 automatically when it is not accessible the first time with 3.1 version. Only difference with Firefox and Netscape is that Firefox retries on it's own whereas in Netscape user needs to refresh the page. It seems Netscape doesn't handled this problem and required use to do refresh. Firefox discovers this on runtime and retries connection with SSL 3.0 (when SSL handshake with SSL3.1 fails with harryandavid site). I remember the SSL stack of Netscape and Firefox are OpenSSL variants. Does this mean the same has been fixed in their stacks or is it handled by the application itself?. Any pointers will be of great help. thanks a lot for going thru my long mail. thanks and regards -Krishna On 1/10/06, Dr. Stephen Henson [EMAIL PROTECTED] wrote: On Tue, Jan 10, 2006, Krishna M Singh wrote: Also when we use SSLv2 only this works fine.. Only with SSLv23 the handshake fails. Any ideas or pointers how to proceed further wud be of great help.. Seems it doesn't support TLS and messes up SSLv3 when the client indicates it supports TLS. Disabling TLS works though: the -no_tls1 option in s_client does that. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: www.harryanddavid.com SSL handshake failure error in non-blocking mode.
On Tue, Jan 10, 2006, Krishna M Singh wrote: Also when we use SSLv2 only this works fine.. Only with SSLv23 the handshake fails. Any ideas or pointers how to proceed further wud be of great help.. Seems it doesn't support TLS and messes up SSLv3 when the client indicates it supports TLS. Disabling TLS works though: the -no_tls1 option in s_client does that. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Openssl-0.9.7c changes cause SSL handshake failure
Title: Openssl-0.9.7c changes cause SSL handshake failure Hi all, I need some help in figuring out how to solve a SSL handshake failure that started after upgrading (from 0.9.7b) to 0.9.7c. Here are the symptoms: SSL_connect breaks with SSL_R_MISSING_EXPORT_TMP_RSA_KEY. This happens because the client plans on using RSA_EXPORT1024_WITH_DES_CBC_SHA, and the server has a certificate with a 1024-bit RSA key. In 0.9.7b there was a bug in X509_certificate_type() that caused it to mark the server's public key with EVP_PKT_EXP (i.e. this is an export cipher key). The bug was fixed in 0.9.7c, and so I have an EXPORT cipher, with NON-EXPORT key. This causes a check in ssl3_check_cert_and_algorithm() to fail because an EXPORT algorithm is used with NON-EXPORT certificate, and no temporary EXPORT key. My question is: Why is this check needed? Is it required in SSL/TLS specification? It seems strange to me to blame the server for not generating a temporary 512 bit key (the algorithm specifies explicitly RSA-1024). Anybody encountered this before? Any solution / workaround? I'm using Windows2000 as the server, and my application which is linked with OpenLDAP and OpenSSL as the client. Thanks Tal
RE: SSL Handshake Failure !
I don't have the specific code, but it's not that much. I take it that you're issuing your own certs with the acceptable client ip in the subjectAltName - you might want to allow a range. I have similar code but not for this purpose, so let's see if I can put them together. My code looks at the subject name, so I might be wrong in looking for the alt name in the subject, but it's a start. SSL *ssl;/* client SSL struct, assume this exists */ int fd, l; struct sockaddr client_addr; char ip_addr[4*3+3+1]; X509 *cert; X509_NAME *subject; char subject_ip[300]; /* get the ip of client */ fd = SSL_get_fd(ssl); l = sizeof(struct sockaddr); getpeername(fd, client_addr, l); /* check rc! */ strcpy(ip_addr, inet_ntoa(client_addr.sin_addr)); /* look in cert for subject name? */ cert = SSL_get_peer_certificate(ssl); subject = X509_get_subject_name(cert); /* check for NULL! */ X509_NAME_get_text_by_NID(subject, NID_subject_alt_name, subject_ip, 300); /* check rc! */ if (strcmp(subject_ip, client_ip) != 0) /* mismatch! */; X509_free(cert); /* reduce reference count */ Steve On Thu, 4 Oct 2001, Andy Schneider wrote: Does anyone have any canned code I could steal that does IP address validation. I.e. grabs the IP address from the alt subject name and compares it against the IP of the incoming socket? Andy S. -Original Message- From: Costas Magos [mailto:[EMAIL PROTECTED]] Sent: 04 October 2001 15:40 To: [EMAIL PROTECTED] Subject: SSL Handshake Failure ! Importance: High Dear all, Sorry for posting the following again, but I am in a bit hurry. I'm running an Apache server (1.3.19) with openssl 0.9.6b on Solaris 2.6 / SPARCclassic platform. Apache serves a site that accesses a database through various cgi-scripts or through a java applet for more specialized actions. The database is managed just fine with the cgi-scripts, but when I try to load the java applet to do some advanced configuration, the browser hangs at some point (while loading some classes) and the server produces the following error logs: [info] [client xxx.xxx.xxx.xxx] SSL accept timeout timed out [error] SSL_accept failed and then [debug] apache_ssl.c(1123): Generating 512 bit key [debug] apache_ssl.c(287): SSL_accept returned 0 [debug] apache_ssl.c(291): error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure [debug] apache_ssl.c(379): Random input /dev/random(1024) - 1024 [debug] apache_ssl.c(1123): Generating 512 bit key [debug] apache_ssl.c(287): SSL_accept returned 0 [debug] apache_ssl.c(291): error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure [debug] apache_ssl.c(379): Random input /dev/random(1024) - 1024 [debug] apache_ssl.c(1123): Generating 512 bit key [debug] apache_ssl.c(287): SSL_accept returned 0 [debug] apache_ssl.c(291): error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake What is going on? Could someone please help me? Any help would be much appreciated. Respectfully, ~~ Costas Magos Ariadne-t Network Operation Center, NCSR Demokritos ~~ email: [EMAIL PROTECTED] tel.: +30 1 6544279, +30 1 6503125 fax: +30 1 6532910 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL Handshake Failure !
Andy Schneider wrote: Does anyone have any canned code I could steal that does IP address validation. I.e. grabs the IP address from the alt subject name and compares it against the IP of the incoming socket? No I don't. But in outline you need to extract and decode the subject alt name extension (see doc/openssl.txt) this will give you a STACK_OF(GENERAL_NAME). Then search for the ip address type and, if found, extract and compare. Theres a function that extracts email addresses from the subject name and subject alt name extensions (its used by the x509 utility) which should be easy enough to adapt. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ssl handshake failure
Hi, I'm trying to connect to a site with a self signed certificate. And I get the below error message. I am able to correctly connect to other secured sites... Thanks in advance for the help. 8 /home/pziatek openssl s_client -connect security.corp.sgi.com:443 -state SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /C=US/ST=CA/L=Mountain [EMAIL PROTECTED] verify error:num=18:self signed certificate verify return:1 depth=0 /C=US/ST=CA/L=Mountain [EMAIL PROTECTED] verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL3 alert read:fatal:bad record mac SSL_connect:failed in SSLv3 read finished A 1113:error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac:s3_pkt.c:774:SSL alert number 20 1113:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:203: CONNECTED(0003) -- .. Peter Ziatek Silicon Graphics, Inc. 650.933.6955 [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ssl handshake failure (was Re: 386 problems)
Ulf, I removed the cpp file and everything finally compiled without errors. Thanks for your continued assistance on this! Unfortunately, I'm still not able to connect and am still at a loss as to why. When I run s_client I receive the following: CONNECTED(0003) 31019:error:140790E3:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:224: I have a client.pem in /usr/local/ssl/certs and even specified that as an option to s_client. When I try running apps on top of openssl (e.g. - lxp, eassl and Net::SSLeay) they dump core. Anybody have any idea why this is happening? I basically just want to use ssleay as a lynx client. Never thought it would be this difficult. Regards, Philip Ulf Möller wrote: The CVS contained an assembler file that should not have been there. Please remove crypto/bf/asm/bx86unix.cpp and run "make" again. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL handshake Failure
I am having these problem about the SSL handshake, the stronghold server return the error code 0x28 (hanshake-failure) after my SSL client program send the Client_key_exchange (0x16,0x03,0x00,..), Cipher_change_spec (0x14,0x03,0x00,) and client-hanshake_finished(0x16,0x03,0x00,...). The server immediately send me a alert packet (0x15,0x03,0x00,0x00,0x02,0x02,0x28). Could some body tell me what handshake_failure mean, its definition and causes of the error. Thank you for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
