OPenssl 20140909 issues
Just found this in the latest openssl 1.0.2 snapshot
Script started on Mon Sep 8 23:19:16 2014
doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20140909$ make test
testing...
(cd ..; make DIRS=crypto all)
making all in crypto...
ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o cpt_err.o
ebcdic.o uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o fips_ers.o mem_clr.o
test -z || ar r ../libcrypto.a fipscanister.o
/usr/bin/ranlib ../libcrypto.a || echo Never mind.
making all in crypto/objects...
making all in crypto/md2...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/rc5...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/camellia...
making all in crypto/seed...
making all in crypto/modes...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/srp...
making all in crypto/store...
making all in crypto/cmac...
if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then (cd ..; make
libcrypto.so.1.0.0); fi
[ -z ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5
-DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o
fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc
(cd ..; make DIRS=ssl all)
making all in ssl...
if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then (cd ..; make
libssl.so.1.0.0); fi
[ -z ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5
-DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o
fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc
( :;LIBDEPS=${LIBDEPS:-../libssl.a ../libcrypto.a -lgmp -ldl -lm -lc};
LDCMD=${LDCMD:-gcc3}; LDFLAGS=${LDFLAGS:--fPIC -DOPENSSL_PIC -DZLIB_SHARED
-DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DRMD160_ASM -DAES_ASM -DGHASH_ASM}; LIBPATH=`for x in $LIBDEPS; do echo $x;
done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/
/:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=heartbeat_test} heartbeat_test.o ${LIBDEPS} )
making all in apps...
(cd ..; make DIRS=crypto all)
making all in crypto...
ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o cpt_err.o
ebcdic.o uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o fips_ers.o mem_clr.o
test -z || ar r ../libcrypto.a fipscanister.o
/usr/bin/ranlib ../libcrypto.a || echo Never mind.
making all in crypto/objects...
making all in crypto/md2...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all
Re: Verifying authenticode signature using openssl API
Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. I have a few follow-up questions on your response. 1. So, encryptedDigest has no relation to the stored messageDigest? I thought it's a encrypted version of the messageDigest? 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. 3. spcPEImageData is probably relevant only for signing that uses page hashes? 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate? In my case, I am the one who is signing the executable using my certificate and a cross certificate issued by Microsoft and I want to programmatically ensure following things. 1. Code is not tampered since it was signed (matching messageDigest with computed hash) 2. Verifying the digital signature (PKCS7_Verify) 3. Confirming that the executable is signed by my company certificate. I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key? Thanks. -Prasad On Sep 06, 2014, at 09:44 PM, Prasad Dabak pda...@icloud.com wrote: Hello, Given a signed Windows portable executable, I want to programmatically verify two things using openssl APIs 1. Verify the digital signature. 2. Confirm that the executable is signed by a specific company using that company's public key. It seems that part (1) can be done by parsing the signedData attribute in the portable executable, extracting the hashing algorithm and digest stored there, re-computing the digest of the executable using the same hashing algorithm and match them. I have following questions. 1. The signData contains messageDigest (unencrypted) and encryptedDigest (encrypted). Is it enough to match messgaeDigest with the computed digest? OR we also need to decrypt the encryptedDigest using the company public key and match that as well? 2. What does PKCS7_Verify exactly do? I looked at https://www.openssl.org/docs/crypto/PKCS7_verify.html and I understand that it verifies certificate chain. However, it's not clear to me as to what exactly it does with respect to signature verification? 3. I am assuming that I require to do both (1) and (2) in order to verify the authenticode signature? 4. What is the best way to verify if the executable is signed by specific company using that company's public key? Any inputs will be greatly appreciated! Thanks. -Prasad
Can we have a PyOpenSSL 0.15?
All, My team is considering a port to Python 3 from Python 2.7. One issue we see is that we cant run a flask server with ssl. I am seeing that the fix is in this pull request: https://github.com/pyca/pyopenssl/pull/78/commits Which has already been merged. Is a new version of PyOpenSSL coming that contains this pull request? Thanks, Eric Chazan
Re: Why does OpenSSL own all the prefixes in the world?
What about introducing a openssl_deprecated.h which sole purpose is to throw in a bunch of defines that map ERR_old_style_name OPENSSL_ERR_new_style_name. To make an old-style codebase compatiblae the only thing to add would be either including openssl_deprecated.h or set a macro on the command line that does so from within the new-style headers (maybe on by default via the configure). And BTW: C++ won't hurt legibility of the source: using some scoped pointers you can cleanup most error paths to become just return OPENSSL_ERR_new_style_error_name. Regards, BenBE. Am 08.09.2014 03:52, schrieb Jakob Bohm: And how would you do that without breaking compatibility with every program (in C, C++ or any other language) that already uses openssl and depends on the current API names? Providing the API, semantics and portability of the original SSLeay library is thesecond-most important feature of OpenSSL (right after actually being a secure SSL/TLSimplementation when used correctly). On 08/09/2014 01:15, Pierre DELAAGE wrote: Hmm... Switch strongly and definitely to C++ Not for fancy object programming, but for more practical syntaxES for things like this. And I am an old C fan programmer... Pierre Delaage Le 08/09/2014 00:04, Kyle Hamilton a écrit : The reason is legacy. Eric Young was not conscious of namespace pollution when he implemented SSLeay; since then, even after the migration to the OpenSSL name and team, the focus has been more on maintaining source compatibility than in creating new interoperability opportunities. To meet the goal of interoperability while enabling an alternate symbolic namespace, what would you suggest? -Kyle H On September 7, 2014 1:30:11 PM PST, Iñaki Baz Castillo i...@aliax.net wrote: Hi, RAND_xxx CRYPTO_xxx ERR_xxx ENGINE_xxx EVP_xxx sk_xxx X509_xxx BIGNUM_xxx RSA_xxx BN_xxx ASN1_xxx EC_xxx etc etc etc. May I understand why it was decided that OpenSSL can own all the prefixes or namespaces in the world? How is it possible that OpenSSL owns the ERR_ prefix (for example ERR_free_strings() and others)? OpenSSL is a library. I should be able to integrate OpenSSL into my own code and define my own prefixes without worrying about creating conflicts with the near 200 prefixes that OpenSSL owns. An example of a well designed C library is libuv [*], in which: * Public API functions and structs begin with uv_. * Private API functions begin with uv__. * Public macros begin UV_. That's a good design! PS: In my project I use both openssl and libsrtp. In which of them do you expect the following macro is defined?: SRTP_PROTECTION_PROFILE [*]https://github.com/joyent/libuv/ Enjoy Jakob signature.asc Description: OpenPGP digital signature
Re: On 2K keys and SHA-256
Hi Rich, Am 08.09.2014 23:59, schrieb Salz, Rich: We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K, and changing the default signing digest from SHA-1 to SHA-256. May I suggest 4096 bit with SHA-256. That way you have a security level of = 128 bit for both primitives and as the weakest link counts ... Also: attacks only get better over time. We’ve already committed this to HEAD/master. We would like to make this change in the upcoming 1.0.2 release as well. Several downstream distributions, such as Debian, have already done this. Microsoft has already announced deprecation of SHA-1 certificates, and Google just recently posted a fairly aggressive plan for Chrome. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... Does anyone have strong objections? The only objection I have regarding this change is that originally intended one reflects only the bare minimum of the chosen primitives that you can widely use without being deprecated. Why aren't people thinking ahead for a moment and try to set defaults more to the middle of the practical range*. *for digests this unfortunately is SHA-256 through SHA-256 as GnuTLS 2.x (available on most Debian Stable boxes) barfs on anything else like SHA-384 or SHA-512. Kind regards, BenBE. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me mailto:rs...@jabber.me Twitter: RichSalz signature.asc Description: OpenPGP digital signature
Re: Performance related queries for SSL based client server model
Hi, Thanks all for your update. But functionality wise it is working fine. I can remove the inner loop but that will require packet size to be of 1K. I tried with that also but did not find any improvement in performance. In my setup there are 8 routers between source destination. Can anyone share me sample SSL based client server programme which I could use to measure performance. Regards, Alok On Tue, Sep 9, 2014 at 3:54 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2014-09-08 19:46 GMT+02:00 Alok Sharma alokonm...@gmail.com: One thing I observerd by looking into scp code that it does not use SSL provided APIs (i.e.SSL_Read or SSL_Write) but they use it differenly i.e. might be directly calling encryption APIs and writing data to sockets. But I don't have much understanding what SSL_Write or SSL_read does internally. It has been already replied above. SSH is not SSL so don't look for SSL_ methods on openssh. Said that, AFAIK openssh uses the crypto library from openssl, but that is not SSL/TLS at all. So wanted to understand if there is any way to improve performance of SSL_Read or SSL_write to achive high performance. Following are my client server programmes. Here client writes file on server machine in hardcoded location and name. You have lot of errors in your program. I suggest that you first properly learn openssl, then measure your code if you need. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
In message CALiegfmvaG-nc=putyxey20otoiow6op+lajohnoqxf86aw...@mail.gmail.com on Mon, 8 Sep 2014 18:19:09 +0200, Iñaki Baz Castillo i...@aliax.net said: ibc Why do I need to provide BIO_get_mem_data() with an already allocated ibc buffer? I've checked the function and I do not understand what it ibc does). The only I want is to get the pointer to the BIO's buffer in ibc which SSL_write() wrote. Why should I provide an allocated buffer? The ibc BIO already has a buffer and the data is already in there after ibc calling SSL_write(). Why do I need to pass an allocated buffer? Actually, you don't, you only need to pass it the address to a char* (that's what a char** is). This code snippet (which is your code snippet that crashes with a small change) is sufficient: -- long read; char* data = NULL; read = BIO_get_mem_data(bio, data); // Use data and read values. BIO_reset(bio); -- Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Value of DEFAULT cipher suite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Rich, Am 09.09.2014 00:42, schrieb Salz, Rich: We are considering removing weak cryptography from the value of DEFAULT. That is, append :!LOW:!EXPORT It is currently defined as this in include/openssl/ssl.h: #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 Please let us know if you have strong objections to this. Please consider also adding !SSLv3 and !RC4 to this list. Regards, BenBE. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJUDsI0AAoJEPHTXLno4S6t9FIP/0U0GxY3LyyULMPFGc+AVGmV BfgR5WZOd1+VsWudCfhpOS9OGAMBdmjxzI2TQvm1osUnSyRI8k8642eCF8v1Gqtf QIGtUp/A0UghKygoo9XzNCLfu2WL6DOa9HYWpURDEVanM+ZGImwNh02zv8b9jXcM REFi7rkr8gIje7O7z9SVb3RkKqp/QBwR9s7w1i2bzdEyKi4pbsGhX0s2zclALTgU 6Gn5SMh0o3LeIoNjvfhxe4KyDY/u97omkgOmThERkgZEILrzcj2lgZZ+sI6W2qpa E/QUNKrStQJXereOp2iAO7uEXPe3Md+VhqsSjP8pxpiTb1U6o74FITeyEggBSWS9 u8i/2sCpXZPRqUGe1OTbxzu3BjFXHOEQ6kc7pZahPAX3M9spY5WMglnFJODCn5F3 QIps8pZ1CJuXm1UhVJ3LvTKsbIsQ3C7egbPrK6zAZwCWRDUmYOya6YUUTA+gu3xs 6Tv6FHoI+r/yyiff4BfhdU7ECHlqw7+pqIgwyIWJQeNRxzOzUquuaQDy2bLnWMX5 +NGQEmgfzIPQhD5rzNI3TUrzutJB+4cyVnaIGjcjzc79gcQYRaLgkGXOg2D5nFgj KGeUbls7kft+48Junrap/2q1ozblQt+D1j9czQPdeFWCnnt+uG6yCtnnPYqtp/GJ 3EOir+BPawK99iMGjUYy =TFs7 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
And of course, I noticed this email after sending my own... sorry. In message CALiegf=BytJ-1ZDzcCw3=e2=6moritr87pjunro4cxorysy...@mail.gmail.com on Mon, 8 Sep 2014 18:41:40 +0200, Iñaki Baz Castillo i...@aliax.net said: ibc 2014-09-08 18:35 GMT+02:00 Kyle Hamilton aerow...@gmail.com: ibc The allocated buffer needs to be sizeof(char *). What's happening is the ibc address of the buffer (buffer[0]) gets written to the ibc pointer-to-pointer-to-char, data. If data == NULL, you're asking to write ibc the address of the buffer to unallocated memory. ibc ibc It's done this way because the return value of the function is the number of ibc valid bytes you can read from that location, and the address must go ibc somewhere for you to get the data from it. ibc ibc I'm sorry this is probably difficult to understand, I don't know if I can ibc explain it more easily. ibc ibc It's clear. And my error was terrible, I was creating a char** data ibc instead of char* data. The following updated code does work: ibc ibc ibc - ibc long read; ibc char* data = NULL; ibc ibc read = BIO_get_mem_data(bio, data); ibc ibc // Use data and read values. ibc - ibc ibc ibc Thanks a lot. ibc ibc ibc -- ibc Iñaki Baz Castillo ibc i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to empty a BIO buffer?
2014-09-09 10:46 GMT+02:00 Richard Levitte rich...@levitte.org: And of course, I noticed this email after sending my own... sorry. :) Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
certificate
dear all
i have just made a code to make a certificate request from a node and my
certificate authority reply with the certificate
the node has attributes as below
X509_REQ *x;
EVP_PKEY *prk;
EVP_PKEY *puk;
X509m_myCert;
//RSA structure contain both private and public key
RSA*rsa_keyPair;
X509_NAME *name;
the function which made the certificate request is
X509_REQ*
AeroRoutingProtocol :: MakeSignedCertReq (int bits, int serial, int days)
{
X509_REQ_set_pubkey(x,puk);
name=X509_REQ_get_subject_name(x);
// it gives errors i don't knoe why
//X509_NAME_add_entry_by_txt(name,C,MBSTRING_ASC, UK, -1, -1, 0);
//X509_NAME_add_entry_by_txt(name,CN,MBSTRING_ASC, OpenSSL Group,
-1, -1, 0);
X509_REQ_sign(x,puk,EVP_md5());
return x;
}
the certificate authority receive this request and reply by the certificate
the function that make certificate as below
X509*
CertificateAuthority :: CreateCertificate (X509 *issuer, X509_REQ *req,
RSA *key )
{
X509 *cert = NULL;
int rv;
X509_NAME *xn_req = NULL, *subject = NULL;
EVP_PKEY *pkey = NULL;
//create the certificate
X509 * x509;
x509 = X509_new();
X509_NAME *issuerSubject = X509_get_subject_name(issuer);
X509_set_issuer_name(cert, issuerSubject);
xn_req = X509_REQ_get_subject_name(req);
X509_set_subject_name(cert, subject);
pkey = X509_REQ_get_pubkey(req);
rv = X509_set_pubkey(cert, pkey);
X509_gmtime_adj(X509_get_notBefore(cert), 0);
X509_gmtime_adj(X509_get_notAfter(cert), 36400);
signCertificateWithKey(cert, key);
return cert;
}
when i compile i got this error
../src/aerorp/model/certificate-authority.cc: In member function ‘X509*
ns3::AeroRP::CertificateAuthority::CreateCertificate(X509*, X509_REQ*,
RSA*)’:
../src/aerorp/model/certificate-authority.cc:58:37: error:
‘signCertificateWithKey’ was not declared in this scope
thanks allot for help
--
Warmest regards and best wishes for a good health,*urs sincerely *
*mero*
RE: cannot read PEM key file - no start line
Hi Viktor, Thanks for the info. I will try what you suggested today. However, I am a bit confused by what you are saying - You may need to separately specify a CAfile, or CApath for validating the server certificate. I have the two pem files below. I thought the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the MongoDB database server and I was supposed to connect from my C++ app with the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file. I am new to this, so I am sorry for not understanding completely. . DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem . private key of DTCD9C3B2F42757.ent.wfb.bank.corp machine . certificate for DTCD9C3B2F42757.ent.wfb.bank.corp, signed by WF Enterprise CA 02 . DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem . WF Enterprise CA 02 certificate, signed by WF Root . WF Root certificate Thanks, Liz -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Monday, September 08, 2014 8:28 PM To: openssl-users@openssl.org Subject: Re: cannot read PEM key file - no start line On Mon, Sep 08, 2014 at 08:14:32PM -0700, Liz Fall wrote: I am trying to connect to a MongoDB SSL-enable database. This is the API: // only really need a PEM on the server side mongo::sslGlobalParams.sslPEMKeyFile = path/to/keyfile.pem; The comment is highly misleading. PEM is a meta format. It encapsulates base64 encoded blobs between BEGIN/END headers/trailers, allowing multiple objects to be concatenated unambiguously and transported undamaged via ASCII email. This this is a client, what goes here is likely a client certificate chain and a client private key, or just NULL, if client certificates are not employed (you're likely authenticating the client with a username and password instead). -- BEGIN RSA PRIVATE KEY - private key for client cert base64 encoded -- END RSA PRIVATE KEY - client cert base64 encoded -- END CERTIFICATE - -- BEGIN CERTIFICATE - intermediate issuer base64 encoded -- END CERTIFICATE - ... -- BEGIN CERTIFICATE - root issuer base64 encoded -- END CERTIFICATE - I would try NULL first. You may need to separately specify a CAfile, or CApath for validating the server certificate. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cannot read PEM key file - no start line
On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net wrote: All, I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB: 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser. Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me. Reading an encrypted private key resulted in an error PEM_read_bio:bad end line:pem_lib.c:802 when the line size was 76 (see below). This kind of surprised me. Since you are receiving the no start line error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths. Can you post the X509 certificate for inspection? Jeff ** # Line breaks at 76 $ cat rsa-pub-xxx.pem -BEGIN PUBLIC KEY- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ 6hfRM1n3+8NlS4Qw76PvM1EMR9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2U pttFup08OUEIlrmkeP1GqMCfaVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQAB -END PUBLIC KEY- # Line breaks at 76 $ cat rsa-priv-xxx.pem -BEGIN RSA PRIVATE KEY- MIICXgIBAAKBgQDse17vxd2lkVIxwt1gkipo0EZo3NdDhIvPRowZ6hfRM1n3+8NlS4Qw76PvM1EM R9FXCFTBtv9zzZ7OkNH84LgG6mbNS28PuWeUFmMZumdLbT4KNu2UpttFup08OUEIlrmkeP1GqMCf aVcbCfl0tScpCMeEhXUpiIvtzUin2kqGHQIDAQABAoGBAJqxzZW98tMW8BS7K0O7+eActqJsLKjv MOIDfSyKlM/17pmo6NX/g1bbvHqCMDd/V3K+cWtTAWJIlOT9mU/51Ib3h29xEQQ6Ql/ubMPAmm/t f7itQMxn5FVY+ZA2/pL/mDzAdMuLeS/1TcHCqjbpAL8VaZjHTqztHBcVcNzbIQ6BAkEA/e7hE6WV caAoFEVfoZW0AIjwWpziQdI1bhNAi70fxWEU1kSq2ZZZhqxU4G37IKmVfBnx3CSzCgp5daPqUpEO oQJBAO5oIOgVf3GqL03fA6N3s2gx9L4VzAaZZynDF6yjhCCAXs8uUSEYKL32a17dFq+0SrQUSS2J Tylsz2cv+Uk6cf0CQQCV5RLb5BypbB78iE8BNTuCLVOkSYON0yZTCe5KDqPYgYwpR3OK6aODSer4 aDObfj+NeEs65jcBsFkuRkol3xbBAkEAiN+rlNNS2fU1N2YEdsNwcy/LLZ7iBh/ohKeHXgx6/RX2 WMhkt7VhHr7tIgeY0MOX6A+Fe+lLU6Mu6DU4z/wIGQJAQfEGaJbtaq8bLu6m2VYPpGig1NyBx9i8 kF/E+JC9ZSYh//5nhp6+lBbxceDcijPqnKGZlMYS51nPLSHQBRqbog== -END RSA PRIVATE KEY- # Line breaks at 76, password is test $ cat rsa-enc-priv-xxx.pem -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,8878824B00BA92932DC5AA1E4A9F12E0 klcOjPvZmj/19sUcf031oUckm2YUw7nEp6UtSbs41OKd2TyRfveNl4vv3J8AzOh18AqPPSKR3chM 8lSvKIdcksieh8raqr2s5wMd8ds/mDkguoVWGVnN8f+FKoVTny7OMhXAbQhk2ZXwZMEU5Q8M/Jnj 3ZfrbgcLYH50UoPlkgD6Y0krcNB+TDJEMvErn7G6RedrDPOjQ2gFCmRSE6Yuqtcgl5JaVS+1UT8Z 4l+EMuUjQcBiwuSQNxgfwyGQ3g/2maluLJsEKHDQhAKufe2c7lXlK/0MdHY+q4RbNLmGBigHb97U A5jTZl5+dBrQgtgPx7V13F/7EHT6m2KrYSDvfoPadcT65sT1ukoZF5rvbdRcN1QtVetVrymwM5XU 8CrlSz6tihleipPx27JUA7WQjIQc/Kk7R0e1dNB0oEkgd0i5+20bg+4/Keh0t5fwkXlyrCwjEItT zoC0Hm2dvXG6BTm1OUyRL94DxStVmqRpwDbthbEUqxYWrxTgWKu+noGYu3xJFI6plKEHTY+YMxjm azeyV8CE0HGwRXTBHpj47bekt5dpxMxZasgeIJqHrUI3am+CijdJTHQyHU3Zxk7rdiLha1inpN6M Z+ImQxqzm22e4/KMnTxcZ7L6hNzCKXgAGZ9gdg2uV+fwwyFRwzLDWMbQFeYH10yHB6Ua6Wg2LZdr +NTuJlrMykVULD382XszNMLFtJGl46lpJ9XKWTTIX4e5Fg5N1WSHS2gD8YLxtRzd9vM9ewsZOMtw gqw5uK7GSJUo8FHKtYuLGKY0jnVHFm2VnYo+76RXQxmJyo+ANmALJCJENCZDMm0I0pRGgRVV -END RSA PRIVATE KEY- $ openssl rsa -in rsa-pub-xxx.pem -pubin -text -noout Public-Key: (1024 bit) Modulus: 00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92: 2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea: 17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33: 51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90: d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16: 63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba: 9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69: 57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88: 8b:ed:cd:48:a7:da:4a:86:1d Exponent: 65537 (0x10001) $ openssl rsa -in rsa-priv-xxx.pem -text -noout Private-Key: (1024 bit) modulus: 00:ec:7b:5e:ef:c5:dd:a5:91:52:31:c2:dd:60:92: 2a:68:d0:46:68:dc:d7:43:84:8b:cf:46:8c:19:ea: 17:d1:33:59:f7:fb:c3:65:4b:84:30:ef:a3:ef:33: 51:0c:47:d1:57:08:54:c1:b6:ff:73:cd:9e:ce:90: d1:fc:e0:b8:06:ea:66:cd:4b:6f:0f:b9:67:94:16: 63:19:ba:67:4b:6d:3e:0a:36:ed:94:a6:db:45:ba: 9d:3c:39:41:08:96:b9:a4:78:fd:46:a8:c0:9f:69: 57:1b:09:f9:74:b5:27:29:08:c7:84:85:75:29:88: 8b:ed:cd:48:a7:da:4a:86:1d publicExponent: 65537 (0x10001) privateExponent: 00:9a:b1:cd:95:bd:f2:d3:16:f0:14:bb:2b:43:bb: f9:e0:1c:b6:a2:6c:2c:a8:ef:30:e2:03:7d:2c:8a: 94:cf:f5:ee:99:a8:e8:d5:ff:83:56:db:bc:7a:82: 30:37:7f:57:72:be:71:6b:53:01:62:48:94:e4:fd: 99:4f:f9:d4:86:f7:87:6f:71:11:04:3a:42:5f:ee: 6c:c3:c0:9a:6f:ed:7f:b8:ad:40:cc:67:e4:55:58: f9:90:36:fe:92:ff:98:3c:c0:74:cb:8b:79:2f:f5:
RE: Value of DEFAULT cipher suite
Please consider also adding !SSLv3 and !RC4 to this list. My plan is to move RC4 and MD5 to LOW; see RT3518. As for SSLv3, the issue is that you really mean the protocol, not the ciphers (there's overlap with SSL and TLS), which is configured separately, and only via code. So I think I have to leave that as-is, unfortunately. Thanks for the feedback. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: On 2K keys and SHA-256
May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem building openssl 1.0.1h on SUSE Linux 9.3 Power PC 64
Hi,
I am trying to build openssl 1.0.1h (static) library on SUSE Linux 9.3 on
PowerPC 64 bit arch using GCC version 3.3.3.
I am getting following errors in app directory.. Can somebody tell me what is
going on wrong and how can I fix this? This is my first post, so
excuse/direct-me to the right forum if I am knocking at the wrong door. I have
seen the earlier archives but did not come across this.
Configured as ./Configure no-shared linux-ppc64
==START
ADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o
pkeyutl.o pkeyutl.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o spkac.o spkac.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o smime.o smime.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o cms.o cms.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o rand.o rand.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o engine.o engine.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o ocsp.o ocsp.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o prime.o prime.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o ts.o ts.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o srp.o srp.c
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o openssl.o openssl.c
rm -f openssl
shlib_target=; if [ -n ]; then \
shlib_target=linux-shared; \
elif [ -n ]; then \
FIPSLD_CC=gcc; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC FIPSLD_CC; \
fi; \
LIBRARIES=-L.. -lssl -L.. -lcrypto ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o dgst.o
dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o
app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o
pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o
srp.o \
LIBDEPS= $LIBRARIES -ldl \
link_app.${shlib_target}
make[2]: Entering directory
`/unixhome/vnayak/workspace/openssl/lnx-ppc64/openssl-1.0.1h/apps'
( :; LIBDEPS=${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl};
LDCMD=${LDCMD:-gcc}; LDFLAGS=${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DB_ENDIAN -DTERMIO -O3 -Wall
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM};
LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d |
uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o
dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o
s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o
sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o
spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
dgst.o(.text+0x7d8): In function `.dgst_main':
: undefined reference to `.OPENSSL_cleanse'
enc.o(.text+0x7fc): In function `.enc_main':
: undefined reference to `.OPENSSL_cleanse'
ca.o(.text+0x3d9c): In function `.ca_main':
: undefined reference to `.OPENSSL_cleanse'
s_server.o(.text+0x3ebc): In
Re: Value of DEFAULT cipher suite
On Tue, Sep 09, 2014 at 11:02:45AM +0200, Benny Baumann wrote: Please consider also adding !SSLv3 and !RC4 to this list. No. That would be unwise at this time. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OPenssl 20140909 issues
Is the top-level rehash target not getting executed? It should be a
dependency of test (via the tests target).
Mike
On Tue, Sep 9, 2014 at 1:41 AM, The Doctor doc...@doctor.nl2k.ab.ca wrote:
Just found this in the latest openssl 1.0.2 snapshot
Script started on Mon Sep 8 23:19:16 2014
doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20140909$ make test
testing...
(cd ..; make DIRS=crypto all)
making all in crypto...
ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o
cpt_err.o ebcdic.o uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o
fips_ers.o mem_clr.o
test -z || ar r ../libcrypto.a fipscanister.o
/usr/bin/ranlib ../libcrypto.a || echo Never mind.
making all in crypto/objects...
making all in crypto/md2...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/rc5...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/camellia...
making all in crypto/seed...
making all in crypto/modes...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/srp...
making all in crypto/store...
making all in crypto/cmac...
if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then (cd ..; make
libcrypto.so.1.0.0); fi
[ -z ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5
-DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude
-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c
fipscanister.o libcrypto.a -lgmp -ldl -lm -lc
(cd ..; make DIRS=ssl all)
making all in ssl...
if [ -n libcrypto.so.1.0.0 libssl.so.1.0.0 ]; then (cd ..; make
libssl.so.1.0.0); fi
[ -z ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS
-pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5
-DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g
-DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude
-DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c
fipscanister.o libcrypto.a -lgmp -ldl -lm -lc
( :;LIBDEPS=${LIBDEPS:-../libssl.a ../libcrypto.a -lgmp -ldl -lm -lc};
LDCMD=${LDCMD:-gcc3}; LDFLAGS=${LDFLAGS:--fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer
-O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM}; LIBPATH=`for x
in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=heartbeat_test} heartbeat_test.o ${LIBDEPS} )
making all in apps...
(cd ..; make DIRS=crypto all)
making all in crypto...
ar r ../libcrypto.a cryptlib.o mem.o mem_dbg.o cversion.o ex_data.o
cpt_err.o ebcdic.o uid.o o_time.o o_str.o o_dir.o o_fips.o o_init.o
fips_ers.o mem_clr.o
test -z || ar r ../libcrypto.a fipscanister.o
/usr/bin/ranlib ../libcrypto.a || echo Never mind.
making all in crypto/objects...
making all in crypto
RE: Value of DEFAULT cipher suite
Moving RC4 to LOW is also premature. It is already at the bottom of the medium cipherlist, that should be enough. I am planning on doing it for master, not 1.0.2 That means it won't be in an official release until... what, at least six months. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Value of DEFAULT cipher suite
On Tue, Sep 09, 2014 at 08:42:36AM -0400, Salz, Rich wrote: Moving RC4 to LOW is also premature. It is already at the bottom of the medium cipherlist, that should be enough. I am planning on doing it for master, not 1.0.2 That means it won't be in an official release until... what, at least six months. Master has security levels, which still need some work, but are a less crude mechanism for such tweaks. Disabling RC4 at security level 2 or some such, is better than incompatibly reclassifying it as LOW. We can discuss the details later. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OPenssl 20140909 issues
On Mon, Sep 08, 2014 at 11:41:42PM -0600, The Doctor wrote: ls: error initializing month strings The literal string month does not appear in OpenSSL 1.0.2 source code. You're probably compiling in a locale not supported by your system. ls -l is unable to format the date. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com: You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect. I did that, but if a openssl header file includes standard C headers that I don't include, then the namespace declaration would affect them too, am I wrong? Mind you, I don't think it's worth the effort, for the reasons I outlined earlier. Sure, it was just a vague attempt. And indeed, lot of functions in OpenSSL are given as macros, so namespaces are of little help. Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: cannot read PEM key file - no start line
On Tue, Sep 09, 2014 at 04:42:53AM -0700, Liz Fall wrote: Thanks for the info. I will try what you suggested today. However, I am a bit confused by what you are saying - You may need to separately specify a CAfile, or CApath for validating the server certificate. I have the two pem files below. Most applications that use TLS do not employ client certificates. In such applications the server typically has a certificate chain file (containing its certificate and those of issuing CAs ordered from leaf to optional root) and a private key file (which may be the same as the chain file, since PEM can store multiple objects of various types in a single file). The client typically has no certificate chain file or private key, rather it needs to be able to verify the server certificate. Thus it needs to specify the location (or employ the system default) of the file or directory holding trusted issuer certificates. I thought the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_server.pem file resided on the MongoDB database server and I was supposed to connect from my C++ app with the DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem file. Or perhaps you're supposed to simply append the intermediate CA certs in the second to the leaf server certificate in the first, and employ the result (with a suitable private key) on the server side. Only the client side, you'll need just the root CA cert in the default system location (see docs for c_rehash) or explicitly loaded by the client as a CAfile. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Can we have a PyOpenSSL 0.15?
I don't think this is the right place to ask on. This list is for OpenSSL itself, not the python binding to it. The PyOpenSSL folks may be watching this list, but this list is probably not the official list to discuss it. -Kyle H On September 8, 2014 8:56:35 AM PST, Eric Chazan eric.cha...@sungardas.com wrote: All, My team is considering a port to Python 3 from Python 2.7. One issue we see is that we cant run a flask server with ssl. I am seeing that the fix is in this pull request: https://github.com/pyca/pyopenssl/pull/78/commits Which has already been merged. Is a new version of PyOpenSSL coming that contains this pull request? Thanks, Eric Chazan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
RE: Value of DEFAULT cipher suite
Master has security levels, which still need some work, but are a less crude mechanism for such tweaks. Disabling RC4 at security level 2 or some such, is better than incompatibly reclassifying it as LOW. We can discuss the details later. That should probably also be done. But things like HIGH LOW, etc are point-in-time statements and raising the bar so that existing applications just get more secure without having to change anything is also worth doing. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Tuesday, 09 September, 2014 09:01 To: openssl-users@openssl.org Subject: Re: Value of DEFAULT cipher suite On Tue, Sep 09, 2014 at 08:42:36AM -0400, Salz, Rich wrote: Moving RC4 to LOW is also premature. It is already at the bottom of the medium cipherlist, that should be enough. I am planning on doing it for master, not 1.0.2 That means it won't be in an official release until... what, at least six months. Master has security levels, which still need some work, but are a less crude mechanism for such tweaks. Disabling RC4 at security level 2 or some such, is better than incompatibly reclassifying it as LOW. We can discuss the details later. For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in the default set is better than not having it there at all. The work factor and conditions for the best attacks on RC4 (around 2**24 largely-similar plaintexts, unless I've missed more-recent improvements, which is certainly possible) are potentially dangerous for some applications - particularly HTTPS against server clusters that will handle the load, where a client (generally a browser) can be tricked into making the requests (generally via malicious scripting). But for other applications it could be much more difficult, in practice, to mount the attack. I think it's fair to say that RC4 is strictly weaker than the other medium ciphers (SEED and RC2), since the best published attacks against RC4 are definitely considerably more feasible than those against the other two. But as Victor said, it's better than plaintext; and it's still very widely used (often preferentially), so there's a decent chance that an OpenSSL-based application using the default suite list will encounter a peer that only supports RC4. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Value of DEFAULT cipher suite
On Tue, Sep 09, 2014 at 10:40:26AM -0400, Salz, Rich wrote: That should probably also be done. But things like HIGH LOW, etc are point-in-time statements and raising the bar so that existing applications just get more secure without having to change anything is also worth doing. This is often a misconception. There are two bars that can be raised. The floor and the ceiling. Raising the ceiling (strength of most preferred algorithms) improves security. For example implement ChaCha with Poly1305, and prefer it to RC4. Raising the floor often breaks interoperability, and leads to people disabling security or automatically failing over to cleartext, ... https://www.ietf.org/mail-archive/web/perpass/current/msg00654.html While there are minor inaccuracies in that post, the core points stand. Far more productive than disabling RC4 would be ensuring that it is not the preferred cipher suite when better options are enabled. To improve security, raise the ceiling. ChaCha, new EC curves, extensions to negotiate DH parameters, ... Raising the floor can do more harm than good. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
For what it's worth, I'm with Victor on this. RC4 as cipher of last resort in the default set is better than not having it there at all. Take it up with the IETF which has two working groups advocating against it. UTA (use of TLS in applications) and the TLS group itself: https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02 Implementations MUST NOT negotiate RC4 cipher suites https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00 As a result, RC4 can no longer be seen as providing a sufficient level of security for TLS sessions. To improve security, raise the ceiling. An equal number of experienced people are equally firm that the only way to raise the standard of practice is to remove bad ciphers. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
Far more productive than disabling RC4 would be ensuring that it is not the preferred cipher suite when better options are enabled. I am not disabling RC4. I am saying that applications that want to use it will, after the post-1.0.2 release is adopted, need to take pro-active action. This follows the current thinking of the IETF. It's just being standards-compliant. If you say security levels are a better way to handle this then why don't security levels require RC4? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate pass phrase brute force...
As far as I know, openssl req doesn't let you specify the encryption cipher for the private key. You can generate the key file first, with openssl genpkey, which does let you specify the encryption cipher; and then use -key to tell openssl to use your existing key rather than creating a new one. You can also do what you describe below, but not encrypt the private key the first time, by using the -nodes option with openssl req; that saves decrypting it before encrypting it with your preferred cipher. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Tuesday, 09 September, 2014 01:19 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... I used the asn1parse command [thanks Dave!] and while the key looks old style it parses as follows: 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC mode The full asn parse is: --- 0:d=0 hl=4 l=2446 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT:PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 20 cons: SEQUENCE 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) --- [I don't know if I needed to redact those fields at all, but I don't think it matters.) So, if I've read that properly, the encryption method is 3DES. --- While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA script from OpenVPN - I thought I'd share a solution that appears to work and do what I want. It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 3DES cypher] in the script. From my look at the syntax of a openssl req -new -newkey ... command, you don't get to specify the cypher it will use in encrypting the private key. This appears to be a result of generating both the key and the signing request in a single step - in this case you don't appear to get to choose what crypto is used to encrypt the private key. [I'd be glad to be shown a way you can specify it - it doesn't appear possible from the command-line options at least.] However, as I pointed out there is code in the EasyRSA tool to re-encrypt the private key with a new password, or remove the password. You can edit the script to use aes256 as follows: [or any of the other cyphers here: https://www.openssl.org/docs/apps/rsa.html#https://www.openssl.org/docs/apps/rsa.html] In the easyrsa bash script: Look for the line: [ local crypto=-des3 ] (It's line 861 in the current EasyRSA version) Change it to: [ local crypto=-aes256 ] Now when you issue the command easyrsa set-rsa-pass, and issue the old encryption key, along with a new one [you can certainly use the same key for the old and new] it will re-encrypt it with aes-256. Looking at the key file it does appear to indeed work and re-encrypts it with AES-256. #cat somekey.key -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC ... --- Thus, this is the best work-around for the tool I can find. Unfortunately it requires a redundant step unless someone can show me a way to put the encryption type for private keys in a config file or specify it as part of a openssl -req ... command But at least it works the way I want it to, and makes the task of setting up keys and certs a bit easier than raw openssl commands. Hope that helps someone else too. And thanks again for all the pointers and tips! [Ya'll are probably going to chuckle and say If you'd just dumped that lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd have avoided all this hoopla in the first place! And yeah, you're probably right - but I trust a good script to do it right more often than I trust myself - but perhaps that trust is misplaced in this case.] Again, glad for any follow-up advice - it's been an interesting thread - at least for me. -Greg For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY) just look on the DEK-Info: header line. For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do openssl asn1parse key.pem and the third line will be an OBJECT (really OID) in the form pbeWithhashandcipher. From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Monday, September 08, 2014 20:58 snip --On that note: Is there a way to determine from an encrypted key-file what encryption was used to encrypt it? [I have the password, so it
RE: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Iñaki Baz Castillo Sent: Tuesday, 09 September, 2014 09:10 To: openssl-users@openssl.org Subject: Re: Why does OpenSSL own all the prefixes in the world? 2014-09-09 13:14 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com: You'd have to include the standard C headers before including the OpenSSL ones, outside the namespace, so that their inclusion by the OpenSSL headers has no effect. I did that, but if a openssl header file includes standard C headers that I don't include, then the namespace declaration would affect them too, am I wrong? It shouldn't. The C standard says that the second and subsequent inclusion of a standard header has no effect, and I believe the current C++ standard inherits that rule. All the implementations I know of (with maybe some special exceptions like Splint) implement that with inclusion guards - conditional-compilation directives around all the contents of the file. So if a standard header is included once outside any namespace, then if it's included again inside a namespace, it shouldn't declare anything in that namespace, because all its contents should be skipped. I believe namespaces don't affect macro identifiers, so the guards should work. I could be wrong about that, though. I haven't tried it myself, and I don't know the C++ standard nearly as well as the C one. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
Re: On 2K keys and SHA-256
I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. 2014-09-09 14:18 GMT+02:00 Salz, Rich rs...@akamai.com: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
We disagree. I've got two IETF WG's coming to the same conclusion so making post-1.0.2 follow IETF practices seems pretty inarguable. The IETF is sadly also prone to knee-jerk reactions. True. Some would put perpass in that category. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
Yes, I'm jumping the gun claiming that the I-D are standards. They're not. They're just drafts. I'm willing to wait and see what happens for a few months. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote: I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. Have any numbers to back that up? The performance ratios are likely similar for recent and not so recent CPUs: signverifysign/s verify/s rsa 1024 bits 0.000385s 0.25s 2599.2 40210.7 rsa 2048 bits 0.002494s 0.78s401.0 12762.7 rsa 4096 bits 0.017500s 0.000284s 57.1 3527.3 On my CPU the sign/s ratios for the two steps are 6.5 and 7.0, which are quite significant. The performance gulf between 1024 and 4096 is rather wide, while the security gain from 2048 to 4096 is far from clear. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Value of DEFAULT cipher suite
I can see RC4 going in the list of low security ciphers within a couple of years anyways, so we can better discourage the usage right now. 2014-09-09 18:14 GMT+02:00 Salz, Rich rs...@akamai.com: We disagree. I've got two IETF WG's coming to the same conclusion so making post-1.0.2 follow IETF practices seems pretty inarguable. The IETF is sadly also prone to knee-jerk reactions. True. Some would put perpass in that category. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verifying authenticode signature using openssl API
On 09/09/2014 09:01, Prasad Dabak wrote: Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. This time I have CC-ed you in addition to the mail list. I have a few follow-up questions on your response. 1. So, encryptedDigest has no relation to the stored messageDigest? I thought it's a encrypted version of the messageDigest? As far as I recall, there is a chain of 4 digests. The first digest is calculated over the file and is stored in the spcIndirectData. The second digest is calculated over the spcIndirectData (the contentInfo of the the PKCS#7 structure) and is stored as messageDigest in the AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash is calculated over the AuthenticatedAttributes and is signed to produce the encryptedDigest in that same signerInfo. All 3 need to be checked to confirm that the file hash is actually (indirectly) signed by the encryptedDigest using the public key in the certificate whose name is listed in the signerInfo. 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP checksum of file). Also it is allowed to be 0 to indicate no checksum (even if you set the checksum, it might be cleared if an Administrator adds his own countersignature to all authorized programs on his computers, aka AppLocker). 3. spcPEImageData is probably relevant only for signing that uses page hashes? I never quite figured out where they store the page hashes. However I believe the constant semi-empty spcPEImageData with the obsolete string is the traditional marker to indicate that the signature is for a PE file, and not e.g. a document file with the same hashed bytestream. 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? If it is, I am myself guessing a bit as to what that function does and does not check. But note that it probably doesn't check the full chain of 3 message digests, since at least the digest over the file itself is inside a blob that the PKCS#7 standard has no opinion about. 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate? Actually, the subject is a data structure (a hierarchical list of sets of tagged strings) and the relevant comparison would be to compare those elements that don't change when getting a new certificate from the CA. It is the CAs responsibility to make sure the don't issue certificates to the wrong people, and if they make a mistake they are expected to quickly add the bad certificate to their published CRL, which is why you need to check the CRL before trusting the certificate. An additional check is to make sure the CA that issued the intermediary certificate that issued the COMAPNY-NAME certificate is actually one of the (few) CAs that COMPANY-NAME is going to buy certificates from. This protects against fake certificates issued by smaller CAs that you aren't going to use anyway. In my case, I am the one who is signing the executable using my certificate and a cross certificate issued by Microsoft and I want to programmatically ensure following things. 1. Code is not tampered since it was signed (matching messageDigest with computed hash) Actually matching digest in spcIndirectData with computed hash. Plus consistency checks to make sure the signature is actually for a PE file and was not otherwise doctored. For instance there should be no bytes in the file after the end of the signature blob. 2. Verifying the digital signature (PKCS7_Verify) 3. Confirming that the executable is signed by my company certificate. I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key? Yep, that is why careful matching against various Distinguished Name fields is needed. On Sep 06, 2014, at 09:44 PM, Prasad Dabak pda...@icloud.com wrote: Hello, Given a signed Windows portable executable, I want to programmatically verify two things using openssl APIs 1. Verify the digital signature. 2. Confirm that the executable is signed by a specific company using that company's public key. It seems that part (1) can be done by parsing the signedData attribute in the portable executable, extracting the hashing algorithm and digest stored there, re-computing the digest of the executable using the same hashing algorithm and match them. I have following questions. 1. The signData contains messageDigest (unencrypted) and encryptedDigest (encrypted). Is it enough to match
Re: Value of DEFAULT cipher suite
On Tue, Sep 09, 2014 at 12:14:36PM -0400, Salz, Rich wrote: We disagree. I've got two IETF WG's coming to the same conclusion so making post-1.0.2 follow IETF practices seems pretty inarguable. The IETF is sadly also prone to knee-jerk reactions. True. Some would put perpass in that category. Which is why I cautioned against overly hasty counter-measures. I don't disagree that applications and operators should generally disable RC4. Howerver, OpenSSL is not the right place to do so. In opportunistic TLS, disabling RC4 is often worse than leaving it enabled. The library should provide a sensible default preference order, and a sensible choice of DEFAULT cipher suites, these can be updated from time to time. Dropping cipher suites nobody is using is fine. Dropping cipher suites that are in wide use, and making the choice in code below the application layer is I think unwise. We could introduce a new cipher suite class name BCP, to complement DEFAULT. The latter is broadly interoperable with sensible ordering but inclusive cipher choices, the former would be more restrictive, offering only the BCP cipher suites, sensibly ordered. Applications that want BCP, could have it. Applications that emphasize interoperability would use DEFAULT. Then you would be free to tweak BCP more aggressively than DEFAULT. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Salz, Rich Sent: Tuesday, 09 September, 2014 11:35 To: openssl-users@openssl.org Subject: RE: Value of DEFAULT cipher suite Far more productive than disabling RC4 would be ensuring that it is not the preferred cipher suite when better options are enabled. I am not disabling RC4. I am saying that applications that want to use it will, after the post-1.0.2 release is adopted, need to take pro-active action. Which is tantamount to disabling it, for any applications that: - Link OpenSSL dynamically and don't set a non-default cipher suite list - Are rebuilt with the new OpenSSL but aren't changed to set a non-default cipher suite list You're talking about violating the Principle of Least Surprise, which is rarely a good idea. This follows the current thinking of the IETF. Glossing what's currently in an I-D as the current thinking of the IETF is quite a stretch. And UTA applies to *applications*, not to libraries. And personally I think UTA is somewhat misguided, particularly in its excessive use of RFC 2119 conditional-compliance (MUST) requirements in sections that the text refers to as recommendations; and I'm not convinced the authors have done a good job of considering the ramifications. As for the PRC4 I-D: It too applies to applications; and unless OpenSSL is going to enforce the final requirement of part 2 (the TLS server MUST terminate the handshake), I can't see how you can claim your proposed change is following the I-D. Without that final requirement, the other two are potentially more dangerous than allowing RC4. It's just being standards-compliant. Which standard are we talking about? In your other message you cited to I-Ds, which are NOT standards. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why does OpenSSL own all the prefixes in the world?
2014-09-09 17:58 GMT+02:00 Michael Wojcik michael.woj...@microfocus.com:
I did that, but if a openssl header file includes standard C headers
that I don't include, then the namespace declaration would affect them
too, am I wrong?
It shouldn't. The C standard says that the second and subsequent inclusion of
a standard header has no effect, and I believe the current C++ standard
inherits that rule.
All the implementations I know of (with maybe some special exceptions like
Splint) implement that with inclusion guards - conditional-compilation
directives around all the contents of the file.
So if a standard header is included once outside any namespace, then if it's
included again inside a namespace, it shouldn't declare anything in that
namespace, because all its contents should be skipped. I believe namespaces
don't affect macro identifiers, so the guards should work.
I could be wrong about that, though. I haven't tried it myself, and I don't
know the C++ standard nearly as well as the C one.
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
--
Iñaki Baz Castillo
i...@aliax.net
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
No, I do not have numbers to back it up, that is why my guess is that 3K-RSA is the next step after 2K-RSA. It also depends on what data you are planning to transport, and in what kind of organisation you are. 2014-09-09 18:21 GMT+02:00 Viktor Dukhovni openssl-us...@dukhovni.org: On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote: I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. Have any numbers to back that up? The performance ratios are likely similar for recent and not so recent CPUs: signverifysign/s verify/s rsa 1024 bits 0.000385s 0.25s 2599.2 40210.7 rsa 2048 bits 0.002494s 0.78s401.0 12762.7 rsa 4096 bits 0.017500s 0.000284s 57.1 3527.3 On my CPU the sign/s ratios for the two steps are 6.5 and 7.0, which are quite significant. The performance gulf between 1024 and 4096 is rather wide, while the security gain from 2048 to 4096 is far from clear. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Value of DEFAULT cipher suite
Folks who want strong BCP crypto, can disable MEDIUM. Folks who want weak non-BCP crypto can enable LOW. I'm putting this on hold to see where we are 6-9 months from now. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Value of DEFAULT cipher suite
On 09/09/2014 00:42, Salz, Rich wrote: We are considering removing weak cryptography from the value of DEFAULT. That is, append :!LOW:!EXPORT It is currently defined as this in include/openssl/ssl.h: #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 Please let us know if you have strong objections to this. In addition to removing the very-weak (less than 70 bits security) ciphers from the default list,this would be a good opportunity to reorder the default list (either via the define, or bettervia whatever internal priorities guide the interpretation of a similar user-provided list), tomaximize security, similar to what is checked e.g. by the online ssllabs checker. Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits, ...), also enable 0/n splitting (and/or prefer a stream cipher)for CBC encryption with older TLS protocol versions whenever the send timing makes them otherwise subject to BEAST. The latter is, by the way, the reason many systems have *recently* been configured to explicitly prefer RC4 as the only unbroken cipher compatible with servers or clients that don't protect against BEAST in other ways. To protect from the known RC4 repeated-plaintext vulnerability, one might consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is actually used. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, 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: Why does OpenSSL own all the prefixes in the world?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, 09 September, 2014 12:44
To: openssl-users@openssl.org
Subject: Re: Why does OpenSSL own all the prefixes in the world?
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
Yes, in this case I'd expect that error. You need to include stdlib.h outside
of any namespace before you include openssl/foo.h.
My advice would be to stick a bunch of include statements for all the standard
headers used by any openssl/*.h into a single .h file, and then include that at
the top of myproject.h and any other C++ header file that includes an OpenSSL
header.
So:
- Create openssl_c_hdrs.h which has:
#include stdlib.h
#include stdio.h
#include string.h
...
- Change myproject.h to have:
#include openssl_c_hdrs.h
namespace myproject {
#include openssl/foo.h
}
Again, I can't say for sure that will work, because I haven't tested it. But it
ought to work around this particular issue. The standard headers included by
openssl_c_hdrs.h will preempt their inclusion within the namespace by the
OpenSSL headers.
Of course, for C++ code you normally wouldn't include the C standard headers;
you'd use their C++ versions (cstdlib, etc). But this sort of thing is a
special case.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
RE: cannot read PEM key file - no start line
Hi Jeff,
Please find the certificates attached.
openssl x509 -in DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pembackup
-inform PEM -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1085434364 (0x40b269fc)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=Wells Fargo, OU=Wells Fargo Certification Authority,
CN=Wells Fargo Root Certificate Authority
Validity
Not Before: May 28 18:17:26 2009 GMT
Not After : May 28 18:17:26 2019 GMT
Subject: C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities,
CN=Wells Fargo Enterprise CA 02
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9b:59:84:56:05:e5:1c:76:dd:e0:3a:ca:14:84:
4e:4d:fe:90:e4:9c:33:24:4b:63:16:25:8d:e2:54:
2c:12:f2:9e:54:dd:69:ef:fb:9a:d7:a7:34:80:58:
62:cd:0b:ee:0f:4d:36:a6:db:54:1b:b4:e7:ea:e5:
28:9d:46:31:25:a8:c3:d9:39:f2:90:04:2e:d6:6e:
4a:b3:58:22:b0:d8:18:08:6c:c7:f2:d9:6e:29:e5:
98:00:da:69:49:1b:79:17:52:2c:dd:8b:6c:34:e1:
a2:62:d5:45:9d:97:f7:15:e8:ce:cd:55:a4:86:74:
f9:ad:85:e3:4d:ff:4e:b2:ee:4a:2b:52:61:ec:dc:
b0:6c:55:39:3f:6c:ad:0b:88:7f:33:dc:67:94:7b:
82:8f:2e:d1:06:63:7d:e7:a8:86:ec:46:fe:04:1a:
ef:a3:b6:5f:4d:fc:d6:b8:5c:e6:bd:f8:9c:2a:8b:
e8:0d:b6:4e:96:82:c7:1e:c4:73:8f:68:90:d9:eb:
98:fb:15:bf:83:e6:67:d6:51:cf:40:26:5f:4d:d2:
e0:3d:47:27:57:ba:a9:3f:ed:5f:45:5c:b9:84:d2:
d0:4f:0d:e7:06:b3:5a:e5:12:c8:64:af:11:06:96:
3a:92:28:38:c1:68:72:34:a3:fe:f5:2b:1c:da:6d:
f8:95
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Certificate Policies:
Policy: 2.16.840.1.114171.500.0.0
CPS: http://www.wellsfargo.com/cps/
Policy: 2.16.840.1.114171.500.0.1
CPS: http://www.wellsfargo.com/cps/
Authority Information Access:
OCSP - URI:http://ocsp-root.pki.wellsfargo.com/
CA Issuers - URI:http://crl.pki.wellsfargo.com/wf_root.crt
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data
Encipherment, Certificate Sign, CRL Sign
X509v3 Authority Key Identifier:
keyid:14:AF:18:F7:BD:E6:E7:6B:E3:5A:FA:EA:51:EF:FE:D4:5A:71:39:C0
DirName:/C=US/O=Wells Fargo/OU=Wells Fargo Certification
Authority/CN=Wells Fargo Root Certificate Authority
serial:39:E4:97:9E
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.pki.wellsfargo.com/root.crl
X509v3 Subject Key Identifier:
C4:AB:45:B6:3A:0B:01:1C:62:5C:CA:3F:C7:E3:CD:2F:30:C4:57:D7
Signature Algorithm: sha1WithRSAEncryption
2d:42:30:eb:21:4d:8f:b9:ab:4d:22:2e:aa:d4:fa:ae:c0:17:
80:a0:29:ca:52:37:1e:d7:a9:6d:66:ba:ab:11:26:98:30:e3:
08:06:8e:c5:76:4a:4a:14:f1:05:06:ba:a9:2a:58:16:0d:0a:
17:1a:8a:b0:d8:a8:b7:c0:80:10:cc:57:71:aa:6b:e4:e2:f0:
ca:d4:c5:be:70:d2:45:af:47:fa:69:4b:4f:a8:e9:66:2f:02:
dd:f6:ea:12:f6:d5:7a:1e:cd:8d:3e:28:8f:c7:cd:6e:c7:f5:
dd:48:0d:d3:1c:65:82:27:b3:e3:b9:68:71:65:40:0d:d6:0f:
fd:1b:9c:1b:7d:68:fb:c3:aa:25:a6:7f:f8:05:ac:73:e0:7a:
2e:84:3d:8d:a6:25:61:a8:97:5c:44:50:a2:92:d2:f1:dc:53:
78:6a:7c:a6:f9:9d:60:ae:20:84:71:bf:03:02:d6:d1:f1:1c:
6a:a4:0e:aa:b0:5c:7f:c0:3e:df:f4:50:60:47:49:eb:6b:d9:
f1:0f:53:e8:7c:1b:74:fa:f4:cd:3a:2a:79:53:39:8b:e0:e0:
2e:3c:b6:7e:ad:5e:12:9e:9a:e4:89:f4:37:bf:2d:92:01:2b:
f0:d3:e5:a4:f8:1b:f7:70:ba:4f:c9:0d:62:2a:10:63:6d:1d:
36:49:6a:2d
This is the C++ MongoDB API I am using to connect to the database:
#include mongo/util/net/ssl_options.h
#include mongo/client/init.h
int main() {
sslGlobalParams.sslMode.store(SSLGlobalParams::SSLMode_requireSSL);
// only really need a PEM on the server side
mongo::sslGlobalParams.sslPEMKeyFile = path/to/keyfile.pem;
mongo::Status status = mongo::client::initialize();
if (!status.isOK())
::abort();
DBClientConnection c;
c.connect(hostname.whatever.com); // outgoing connections are SSL
}
My question to MongoDB support was: From the code above, the comment states
that there is only a need of a PEM on the server side. What identifies the key
store on the C++ client server? Is
RE: Value of DEFAULT cipher suite
In addition to removing the very-weak (less than 70 bits security) ciphers from the default list,this would be a good opportunity to reorder the default I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and rather strong :) feelings on the subject. Doing things like putting PFS first would greatly increase the computation load on servers and doesn't seem like the right thing to do as a quiet change. (But yes, moving RC4 down to LOW does seem to me like the right thing to do. :) To protect from the known RC4 repeated-plaintext vulnerability, one might consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is actually used. The TLS WG looked at adding arbitrary padding as a record type. I hope it comes back. Maybe the fact that the next TLS WG interim meeting will be at INRIA, home of the triple-handshake attack and the padding proposal, will have some effect :) -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
On 09/09/2014 14:18, Salz, Rich wrote: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. There was (some years ago) a heated debate between Certicom/NSA and the rest of the crypto community regarding the RSA sizes needed to match a given symmetric key security level. I don't know if it was ever resolved, but I guess some are going to use the old Certicom list to choose their RSA key sizes. Another, related problem is the large amount of patent FUD (and maybe real issues too) regarding the ECC patent situation, causing many applications to only use traditional RSA, DSA and DH, rather than their ECC counterparts. Until this problem is truly resolved for everybody (not just the OpenSSL project and the US Government), supporting even painfully slow RSA, DSA and DH key lengths is a practical necessity. Note that the only public guidance I have found on this was written by the NSA, which affects it credibility in the current international political climate. One problem which I recently encountered when using stunnel for a dedicated long running session is that OpenSSL 1.0.1 apparently rejects large client keys with SSL_accept: 1408E098: error: 1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size, which forced me to downgrade from 6K RSA to 4K RSA for the client auth. But this was for a dedicated link where the CPU overhead was acceptable. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, 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
Re: Value of DEFAULT cipher suite
On Tue, Sep 09, 2014 at 07:04:36PM +0200, Jakob Bohm wrote: In addition to removing the very-weak (less than 70 bits security) ciphers from the default list,this would be a good opportunity to reorder the default list (either via the define, or bettervia whatever internal priorities guide the interpretation of a similar user-provided list), tomaximize security, similar to what is checked e.g. by the online ssllabs checker. Basically: Prefer PFS suites to non-PFS suites (i.e. prefer EDH/ECDH to bare RSA) at each nominalsecurity level (256 bits, 192 bits, 128 bits, ...) This is already the case starting 1.0.0. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate pass phrase brute force...
At least 3DES is *some* encryption. The issue is that peoples' computers are usually infested with malware; it's better to assume (for a software distribution) that the disk is compromised, and always encrypt it before writing. Perhaps there should be a cipher option for the req -newkey option? -Kyle H On September 9, 2014 8:58:08 AM PST, Michael Wojcik michael.woj...@microfocus.com wrote: As far as I know, openssl req doesn't let you specify the encryption cipher for the private key. You can generate the key file first, with openssl genpkey, which does let you specify the encryption cipher; and then use -key to tell openssl to use your existing key rather than creating a new one. You can also do what you describe below, but not encrypt the private key the first time, by using the -nodes option with openssl req; that saves decrypting it before encrypting it with your preferred cipher. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Tuesday, 09 September, 2014 01:19 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... I used the asn1parse command [thanks Dave!] and while the key looks old style it parses as follows: 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC mode The full asn parse is: --- 0:d=0 hl=4 l=2446 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT:PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 20 cons: SEQUENCE 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) --- [I don't know if I needed to redact those fields at all, but I don't think it matters.) So, if I've read that properly, the encryption method is 3DES. --- While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA script from OpenVPN - I thought I'd share a solution that appears to work and do what I want. It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 3DES cypher] in the script. From my look at the syntax of a openssl req -new -newkey ... command, you don't get to specify the cypher it will use in encrypting the private key. This appears to be a result of generating both the key and the signing request in a single step - in this case you don't appear to get to choose what crypto is used to encrypt the private key. [I'd be glad to be shown a way you can specify it - it doesn't appear possible from the command-line options at least.] However, as I pointed out there is code in the EasyRSA tool to re-encrypt the private key with a new password, or remove the password. You can edit the script to use aes256 as follows: [or any of the other cyphers here: https://www.openssl.org/docs/apps/rsa.html#https://www.openssl.org/docs/apps/rsa.html] In the easyrsa bash script: Look for the line: [ local crypto=-des3 ] (It's line 861 in the current EasyRSA version) Change it to: [ local crypto=-aes256 ] Now when you issue the command easyrsa set-rsa-pass, and issue the old encryption key, along with a new one [you can certainly use the same key for the old and new] it will re-encrypt it with aes-256. Looking at the key file it does appear to indeed work and re-encrypts it with AES-256. #cat somekey.key -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC ... --- Thus, this is the best work-around for the tool I can find. Unfortunately it requires a redundant step unless someone can show me a way to put the encryption type for private keys in a config file or specify it as part of a openssl -req ... command But at least it works the way I want it to, and makes the task of setting up keys and certs a bit easier than raw openssl commands. Hope that helps someone else too. And thanks again for all the pointers and tips! [Ya'll are probably going to chuckle and say If you'd just dumped that lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd have avoided all this hoopla in the first place! And yeah, you're probably right - but I trust a good script to do it right more often than I trust myself - but perhaps that trust is misplaced in this case.] Again, glad for any follow-up advice - it's been an interesting thread - at least for me. -Greg For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY) just look on the DEK-Info: header line. For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do openssl asn1parse key.pem and the third line will be an OBJECT (really OID) in the
RE: Certificate pass phrase brute force...
Sure, if that's a better fit to your threat model. (I certainly wouldn't recommend changing openssl req to make -nodes the default.) I was just suggesting possibilities for Gregory. Personally, I'd probably go with generating an encrypted private key with openssl genpkey first, but that might be more changes to the EasyRSA script than he's inclined to make. He has a working solution now which seems fine for his purposes. A cipher option for openssl req -newkey wouldn't be a bad idea, but it's not a high priority, so I wouldn't expect it to happen anytime soon unless someone wants to submit a patch. Michael Wojcik Technology Specialist, Micro Focus From: Kyle Hamilton [mailto:aerow...@gmail.com] Sent: Tuesday, 09 September, 2014 13:43 To: openssl-users@openssl.org; Michael Wojcik Subject: RE: Certificate pass phrase brute force... At least 3DES is *some* encryption. The issue is that peoples' computers are usually infested with malware; it's better to assume (for a software distribution) that the disk is compromised, and always encrypt it before writing. Perhaps there should be a cipher option for the req -newkey option? -Kyle H On September 9, 2014 8:58:08 AM PST, Michael Wojcik michael.woj...@microfocus.com wrote: As far as I know, openssl req doesn't let you specify the encryption cipher for the private key. You can generate the key file first, with openssl genpkey, which does let you specify the encryption cipher; and then use -key to tell openssl to use your existing key rather than creating a new one. You can also do what you describe below, but not encrypt the private key the first time, by using the -nodes option with openssl req; that saves decrypting it before encrypting it with your preferred cipher. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Tuesday, 09 September, 2014 01:19 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... I used the asn1parse command [thanks Dave!] and while the key looks old style it parses as follows: 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC mode The full asn parse is: --- 0:d=0 hl=4 l=2446 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT:PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 20 cons: SEQUENCE 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) --- [I don't know if I needed to redact those fields at all, but I don't think it matters.) So, if I've read that properly, the encryption method is 3DES. --- While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA script from OpenVPN - I thought I'd share a solution that appears to work and do what I want. It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non 3DES cypher] in the script. From my look at the syntax of a openssl req -new -newkey ... command, you don't get to specify the cypher it will use in encrypting the private key. This appears to be a result of generating both the key and the signing request in a single step - in this case you don't appear to get to choose what crypto is used to encrypt the private key. [I'd be glad to be shown a way you can specify it - it doesn't appear possible from the command-line options at least.] However, as I pointed out there is code in the EasyRSA tool to re-encrypt the private key with a new password, or remove the password. You can edit the script to use aes256 as follows: [or any of the other cyphers here: https://www.openssl.org/docs/apps/rsa.html#https://www.openssl.org/docs/apps/rsa.html] In the easyrsa bash script: Look for the line: [ local crypto=-des3 ] (It's line 861 in the current EasyRSA version) Change it to: [ local crypto=-aes256 ] Now when you issue the command easyrsa set-rsa-pass, and issue the old encryption key, along with a new one [you can certainly use the same key for the old and new] it will re-encrypt it with aes-256. Looking at the key file it does appear to indeed work and re-encrypts it with AES-256. #cat somekey.key -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC ... --- Thus, this is the best work-around for the tool I can find. Unfortunately it requires a redundant step unless someone can show me a way to put the encryption type for private keys in a config file or specify it as part of a openssl -req ... command But at least it works the
Re: Value of DEFAULT cipher suite
On 09/09/2014 19:20, Salz, Rich wrote: In addition to removing the very-weak (less than 70 bits security) ciphers from the default list,this would be a good opportunity to reorder the default I'd prefer to wait until TLS 1.3 is implemented, which has some definite (and rather strong :) feelings on the subject. Doing things like putting PFS first would greatly increase the computation load on servers and doesn't seem like the right thing to do as a quiet change. (But yes, moving RC4 down to LOW does seem to me like the right thing to do. :) You conveniently snipped the part of my post which explained why RC4 is currently the*strongest* available cipher when talking to some clients, being (in those situations)effectively stronger than AES-256 CBC, despite its known weaknesses. To protect from the known RC4 repeated-plaintext vulnerability, one might consider adding rate limiting to some SSL/TLS protocol steps whenever RC4 is actually used. The TLS WG looked at adding arbitrary padding as a record type. I hope it comes back. Maybe the fact that the next TLS WG interim meeting will be at INRIA, home of the triple-handshake attack and the padding proposal, will have some effect :) That arbitrary padding (or any other future TLS feature) will do nothing to mitigate the problem that interoperating with some widely deployed real world clients leaves the choice between CBC with no mitigation and RC4 with limitedkey lifespan (e.g. max 2**?? bytes encrypted with any given key). You really should look at the extensive research done by SSL Labsbefore blindly deprecating stuff. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, 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: Value of DEFAULT cipher suite
You really should look at the extensive research done by SSL Labsbefore blindly deprecating stuff. Sorry you think I'm doing that. I'm raising an issue six months before it will affect people. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verifying authenticode signature using openssl API
Thanks Jacob for your response. Very informative indeed! Thanks -Prasad Sent from my iPhone On 09-Sep-2014, at 10:05 pm, Jakob Bohm jb-open...@wisemo.com wrote: On 09/09/2014 09:01, Prasad Dabak wrote: Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. This time I have CC-ed you in addition to the mail list. I have a few follow-up questions on your response. 1. So, encryptedDigest has no relation to the stored messageDigest? I thought it's a encrypted version of the messageDigest? As far as I recall, there is a chain of 4 digests. The first digest is calculated over the file and is stored in the spcIndirectData. The second digest is calculated over the spcIndirectData (the contentInfo of the the PKCS#7 structure) and is stored as messageDigest in the AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash is calculated over the AuthenticatedAttributes and is signed to produce the encryptedDigest in that same signerInfo. All 3 need to be checked to confirm that the file hash is actually (indirectly) signed by the encryptedDigest using the public key in the certificate whose name is listed in the signerInfo. 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP checksum of file). Also it is allowed to be 0 to indicate no checksum (even if you set the checksum, it might be cleared if an Administrator adds his own countersignature to all authorized programs on his computers, aka AppLocker). 3. spcPEImageData is probably relevant only for signing that uses page hashes? I never quite figured out where they store the page hashes. However I believe the constant semi-empty spcPEImageData with the obsolete string is the traditional marker to indicate that the signature is for a PE file, and not e.g. a document file with the same hashed bytestream. 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? If it is, I am myself guessing a bit as to what that function does and does not check. But note that it probably doesn't check the full chain of 3 message digests, since at least the digest over the file itself is inside a blob that the PKCS#7 standard has no opinion about. 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate? Actually, the subject is a data structure (a hierarchical list of sets of tagged strings) and the relevant comparison would be to compare those elements that don't change when getting a new certificate from the CA. It is the CAs responsibility to make sure the don't issue certificates to the wrong people, and if they make a mistake they are expected to quickly add the bad certificate to their published CRL, which is why you need to check the CRL before trusting the certificate. An additional check is to make sure the CA that issued the intermediary certificate that issued the COMAPNY-NAME certificate is actually one of the (few) CAs that COMPANY-NAME is going to buy certificates from. This protects against fake certificates issued by smaller CAs that you aren't going to use anyway. In my case, I am the one who is signing the executable using my certificate and a cross certificate issued by Microsoft and I want to programmatically ensure following things. 1. Code is not tampered since it was signed (matching messageDigest with computed hash) Actually matching digest in spcIndirectData with computed hash. Plus consistency checks to make sure the signature is actually for a PE file and was not otherwise doctored. For instance there should be no bytes in the file after the end of the signature blob. 2. Verifying the digital signature (PKCS7_Verify) 3. Confirming that the executable is signed by my company certificate. I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key? Yep, that is why careful matching against various Distinguished Name fields is needed. On Sep 06, 2014, at 09:44 PM, Prasad Dabak pda...@icloud.com wrote: Hello, Given a signed Windows portable executable, I want to programmatically verify two things using openssl APIs 1. Verify the digital signature. 2. Confirm that the executable is signed by a specific company using that company's public key. It seems that part (1) can be done by parsing the signedData attribute in the portable executable, extracting the hashing algorithm and digest stored there,
RE: Why does OpenSSL own all the prefixes in the world?
In the FWIW column Please don't mangle names by forcing C++ namespaces.
Some us call OpenSSL from Python (and other dynamic languages) and depend on
the C naming convention. Adding a OSSL_ prefix is fine; mangling creates
huge problems.
-- Sent fm iTouch via Boxer
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, 09 September, 2014 12:44
To: openssl-users@openssl.org
Subject: Re: Why does OpenSSL own all the prefixes in the world?
May be I was not clear, but what I mean is:
- Let's suppose openssl/foo.h has a #include stdlib.h.
- In myproject.h I add:
namespace myproject {
#include openssl/foo.h
}
- And then in myproject.cpp I write:
p = (char*)malloc(sizeof(char) * 100);
Would this produce the malloc not found, may be you mean
'myproject::malloc'? error?
PS: Note that I do NOT include sdtlib.h in myproject.*.
Yes, in this case I'd expect that error. You need to include stdlib.h outside
of any namespace before you include openssl/foo.h.
My advice would be to stick a bunch of include statements for all the standard
headers used by any openssl/*.h into a single .h file, and then include that at
the top of myproject.h and any other C++ header file that includes an OpenSSL
header.
So:
- Create openssl_c_hdrs.h which has:
#include stdlib.h
#include stdio.h
#include string.h
...
- Change myproject.h to have:
#include openssl_c_hdrs.h
namespace myproject {
#include openssl/foo.h
}
Again, I can't say for sure that will work, because I haven't tested it. But it
ought to work around this particular issue. The standard headers included by
openssl_c_hdrs.h will preempt their inclusion within the namespace by the
OpenSSL headers.
Of course, for C++ code you normally wouldn't include the C standard headers;
you'd use their C++ versions (cstdlib, etc). But this sort of thing is a
special case.
--
Michael Wojcik
Technology Specialist, Micro Focus
This message has been scanned for malware by Websense. www.websense.com
???H???7??m
)z{,???RǫJ?i??Lj)b????)z{,?? ??)z{,????h??^t???Ƨj^??%??
RE: Why does OpenSSL own all the prefixes in the world?
The (bad) idea of using C++ namespaces was just targered for those integrating OpenSSL into their own C++ projects. El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. -- Sent fm iTouch via Boxer
Re: Verifying authenticode signature using openssl API
http://msdn.microsoft.com/en-us/windows/hardware/gg463180.aspx is the spec for the Authenticode PE signature format. http://msdn.microsoft.com/en-us/gg463119 is the Microsoft PE and COFF Specification. Better download them now before they disappear, they appear to be deprecated in favor of Windows 8 format packages (of which I have no information). On September 9, 2014 10:18:18 AM PST, Prasad Dabak pda...@icloud.com wrote: Thanks Jacob for your response. Very informative indeed! Thanks -Prasad Sent from my iPhone On 09-Sep-2014, at 10:05 pm, Jakob Bohm jb-open...@wisemo.com wrote: On 09/09/2014 09:01, Prasad Dabak wrote: Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding. This time I have CC-ed you in addition to the mail list. I have a few follow-up questions on your response. 1. So, encryptedDigest has no relation to the stored messageDigest? I thought it's a encrypted version of the messageDigest? As far as I recall, there is a chain of 4 digests. The first digest is calculated over the file and is stored in the spcIndirectData. The second digest is calculated over the spcIndirectData (the contentInfo of the the PKCS#7 structure) and is stored as messageDigest in the AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash is calculated over the AuthenticatedAttributes and is signed to produce the encryptedDigest in that same signerInfo. All 3 need to be checked to confirm that the file hash is actually (indirectly) signed by the encryptedDigest using the public key in the certificate whose name is listed in the signerInfo. 2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header. Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IP checksum of file). Also it is allowed to be 0 to indicate no checksum (even if you set the checksum, it might be cleared if an Administrator adds his own countersignature to all authorized programs on his computers, aka AppLocker). 3. spcPEImageData is probably relevant only for signing that uses page hashes? I never quite figured out where they store the page hashes. However I believe the constant semi-empty spcPEImageData with the obsolete string is the traditional marker to indicate that the signature is for a PE file, and not e.g. a document file with the same hashed bytestream. 4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves? If it is, I am myself guessing a bit as to what that function does and does not check. But note that it probably doesn't check the full chain of 3 message digests, since at least the digest over the file itself is inside a blob that the PKCS#7 standard has no opinion about. 5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate? Actually, the subject is a data structure (a hierarchical list of sets of tagged strings) and the relevant comparison would be to compare those elements that don't change when getting a new certificate from the CA. It is the CAs responsibility to make sure the don't issue certificates to the wrong people, and if they make a mistake they are expected to quickly add the bad certificate to their published CRL, which is why you need to check the CRL before trusting the certificate. An additional check is to make sure the CA that issued the intermediary certificate that issued the COMAPNY-NAME certificate is actually one of the (few) CAs that COMPANY-NAME is going to buy certificates from. This protects against fake certificates issued by smaller CAs that you aren't going to use anyway. In my case, I am the one who is signing the executable using my certificate and a cross certificate issued by Microsoft and I want to programmatically ensure following things. 1. Code is not tampered since it was signed (matching messageDigest with computed hash) Actually matching digest in spcIndirectData with computed hash. Plus consistency checks to make sure the signature is actually for a PE file and was not otherwise doctored. For instance there should be no bytes in the file after the end of the signature blob. 2. Verifying the digital signature (PKCS7_Verify) 3. Confirming that the executable is signed by my company certificate. I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key? Yep, that is why careful matching against various Distinguished Name fields is needed. On Sep 06, 2014, at 09:44 PM, Prasad Dabak pda...@icloud.com wrote: Hello, Given a
Re: On 2K keys and SHA-256
Hi Rich, Am 09.09.2014 14:18, schrieb Salz, Rich: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. Sure, there are 6 related bugs when searching for keygen on Mozilla's Bugzilla that effect the problem: Key size spec for KEYGEN tag: https://bugzilla.mozilla.org/show_bug.cgi?id=495876 (potentially doing a comma list of asymm+size - e.g. rsa2048,dsa2048,... - might be an option working for every cipher with ecc-* to wildcard all EC curves or !dsa to prohibit any DSA keys might be an option). 1024 bit option should be removed: https://bugzilla.mozilla.org/show_bug.cgi?id=649910 (or the default options modified to more sane values like 2048, 3072 and 4096) Automated tests for KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=698315 (IIRC this one was the blocker for some of the other issues) Some more automated tests for KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=960888 (IMHO low prio, but probably related) SPKAC signed with MD5withRSAencryption https://bugzilla.mozilla.org/show_bug.cgi?id=549460 (would be nice if this was done with SHA-2 - or I'd prefer using a setting to select between MD5 up to SHA-3, but optional on that setting) Increase options offered by KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=495836 (IMHO one of the oldest issues in the list) For Chrome I can fire up a search on the bugtracker too if you like, but the issues should be similar. Also, when we are at client certificates: please remove the limit of sent client certificates: If I happen to have a certificate with such a long key (and Firefox happily imports them) you shouldn't get into trouble while using them. Will file a bug for the exact behaviour when I get around to it (related to the #747453 issue in Debian). Regards, BenBE. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org signature.asc Description: OpenPGP digital signature
Re: Why does OpenSSL own all the prefixes in the world?
On Tue, Sep 9, 2014 at 2:42 PM, Iñaki Baz Castillo i...@aliax.net wrote: The (bad) idea of using C++ namespaces was just targeted for those integrating OpenSSL into their own C++ projects. Now, I would have said that using C++ namespaces was a good idea and perhaps it might be motivation to replace the MACROs by something more useful, El 09/09/2014 20:39, Larry Bugbee bug...@seanet.com escribió: In the FWIW column Please don't mangle names by forcing C++ namespaces. Some us call OpenSSL from Python (and other dynamic languages) and depend on the C naming convention. Adding a OSSL_ prefix is fine; mangling creates huge problems. I use a number of such languages and it isn't all that hard to mix them with C++ (in sme cases, I'd extend them using C++ code, for the sake of performance). In the case of Python, for example, there is a boost library designed specifically for that purpose. From my perspective, that is not a big problem. Rather, it is just one of countless things I routinely have to deal with: just the cost of getting things done. Cheers Ted -- R.E.(Ted) Byers, Ph.D.,Ed.D. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate pass phrase brute force...
@Kyle: I'm the admin for the OpenVPN system setup and config, and generate all the server/client certs, CA etc., and if my machine is infested with malware, then well, the CA's compromised, along with everything else. IOW, game over. It's not that I disagree with you particularly, but I doubt that the short time a private key is exposed before it gets re-encrypted, will matter much, especially in the very controlled situation I'm contemplating. [Which is actually inside a sterile VM.] --- @Michael: Yeah, I can use the EasyRSA tool to initially create the Key+CSR without a password [encryption-less] and then add the aes-256 re-key in the second process. [Like so: # easyrsa build-client-full somefilename nopass ] As I was writing up the post last night, I thought about describing that process, but thought it would confuse things further since I hadn't opened the thread that way... But yet, that will make it easier as I only have to input the password once into the terminal, instead of on both passes. And you're right in regards to modifying the EasyRSA script; it's more work than I'm able to do at the moment, and while I'm not terrible at bash, I'd be hesitant in making fairly major mods to [security critical] code in fear of introducing ill effects that won't get caught in a cursory peer-review. The current code can be made to work without too much hassle and has been around for a while and has been real-world tested. Unless the current maintainer is willing to do it, it's probably better to leave it the way it is now with the minor change I suggest. Again thanks all for the excellent help, ideas and suggestions. It's been a pleasure. [And that's an uncommon compliment - far more than can be said of many listservs.] -Greg Sure, if that's a better fit to your threat model. (I certainly wouldn't recommend changing openssl req to make -nodes the default.) I was just suggesting possibilities for Gregory. Personally, I'd probably go with generating an encrypted private key with openssl genpkey first, but that might be more changes to the EasyRSA script than he's inclined to make. He has a working solution now which seems fine for his purposes. A cipher option for openssl req -newkey wouldn't be a bad idea, but it's not a high priority, so I wouldn't expect it to happen anytime soon unless someone wants to submit a patch. Michael Wojcik Technology Specialist, Micro Focus From: Kyle Hamilton [mailto:aerow...@gmail.com] Sent: Tuesday, 09 September, 2014 13:43 To: openssl-users@openssl.org; Michael Wojcik Subject: RE: Certificate pass phrase brute force... At least 3DES is *some* encryption. The issue is that peoples' computers are usually infested with malware; it's better to assume (for a software distribution) that the disk is compromised, and always encrypt it before writing. Perhaps there should be a cipher option for the req -newkey option? -Kyle H On September 9, 2014 8:58:08 AM PST, Michael Wojcik michael.woj...@microfocus.com wrote: As far as I know, openssl req doesn't let you specify the encryption cipher for the private key. You can generate the key file first, with openssl genpkey, which does let you specify the encryption cipher; and then use -key to tell openssl to use your existing key rather than creating a new one. You can also do what you describe below, but not encrypt the private key the first time, by using the -nodes option with openssl req; that saves decrypting it before encrypting it with your preferred cipher. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Tuesday, 09 September, 2014 01:19 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... I used the asn1parse command [thanks Dave!] and while the key looks old style it parses as follows: 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC mode The full asn parse is: --- 0:d=0 hl=4 l=2446 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT:PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2 32:d=4 hl=2 l= 14 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=3 hl=2 l= 20 cons: SEQUENCE 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA (REDACTED) --- [I don't know if I needed to redact those fields at all, but I don't think it matters.) So, if I've read that properly, the encryption method is 3DES. --- While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA script from OpenVPN - I
Re: Certificate pass phrase brute force...
Having a sterile VM to do all of the cert generation is a good idea. But can you guarantee, in these days of logging and versioned filesystems, that the unencrypted key file data block will in fact be overwritten by the encryption? Or will it remain intact, with a new data block allocated for the new content? (Also, I'm trying to generalize good security principles to the design of a non-specific script. I now see that you have a particular scenario with a particular threat model in mind, and disclaim the creation of a solution for general utility.) -Kyle H On September 9, 2014 3:27:27 PM PST, Gregory Sloop gr...@sloop.net wrote: @Kyle: I'm the admin for the OpenVPN system setup and config, and generate all the server/client certs, CA etc., and if my machine is infested with malware, then well, the CA's compromised, along with everything else. IOW, game over. It's not that I disagree with you particularly, but I doubt that the short time a private key is exposed before it gets re-encrypted, will matter much, especially in the very controlled situation I'm contemplating. [Which is actually inside a sterile VM.] --- @Michael: Yeah, I can use the EasyRSA tool to initially create the Key+CSR without a password [encryption-less] and then add the aes-256 re-key in the second process. [Like so: # easyrsa build-client-full somefilename nopass ] As I was writing up the post last night, I thought about describing that process, but thought it would confuse things further since I hadn't opened the thread that way... But yet, that will make it easier as I only have to input the password once into the terminal, instead of on both passes. And you're right in regards to modifying the EasyRSA script; it's more work than I'm able to do at the moment, and while I'm not terrible at bash, I'd be hesitant in making fairly major mods to [security critical] code in fear of introducing ill effects that won't get caught in a cursory peer-review. The current code can be made to work without too much hassle and has been around for a while and has been real-world tested. Unless the current maintainer is willing to do it, it's probably better to leave it the way it is now with the minor change I suggest. Again thanks all for the excellent help, ideas and suggestions. It's been a pleasure. [And that's an uncommon compliment - far more than can be said of many listservs.] -Greg Sure, if that's a better fit to your threat model. (I certainly wouldn't recommend changing openssl req to make -nodes the default.) I was just suggesting possibilities for Gregory. Personally, I'd probably go with generating an encrypted private key with openssl genpkey first, but that might be more changes to the EasyRSA script than he's inclined to make. He has a working solution now which seems fine for his purposes. A cipher option for openssl req -newkey wouldn't be a bad idea, but it's not a high priority, so I wouldn't expect it to happen anytime soon unless someone wants to submit a patch. Michael Wojcik Technology Specialist, Micro Focus From: Kyle Hamilton [mailto:aerow...@gmail.com] Sent: Tuesday, 09 September, 2014 13:43 To: openssl-users@openssl.org; Michael Wojcik Subject: RE: Certificate pass phrase brute force... At least 3DES is *some* encryption. The issue is that peoples' computers are usually infested with malware; it's better to assume (for a software distribution) that the disk is compromised, and always encrypt it before writing. Perhaps there should be a cipher option for the req -newkey option? -Kyle H On September 9, 2014 8:58:08 AM PST, Michael Wojcik michael.woj...@microfocus.com wrote: As far as I know, openssl req doesn't let you specify the encryption cipher for the private key. You can generate the key file first, with openssl genpkey, which does let you specify the encryption cipher; and then use -key to tell openssl to use your existing key rather than creating a new one. You can also do what you describe below, but not encrypt the private key the first time, by using the -nodes option with openssl req; that saves decrypting it before encrypting it with your preferred cipher. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Tuesday, 09 September, 2014 01:19 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... I used the asn1parse command [thanks Dave!] and while the key looks old style it parses as follows: 50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC mode The full asn parse is: --- 0:d=0 hl=4 l=2446 cons: SEQUENCE 4:d=1 hl=2 l= 64 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT:PBES2 17:d=2 hl=2 l= 51 cons: SEQUENCE 19:d=3 hl=2 l= 27 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2 32:d=4 hl=2
RE: Certificate pass phrase brute force...
(Sorry not inline, my Outlook can’t do that for HTML.)
That’s actually a subvariant I forgot to describe: PKCS#8 *version 2*.
It has “BEGIN ENCRYPTED PRIVATE KEY” (not specifying RSA etc.) like version 1,
but instead of a single PBE algorithm-id PBE-with-$kdf-and-$cipher it has a
structure
PBES2 with {$kdf-alg using $params} and {$cipher-alg using $params}.
So yes you read right, the cipher part is TDEA aka [3]DES[3]-EDE[3] in CBC mode.
Yes, req –newkey can only encrypt with TDEA. You can do that and then
re-encrpyt as you did; or you generate the key separately with genpkey
encrypting with any algo and then use req –new on that key.
Either way is two steps.
However, your conversion apparently produced a legacy-format file
“BEGIN RSA PRIVATE KEY” with DEK-Info. You/the script probably used
rsa -$cipher , which does this. This is MUCH LESS SECURE.
As I believe was mentioned, no one will bruteforce the data cipher,
neither TDEA nor AES-anything. Even 112 would take basically all the
computers on Earth for many many years, and 128 millions or more.
Even NSA can’t do that. What can be attacked is the password-based
derivation, especially if the password is something a human can remember.
And for backward compatibility the legacy-format files use a poor PBKDF –
based on PBKDF1 (slightly poor) WITH ITERATIONS=1 (AWFUL!!!).
If you want decent security at all, much less anything even approaching the
strength AES-256 appears to promise, use pkcs8 –topk8 –v2 $cipher
(which unobviously works for input that is already pkcs8) or pkey -$cipher .
Cheers.
From: mailto:owner-openssl-us...@openssl.org owner-openssl-us...@openssl.org
[ mailto:owner-openssl-us...@openssl.org
mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Tuesday, September 09, 2014 01:19
To: mailto:openssl-users@openssl.org openssl-users@openssl.org
Subject: Re: Certificate pass phrase brute force...
I used the asn1parse command [thanks Dave!] and while the key looks old style
it parses as follows:
50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc
Which appears to equate to: des-ede3-cbc Three key triple DES EDE in CBC
mode
The full asn parse is:
---
0:d=0 hl=4 l=2446 cons: SEQUENCE
4:d=1 hl=2 l= 64 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT:PBES2
17:d=2 hl=2 l= 51 cons: SEQUENCE
19:d=3 hl=2 l= 27 cons: SEQUENCE
21:d=4 hl=2 l= 9 prim: OBJECT:PBKDF2
32:d=4 hl=2 l= 14 cons: SEQUENCE
34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA
(REDACTED)
44:d=5 hl=2 l= 2 prim: INTEGER :0800
48:d=3 hl=2 l= 20 cons: SEQUENCE
50:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc
60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA
(REDACTED)
---
[I don't know if I needed to redact those fields at all, but I don't think it
matters.)
So, if I've read that properly, the encryption method is 3DES.
---
While this isn't really relevant to OpenSSL, and more relevant to the EasyRSA
script from OpenVPN - I thought I'd share a solution that appears to work and
do what I want.
It doesn't appear easy to modify the EasyRSA script to use aes-256 [or any non
3DES cypher] in the script. From my look at the syntax of a openssl req -new
-newkey ... command, you don't get to specify the cypher it will use in
encrypting the private key. This appears to be a result of generating both the
key and the signing request in a single step - in this case you don't appear to
get to choose what crypto is used to encrypt the private key. [I'd be glad to
be shown a way you can specify it - it doesn't appear possible from the
command-line options at least.]
However, as I pointed out there is code in the EasyRSA tool to re-encrypt the
private key with a new password, or remove the password.
You can edit the script to use aes256 as follows: [or any of the other cyphers
here: https://www.openssl.org/docs/apps/rsa.html
https://www.openssl.org/docs/apps/rsa.html#]
In the easyrsa bash script:
Look for the line: [ local crypto=-des3 ] (It's line 861 in the current
EasyRSA version)
Change it to: [ local crypto=-aes256 ]
Now when you issue the command easyrsa set-rsa-pass, and issue the old
encryption key, along with a new one [you can certainly use the same key for
the old and new] it will re-encrypt it with aes-256.
Looking at the key file it does appear to indeed work and re-encrypts it with
AES-256.
#cat somekey.key
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC ...
---
Thus, this is the best work-around for the tool I can find. Unfortunately it
requires a redundant step unless someone can show me a way to put the
encryption type for private keys in a config file or specify it as part of a
openssl -req ... command
But at least it works the way I want it to, and makes the task of setting up
keys and certs a bit easier than
RE: cannot read PEM key file - no start line
I was half wrong before. The base64 read in EVP_Decode* allows 76. But the PEM parser in PEM_read_bio enforces exactly 64 only for input files that have PEM-encrypt headers which in practice is only encrypted legacy-format privatekey files. (Nonprivate things like cert, CSR, publickey, params, etc. aren’t encrypted at all. PKCS8 privatekey or PKCS12 key-plus-cert is encrypted within the ASN1, not as PEM.) I have and know of no software to create encrypted legacy-format privatekeys other than OpenSSL itself which always writes 64, so I never encountered this before. (Other sw does do PKCS8-e or PKCS12 but see above.) (As seen elsethread, OP apparently had PEM certs where PEM key was expected.) From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Tuesday, September 09, 2014 08:09 To: OpenSSL Users List Subject: Re: cannot read PEM key file - no start line On Sun, Sep 7, 2014 at 10:26 PM, Liz Fall f...@sbcglobal.net wrote: All, I am getting the following with my client cert when trying to connect to an SSL-enabled MongoDB: 2014-09-03T13:37:56.881-0500 ERROR: cannot read PEM key file: /users/apps/tstlrn/u019807/DTCD9C3B2F42757.ent.wfb.bank.corp_mongo_wells.pem error:0906D06C:PEM routines:PEM_read_bio:no start line I just tried to duplicate with a key (not a certificate) that uses line breaks at 76 characters. I don't have a certificate because my routines don't support certificates. But it should reveal a little about the OpenSSL parser. Reading the public and private keys were OK when the line size was 76 (see below). So the OpenSSL parser is lenient during a read. This seems very reasonable to me. Reading an encrypted private key resulted in an error PEM_read_bio:bad end line:pem_lib.c:802 when the line size was 76 (see below). This kind of surprised me. Since you are receiving the no start line error (and not another error), I would suspect you are reading an ASN.1/DER encoded certificate; and not a PEM encoded certificate. The error occured before anything related to line lengths. snip rest
