Hi - HTTPD Configuration with MOD SSL
Hi, I want to enable HTTPD to support multi-layer certificates (ca chain). I had 2 options Option 1: We can configure SSLCertificateFile (EE file) and SSLCertificateChainFile (CA Chain) Option 2: We can configure SSLCertificateFile (EE+CA Chain) When we tested we found that Option 2 worked and Option 1 did not. Any idea if I have missed anything in Option 1 or how to make Option 1 work HTTP version Is 2.2.3 Regards Srini
OpenSSL for Linux
Hi, We are using openssl1.0.0g for windows. But when we tried to use same for linux, we are running into issue while compiling SSL module. And we found that the issue in Apache2.0.63 and openssl1.0.0g integration http://serverfault.com/questions/159883/installing-apache-with-openssl https://issues.apache.org/bugzilla/show_bug.cgi?id=49034 https://issues.apache.org/bugzilla/show_bug.cgi?id=47578 So we used openssl0.9.8s and its working fine. Can we use 0.9.8s for Linux? Is there any vulnerability in openssl0.9.8s? Regards, Riyaz
How to resume the TLS session
Hi All, Please let me know if there is an API that will resume the session without going through the handshake process again ( the session might have broken down due to unplugging of LAN cable etc) Thanks, Gayathri
Recall: OpenSSL for Linux
Mohamed Riyazudeen Kandrath Mohamed Ibrahim would like to recall the message, OpenSSL for Linux. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL for Linux
Hi, We are using openssl1.0.0g for windows. But when we tried to use same for Linux, we are running into issue while compiling SSL module. And we found that the issue in Apache2.0.63 and openssl1.0.0g integration http://serverfault.com/questions/159883/installing-apache-with-openssl https://issues.apache.org/bugzilla/show_bug.cgi?id=49034 https://issues.apache.org/bugzilla/show_bug.cgi?id=47578 So we used openssl0.9.8s and its working fine. Can we use 0.9.8s for Linux? Is there any vulnerability in openssl0.9.8s? Regards, Riyaz
OpenSSL FIPS Object Module v1.2
Hello, I searched the archives but did not find the answer to this question. What is the reason OpenSSL FIPS Object Module v1.2 is no longer listed as FIPS validated? It seems only v1.2.3 is now listed: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2008.htm#1051 Thanks in advance! -Ashit
RE: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
Thanks for the response, I'm trying to allow end-users to use commercially purchased certificates so I'd rather not make the assumption that the key is exportable. Using the capi engine sounds like a viable alternative, but I've had trouble tracking down details on how to use it. Unfortunately I have a few restrictions; we're fips-certified on openssl 0.98n so that's the version I'm stuck with (without recertifying). I also want to use the crypto api directly to tell it which certificate to load and use (i.e. user configurable through a gpo setting) and then have the engine use that certificate for the ssl handshake to the peer. I've read the O'Reilly section on Engines but it's pretty rudimentary and doesn't touch the capi engine, do you have a pointer to any user documentation that might have some examples on using the capi engine? Thanks again ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: March 7, 2012 5:52 PM To: openssl-users@openssl.org Subject: Re: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop On Wed, Mar 07, 2012, Nou Dadoun wrote: I'm trying to develop a package which can establish an ssl connection between a windows server and a client using openssl and I'm running into some serious road blocks - I'm a relative novice at both the openssl and wincrypt apis, I've done extensive searching for any hints at how this problem might be solved but I haven't found anything similar which might be applicable. Here's a high-level description: On the server side, I'm using both openssl and the windows crypto api, I use the windows crypto api to access the windows certificate store and search for and load the certificate (with its private key) that I'm interested in using. I spent some time trying to extract the private key to use in openssl directly but discovered that the windows crypto api refuses to let go of it in a form that openssl can use directly. So I'm using the openssl RSA_set_method facility to replace the private key decrypt method (rsa_priv_dec) to pass off the heavy lifting to the cryptoapi (this seems like a reasonable thing to do and the kind of thing that would be done with a smart card or TCM or something where there's no direct access to the private key). I tell openssl to use the x509 encoding of the loaded certificate for incoming connections and wait. When a client SSL HELLO comes in, the server presents the x509 certificate, the client uses the public key in the certificate to encrypt its secret and sends the response to the server to decrypt with the private key. The server receives the response, my replaced method kicks in and tries to decrypt the 128-byte response using CryptDecrypt with the private key and fails with NTE_BAD_DATA (pretty opaque and not very informative). So the connection fails. I've done some unit testing on the api's and I can encrypt/decrypt sample messages using CryptEncrypt and CryptDecrypt, but anything that I've encrypted with RSA_public_encrypt gives me the same NTE_BAD_DATA error when I hand it to (private key) CryptDecrypt. I've extracted the PUBLICKEYBLOB to get the windows representation of the public key and I can see that the key bytes are in reverse order of the public key portion of the x509 certificate. I've read that the crypto api uses little-endian as opposed to everybody else's big-endian but (perhaps foolishly) assumed that that difference was only an internal representation issue, that something encrypted by openssl should be decryptable by CryptoAPI (I tried reversing the bytes of the encrypted message too and that didn't work.) So I'm a little stymied, am I missing some secret sauce somewhere? If openssl had an api to load certificates from windows cert stores that would be an alternate route but it seems as though this mechanism of using CryptoApi to handle the certificate access/management shouldn't be as difficult as it seems. And surely the interop problem I'm experiencing can't be unique to my setup. Anyone have any suggestions? I can post code on request but thought I'd start with a high-level description of the problem to avoid clouding the issue too much. If windows can export the key and certificate as a PKCS#12 (PFX) file you can use that with OpenSSL. If the key is unexportable you can't. OpenSSL has a CryptoAPI ENGINE you can use and that will handle the conversion between formats for you. It is supported on the command line which you can use as a test. 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
Re: OpenSSL FIPS Object Module v1.2
On 03/08/2012 01:43 PM, Ashit Vora wrote: Hello, I searched the archives but did not find the answer to this question. What is the reason OpenSSL FIPS Object Module v1.2 is no longer listed as FIPS validated? It seems only v1.2.3 is now listed: That's because the original validation #1051 has been extended to include additional platforms. Each such extension resulting in a change to the software (each set of extensions, actually) results in an incremented module revision number, now at 1.2.3. The functionality of revision 1.2.3 completely subsumes that of prior revisions, hence reference to those has been dropped. There is no reason to use any earlier revisions for any new product development or deployment, but deployed instances of earlier revisions remain valid. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
Thanks Steve. This makes sense (i.e. newer versions subsuming older versions). However given that 1.2 is no longer listed on the NIST website, that version can no longer be considered FIPS validated. This is an issue for deployed products that have depended on v1.2 for FIPS compliance. -Ashit On Thu, Mar 8, 2012 at 3:46 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 03/08/2012 01:43 PM, Ashit Vora wrote: Hello, I searched the archives but did not find the answer to this question. What is the reason OpenSSL FIPS Object Module v1.2 is no longer listed as FIPS validated? It seems only v1.2.3 is now listed: That's because the original validation #1051 has been extended to include additional platforms. Each such extension resulting in a change to the software (each set of extensions, actually) results in an incremented module revision number, now at 1.2.3. The functionality of revision 1.2.3 completely subsumes that of prior revisions, hence reference to those has been dropped. There is no reason to use any earlier revisions for any new product development or deployment, but deployed instances of earlier revisions remain valid. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net
Re: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
On Thu, Mar 08, 2012, Nou Dadoun wrote: Thanks for the response, I'm trying to allow end-users to use commercially purchased certificates so I'd rather not make the assumption that the key is exportable. Using the capi engine sounds like a viable alternative, but I've had trouble tracking down details on how to use it. Unfortunately I have a few restrictions; we're fips-certified on openssl 0.98n so that's the version I'm stuck with (without recertifying). I also want to use the crypto api directly to tell it which certificate to load and use (i.e. user configurable through a gpo setting) and then have the engine use that certificate for the ssl handshake to the peer. I've read the O'Reilly section on Engines but it's pretty rudimentary and doesn't touch the capi engine, do you have a pointer to any user documentation that might have some examples on using the capi engine? If you need all crypto to be FIPS compliant (for some value of compliant) that's a can of worms because the relevant CSPs might not be and you'd be mixing various cryptographic operations across boundaries. 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: Tutorials on OpenSSL integration with nCipher HSM (nShield) ?
Hi Sander, Thank you for your elaborate response. It has helped me a great deal. A follow-up question- fookey fookey_certreq fookey_selfcert The first one looks a lot like a private key, but it is a dummy key. This is the key file you pass to the OpenSSL library. It looks so much like a private key, that the library will just use it. However, when you use it with the CHIL engine registered, and the Hardware Crypto Hook library loaded, the Hardware Crypto Hook library will find embedded (hence 'embed') in the private exponent value for that dummy key a pointer to the real key, protected by the nCipher Security World and saved under the Key Management Data folder. I try loading the private key 'fookey' using - ENGINE_load_private_key( e, fookey, NULL, NULL ); but it fails. This key was generated like you said, to be of application type embed. However, if I try to load a key of type hwcrhk, it succeeds with no changes to the rest of the code. (Still using CHIL engine, and as a pre-command to the engine I've set SO_PATH to be the location of the hwcrhk dll). The other part- SSL_CTX_use_certificate_chain_file( sslCtx, PATH_TO_fookey_selfcert ); seems to be working as the function returns a value of 1. 2. My private key is ultimately protected by a smart-card pass-phrase. At which step is the pass phrase supplied and how by an application that is making use of the OpenSSL (CHIL) engine API? OpenSSL, CHIL and the Hardware Crypto Hook library lack the capability to prompt for smart cards and passphrases. You need to start your OpenSSL program out of the nCipher preload utility. Run preload --help to find out which options are available. So I'm using module-protected keys for now. But later on once I want to use card-protected keys, I'll look into the pre-commands or post-commands for specifying the passphrase to the engine. Note that you can contact Thales technical support as part of your support contract. They also sell Developer Support to help you with your code. I tried, but this seems to be faster and more effective :) Thanks again, Sunjeet
Re: Tutorials on OpenSSL integration with nCipher HSM (nShield) ?
None of the above ;-) If you have the CHIL ENGINE you load a private key using ENGINE_load_private_key() and pass the appropriate ENGINE pointer and the name of the key which will presumably be rsa-test. That will get you an EVP_PKEY pointer which you can pass to SSL_CTX_use_PrivateKey(). Thank you for your response Stephen. As I write in my other recent post, I am having some trouble with using SSL_CTX_use_PrivateKey() on the private key of application type embed but it seems to work for the private key of type hwcrhk. I'm using CHIL engine with the SO_PATH configured to be the location of hwcrhk dll. Any ideas why? Thanks much, Sunjeet __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
1.0.1beta1, incompatibility with gnutls?
I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Openssl 0.9.8h works just fine though. Is this a known issue? ./openssl s_server -key src/data/server.key -cert src/data/server.crt -tlsextdebug Using default temp DH parameters Using default temp ECDH parameters ACCEPT TLS client extension unknown (id=9), len=3 - 02 00 01 ... TLS client extension server name (id=0), len=14 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1 ERROR 4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported extension:s3_pkt.c:1240:SSL alert number 110 shutting down SSL CONNECTION CLOSED ACCEPT David Holmes | Technical Marketing Manager - Security F5 Networks P 206.272. F 206.272.5556 www.f5.com D 206.272.6740 Follow @dholmesf5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
On 03/08/2012 04:05 PM, Ashit Vora wrote: Thanks Steve. This makes sense (i.e. newer versions subsuming older versions). However given that 1.2 is no longer listed on the NIST website, that version can no longer be considered FIPS validated. This is an issue for deployed products that have depended on v1.2 for FIPS compliance. Well, I disagree. Though I will be the first to note that only the CMVP is in a position to make any authoritative pronouncements. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
On 03/08/2012 05:12 PM, Steve Marquess wrote: On 03/08/2012 04:05 PM, Ashit Vora wrote: Thanks Steve. This makes sense (i.e. newer versions subsuming older versions). However given that 1.2 is no longer listed on the NIST website, that version can no longer be considered FIPS validated. This is an issue for deployed products that have depended on v1.2 for FIPS compliance. Well, I disagree. Though I will be the first to note that only the CMVP is in a position to make any authoritative pronouncements. I should also point out that the certificate still references the original revision number 1.2: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1051.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
Regarding the certificate, it will never be updated. Whenever the CMVP updates a listing because of a change letter process (IG G.5 scenario 1) they only update the website listing. They never update the certificate. The understanding is that the website listing supersedes the certificate. Please see CMVP FAQ ( http://csrc.nist.gov/groups/STM/cmvp/documents/CMVPFAQ.pdf) section 5.9, If the CMVP validation web site does not match the posted certificate, which is valid?: * When a module is validated, an entry is posted on the CMVP web site valuation list along with a softcopy of the initial printed validation certificate. The hardcopy validation certificate is for informational purposes only. The CMVP web site validation list is the official source of validation information in reference to the module. If changes are made to the module that would change the referenced certificate information, only the web site validation list is updated.* Also note that the security policy that is currently linked to on the website only mentions 1.2.3 as the validated module. There is no mention 1.2. All of this points to the conclusion that 1.2 is not FIPS validated currently. If the intention was to not remove 1.2, I would highly recommend contacting your FIPS laboratory and getting it changed. It would be quite simple to change this. My suspicion is that when the laboratory submitted the change letter they forgot to include 1.2 in the list of changes required to the validation. As such CMVP removed 1.2 listing. Thanks! -Ashit On Thu, Mar 8, 2012 at 5:32 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 03/08/2012 05:12 PM, Steve Marquess wrote: On 03/08/2012 04:05 PM, Ashit Vora wrote: Thanks Steve. This makes sense (i.e. newer versions subsuming older versions). However given that 1.2 is no longer listed on the NIST website, that version can no longer be considered FIPS validated. This is an issue for deployed products that have depended on v1.2 for FIPS compliance. Well, I disagree. Though I will be the first to note that only the CMVP is in a position to make any authoritative pronouncements. I should also point out that the certificate still references the original revision number 1.2: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1051.pdf -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net
Re: 1.0.1beta1, incompatibility with gnutls?
On 03/08/2012 11:05 PM, David Holmes wrote: I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Openssl 0.9.8h works just fine though. Is this a known issue? 127.0.0.1 is not a valid servername. I don't remember but you might want to play with the servername parameter of s_server. ./openssl s_server -key src/data/server.key -cert src/data/server.crt -tlsextdebug Using default temp DH parameters Using default temp ECDH parameters ACCEPT TLS client extension unknown (id=9), len=3 - 02 00 01 ... TLS client extension server name (id=0), len=14 - 00 0c 00 00 09 31 32 37-2e 30 2e 30 2e 31 .127.0.0.1 ERROR 4150167176:error:14094456:SSL routines:SSL3_READ_BYTES:tlsv1 unsupported extension:s3_pkt.c:1240:SSL alert number 110 shutting down SSL CONNECTION CLOSED ACCEPT David Holmes | Technical Marketing Manager - Security F5 Networks P 206.272. F 206.272.5556 www.f5.com D 206.272.6740 Follow @dholmesf5 __ 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: 1.0.1beta1, incompatibility with gnutls?
On Thu, Mar 08, 2012, David Holmes wrote: I'm trying to use openssl 1.0.1beta1 s_server with gnutls 2.4.1 (gnutls-cli). s_server is complaining of an unknown extension (see debug output below). Openssl 0.9.8h works just fine though. Is this a known issue? There was an issue relating to heartbeats in beta1, try beta3. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
On 03/08/2012 06:09 PM, Ashit Vora wrote: Regarding the certificate, it will never be updated. Whenever the CMVP updates a listing because of a change letter process (IG G.5 scenario 1) they only update the website listing. They never update the certificate. The understanding is that the website listing supersedes the certificate. Please see CMVP FAQ (http://csrc.nist.gov/groups/STM/cmvp/documents/CMVPFAQ.pdf) section 5.9, If the CMVP validation web site does not match the posted certificate, which is valid?: / When a module is validated, an entry is posted on the CMVP web site valuation list along with a softcopy of the initial printed validation certificate. The hardcopy validation certificate is for informational purposes only. The CMVP web site validation list is the official source of validation information in reference to the module. If changes are made to the module that would change the referenced certificate information, only the web site validation list is updated./ Also note that the security policy that is currently linked to on the website only mentions 1.2.3 as the validated module. There is no mention 1.2. It is mentioned: ...The v1.2.3 Module can be used in any environment supported by the earlier v1.2 Module.. I can see where you may have been confused by that and the statement Note that the OpenSSL FIPS Object Module v1.2.3 completely replaces the earlier OpenSSL FIPS Object Module v1.2., but those refers to the functional completeness of the modified module (the fact that there is no OE for which only an earlier revision works); *not* the legitimacy of the original validation. All of this points to the conclusion that 1.2 is not FIPS validated currently. Sorry, I still disagree. Of course the certificate isn't updated, that was my point (and now no individual certificate is issued at all). A change letter mod is an update to an existing validation, not a new validation. Only the new changed element(s) are considered and previous validation review and testing is not repeated. For instance, the most recent mod was to add two new platforms. None of the prior OE testing, or source code or document review was repeated, because all of that prior testing remains valid. Ditto for the earlier mods. By your theory all of the hundreds of thousands (millions...?) of deployed instances of the 1.2, 1.2.1, 1.2.2 modules have retroactively become illegitimate -- a significant fraction of all deployed FIPS 140-2 validated software. I do not believe that is the case and I leave it to you to prove otherwise by filing an objection with the CMVP (yes, anyone can challenge the legitimacy of our validations and that was in fact done a number of times for the early OpenSSL FIPS Object Module Validations). If the intention was to not remove 1.2, I would highly recommend contacting your FIPS laboratory and getting it changed. It would be quite simple to change this. My suspicion is that when the laboratory submitted the change letter they forgot to include 1.2 in the list of changes required to the validation. As such CMVP removed 1.2 listing. We did not forget anything, for any of the change letter mods (via multiple labs, incidentally). The updates were all carefully designed to be strictly cumulative, differing only in the addition of new OEs with newer revisions subsuming but not invalidating earlier ones. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module v1.2
Steve, First let me clarify that it isn't my intent to challenge OpenSSL validation. In fact the reason I started down this path is because I have a product that uses v1.2 and needs to claim FIPS compliance. I cannot legitimately make that claim if v1.2 is not listed. However I have sent a query to CMVP to get clarification. If CMVP says I am mistaken, I will be extremely happy. In the meantime, your response did not address the CMVP FAQ I pointed to which backs up what I am saying. I am reproducing it here again: ***When a module is validated, an entry is posted on the CMVP web site valuation list along with a softcopy of the initial printed validation certificate. The hardcopy validation certificate is for informational purposes only. The CMVP web site validation list is the official source of validation information in reference to the module. If changes are made to the module that would change the referenced certificate information, only the web site validation list is updated. *This clearly indicates that the CMVP website is the official source of validation information. This infers that the version listed on the validation website is the validated version. Do you interpret this differently? Thanks! -Ashit On Thu, Mar 8, 2012 at 6:49 PM, Steve Marquess marqu...@opensslfoundation.com wrote: On 03/08/2012 06:09 PM, Ashit Vora wrote: Regarding the certificate, it will never be updated. Whenever the CMVP updates a listing because of a change letter process (IG G.5 scenario 1) they only update the website listing. They never update the certificate. The understanding is that the website listing supersedes the certificate. Please see CMVP FAQ (http://csrc.nist.gov/groups/STM/cmvp/documents/CMVPFAQ.pdf) section 5.9, If the CMVP validation web site does not match the posted certificate, which is valid?: / When a module is validated, an entry is posted on the CMVP web site valuation list along with a softcopy of the initial printed validation certificate. The hardcopy validation certificate is for informational purposes only. The CMVP web site validation list is the official source of validation information in reference to the module. If changes are made to the module that would change the referenced certificate information, only the web site validation list is updated./ Also note that the security policy that is currently linked to on the website only mentions 1.2.3 as the validated module. There is no mention 1.2. It is mentioned: ...The v1.2.3 Module can be used in any environment supported by the earlier v1.2 Module.. I can see where you may have been confused by that and the statement Note that the OpenSSL FIPS Object Module v1.2.3 completely replaces the earlier OpenSSL FIPS Object Module v1.2., but those refers to the functional completeness of the modified module (the fact that there is no OE for which only an earlier revision works); *not* the legitimacy of the original validation. All of this points to the conclusion that 1.2 is not FIPS validated currently. Sorry, I still disagree. Of course the certificate isn't updated, that was my point (and now no individual certificate is issued at all). A change letter mod is an update to an existing validation, not a new validation. Only the new changed element(s) are considered and previous validation review and testing is not repeated. For instance, the most recent mod was to add two new platforms. None of the prior OE testing, or source code or document review was repeated, because all of that prior testing remains valid. Ditto for the earlier mods. By your theory all of the hundreds of thousands (millions...?) of deployed instances of the 1.2, 1.2.1, 1.2.2 modules have retroactively become illegitimate -- a significant fraction of all deployed FIPS 140-2 validated software. I do not believe that is the case and I leave it to you to prove otherwise by filing an objection with the CMVP (yes, anyone can challenge the legitimacy of our validations and that was in fact done a number of times for the early OpenSSL FIPS Object Module Validations). If the intention was to not remove 1.2, I would highly recommend contacting your FIPS laboratory and getting it changed. It would be quite simple to change this. My suspicion is that when the laboratory submitted the change letter they forgot to include 1.2 in the list of changes required to the validation. As such CMVP removed 1.2 listing. We did not forget anything, for any of the change letter mods (via multiple labs, incidentally). The updates were all carefully designed to be strictly cumulative, differing only in the addition of new OEs with newer revisions subsuming but not invalidating earlier ones. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.net
Via Padlock Engine Performance
I just put together a mini workstation intended to run a VPN gateway/firewall that uses a Via Nano X2 CPU. From what I've read, Padlock (Via's hardware encryption) support should be working out of the box. So, I set out to benchmark the engine on 32-bit Ubuntu 10.04 using their default OpenSSL 0.9.8k package with the following commands: openssl speed -evp aes-128-cbc ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 76686.88k 192106.28k 260108.93k 322961.41k 372782.58k openssl speed -evp aes-128-cbc -engine padlock engine padlock set. ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 76391.00k 191907.86k 259815.42k 323360.43k 373239.07k Bummer... no real difference. I decided to try out a newer version of OpenSSL just for the heck of it, so I downloaded and compiled version 1.0.1 beta 3 and ran the tests again. I saw slightly better performance (which was nice to see), but still no difference between the two commands. So my first question: is this the correct way to try and benchmark the difference between the Padlock engine and pure software encryption? I later decided to try and be adventurous... I ported and applied Michal Ludvig's SHA patch (http://www.logix.cz/michal/devel/padlock/) to the 1.0.1 beta 3 source, recompiled, and re-tested. The results: openssl speed -evp aes-128-cbc ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 89220.56k 278624.69k 552093.53k 731517.95k 808315.56k openssl speed -evp aes-128-cbc -engine padlock engine padlock set. ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 89284.97k 278373.91k 552335.96k 734417.27k 807966.04k It's nice to see the speed up, but still no difference between the two commands. I then decided to configure OpenSSL without Padlock support by running ./Configure no-hw-padlock linux-elf. I verified with openssl engine that Padlock did not show up as an available engine. The result with Padlock support not compiled into OpenSSL: openssl speed -evp aes-128-cbc ... type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 54053.36k64930.07k68002.22k69331.65k69695.44k That definitely dropped performance. And my second question: was that a fair test with Padlock removed or did my configure command change something else that would've skewed the results to look this poor? Thanks in advance for any help you can provide! -- Kyle Dodson kyledod...@gmail.com (Email) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Please Clarify : Unable to verify leaf signature (21)
From: owner-openssl-us...@openssl.org On Behalf Of Mr.Rout Sent: Wednesday, 07 March, 2012 05:33 While setting up the TLS session i am facing below error. TLS Alert Level: Fatal, Description: Unable to verify leaf signature (21) I created the Chained certfificate like below : ROOTCAServerCA-ServerCert I kept ROOTCA at my TLS client and cancatenated version of all the above certs (cat ROOTCA.pem ServerCA.pem Servercert.pem server.pem Is your server using OpenSSL? I'm assuming it probably is since you ask here, but you didn't say so. If so it can't be using that particular server.pem file, because you would never get as far as a handshake if you give OpenSSL either a cert-file or a chain-file with the root cert (or any cert other than the entity cert) first. Assuming OpenSSL, you have two choices, depending on what the program does (or you change it to do). 1. concatenate the server cert, then the intermediate cert (all of them if more than one), then optionally the root cert, in PEM format in a file and have the program specify that file to _use_certificate_chain_file NOT _use_certificate_file. 2. have the program call _use_certificate_file with a file (PEM or DER) containing the server cert (and optionally the server key if you use the same file for _use_PrivateKey_file) AND ALSO put the intermediate cert(s) and optionally root cert in the server's local truststore, which can be any of: 2A. a concatenated PEM file the program gives to _load_verify_locations 2B. separate PEM files in a directory with hash names ditto 2C,2D. a concatenated file, or directory of hashnamed files, that are the defaults for the build of OpenSSL you are using, typically something like /etc/ssl/certs[/cacerts.pem] and the program calls _set_default_verify_paths. A server-specific truststore (2A,2B) may already exist if the server does client-authentication, otherwise likely not. You may include the root in the chain-file (1) or truststore (2) but don't need to; the client must always use a locally stored copy (which you say it has) and ignore any the server sends. In (2) you often do want the root in the truststore, especially the default one, for other uses. In (1) it's up to you. Technically there is a third alternative: you can put the intermediate(s) (and root) in each client's truststore, and then the server doesn't need to send it(them). This is usually more difficult, and for a public server usually impossible. For client-auth if used (which is rare) repeat above with client and server swapped. Note: When its 2nd level chained certs then i am facing the issue where as for 1-level chained (i.e. CA signed cert) i donot see this issue. For your '1-level' no intermediate exists for the above to apply to. Self-signed is a bit different but you didn't ask about that. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
