Re: FIPS_mode_set(1) - FIPS_mode_set(0) - FIPS_mode_set(1)
This is a problem for us with FIPS module 1.2.0. wolfoftheair wrote: Is this still present in FIPS module 1.2.0? -Kyle H On Mon, Aug 24, 2009 at 11:55 AM, Mike Trentmichael.tr...@xerox.com wrote: Mike Trent wrote: It seems that after setting FIPS mode off one cannot set it back on again in the same executable. I have a test program which does: FIPS_mode_set(1) - works ok indicated by a return true. FIPS_mode_set(0) - to turn off and works ok, at least the FIPS_mode() call returns 0, so it seems to be off. Then followed by again FIPS_mode_set(1) which returns a 0 indicating failure. A FIPS_Mode() call indicates that the test program is still in non FIPS mode. Is it possible to turn off FIPS and turn it back on in an executable? Thanks. Ok... found the answer. One needs to make this call: RAND_set_rand_method(NULL); prior to making a FIPS_mode_set(1) after having turned off FIPS. -- View this message in context: http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25121535.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@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 -- View this message in context: http://www.nabble.com/FIPS_mode_set%281%29---FIPS_mode_set%280%29---FIPS_mode_set%281%29-tp25121412p25530885.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
openssl and PIC
Hello. In my shared library project I utilize during linking some complied .o files, some static .a libraries and some shared .so libraries. One of utilized libraries is openssl. When I use openssl as shared library, my result library has not TEXTREL section and that is what I want. When I use openssl as static library, my result library has TEXTREL section. I work under ubuntu 8.04. I was utilizing both available here libcrypto.so and libcrypto.a and the same libraries created by me from 0.9.8j version. Result was always the same - with openssl as .so I had no TEXTREL, with openssl as .a I have TEXTREL section. Has anybody any idea how to link my project files with static libcrypto.a to eliminate TEXTREL ? Best regards Jacek -- View this message in context: http://www.nabble.com/openssl-and-PIC-tp25531085p25531085.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: FIPS capable openssl X509_get_pub_key
On Wed, Sep 23, 2009, Pankaj Aggarwal wrote: Ok !! Stephen, Could you tell me which RSA Sign Verfiy functions are available in fips mode. The FIPS 140-2 Annexure A states that RSASSA-PKCS1-v1_5 and RSASSA-PSS contained within PKCS#1 v2.1 can be used for sign/verify. What are the corresponding OpenSSL function which should be used? Everything must go via EVP. You can't sign raw digests in FIPS mode, you must use EVP_Sign*() and EVP_Verify*(). The one exception is the SSL/TLS SHA1+MD5 signature which is permitted but not explicitly tested as part of the validation. To permit PSS some extra flags are added, see the dgest utility for some details. This is a bit of a hack but was the only way to support PSS in 0.9.8 without breaking binary compatibility. 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: SSL_set_tlsext_host_name and IDN
On Wednesday 23 September 2009 13:25:09 Victor Duchovni wrote: On Wed, Sep 23, 2009 at 11:03:55AM +1000, Daniel Black wrote: Should SSL_set_tlsext_host_name convert the domain name to ACE as per RFC4366 3.1 where it talks about IDNA (RFC 3490)? On the wire, domain names are always of the ASCII xn--mumble variety. The corresponding Unicode is a matter of user display. Thus, to the extent that hostnames are exchanged in SNI, they are ASCII host names. The RFC is clear as mud of course. :-( http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3 got mentioned to me and though it clears it up it misses references to ACE. So SSL_set_tlsext_host_name() is a valid ASCII domain name, that may encode a Unicode name, but is not directly unicode. given the number of people/application programmers that will assume UTF-8 is valid here is validating characters x7F worth it? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_set_tlsext_host_name and IDN
On Thu, Sep 24, 2009 at 01:00:34AM +1000, Daniel Black wrote: On Wednesday 23 September 2009 13:25:09 Victor Duchovni wrote: On Wed, Sep 23, 2009 at 11:03:55AM +1000, Daniel Black wrote: Should SSL_set_tlsext_host_name convert the domain name to ACE as per RFC4366 3.1 where it talks about IDNA (RFC 3490)? On the wire, domain names are always of the ASCII xn--mumble variety. The corresponding Unicode is a matter of user display. Thus, to the extent that hostnames are exchanged in SNI, they are ASCII host names. The RFC is clear as mud of course. :-( http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-05#section-3 got mentioned to me and though it clears it up it misses references to ACE. So SSL_set_tlsext_host_name() is a valid ASCII domain name, that may encode a Unicode name, but is not directly unicode. given the number of people/application programmers that will assume UTF-8 is valid here is validating characters x7F worth it? Such clients are in violation of the specification, there is no way for the client to advertise the character-set of the hostname, and assuming UTF-8, is neither robust nor easy to implement. I would just ignore non-ASCII hostnames, if the hostname is being using to select a server certificate/key pair for a DNS name. Pretend no SNI data is sent. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
verify client certificate at a later point
Dear OpenSSL group, I have a somewhat curious setting (without CAs) about routing information along several nodes: [1] first an unkown client establishes a connection to a known server thus I set SSL_CTX_set_verify(this-ctx, SSL_VERIFY_NONE, NULL); and let the client verify the servers certificate, like this X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); [2] now a secure connection is established on it the server receives data encrypted with the servers public key, so only it can read it in the data is information about the next node and the previous node now the server knows the ssl certificate of the previous node and thus wants to check it, since the verify mode is still set to server only, we set it a new SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); [3] if the server now runs the code above X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); x509 will be NULL. This is probably because the handshake has already taken place. So there simply is no client certificate. Now I am trying to find a way around this problem, but failed so far. It would be nice to either find a way that both certificates are exchanged during handshae, but only the server one is verified at first or to find a way to request a certificate from the client at a later point. Has anyone an idea, how this could be achieved with the OpenSSL API? Thank You Very Much! Michael
Re: verify client certificate at a later point
On Wed, Sep 23, 2009 at 10:04:48PM +0200, Michael Prinzinger wrote: and let the client verify the servers certificate, like this X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); This only verifies the server's *trust chain*, but not its identity. To properly verify a server, you MUST examine the certificate subjectAltName extensions and if these are missing the CommonName in the subject DN. [2] now a secure connection is established No secure connection is exists unless the client verified the server certificate. on it the server receives data encrypted with the servers public key, so only it can read it in the data is information about the next node and the previous node now the server knows the ssl certificate of the previous node and thus wants to check it, since the verify mode is still set to server only, we set it a new SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); Entirely pointless after the SSL handshake is done. [3] if the server now runs the code above X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); Again this would just verify the trust chain, and say nothing about the client identity. Has anyone an idea, how this could be achieved with the OpenSSL API? You are solving the wrong problem. Forget OpenSSL APIs, ... what actual security goals are you trying to achieve and what is available on the client and server to get you there? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: verify client certificate at a later point
I set the following for the global context which is used to create the
connection:
// Set the SSL certificate verify mode
SSL_CTX_set_verify(_globalContext, SSL_VERIFY_PEER, NULL);
Then the server requests the peer (i.e. the client) for a certificate during
the handshake, which the client can either ignore, or provide.
Then, right after SSL_accept() returns 0, i.e. now we are ready to check the
certificate, I add the following code to see if the client provided a
certificate and whether it is acceptable.
Check that SSL_get_verify_result(_connContext) == X509_V_OK, // This
checks for the validity of the certificate chain.
// Did the client provide a certificate?
cert = SSL_get_peer_certificate(_connContext);
if (cert == NULL) { // Client provided no certificate.
// mark it as not provided certificate during handshake and give it
lower privileges.
// Otherwise check the certificate for acceptability and if that check
passes give it higher privileges.
Hope that helps.
The other option is to do a handshake without asking for a client certificate
first, then do a re-handshake and ask the client for a certificate when
required.
Ashish
__
Ashish V. Thapliyal, Security Architect, Citrix Online Division, 6500 Hollister
Ave, Goleta, CA 93117. V: +1 (805) 690 2908.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Michael Prinzinger
Sent: Wednesday, September 23, 2009 1:05 PM
To: openssl-users@openssl.org
Subject: verify client certificate at a later point
Dear OpenSSL group,
I have a somewhat curious setting (without CAs) about routing information along
several nodes:
[1] first an unkown client establishes a connection to a known server
thus I set
SSL_CTX_set_verify(this-ctx, SSL_VERIFY_NONE, NULL);
and let the client verify the servers certificate, like this
X509* x509 = SSL_get_peer_certificate(s);
CHECK(x509 != NULL);
//check certificate
long certVerifyResults = SSL_get_verify_result(s);
if(certVerifyResults != X509_V_OK)
throw SSLException(Error! Certificate could not be verified.\n);
//free x509
X509_free(x509);
[2] now a secure connection is established
on it the server receives data encrypted with the servers public key, so
only it can read it
in the data is information about the next node and the previous node
now the server knows the ssl certificate of the previous node and thus wants
to check it,
since the verify mode is still set to server only, we set it a new
SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
[3] if the server now runs the code above
X509* x509 = SSL_get_peer_certificate(s);
CHECK(x509 != NULL);
//check certificate
long certVerifyResults = SSL_get_verify_result(s);
if(certVerifyResults != X509_V_OK)
throw SSLException(Error! Certificate could not be verified.\n);
//free x509
X509_free(x509);
x509 will be NULL.
This is probably because the handshake has already taken place. So there simply
is no client certificate.
Now I am trying to find a way around this problem, but failed so far.
It would be nice to either find a way that both certificates are exchanged
during handshae, but only the server one is verified at first
or to find a way to request a certificate from the client at a later point.
Has anyone an idea, how this could be achieved with the OpenSSL API?
Thank You Very Much!
Michael
Re: verify client certificate at a later point
Thank you for your answer Victor, I am trying to establish a routing path for an anonymity protocol ( http://en.wikipedia.org/wiki/Phantom_Anonymity_Protocol). This is a one way procedure: the node that wants to be anonymized selects a couple of other nodes and sends an array with setup packages (encrypted with the node's public key) to the first node, it had selectd. Now every such node accepts an anonymous connection from a client, receives this array, decrypts the setup package meant for this node, and finds inside: IP and Certificate of the previous and next node (and some more information unrelated to openssl). When establishing a connection to the next node, the current node can thus verify the certificate of the next node. However, now that the current node also got to know the previous node's certificate in a secure way, it can also verify the previous node's certificate. However, the handshake was already made, and the previous node did not send a certificate. That is why I am looking for a way to get this certificate after the handshake was already made, so the current node can verify it. === also thanks for your remarks about how to actually verify a socket. I will extend my verification method by also checking the extensions. I would be grateful, if you could help! Michael On Wed, Sep 23, 2009 at 10:18 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Sep 23, 2009 at 10:04:48PM +0200, Michael Prinzinger wrote: and let the client verify the servers certificate, like this X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); This only verifies the server's *trust chain*, but not its identity. To properly verify a server, you MUST examine the certificate subjectAltName extensions and if these are missing the CommonName in the subject DN. [2] now a secure connection is established No secure connection is exists unless the client verified the server certificate. on it the server receives data encrypted with the servers public key, so only it can read it in the data is information about the next node and the previous node now the server knows the ssl certificate of the previous node and thus wants to check it, since the verify mode is still set to server only, we set it a new SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); Entirely pointless after the SSL handshake is done. [3] if the server now runs the code above X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); Again this would just verify the trust chain, and say nothing about the client identity. Has anyone an idea, how this could be achieved with the OpenSSL API? You are solving the wrong problem. Forget OpenSSL APIs, ... what actual security goals are you trying to achieve and what is available on the client and server to get you there? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: verify client certificate at a later point
Thank You Ashish for your answer! On Wed, Sep 23, 2009 at 10:30 PM, Ashish Thapliyal ashish.thapli...@citrix.com wrote: I set the following for the global context which is used to create the connection: // Set the SSL certificate verify mode SSL_CTX_set_verify(_globalContext, SSL_VERIFY_PEER, NULL); Then the server requests the peer (i.e. the client) for a certificate during the handshake, which the client can either ignore, or provide. yes I want the client to provide a certificate. this also works, if I set the globalContext like above However at this point the server cannot yet verify the client's certificate. So calling BIO_do_connect(BIO* client_socket) returns -1, because the client certificate could not be verified. The other option is to do a handshake without asking for a client certificate first, then do a re-handshake and ask the client for a certificate when required. Yes this would work. Because later the server will get the client certificate in a secure fashion. So how can I redo the handshake? I do not want to close and open the connection a new, just ask the client again for its certificate. Do you know how to do that? Thank You! Michael Ashish __ Ashish V. Thapliyal, Security Architect, Citrix Online Division, 6500 Hollister Ave, Goleta, CA 93117. V: +1 (805) 690 2908. *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Michael Prinzinger *Sent:* Wednesday, September 23, 2009 1:05 PM *To:* openssl-users@openssl.org *Subject:* verify client certificate at a later point Dear OpenSSL group, I have a somewhat curious setting (without CAs) about routing information along several nodes: [1] first an unkown client establishes a connection to a known server thus I set SSL_CTX_set_verify(this-ctx, SSL_VERIFY_NONE, NULL); and let the client verify the servers certificate, like this X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); [2] now a secure connection is established on it the server receives data encrypted with the servers public key, so only it can read it in the data is information about the next node and the previous node now the server knows the ssl certificate of the previous node and thus wants to check it, since the verify mode is still set to server only, we set it a new SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); [3] if the server now runs the code above X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); x509 will be NULL. This is probably because the handshake has already taken place. So there simply is no client certificate. Now I am trying to find a way around this problem, but failed so far. It would be nice to either find a way that both certificates are exchanged during handshae, but only the server one is verified at first or to find a way to request a certificate from the client at a later point. Has anyone an idea, how this could be achieved with the OpenSSL API? Thank You Very Much! Michael
Re: verify client certificate at a later point
On Wed, Sep 23, 2009 at 10:43:11PM +0200, Michael Prinzinger wrote: I am trying to establish a routing path for an anonymity protocol ( http://en.wikipedia.org/wiki/Phantom_Anonymity_Protocol). This is a one way procedure: the node that wants to be anonymized selects a couple of other nodes and sends an array with setup packages (encrypted with the node's public key) to the first node, it had selectd. Now every such node accepts an anonymous connection from a client, receives this array, decrypts the setup package meant for this node, and finds inside: IP and Certificate of the previous and next node (and some more information unrelated to openssl). Certificates are useless without corresponding signed messages. What messages are signed by the private key of the previous node, that the current node can forward to the next? When establishing a connection to the next node, the current node can thus verify the certificate of the next node. Sure. However, now that the current node also got to know the previous node's certificate in a secure way, it can also verify the previous node's certificate. This makes no sense. What message associated with the previous node do you need to authenticate? Note, the SSL handshake involves the current client signing the SSL handshake, and the certificate binds the client's identity to that signature. Why do you need client identity in an anonymity protocol? What is the security role of the previous node certificate. You are very confused about the requirements. Forget APIs, and programming approaches for now, arrive a sensible protocol description. What is the multi-hop protocol and how/why do you plan to secure it with assymetric cryptography? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
generating RSA keypair with non-standard public exponents
I noted that when generating a RSA public key pair using a non-standard public exponent (particularly, 65538, or 0x01, 0x00,0x02), the RSA_generate_key never returns, and the program keeps using 100% CPU until I kill it. My question is: Is this behavior expected? If some non-standard publ. exponent is problematic, shouldn't we abort with error before attempting to use it? Or, to put it in another way, should the caller validate the public exponent before issuing RSA_generate_key(), to avoid a potential DoS? Thanks, -Klaus -- Klaus Heinrich Kiwi | kla...@br.ibm.com | http://blog.klauskiwi.com Open Source Security blog : http://www.ratliff.net/blog IBM Linux Technology Center : http://www.ibm.com/linux/ltc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: verify client certificate at a later point
Dear Victor, On Wed, Sep 23, 2009 at 11:33 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Sep 23, 2009 at 10:43:11PM +0200, Michael Prinzinger wrote: Certificates are useless without corresponding signed messages. What messages are signed by the private key of the previous node, that the current node can forward to the next? I only want to verify that the previous node is the node it is supposed to be. After decrypting the setup package I have the certificate (and ip) od the correct previous node. This makes no sense. What message associated with the previous node do you need to authenticate? Note, the SSL handshake involves the current client signing the SSL handshake, and the certificate binds the client's identity to that signature. Thanks for explaining. The previous node is supposed to sign the handshake, so the current node can verify the previous node is indeed the node it should be. Since I can only do that after the initial handshake, I have to redo the handshake. Is there an easy way to redo the handshake? Why do you need client identity in an anonymity protocol? What is the security role of the previous node certificate. all routing nodes are chosen by the node that want to stay anonymnous. the whole process is completely decentralized. So there needs to be a lot of security mechanisms to make sure, the packages really traverese the path, the anonymized node has chosen. This includes a verification of the two nodes, such a routing node is connected to. And this verification means: verifying the ip of the previous node and the certificate of it (i.e. verifying that the previous node has the correct certificate private key, fitting the certificate the current node is holding) (i.e. the previous node needs to sign something with its private key (the handshake) so the current node can verify it) You are very confused about the requirements. Forget APIs, and programming approaches for now, arrive a sensible protocol description. What is the multi-hop protocol and how/why do you plan to secure it with assymetric cryptography? I am only implementing the design. The design of the protocol is already very well developed. You will find a link to the white paper on the Wikipedia page: http://en.wikipedia.org/wiki/Phantom_Anonymity_Protocol So yes it really makes sense this way :) (its unorthodox concerning OpenSSL, but still very secure) So I think all I need to do is find a way to redo the handshake, after the connection was already established. only this time the client should sign the handshake, and the server should verify it. Could you provide me some help, how to do this! Thank You Michael -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: generating RSA keypair with non-standard public exponents
From: owner-openssl-us...@openssl.org On Behalf Of Klaus Heinrich Kiwi Sent: Wednesday, 23 September, 2009 15:59 I noted that when generating a RSA public key pair using a non-standard public exponent (particularly, 65538, or 0x01, 0x00,0x02), the RSA_generate_key never returns, and the program keeps using 100% CPU until I kill it. My question is: Is this behavior expected? If some non-standard publ. exponent is problematic, shouldn't we abort with error before attempting to use it? RSA doesn't work if e (or d) has any common factors with phi(m) = IIRC LCM(p-1,q-1). If this happens, the code just tries again. This means there are no p,q for which any even e can work, hence the infinite loop. As mentioned on the man page, BTW. For an e with a factor small but greater than 2, many p,q won't work but some will. Is this a desirable case? I don't know. The popular standard e (3 and 65537) were chosen to be (odd) primes and for the latter the chance of a keygen try failing is tiny. Or, to put it in another way, should the caller validate the public exponent before issuing RSA_generate_key(), to avoid a potential DoS? If you're going to accept e from an untrustworthy source, probably. Or it appears you can use the callback to impose a limit on the number of tries, amount of time, etc. as you consider appropriate. If you allow large e (any significant fraction of the modulus size) it might be a covert channel for the keygen-requestor to leak info (if the requestor is malicious against its owner, apparently not you if you are worried about attacks by the owner against you). I'd also worry whether there is a way for malicious requestor to choose e such that it assists or enables later side-channel attacks against encryptors or verifiers using the resulting publickey, but I don't know enough to analyze for that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: verify client certificate at a later point
Hi Michael, I have not implemented a rehandshake but as I understand, it can be pretty complicated. Searching for OpenSSL rehandshake on google pointed me to this article (http://www.rtfm.com/openssl-examples/part2.pdf) by Eric Rescorla, describing the rehandshake in detail. Hope this helps. Ashish. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Michael Prinzinger Sent: Wednesday, September 23, 2009 2:02 PM To: openssl-users@openssl.org Subject: Re: verify client certificate at a later point Thank You Ashish for your answer! On Wed, Sep 23, 2009 at 10:30 PM, Ashish Thapliyal ashish.thapli...@citrix.commailto:ashish.thapli...@citrix.com wrote: I set the following for the global context which is used to create the connection: // Set the SSL certificate verify mode SSL_CTX_set_verify(_globalContext, SSL_VERIFY_PEER, NULL); Then the server requests the peer (i.e. the client) for a certificate during the handshake, which the client can either ignore, or provide. yes I want the client to provide a certificate. this also works, if I set the globalContext like above However at this point the server cannot yet verify the client's certificate. So calling BIO_do_connect(BIO* client_socket) returns -1, because the client certificate could not be verified. The other option is to do a handshake without asking for a client certificate first, then do a re-handshake and ask the client for a certificate when required. Yes this would work. Because later the server will get the client certificate in a secure fashion. So how can I redo the handshake? I do not want to close and open the connection a new, just ask the client again for its certificate. Do you know how to do that? Thank You! Michael Ashish __ Ashish V. Thapliyal, Security Architect, Citrix Online Division, 6500 Hollister Ave, Goleta, CA 93117. V: +1 (805) 690 2908. From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org] On Behalf Of Michael Prinzinger Sent: Wednesday, September 23, 2009 1:05 PM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: verify client certificate at a later point Dear OpenSSL group, I have a somewhat curious setting (without CAs) about routing information along several nodes: [1] first an unkown client establishes a connection to a known server thus I set SSL_CTX_set_verify(this-ctx, SSL_VERIFY_NONE, NULL); and let the client verify the servers certificate, like this X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); [2] now a secure connection is established on it the server receives data encrypted with the servers public key, so only it can read it in the data is information about the next node and the previous node now the server knows the ssl certificate of the previous node and thus wants to check it, since the verify mode is still set to server only, we set it a new SSL_CTX_set_verify(this-ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); [3] if the server now runs the code above X509* x509 = SSL_get_peer_certificate(s); CHECK(x509 != NULL); //check certificate long certVerifyResults = SSL_get_verify_result(s); if(certVerifyResults != X509_V_OK) throw SSLException(Error! Certificate could not be verified.\n); //free x509 X509_free(x509); x509 will be NULL. This is probably because the handshake has already taken place. So there simply is no client certificate. Now I am trying to find a way around this problem, but failed so far. It would be nice to either find a way that both certificates are exchanged during handshae, but only the server one is verified at first or to find a way to request a certificate from the client at a later point. Has anyone an idea, how this could be achieved with the OpenSSL API? Thank You Very Much! Michael
error:0200274D:system library:connect:reason(1869)?
Hello, I am receiving a 0200274D error when attempting to connect to a linux server. 274D=10061 ECONNREFUSED. Not sure what the reason is 1869? could somebody please tell me. Much appreciated in adavance. Thanks, Garyc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
