Re: OpenSSL wikibook
On 02/02/2013 03:46 AM, Bry8 Star wrote: It would be great to see a wiki site of OpenSSL, like: https://wiki.openssl.org/ Then helpful, experienced and knowledgeable users can contribute and help each-others. This is a good idea that has been proposed a number of times. It hasn't been acted on before due to limited spare cycles and competition for other needs like the server move and upgrade. Personally I also have some reservations, 1) I've never set up or managed a wiki before and 2) the presence of content officially hosted at wiki.openssl.org would imply endorsement by the OpenSSL team. Frankly there is some very misleading OpenSSL related documentation and commentary floating around the Internet, and the only thing worse than no documentation is bad documentation. I know my colleagues and I may not be able to give the wiki the attention it needs to always be completely current and accurate. But, that shouldn't be an excuse for doing nothing. So I propose to set up a wiki at the OSF web site, http://wiki.opensslfoundation.com/ as an initial attempt and experiment. If that turns out well we'll move it to wiki.openssl.org later. Based on some preliminary research and input we're looking at MediaWiki. Give us a few days to get that stood up and I'll make an announcement when we think it's more or less ready. -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.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL wikibook
Hello Steve, Nice to hear about your proposal. Just a few comments about docs : As I said I think that the command line doc is not so bad, for example. I think that some docs will benefit from a wiki, other docs...not. For API docs I really think that it must come from the code, as in java API. What is missing presently in openssl API doc is function available since :, this page has been updated on date. And maybe, as in linux man pages, maintained by ... with a valid mail contact if some errors has to be reported in the doc. Many people are lacking HOW TO docs, which are more suitable for a wiki. For myself I was looking for command line use cases such as how to create a CSR, how to self sign a cert?, I want a cert for specific purposes signing mail/ signing java applets... how to do that., how to revoke a cert, how to check the validity of a cert or a collection of certs in a ca (to know what to renew), how to renew a cert... How to set up a quick ca (I checked the code of some apps and scripts and was not satisfied with the options offered). And for such an infinite set of question and answers, a wiki can be a good tool. But with a minimum of structuration in big chapters. For a programmer, the mailing list can help to find some returning topics that could be put in a wiki.: with some programming examples. What I mean is that I think the API and APPS can only be documented by the dev team, for their man pages. But the wiki could deal with specific use cases, HOWTO...and programming examples. Best regards, Pierre Le 04/02/2013 12:16, Steve Marquess a écrit : On 02/02/2013 03:46 AM, Bry8 Star wrote: It would be great to see a wiki site of OpenSSL, like: https://wiki.openssl.org/ Then helpful, experienced and knowledgeable users can contribute and help each-others. This is a good idea that has been proposed a number of times. It hasn't been acted on before due to limited spare cycles and competition for other needs like the server move and upgrade. Personally I also have some reservations, 1) I've never set up or managed a wiki before and 2) the presence of content officially hosted at wiki.openssl.org would imply endorsement by the OpenSSL team. Frankly there is some very misleading OpenSSL related documentation and commentary floating around the Internet, and the only thing worse than no documentation is bad documentation. I know my colleagues and I may not be able to give the wiki the attention it needs to always be completely current and accurate. But, that shouldn't be an excuse for doing nothing. So I propose to set up a wiki at the OSF web site, http://wiki.opensslfoundation.com/ as an initial attempt and experiment. If that turns out well we'll move it to wiki.openssl.org later. Based on some preliminary research and input we're looking at MediaWiki. Give us a few days to get that stood up and I'll make an announcement when we think it's more or less ready. -Steve M. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Compiling openssl fips in Windows
From: owner-openssl-us...@openssl.org On Behalf Of Jon Evers Sent: Friday, 01 February, 2013 17:45 I'm trying to link an application that will use openssl and fips. I'm getting linker errors snip [using] MS Visual Studio 2008. I'm trying to link the DLL, lib32eay.dll. Did you put libeay32.dll in the VS project or libeay32.lib ? VS needs the latter. You *link* with the export library and then *run* with the dll (from the same build, or at least a build which is binary compatible) and if the dll is not in your PATH I think you need a setting for that also. To answer your other question elsethread, you similarly need ssleay32 if and only if your app uses protocol functions. libeay on Windows (libcrypto on Unix) provides crypto primitives (like AES_* RC4_* SHA_* etc), some utility primitives like ASN1_* PEM_* BIO_* PEM_*, and the generic wrapper EVP_*. Parts of libeay/libcrypto (only) are replaced in FIPS mode. (Actually the normal versions are still there, but not used.) ssleay (libssl) implements SSL protocol (including TLS and DTLS, which technically are slightly different) *using* libeay/libcrypto, and thus using FIPS primitives if enabled. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: EVP_aes_128_cbc decrypt block ordering
From: owner-openssl-us...@openssl.org On Behalf Of Tage Korsdal Nielsen Sent: Friday, 01 February, 2013 03:19 New to OpenSSL, but designing a PC application that must encrypt a stream of 48 bytes message blocks to a USB device with aes128.The iv's gets generated and synchronized when the connection with the device is established, and I would like to keep the same cipher context going until the the device is disconnected. I wrote some test code snip The first encryption/decryption is ok, but then it starts altering the order of the individual cipher blocks in my message, and on the first decryption it reports that only 32 bytes have been decrypted, although the entire 48 byte output buffer is correct. EVP_ for a block cipher by default uses PKCS#5 padding. This is added on the Encrypt side (only) when you do Final, and checked and removed on the Decrypt side. To do this, the Decrypt side must run 1 block behind the ciphertext. I'm not sure why (apparently-correct) data is written beyond the returned count in this case, but any data beyond the count is not valid. Padding is the default because it supports arbitrary-length data which is usually what people want. If you want padding, you can't keep the context going. If you don't want padding, and if your plaintext is chosen as a multiple of the cipher blocksize likely you don't: EVP_CIPHER_CTX_set_padding (ctx, 0); Or use the low-level AES_* routines; they don't do padding (but do do most modes, like CBC). Note without padding your data *must* be a multiple of the blocksize. Your odd_length does do Final on each side and looks like it would work if you were using a context not already messed up by your previous code. But per below it isn't what you want. I then tried with RC4, here everything was ok. RC4 is a stream cipher and doesn't need padding. Since I need the above functionallity with AES, I did the following hack, in evp_enc.c line 478: snip: basically munged padding Then it worked for my streamed block sized aligned messages, but of course not for the odd length test (which I will never use anyway). Strangely (for me anyway) RC4 code still works after the hack, both block size aligned stream and odd length. See above. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PEM_read_PrivateKey using ECDSA PEMS
From: owner-openssl-us...@openssl.org On Behalf Of redpath Sent: Friday, 01 February, 2013 14:55 I am using ECDSA to create and verify a signature for a document. I apparently cannot use the ecdsa.PEM directory and so here is my question. Nit: ecdsa.pem is a file, containing (parameters and) a key, not a directory. Below I have abstraction code for my question. The keys created are with the openssl commands shown below. openssl ecparam -out *ecdsa.pem *-name secp224r1 -genkey openssl req -newkey ec:ecdsa.pem -x509 -nodes -days 731 -keyout *ecdsapriv.pem* -out *ecdsapublic.x509* The artifacts generated by these commands are * ecdsa.pem ecdsapriv.pem ecdsapublic.x509* I then create an ECDSA using the ecdsapriv.pem m= getdata(*mydocument*,len); //orignal document result=sha256((char *)m,len); fp =fopen(*ecdsapriv.pem*, rb); */*marked*/* pevpkey= PEM_read_PrivateKey(fp, pevpkey, NULL, NULL); peckey= EVP_PKEY_get1_EC_KEY(pevpkey); EC_KEY_set_group(peckey,EC_GROUP_new_by_curve_name( NID_secp224r1) ); This isn't needed, an ECC key read from a PEM file already has the correct group. In fact if the key in the file is for a different (wrong?) group this will screw it up totally. unsigned int siglen = ECDSA_size(peckey); printf(Max signature length is %d \n,siglen); siglen = ECDSA_size(peckey); unsigned char *ptr = OPENSSL_malloc(siglen); unsigned char *save= ptr; ECDSA_SIG *sig; ret= ECDSA_sign(0 ,result, SHA256_DIGEST_LENGTH, ptr, siglen, peckey); You don't need to set siglen twice, you don't need two pointers here, and you don't use sig at all. In real code you should check (at least) file opens and mallocs for null before using them, but for posting I'll ignore that. outfp = fopen(*mysignatureEC*,wb); fwrite(save, 1, siglen, outfp); fclose(fp); **then I verify it reading the X509* snip AND ALL WORKS WELL but *why can't I use the *ecdsa.pem* directly instead I had to use the ecdsapriv.pem? Your ecparam command generated a key(pair) in ecdsa.pem. Your req -newkey -x509 command generated a *different* key(pair) in ecdsapriv.pem and a cert for *that* key in ecdsapublic.x509. The cert matches the key in ecdsapriv.pem and can verify signatures using that key. The cert does not match the key in ecdsa.pem which is a different key and cannot verify signatures using that key. You would think the name of this function PEM_read_PrivateKey(**) means it reads a PEM that might have the public and private key and gets the private but apparently not? Yes it does read the privatekey representation, which for OpenSSL always includes the publickey value(s), from the file you specify. (For DSA and ECC/ECDSA the standard privatekey structure includes the public value. For RSA a naive privatekey does not include the public exponent, but OpenSSL uses the CRT form which does.) If you have two files containing different keys, reading those files gives you different keys. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Null (or default) certificates?
From: owner-openssl-us...@openssl.org On Behalf Of Nathan Smyth Sent: Friday, 01 February, 2013 08:47 Is it possible to have null, untrusted, or shared certificates, to simplify deployment for apps that don't care about SSL? Basically I have an infrastructure that uses OpenSSL for comms. As it is protocol based, it's important that everything runs the same code (I.e. I don't want different ports for non-SSL comms, and the SSL sockets require different blocking mechanisms otherwise deadlocks). However, some applications using the infrastructure won't care about TLS. To ease development/deployment for those, I don't want them to have to define certificates, CAs, etc etc for nothing. Rather, is there anyway I can package the code such that there is a default (insecure certificate/CA) that they can use which will work with other SSL clients (though insecurely); or they can specify their own for real security? So actually you do care about SSL/TLS, you just don't care about the authentication and possibly encryption features. Essentially, just want some sort of default SSL certificate that is accepted, can be used to establish a connection just as any other, but doesn't actually provide security. As discussed in your other thread, SSL/TLS defines and OpenSSL supports aNULL suites which use and need no fixed keycerts (but do need ephemeral keys or at least parameters, the same ones as authenticated DHE and ECDHE suites). Alternatively, you can share keycert for systems using the normal (authenticating) suites, with the caveat roughly as you stated -- if you share mysecretkey with 5 or 20 or 300 systems, and their admins and maybe users, it isn't secret anymore and doesn't provide any real security. But it does allow the code and protocol to work the same. 1A. Simplest is to create one key, and a selfsigned cert for that key. Use that key/cert as the server key/cert for each server, and as the client key/cert for each client if you use client-auth as I think you said you do. Also make that cert a trusted CA cert on each client, and on each server if using client-auth. If you want the same system(s), or install package(s), to support real certs as well, you need a truststore that includes your selfsigned cert plus a suitable set of real CAs; if you have a special config or install for insecure systems that truststore can be your selfsigned cert and nothing else. 1B. Slightly more realistic is to create your own CA (cakey and cacert) and your own EE key and EE cert using that CA. Then make the EE key/cert the server key/cert for each server and the client key/cert for each client if applicable, and the *CA* cert a trusted CA cert for each client and each server if applicable. Truststore issues same as 1A. 1C. Create one EE key, and get an EE cert from a real CA for it. This probably costs you a few bucks a year. Make that EE key/cert the server key/cert and client key/cert if applicable. If your systems need to make any other SSL (authenticated) connections they probably already have a truststore containing the usual-suspect CAs, if not add one. 2. OpenSSL itself does not care about domain name(s) in the cert. If your application does, as most should, and cannot be overridden, you must have the name(s) in the cert match the name(s) used by the clients for the servers, and possibly the name(s) of the clients seen by the servers (but that's rarer). 2A. One way is to put in the cert all the server domain names, or if they are all neighbors like fred.example.com george.example.com fruitbat.example.com put a single wildcard for them. You can have one name in the SubjectName in the cert, or multiple names (including wildcards) in the SubjectAlternativeName extension. For 1A and 1B, OpenSSL will let you put any name(s) you wish in your cert, although configuring values for SAN is clumsier than for Subject. For 1C, the CA may charge extra for SAN and usually will limit the name(s) to a domain you own and any subdomains under it. 2B. The other way is to choose name(s) or wildcard(s) in the cert and then create domain names for the servers matching the name(s) in the cert. These can be aliases using CNAME. This requires you have authority to put things in your DNS zone, or alternatively authority to add DNS entries on each client that needs them using an etc/hosts file or similar. If your servers reverse-lookup their clients, you have to *replace* the PTR entries which may be less desirable, and I'm not sure etc/hosts works reliably (although on my captive Windows test systems, it usually does). But one warning: be sure your users understand this is not secure. For some people just telling them, even repeatedly, is not enough. __ OpenSSL Project http://www.openssl.org User Support Mailing List
SSL ciphersuites related
Hi All, I need some help to resolve some issues found after implimentinf SSL using openssl client. Below are the issues: 42873 - SSL Medium Strength Cipher Suites Supported [-/+] 26928 - SSL Weak Cipher Suites Supported [-/+] 53491 - SSL / TLS Renegotiation DoS [-/+] 31705 - SSL Anonymous Cipher Suites Supported [-/+] 42880 - SSL / TLS Renegotiation Handshakes MiTM Plaintext Data Injection [-/+] Please guide me how to resolve these issues. Kind Regards, Ravindra Bararawa =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
Re: PEM_read_PrivateKey using ECDSA PEMS
First of all let me correct this I am using ECDSA to create and verify a signature for a document. I apparently cannot use the ecdsa.PEM *directory* and so here is my question. to this I am using ECDSA to create and verify a signature for a document. I apparently cannot use the ecdsa.PEM *directly* and so here is my question. I have no idea why the directly got typed as a directory, it happens. I will look at the usage of the PEM directly thank you in advance. -- View this message in context: http://openssl.6102.n7.nabble.com/PEM-read-PrivateKey-using-ECDSA-PEMS-tp43438p43492.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: Compiling openssl fips in Windows
Jon, Regarding: According to my interpretation of the documentation, it should be included in libeay32.dll: Section 2.4.2 Note that except in the most unusual circumstances the FIPS Object Module itself (fipscanister.o) is not linked directly with application code. Section 4.3.3 The resulting FIPS capable OpenSSL can be used for shared or static linking. The shared library built (when ms\ntdll.mak is used as the Makefile) links fipscanister.lib into libeay32.dll using fipslink.pl I wonder if you're working off of an older version of the documentation. I've been using the User Guide v2.0 found here: http://www.openssl.org/docs/fips/UserGuide-2.0.pdf Thanks, LM
RE: Compiling openssl fips in Windows
LM, I was using the Jan 18, 2013 version. It looks like the current is now Jan 25, 2013. However, those sections and paragraphs I quoted are still there. Just look down a few paragraphs to find them. Section 5.3.2 seems to be the root of my problem. I don't think my project, based on ms\nt.mak, is working correctly. As a makefile example, nt.mak is fairly complex and I had to trace and pull out quite a few symbols and modify them to get it to run. Does anyone have a basic make file for Windows that links the openssl and fips libraries or maybe a simple VS2008 project that they can post or send me? Thanks for any help. -Jon Section 5.3.2 The static library Makefile ms\nt.mak in the OpenSSL distribution gives an example of the usage of fipslink.pl. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Memmott, Lester Sent: Monday, February 04, 2013 2:51 PM To: openssl-users@openssl.org Subject: RE: Compiling openssl fips in Windows Jon, Regarding: According to my interpretation of the documentation, it should be included in libeay32.dll: Section 2.4.2 Note that except in the most unusual circumstances the FIPS Object Module itself (fipscanister.o) is not linked directly with application code. Section 4.3.3 The resulting FIPS capable OpenSSL can be used for shared or static linking. The shared library built (when ms\ntdll.mak is used as the Makefile) links fipscanister.lib into libeay32.dll using fipslink.pl I wonder if you're working off of an older version of the documentation. I've been using the User Guide v2.0 found here: http://www.openssl.org/docs/fips/UserGuide-2.0.pdf Thanks, LM 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: Compiling openssl fips in Windows
Dave, I am linking libeay32.lib. I did try the .dll and tried to make it a reference in a VS2008 project, but that completely failed. If I understand correctly ssleay32 is needed to implement SSL/TLS protocols? If so, I definitely need to include it. But, currently my linking issues don't seem to be affected by this library being included or not. My link issues are either : 1) Can't find FIPS symbols (FIPS_hmac_final, FIPS_hmac_init_ex) OR 2) with fipscanister.lib also linked - duplicate symbols int MSVCRT.lib and LIBCMT.lib (like __exit, _raise and _malloc) I think a simple, basic make file for a windows console application would greatly help me track down my linker issues. I'm sure it is some simple mismatch or mistake I make in the make file I sourced from nt.mak. I just can't seem to pinpoint it. Thanks, -Jon -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Monday, February 04, 2013 1:58 PM To: openssl-users@openssl.org Subject: RE: Compiling openssl fips in Windows From: owner-openssl-us...@openssl.org On Behalf Of Jon Evers Sent: Friday, 01 February, 2013 17:45 I'm trying to link an application that will use openssl and fips. I'm getting linker errors snip [using] MS Visual Studio 2008. I'm trying to link the DLL, lib32eay.dll. Did you put libeay32.dll in the VS project or libeay32.lib ? VS needs the latter. You *link* with the export library and then *run* with the dll (from the same build, or at least a build which is binary compatible) and if the dll is not in your PATH I think you need a setting for that also. To answer your other question elsethread, you similarly need ssleay32 if and only if your app uses protocol functions. libeay on Windows (libcrypto on Unix) provides crypto primitives (like AES_* RC4_* SHA_* etc), some utility primitives like ASN1_* PEM_* BIO_* PEM_*, and the generic wrapper EVP_*. Parts of libeay/libcrypto (only) are replaced in FIPS mode. (Actually the normal versions are still there, but not used.) ssleay (libssl) implements SSL protocol (including TLS and DTLS, which technically are slightly different) *using* libeay/libcrypto, and thus using FIPS primitives if enabled. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org 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. __ 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?
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
