Windows certificate store support
Hi, I am new to openssl and is facing with the following dilemma. A server application needs to read certificates and private keys from the windows certificate store for establishing SSL connection with the clients. Can anyone tell whether openssl supports/ have interfaces for accessing certificates from windows certificate store? -- Regards, Sreekanth
Re: Windows certificate store support
Hi, For access to the windows store, openssl provides the CAPI engine. I've looked into this recently, because I needed the same support for loading server side certificates with CAPI engine, but unfortunately, I learned that there is no support for this in an official release of openssl (I still hope I'm wrong :) ). There is a patch for this on the openssl dev list: http://rt.openssl.org/Ticket/Display.html?id=2463user=guestpass=guest Anyway, as I said, I don't think that this code got into an official release... Regards! From: Sreekanth Sukumaran sree...@gmail.com To: openssl-users@openssl.org Sent: Tuesday, February 5, 2013 11:56 AM Subject: Windows certificate store support Hi, I am new to openssl and is facing with the following dilemma. A server application needs to read certificates and private keys from the windows certificate store for establishing SSL connection with the clients. Can anyone tell whether openssl supports/ have interfaces for accessing certificates from windows certificate store? -- Regards, Sreekanth
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [05 Feb 2013] SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing differences arising during MAC processing. Details of this attack can be found at: http://www.isg.rhul.ac.uk/tls/ All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x Note: this vulnerability is only partially mitigated when OpenSSL is used in conjuction with the OpenSSL FIPS Object Module and the FIPS mode of operation is enabled. Thanks go to Nadhem J. AlFardan and Kenneth G. Paterson of the Information Security Group Royal Holloway, University of London for discovering this flaw. An initial fix was prepared by Adam Langley a...@chromium.org and Emilia Käsper ekas...@google.com of Google. Additional refinements were added by Ben Laurie, Andy Polyakov and Stephen Henson of the OpenSSL group. Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y TLS 1.1 and 1.2 AES-NI crash (CVE-2012-2686) = A flaw in the OpenSSL handling of CBC ciphersuites in TLS 1.1 and TLS 1.2 on AES-NI supporting platforms can be exploited in a DoS attack. If you are unsure if you are using AES-NI see References below. Anyone using an AES-NI platform for TLS 1.2 or TLS 1.1 on OpenSSL 1.0.1c is affected. Platforms which do not support AES-NI or versions of OpenSSL which do not implement TLS 1.2 or 1.1 (for example OpenSSL 0.9.8 and 1.0.0) are not affected. Thanks go to Adam Langley a...@chromium.org for initially discovering the bug and developing a fix and to Wolfgang Ettlingers wolfgang.ettlin...@gmail.com for independently discovering this issue. Affected users should upgrade to OpenSSL 1.0.1d OCSP invalid key DoS issue (CVE-2013-0166) A flaw in the OpenSSL handling of OCSP response verification can be exploitedin a denial of service attack. All versions of OpenSSL are affected including 1.0.1c, 1.0.0j and 0.9.8x This flaw was discovered and fixed by Stephen Henson of the OpenSSL core team. Affected users should upgrade to OpenSSL 1.0.1d, 1.0.0k or 0.9.8y. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20130204.txt Wikipedia AES-NI description: http://en.wikipedia.org/wiki/AES-NI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBURETXqLSm3vylcdZAQLE2QgAuHTRN3khjkmt/NRS4hg/mT+YRD+aJMsU mhCoqYvVuW0GVJHCY4yiBUoj0bgTfwWyazQRaWSFX8ewc/mHqNKYoVBSczb9nxqZ Kh41maLcKGMHtDNQlb5bINa95+9Ix9+J9Izdd7dWycpApN/azCV+r/kkXVArAq8J jYZ5Wl7PtSELArAtN5R56TgmSpcZvnIkqm7dV9rkJZGE9PBXskiLJjozWqPHgvQC HcAXNuAgrWJjuCKimictGoC0gP+tmF7tMIqYKT8/16qAqWs4vBk/Z0rxpQ4wV6pU 6jWjcFL+dVQm/59RKtYwsnBPmXgH9zg7kS2y0xcHTWJG3EKucxe8zQ== =BgHn -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Sign public key without having CSR or private key?
On 07.07.2012 23:27, Dr. Stephen Henson wrote: I added an option -force_pubkey to the OpenSSL 'x509' utility to do this. It is only in HEAD at present. Hi Steve, that's excellent! If I am not mistaken, this is exactly what one would also need in order to use the pubkey in individually trusted S/MIME-Certs when the issuing CA is categorically untrusted. One could simply create a cert for local use in encryption/signature-validation from one's own trusty CA. Are there any plans to include your patch in vanilla openssl anytime soon? Thanks, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Sign public key without having CSR or private key?
On Tue, Feb 05, 2013, Michael Ionescu wrote: On 07.07.2012 23:27, Dr. Stephen Henson wrote: I added an option -force_pubkey to the OpenSSL 'x509' utility to do this. It is only in HEAD at present. Hi Steve, that's excellent! If I am not mistaken, this is exactly what one would also need in order to use the pubkey in individually trusted S/MIME-Certs when the issuing CA is categorically untrusted. One could simply create a cert for local use in encryption/signature-validation from one's own trusty CA. There are problems with that approach. In the case of PKCS#7 certificates are identified by issuer name and serial number not public key. So a new CA wouldn't be recognised as it would have a different name. In the case of CMS you can identify the certificate by key identifier: but you'd have to make sure the SKID extension of the new certificate matched the old one. Are there any plans to include your patch in vanilla openssl anytime soon? It can be backported to OpenSSL 1.0.2 easily enough. Due to the versioning rules it can't appear in anything sooner. 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: Client Random
On 2/5/2013 12:05 PM, Thulasi wrote: Hello all, ** This is not regarding OpenSSL software but about the protocol in general. I am trying to understand the use of 32 byte(4 byte data + 28 byte rand) client random which is part of Client Hello. I understand that Server Random is required to avoid replay attacks by making server to dynamically contribute in the derivation of session keys along with Pre-master-secret chosen by Client, but what additional security is derived from Client Random? The same benefits, but seen from the other end. Server random protects the server from being attacked with replays of client packets, amongst other benefits. Client random protects the client from being attacked with replays of server packets, amongst other benefits. Simple, really. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Bad threading of OpenSSL security advisories on the mail lists
When OpenSSL issues security advisories, two unfortunate details make it hard to receive them through the mail lists: 1. All the advisories have the *exact* same subject, causing many mail clients to incorrectly thread them as responses to previous security advisories. Suggested solution: Include the date or other identifier field in the e-mail subject, just as is already done in the first line of the advisory text. 2. For some reason, the mail list software causes double sending of the advisories to users who are subscribed (with the same e-mail address) to more than one of the mail lists (such as -users and -announce), you may want to look for ways to make the mail list software be a bit smarter about cross-posted messages in general, and if the smarts are already in the mail list software, then check if the way advisories are cross posted defeats this code in an avoidable way. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client Random
Thanks Jakob. But still, it is not clear to me. If server random is not present, a malicious user can copy all the messages from client and can replay them multiple times leading to DoS attack. But even if client random is not present, I believe, attacker cannot replay messages from server side as client is going to choose the pre-master-secret. i.e attacker cannot replay any encrypted record as he will not be able to decrypt the pre-master-secret encrypted by server's public key and so, cannot generate the session key. Am I still missing something trivial? Thanks, Thulasi. On 5 February 2013 21:21, Jakob Bohm jb-open...@wisemo.com wrote: On 2/5/2013 12:05 PM, Thulasi wrote: Hello all, ** This is not regarding OpenSSL software but about the protocol in general. I am trying to understand the use of 32 byte(4 byte data + 28 byte rand) client random which is part of Client Hello. I understand that Server Random is required to avoid replay attacks by making server to dynamically contribute in the derivation of session keys along with Pre-master-secret chosen by Client, but what additional security is derived from Client Random? The same benefits, but seen from the other end. Server random protects the server from being attacked with replays of client packets, amongst other benefits. Client random protects the client from being attacked with replays of server packets, amongst other benefits. Simple, really. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __**__**__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS Object Module and FIPS Capable Library Combinations?
Hi All, This relates to 'OpenSSL Security Advisory [05 Feb 2013]' and the accompanying CVEs. The bulletin did not address combinations of FIPS Object Module and FIPS Capable Library Combinations. Please forgive my ignorance. I don't like to take a lot of latitude or license on these things. I'm trying to determine (1) what does OpenSSL recommend/require, and (2) what do I have to [possibly] fix in the field. Is it permissible to use openssl-1.0.1d.tar.gz with openssl-fips-2.0.1.tar.gz? Or should we be using openssl-fips-2.0.2.tar.gz? If we are only using cryptography from libcrypto.a - and not ssl/tls from libssl.a - is openssl-1.0.1c.tar.gz still permissible to use? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
1.0.1d
Thanks for the new release, and all the ongoing work. How does the release relate to the source under git as viewed through http://git.openssl.org/gitweb/ ? I don't see any mention of 1.0.1d in there, and the latest change in 1_0_1-stable was 13 days ago. Is the web view of the repository lagging behind, or is the real source tree currently elsewhere? Can we assume that all changes in 1_0_1-stable in git as of 13 days ago are present in the 1.0.1d release? A minor point (something I assume hasn't been got to yet) the ChangeLog at http://www.openssl.org/news/changelog.html is out of date, doesn't mention all the 1.0.1d changes mentioned in the tarball's CHANGES. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
fipslink
Does anyone have a windows make file that uses fipslink to build an executable that they can forward to me? Alternatively a Visual Studio project that uses that would also help? The smaller and simpler the project the better. I'm trying to build a windows executable that uses the fips libraries and I think I'm not using this utility correctly. I'm stuck with linker errors. Thanks, -Jon Evers Live customer support is available 24/7/365 from the U.S. for all customers worldwide and locally in other countries. Find out more at www.go2vanguard.com. Enable Yourself Learn more about Vanguard zSecurity University training classes offered online, on-demand by request, or in a traditional classroom setting in cities worldwide. www.go2vanguard.com This e-mail and any attachments are intended solely for the use of the addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination of this e-mail or any attachments is strictly prohibited. If you have received this e-mail in error, please do not read this email, please delete all copies of this e-mail and any attachments and notify the sender immediately. Thank you.
Re: FIPS Object Module and FIPS Capable Library Combinations?
On 02/05/2013 03:11 PM, Jeffrey Walton wrote: Hi All, This relates to 'OpenSSL Security Advisory [05 Feb 2013]' and the accompanying CVEs. The bulletin did not address combinations of FIPS Object Module and FIPS Capable Library Combinations. Please forgive my ignorance. I don't like to take a lot of latitude or license on these things. I'm trying to determine (1) what does OpenSSL recommend/require, and (2) what do I have to [possibly] fix in the field. Is it permissible to use openssl-1.0.1d.tar.gz with openssl-fips-2.0.1.tar.gz? Or should we be using openssl-fips-2.0.2.tar.gz? If we are only using cryptography from libcrypto.a - and not ssl/tls from libssl.a - is openssl-1.0.1c.tar.gz still permissible to use? There are two separate issues here, that of FIPS 140-2 validation and that of defense against malicious compromise. The two are quite distinct and in fact mutually exclusive to a significant extent. The #1747 validation is applicable to any of openssl-fips-2.0.tar.gz, openssl-fips-2.0.1.tar.gz, openssl-fips-2.0.2.tar.gz and (soon) openssl-fips-2.0.3.tar.gz when used with any version of OpenSSL 1.0.1. If your primary objective is satisfying a requirement for FIPS 140-2 validated cryptography then use any of those combinations and you're golden. But... The mitigation of the Lucky 13 TLS vulnerability recently added to OpenSSL 1.0.1d is unfortunately only partially effective when OpenSSL is built with the fips option to include the OpenSSL FIPS Object Module, and the FIPS mode of operation is enabled. That is because properly addressing the timing issues would require the introduction of low level functions to the FIPS module, but modifications to validated cryptography are not allowed(*). So a partial mitigation was implemented in OpenSSL, but that is known to be less than fully satisfactory and has not been tested for efficacy. When FIPS mode is enabled in a FIPS capable OpenSSL, including 1.0.1d, the Lucky 13 vulnerability should be considered still present. If your primary objective is security, in the real-world sense of protection from malicious compromise, use OpenSSL 1.0.1d but do *not* use the OpenSSL FIPS Object Module, or at least don't enable FIPS mode. Unfortunately the environments where the FIPS module is currently used will typically be those environments where such use is mandated. By the very nature of the FIPS 140-2 validation process validated cryptography will always be less secure than the unvalidated equivalent. Note this is true not only of the #1747 module but also for all validated cryptography that is based on OpenSSL (which is most validated cryptography). Even worse, Paterson and AlFardan note in their paper that all current TLS implementations will exhibit the same vulnerability, and so this problem is likely universal for all validated cryptography that is used for TLS. -Steve M. (*)Technically the necessary code changes could be added to the validation via a maintenance letter by retesting each of the 50 plus platforms. That would cost over a hundred thousand dollars in test lab fees alone and would require man-months of labor. That is not going to happen. -- 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.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to convert from PEM to DER format?
Thanks Dave, EVP_DecodeBlock did the magic. -Sri On Tue, Feb 5, 2013 at 5:47 AM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Srivardhan Hebbar Sent: Tuesday, 29 January, 2013 04:57 I have a string which has the certificate in PEM(Base64) format. I want to convert it to DER format(unsigned char). How can I do it? I wrote the following code:snip This code is failing. Am getting 'x' always null. PEM is not just base64. PEM is base64 plus header and trailer lines, here -BEGIN CERTIFICATE and -END CERTIFICATE- . Do you have that? If not, either: - add the header and trailer lines, then PEM_read and i2d as now -- except there is no guarantee that a (DER) certificate fits in 4K bytes. Reasonable DNs, and practically usable pubkey and signature, can't be much more than 1K, but CAs can, and some do, add the most mind-boggling crud in extensions. Either call i2d_(,NULL) first to determine the length and allocate that; or call it and check the length fits in your fixed size before doing i2d_(,buffer); or check the PEM (or just the base64) before decoding is not more than about 5.3KC (which does guarantee the binary fits in 4KB). - decode the base64 to binary directly. With OpenSSL you can read it through a b64-BIO, or (undocumented) just call EVP_DecodeBlock, or you can decode b64 in about 20 lines of C (maybe 10 if you don't care about handling errors). Unlike the above approach this does not check your data contains a facially-valid cert (that is, it is correctly structured and all required fields exist, but we don't know if it was properly signed by a trusted CA and not expired or revoked). But if you subsequently use the DER cert for anything, presumably that will at least decode it and hopefully verify/validate it. Aside: you could save some copies by creating a readonly mem-BIO directly on the c++ std::string's internal buffer, instead of .c_str() which may need to copy and BIO_puts which definitely does. But unless you have many (or huge) certs this shouldn't matter much. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
