From richmoore44 at gmail.com Wed Jul 1 09:51:01 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 1 Jul 2015 10:51:01 +0100 Subject: [openssl-users] libtlssep In-Reply-To: <20150630135506.GA11732@imp.flyn.org> References: <20150630135506.GA11732@imp.flyn.org> Message-ID: On 30 June 2015 at 14:55, W. Michael Petullo wrote: > and a research prototype at: > > https://www.flyn.org/projects/libtlssep/ > The libtlssep website. > > We would love to hear any constructive comments you might have, and would > be interested in hearing about any possibility for future collaboration. > ?I like the concept of using priv sep. :-) I haven't had a chance to look at your code properly, but one thing I noticed from a quick read through the docs was that you're relying on passing fds to t lssep_connect ?() that will make it impossible for people to write code that works through proxies (HTTP, socks etc.) unless you build support into the library itself. An abstraction along the lines of BIO that provides for working on buffers would really be needed for this use case. ?Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikonta at yandex.ru Wed Jul 1 10:38:28 2015 From: ikonta at yandex.ru (Ikonta) Date: Wed, 01 Jul 2015 13:38:28 +0300 Subject: [openssl-users] Alternatives to flat text file database back-end? Message-ID: <532151435747108@web18j.yandex.ru> Hi everybody, Possibly stupid question: The default and only known for me OpenSSL database format is flat text file (afair index.txt in default openssl.cnf). Was ever suggested an idea to provide some alternatives (maybe relational (SQL) database server, or sqlite, or LDAP)? What can I read (or at least what keywords use to search) about it? Or it will be better to ask this question into -dev list? From kurt at roeckx.be Wed Jul 1 18:13:39 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 1 Jul 2015 20:13:39 +0200 Subject: [openssl-users] Alternatives to flat text file database back-end? In-Reply-To: <532151435747108@web18j.yandex.ru> References: <532151435747108@web18j.yandex.ru> Message-ID: <20150701181339.GA19820@roeckx.be> On Wed, Jul 01, 2015 at 01:38:28PM +0300, Ikonta wrote: > Hi everybody, > > Possibly stupid question: > The default and only known for me OpenSSL database format is flat text file (afair index.txt in default openssl.cnf). > Was ever suggested an idea to provide some alternatives (maybe relational (SQL) database server, or sqlite, or LDAP)? > What can I read (or at least what keywords use to search) about it? You might want to look at: https://pki.openca.org/ http://www.ejbca.org/ Others are: http://xca.sourceforge.net/ tinyca (website doesn't seem to work anymore, it's probably not what you want.) There is also https://github.com/letsencrypt/boulder, but that's probably not what you're looking for. Kurt From rsalz at akamai.com Wed Jul 1 19:05:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Jul 2015 19:05:03 +0000 Subject: [openssl-users] libtlssep In-Reply-To: <20150630135506.GA11732@imp.flyn.org> References: <20150630135506.GA11732@imp.flyn.org> Message-ID: <400f3ec61b094b68b33802800410a23e@ustx2ex-dag1mb2.msg.corp.akamai.com> > I am writing to introduce a new TLS library which presently makes use of > OpenSSL: libtlssep. Libtlssep has two aims: (1) to provide a simpler API to > application developers and (2) to encourage the decomposition of > applications into at least two processes, one of which isolates access to > secret cryptographic keys. This is interesting work; thanks for posting about it! You might also be interested in the libtls project in OpenBSD, which has very similar goals. From noloader at gmail.com Wed Jul 1 20:08:18 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 1 Jul 2015 16:08:18 -0400 Subject: [openssl-users] libtlssep In-Reply-To: <20150630135506.GA11732@imp.flyn.org> References: <20150630135506.GA11732@imp.flyn.org> Message-ID: On Tue, Jun 30, 2015 at 9:55 AM, W. Michael Petullo wrote: > Dear OpenSSL community, > > I am writing to introduce a new TLS library which presently makes use > of OpenSSL: libtlssep. Libtlssep has two aims: (1) to provide a simpler > API to application developers and (2) to encourage the decomposition of > applications into at least two processes, one of which isolates access > to secret cryptographic keys. It was added to the Related Links section of the wiki to help with awareness. https://wiki.openssl.org/index.php/Related_Links#Open_Source_Cryptographic_Libraries Jeff From noloader at gmail.com Wed Jul 1 21:04:09 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 1 Jul 2015 17:04:09 -0400 Subject: [openssl-users] Token Binding Extension? Message-ID: Does OpenSSL implement the Token Binding extension? https://tools.ietf.org/html/draft-ietf-tokbind-protocol Token Binding finds its roots in Origin Bound Certificates (https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final162.pdf). I'm also aware of some related, independent work by a fellow named Jacob Thompson of Independent Security Evaluators. https://securityevaluators.com/knowledge/case_studies/mutual/ Token Binding and OCB are a useful tool to stop MitM in some security models, like those used on the web and by browsers. From vogelke at pobox.com Thu Jul 2 04:37:40 2015 From: vogelke at pobox.com (Karl Vogel) Date: 2 Jul 2015 04:37:40 -0000 Subject: [openssl-users] Minor portability fix for Solaris-11.1 Message-ID: <20150702043740.4863.qmail@kev-solaris.wpafb.af.mil> Greetings: I ran into a minor test problem when building OpenSSL-1.0.2c. Host: me% uname -a SunOS myname 5.11 11.1 i86pc i386 i86pc Solaris Compiler: me% gcc -v Target: i386-pc-solaris2.11 Thread model: posix gcc version 4.5.2 (GCC) Configuration: CC=gcc; export CC CFLAGS='-m64'; export CFLAGS CPPFLAGS='-I/usr/local/include'; export CPPFLAGS LDFLAGS='-m64 -L/usr/local/lib'; export LDFLAGS Configuring for solaris64-x86_64-gcc The build worked, but running "make test" gave these messages: [...] Testing ciphersuites Testing ciphersuites for TLSv1.2 ./testssl[149]: local: not found [No such file or directory] ./testssl[150]: local: not found [No such file or directory] Testing AES256-GCM-SHA384 Available compression methods: NONE TLSv1.2, cipher TLSv1/SSLv3 AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done ./testssl[149]: local: not found [No such file or directory] ./testssl[150]: local: not found [No such file or directory] Testing AES256-SHA256 [...] On Solaris-11.1, /bin/sh links to /usr/bin/i86/ksh93, which doesn't handle local variables properly. Using "typeset" fixes it; the patch is below. -- Karl Vogel I don't speak for the USAF or my company vogelke at pobox dot com http://www.pobox.com/~vogelke ========================================================================= *** testssl.orig Fri Jun 12 10:51:21 2015 --- testssl Wed Jul 1 00:38:52 2015 *************** *** 148,151 **** test_cipher() { ! local cipher=$1 ! local protocol=$2 echo "Testing $cipher" --- 148,151 ---- test_cipher() { ! typeset cipher=$1 ! typeset protocol=$2 echo "Testing $cipher" From rsalz at akamai.com Thu Jul 2 12:00:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Jul 2015 12:00:27 +0000 Subject: [openssl-users] Minor portability fix for Solaris-11.1 In-Reply-To: <20150702043740.4863.qmail@kev-solaris.wpafb.af.mil> References: <20150702043740.4863.qmail@kev-solaris.wpafb.af.mil> Message-ID: <389b553a435347949ec3a2b6df6a0700@ustx2ex-dag1mb2.msg.corp.akamai.com> > ./testssl[149]: local: not found [No such file or directory] > ./testssl[150]: local: not found [No such file or directory] This is marked in RT 3907 and was fixed last week; it will be in the next releases. Thanks. From matt at openssl.org Thu Jul 2 12:00:47 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 02 Jul 2015 13:00:47 +0100 Subject: [openssl-users] Minor portability fix for Solaris-11.1 In-Reply-To: <20150702043740.4863.qmail@kev-solaris.wpafb.af.mil> References: <20150702043740.4863.qmail@kev-solaris.wpafb.af.mil> Message-ID: <559527EF.10802@openssl.org> On 02/07/15 05:37, Karl Vogel wrote: > On Solaris-11.1, /bin/sh links to /usr/bin/i86/ksh93, which doesn't handle > local variables properly. Using "typeset" fixes it; the patch is below. > Hi Karl Rich Salz fixed this a while ago in git. It should be sorted in the next release. Matt From jaya.nageswar at gmail.com Thu Jul 2 12:28:18 2015 From: jaya.nageswar at gmail.com (Jaya Nageswar) Date: Thu, 2 Jul 2015 17:58:18 +0530 Subject: [openssl-users] regarding the vulnerability CVE-2015-1788 Message-ID: Dear openssl users, I have a question regarding the vulnerability CVE-2015-1788. At http://openssl.org/news/secadv_20150611.txt, I would like to get the clarification on the follwing statement. This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent 1.0.0 and 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are affected. I would like to know in which version of 0.9.8, this vulnerability is fixed. I do not find the code changes related to this in 0.9.8zg that are committed for 1.0.1n( https://github.com/openssl/openssl/commit/4924b37ee01f71ae19c94a8934b80eeb2f677932) for fixing the same. Is the fix different for 0.9.8 and 1.0.1 versions. Please help me. Regards, -Jaya Nageswar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jul 2 12:30:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Jul 2015 12:30:46 +0000 Subject: [openssl-users] regarding the vulnerability CVE-2015-1788 In-Reply-To: References: Message-ID: The link you posted, and quoted from, says which versions are vulnerable and which ones are fixed. You could run a diff between them to isolate the fix. Or you could just upgrade. From rsalz at akamai.com Thu Jul 2 12:35:20 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Jul 2015 12:35:20 +0000 Subject: [openssl-users] Old "RSA_NET" key format Message-ID: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> We are thinking about removing the old "RSA_NET" format for private keys. This is used by very old Netscape and IIS. This would remove the d2i/i2d RSA_NET API's, and the "nss" format flag from the openssl program. It would not remove the SPKI stuff. If this would cause a problem for you, please respond soon. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jul 2 12:56:39 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 02 Jul 2015 13:56:39 +0100 Subject: [openssl-users] regarding the vulnerability CVE-2015-1788 In-Reply-To: References: Message-ID: <55953507.1030802@openssl.org> On 02/07/15 13:28, Jaya Nageswar wrote: > Dear openssl users, > > I have a question regarding the vulnerability CVE-2015-1788. > > At http://openssl.org/news/secadv_20150611.txt, I would like to get the > clarification on the follwing statement. > > This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent 1.0.0 and > 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are affected. > > I would like to know in which version of 0.9.8, this vulnerability is > fixed. I do not find the code changes related to this in 0.9.8zg that > are committed for > 1.0.1n(https://github.com/openssl/openssl/commit/4924b37ee01f71ae19c94a8934b80eeb2f677932) > for fixing the same. Is the fix different for 0.9.8 and 1.0.1 versions. > Please help me. Like the advisory said, 0.9.8r and below are affected...or putting it another way 0.9.8s is the first version where this vulnerability is fixed. The fix is different between the two versions - 0.9.8 doesn't have the optimised implementation of that function that is present in later versions. Unfortunately the same bug existed in both the optimised and unoptimised forms. The un-optimised version got fixed some while ago, but the optimised version did not. The fix in 0.9.8 is here: https://github.com/openssl/openssl/commit/22152d6885fac98777ae1d7626a78c20b1ab4295 Matt From jaya.nageswar at gmail.com Thu Jul 2 15:30:50 2015 From: jaya.nageswar at gmail.com (Jaya Nageswar) Date: Thu, 2 Jul 2015 21:00:50 +0530 Subject: [openssl-users] regarding the vulnerability CVE-2015-1788 In-Reply-To: <55953507.1030802@openssl.org> References: <55953507.1030802@openssl.org> Message-ID: thanks Matt for the information provided. On Thu, Jul 2, 2015 at 6:26 PM, Matt Caswell wrote: > > > On 02/07/15 13:28, Jaya Nageswar wrote: > > Dear openssl users, > > > > I have a question regarding the vulnerability CVE-2015-1788. > > > > At http://openssl.org/news/secadv_20150611.txt, I would like to get the > > clarification on the follwing statement. > > > > This issue affects OpenSSL versions: 1.0.2 and 1.0.1. Recent 1.0.0 and > > 0.9.8 versions are not affected. 1.0.0d and 0.9.8r and below are > affected. > > > > I would like to know in which version of 0.9.8, this vulnerability is > > fixed. I do not find the code changes related to this in 0.9.8zg that > > are committed for > > 1.0.1n( > https://github.com/openssl/openssl/commit/4924b37ee01f71ae19c94a8934b80eeb2f677932 > ) > > for fixing the same. Is the fix different for 0.9.8 and 1.0.1 versions. > > Please help me. > > Like the advisory said, 0.9.8r and below are affected...or putting it > another way 0.9.8s is the first version where this vulnerability is fixed. > > The fix is different between the two versions - 0.9.8 doesn't have the > optimised implementation of that function that is present in later > versions. Unfortunately the same bug existed in both the optimised and > unoptimised forms. The un-optimised version got fixed some while ago, > but the optimised version did not. The fix in 0.9.8 is here: > > > https://github.com/openssl/openssl/commit/22152d6885fac98777ae1d7626a78c20b1ab4295 > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Thu Jul 2 15:53:41 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Thu, 02 Jul 2015 11:53:41 -0400 Subject: [openssl-users] How to provide KDF to ECDH key computation when using EVP API? In-Reply-To: <5592BA38.2070101@wisemo.com> References: <55847A35.2050207@gmail.com> <558F623F.60907@gmail.com> <5592BA38.2070101@wisemo.com> Message-ID: <55955E85.5010007@gmail.com> Hello Jakob, > How does this all compare to the EVP API for traditional > DH?, I think this is a closer equivalent for API design > than ECDSA. Good point. For traditional DH, no Key Derivation Function is mentioned anywhere. It has a larger associated set of methods (see below) than ECDH, but the compute_key() function in particular is simpler. So this does not look too good for my case... Reinier struct dh_method { const char *name; /* Methods here */ int (*generate_key) (DH *dh); int (*compute_key) (unsigned char *key, const BIGNUM *pub_key, DH *dh); /* Can be null */ int (*bn_mod_exp) (const DH *dh, BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx); int (*init) (DH *dh); int (*finish) (DH *dh); int flags; char *app_data; /* If this is non-NULL, it will be used to generate parameters */ int (*generate_params) (DH *dh, int prime_len, int generator, BN_GENCB *cb); }; On 6/30/15 11:48 AM, Jakob Bohm wrote: > On 28/06/2015 04:55, Reinier Torenbeek wrote: >> Hi again, >> >> After digging into the ECDH code a bit more, I (sort of) found an answer >> to my question. >> >> My reason to look at using the KDF is to apply a hash to the shared >> secret to compute a useable key within the derive function. There is a >> control value called EVP_PKEY_CTRL_MD which seems like it could be used >> for this purpose. However, for EC keys it looks like this control value >> only has a meaning for the signing functionality, not for the key >> derivation functionality. This looks like an omission to me. A small >> test showed that it would not be too hard to have the hash applied when >> doing key derivation as well. >> >> If the approach sketched above is not right or possible, then exposing >> the KDF function to the user of the EVP API seems a logical alternative. >> However, the KDF function prototype is rather limited, with only an in >> and out and no context at all. The latter would be required to make it >> useful. >> >> Since this functionality looks like it is a kind of half-finished to me, >> can anybody give some insight in its status or confirm/correct my >> conclusions? >> >> Thanks, >> Reinier >> >> On 6/19/15 4:23 PM, Reinier Torenbeek wrote: >>> Hi, >>> >>> My goal is to implement ECDH in my own engine. The snippet below shows >>> the struct that needs to be filled and set as the engine's ECDH method: >>> >>> struct ecdh_method { >>> const char *name; >>> int (*compute_key) (void *key, size_t outlen, const EC_POINT *pub_key, >>> EC_KEY *ecdh, void *(*KDF) (const void *in, >>> size_t inlen, void *out, >>> size_t *outlen)); >>> # if 0 >>> int (*init) (EC_KEY *eckey); >>> int (*finish) (EC_KEY *eckey); >>> # endif >>> int flags; >>> char *app_data; >>> }; >>> >>> I intend to leverage the KDF mechanism, but it does not seem to be >>> exposed in the EVP API. Is that possible at all? If yes, how do I do >>> that? If no, what is the purpose of the KDF() parameter in compute_key? > How does this all compare to the EVP API for traditional > DH?, I think this is a closer equivalent for API design > than ECDSA. >>> (By the way, struct ecdh_method is in crypto/ecdh/ech_locl.h, which >>> seems to be a private header file. Am I supposed/allowed to include it >>> anyway?) > Unfortunately, someone thinks that OpenSSL should be made > as useless as possible, strangely, this all began shortly > after the heartbleed backdoor was closed. > > 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-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.cuypers at technisat.de Fri Jul 3 15:01:08 2015 From: roger.cuypers at technisat.de (Dr. Roger Cuypers) Date: Fri, 3 Jul 2015 15:01:08 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath Message-ID: Hello there, I'm trying to do peer client verification using the SSL_CTX_load_verify_locations function in conjunction with the SSL_get_peer_certificate and SSL_get_verify_result function. If I SSL_get_verify_result call this way setting CAFile, it will work for me: SSL_CTX_load_verify_locations( sslContext, "D:\\certs\\-.wikipedia.org.crt", NULL ); However, setting only CAPath will not: SSL_CTX_load_verify_locations( sslContext, NULL, "D:\\certs" ); This will result in a X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY error. The cert directory D:\\certs looks like this: -.wikipedia.org.crt ca_client.jks ca_server.jks My expectation would be that the library uses -.wikipedia.org.crt As it is the only certificate available or am I doing something wrong? API is openssl-1.0.2c. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwelty at nwtime.org Sat Jul 4 08:54:26 2015 From: rwelty at nwtime.org (Richard Welty) Date: Sat, 04 Jul 2015 04:54:26 -0400 Subject: [openssl-users] efficient way to encrypt, then sign? Message-ID: <55979F42.4040701@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 what is the lowest overhead method for encrypting using CMS_encrypt then signing using CMS_sign? it seems like using BIO_new_mem_buf ought to do but i don't see a method for getting the length of the CMS_ContentInfo object to feed to the BIO creation method. thanks, richard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVl59CAAoJEBg+LdNh/YEcnB8QAJgj2JeIyigGBGxUqrdCHf0Q O02+ToK3afT0VMuvjcvtTbDRxwBO0VxRBjpUGjJvBoHRsUBCEs/EPKB4hUhQ2VE3 8M8xPZT/xIWiUInSKcCzep+B226siD0oQhfrMSlTW5jZL2zzCe+TwJxKYG9vaY+V +YNSz22XWZvHF07gir04S413XNVm6qcEyLnl6cMRbdLHHuLOkI2NbqyWbqQ0976R iHpVtFpNbyJVCcn/tWLEFV0/FcuTkm8ytCYTn4sgIN5AJ/SwKRWUMz/AoIA8LJDB amVnKzpzc+/G8PctUXZmCbYUB4xRQmxS/gAYf/+XbHdsZInvOSiq9pbcLcPZ+jHa /Gkp6SYf44NpmEjt25trMlBXoY+gQzGpfeCj1E60/shEMkyoe40SPA5rCJc4JCg4 P1Nbt4Yu++Zfn64EUwrUo7m9GJ9R0R0l75Pekqjy3zMjh+9WCm1caMtcXDwC6udw aL4tKqSGxTFySd/U6gkWryIuamPDg676ATy0wMp+slBWa+NprB7UbscBUJIxdzfn Sv2uZb7ldnVsMb69Foo6MmwFgsuuECdQDgq5PlLHcWDXQjA7onSDJADpucorpzR3 sOdCY2FbaQQrJsl1hZykoJ9rzrFcIABGotWXgcVqGPAUC08iX/V1haYdX0HMULfD xJ6y2otpS3YSXCaHXnRM =iqLe -----END PGP SIGNATURE----- From steve at openssl.org Sat Jul 4 10:53:01 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 4 Jul 2015 10:53:01 +0000 Subject: [openssl-users] efficient way to encrypt, then sign? In-Reply-To: <55979F42.4040701@nwtime.org> References: <55979F42.4040701@nwtime.org> Message-ID: <20150704105301.GA12845@openssl.org> On Sat, Jul 04, 2015, Richard Welty wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > what is the lowest overhead method for encrypting using > CMS_encrypt then signing using CMS_sign? it seems like > using BIO_new_mem_buf ought to do but i don't see a method > for getting the length of the CMS_ContentInfo object to > feed to the BIO creation method. > The function i2d_CMS_ContentInfo will return the length and encode the structure with the appropriate arguments for example: unsigned char *buf = NULL; int buflen; buflen = i2d_CMS_ContentInfo(cms, &buf); Depending on the format you want there is a lower overhead (in terms of memory usage) method: you may be able to chain two streaming BIOs and sign encrypted data on the fly. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From Walter.H at mathemainzel.info Sun Jul 5 10:48:50 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 05 Jul 2015 12:48:50 +0200 Subject: [openssl-users] Certificate serialnumber? Message-ID: <55990B92.30302@mathemainzel.info> Hello, I'm using openssl command-line in a Linux-Box (CentOS 6.x with squid) like this: I havn't defined anything - everything is set default from the linux distribution openssl req -new -newkey rsa:2048 -subj '/CN=Squid SSL-Bump CA/C=/O=/OU=/' -sha256 -days 365 -nodes -x509 -keyout ./squidCA.pem -out ./squidCA.pem the question: where does the serial number for this certificate come from? is it random by default when nothing is said about it? would this be also an option when using openssl like this: openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate ... -enddate ... .... Thanks. -- Best regards, Ing. Walter H?hlhubmer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From ben at an3k.de Sun Jul 5 11:58:03 2015 From: ben at an3k.de (Ben Humpert) Date: Sun, 5 Jul 2015 13:58:03 +0200 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <55990B92.30302@mathemainzel.info> References: <55990B92.30302@mathemainzel.info> Message-ID: Take a look in your openssl.cnf and you should see the option "serial" with a path / file specified. The serial number is taken from that file. If the file doesn't exists or is empty when the very first certificate is created then 01 is used as a serial for it. Rich Salz recommended me this SSL Cookbook https://www.feistyduck.com/books/openssl-cookbook/ by Ivan Risti? and based on that you should initiate the database and serial files before you create certificates to avoid problems that can occour after month / years. I use cd /etc/ssl/ mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out ./ca/reqs chmod 700 ./ca/private cp /dev/null ./ca/db/an3kRootCA.db cp /dev/null ./ca/db/an3kRootCA.db.attr openssl rand -hex 16 > ./ca/db/an3kRootCA.crt.srl echo 1001 > ./ca/db/an3kRootCA.crl.srl cd /etc/ssl/ca/ to create the whole environment and initiate the database and serial files. This is based on the SSL Cookbook information. If you want to read it for yourself please open https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html begin with paragraph "Creating a Private Certification Authority" (F3). 2015-07-05 12:48 GMT+02:00 Walter H. : > Hello, > > I'm using openssl command-line in a Linux-Box (CentOS 6.x with squid) like > this: > > I havn't defined anything - everything is set default from the linux > distribution > openssl req -new -newkey rsa:2048 -subj '/CN=Squid SSL-Bump CA/C=/O=/OU=/' > -sha256 -days 365 -nodes -x509 -keyout ./squidCA.pem -out ./squidCA.pem > > the question: where does the serial number for this certificate come from? > is it random by default when nothing is said about it? > > would this be also an option when using openssl like this: > > openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate ... > -enddate ... .... > > Thanks. > > -- > Best regards, > Ing. Walter H?hlhubmer > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From dthompson at cardconnect.com Sun Jul 5 12:19:27 2015 From: dthompson at cardconnect.com (David Thompson) Date: Sun, 5 Jul 2015 12:19:27 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: Message-ID: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> From: openssl-users On Behalf Of Dr. Roger Cuypers Sent: Friday, July 03, 2015 11:01 > I'm trying to do peer client verification using the SSL_CTX_load_verify_locations function > However, setting only CAPath will not: > This will result in a X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY error. > The cert directory D:\\certs looks like this: > -.wikipedia.org.crt > ca_client.jks > ca_server.jks > My expectation would be that the library uses -.wikipedia.org.crt > As it is the only certificate available or am I doing something wrong? A truststore generally can contain many certs, not just one. OpenSSL needs to find the correct one(s) for each connection and uses special names for this. >From manpage https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links. The semantically similar https://www.openssl.org/docs/apps/verify.html -CApath option is slightly briefer: A directory of trusted certificates. The certificates should have names of the form: hash.0 or have symbolic links to them of this form ("hash" is the hashed certificate subject name: see the -hash option of the x509 utility). Under Unix the c_rehash script will automatically create symbolic links to a directory of certificates. Note c_rehash only works on Unix, or quasi-Unix like Cygwin/Windows. For native Windows one or two is easiest done by hand: openssl x509 -in certfile.pem -noout -subject_hash (outputs hex number call it xxxxxxxx) mklink /h xxxxxxxx.0 certfile.pem To do it automatically you need a trick to capture the value, something like for %f in (*.pem) do for /v %h ('openssl x509 -in %f -noout -subject_hash') ^ do mklink /h %v.0 %f except that doesn't handle errors or collisions intelligently. (And if you want to make it a .bat file, remember all "local" % must be doubled in .bat.) Note this *method* hasn't changed for at least a decade, but the *hash* used for -subject_hash did change between 0.9.8 and 1.0.0. If you create hashlinks with 0.9.8 they won't work for 1.0.0 and up, and vice versa. And note only *one* cert per file in CApath is used. If your wikipedia.crt file has multiple certs, using it as CAfile puts them *all* in the truststore and uses them if needed, but for CApath you must split out separate file for each needed cert, each with a hashlink (or name) as above. But the server I get for wikipedia.org:443 (208.80.154.224) (as it should) provides full chain up to but excluding GlobalSign Root CA, so that root is the only cert you should need regardless of store format. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. From dthompson at cardconnect.com Sun Jul 5 12:19:46 2015 From: dthompson at cardconnect.com (David Thompson) Date: Sun, 5 Jul 2015 12:19:46 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <55990B92.30302@mathemainzel.info> References: <55990B92.30302@mathemainzel.info> Message-ID: <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> > From: openssl-users On Behalf Of Walter H. > Sent: Sunday, July 05, 2015 06:49 > openssl req -new -newkey rsa:2048 -subj '/CN=Squid SSL-Bump > CA/C=/O=/OU=/' -sha256 -days 365 -nodes -x509 -keyout ./squidCA.pem > -out ./squidCA.pem > > the question: where does the serial number for this certificate come from? > is it random by default when nothing is said about it? > Quoting the man page for req(1) -- although depending on the packaging which I don't know for CentOS it may be a different section like 1s or 1ssl -- and also on the web https://www.openssl.org/docs/apps/req.html -x509 this option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA. The extensions added to the certificate (if any) are specified in the configuration file. Unless specified using the set_serial option, a large random number will be used for the serial number. > would this be also an option when using openssl like this: > > openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate > ... -enddate ... .... > 'ca' always uses the value currently in a 'serial' file configured in the configuration file, and increments it, thus using sequential numbers when you issue more than one cert. 'ca' also records issued certs in a 'database' file usually named index.txt (a VERY SIMPLE db, just a file with text lines and columns) which makes sequential numbers convenient. If you want nonsequential numbers you can edit the serial file before each or any execution of 'ca'. This is mostly described on the man page for ca(1ssl), although on checking I see it isn't actually stated that serial values are incremented; you're supposed to infer that from the usual meaning of the word, although the X.509 meaning has diverged. OpenSSL's other, simpler but less capable way to issue a child cert is 'openssl x509' with '-req' and '-CA', plus '-CAkey' unless the key is in the (CA)cert file, and other options as needed. In this method you may specify '-set_serial' as an option; else it uses the serial-file method like 'ca' except the filename may be an option or defaults to the (CA)cert file name with .pem or other suffix changed to .srl. And 'x509 -req -CA' does NOT record the index.txt 'database'. Now, where do you think documentation of 'x509' might be? ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. From dthompson at cardconnect.com Sun Jul 5 12:19:50 2015 From: dthompson at cardconnect.com (David Thompson) Date: Sun, 5 Jul 2015 12:19:50 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: References: <55990B92.30302@mathemainzel.info> Message-ID: <7C7B83BD5B04E744A206B6F55159E444B07FC21D@MSG1.ftservice.local> > From: openssl-users On Behalf Of Ben Humpert > Sent: Sunday, July 05, 2015 07:58 > Take a look in your openssl.cnf and you should see the option "serial" > with a path / file specified. The serial number is taken from that > file. If the file doesn't exists or is empty when the very first > certificate is created then 01 is used as a serial for it. > That's for 'ca', not for 'req -new -x509'. See my answer. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. From Walter.H at mathemainzel.info Sun Jul 5 13:43:30 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 05 Jul 2015 15:43:30 +0200 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> References: <55990B92.30302@mathemainzel.info> <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> Message-ID: <55993482.30303@mathemainzel.info> On 05.07.2015 14:19, David Thompson wrote: > Quoting the man page for req(1) -- although depending on the packaging > which I don't know for CentOS it may be a different section like 1s or 1ssl -- > and also on the web https://www.openssl.org/docs/apps/req.html > > -x509 > this option outputs a self signed certificate instead of a certificate request. > This is typically used to generate a test certificate or a self signed root CA. > The extensions added to the certificate (if any) are specified in the > configuration file. Unless specified using the set_serial option, > a large random number will be used for the serial number. > >> would this be also an option when using openssl like this: >> >> openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate >> ... -enddate ... .... >> > 'ca' always uses the value currently in a 'serial' file configured in the > configuration file, and increments it, thus using sequential numbers > when you issue more than one cert. as you above, "Unless specified using the set_serial option, ..." is it the same with 'serial' file when using openssl ca ...? I mean, would the serial be random, when there is no 'serial' file specified, neither in the openssl.cnf nor at the command parameters ... Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From rsalz at akamai.com Sun Jul 5 15:56:15 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 5 Jul 2015 15:56:15 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> References: <55990B92.30302@mathemainzel.info> <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> Message-ID: <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> > > the question: where does the serial number for this certificate come from? > > is it random by default when nothing is said about it? It will be random if (a) the serial file does not exist; and (b) you specify the -create_serial flag. Otherwise it opens the file, reads the number (defaulting to zero if not exists) and increments it, updates the file, and uses that as the new serial number. From steve at openssl.org Sun Jul 5 18:56:08 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 5 Jul 2015 18:56:08 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55990B92.30302@mathemainzel.info> <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150705185608.GA305@openssl.org> On Sun, Jul 05, 2015, Salz, Rich wrote: > > > > the question: where does the serial number for this certificate come from? > > > is it random by default when nothing is said about it? > > It will be random if (a) the serial file does not exist; and (b) you specify the -create_serial flag. Otherwise it opens the file, reads the number (defaulting to zero if not exists) and increments it, updates the file, and uses that as the new serial number. > Unless I'm misreading the code an absent serial number file is an error. We don't start with zero any more because this can result in duplicate issuer names and serial numbers which can cause hard to trace problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Sun Jul 5 19:27:56 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 5 Jul 2015 19:27:56 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <20150705185608.GA305@openssl.org> References: <55990B92.30302@mathemainzel.info> <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150705185608.GA305@openssl.org> Message-ID: <53048240699946c19419835abce60756@ustx2ex-dag1mb2.msg.corp.akamai.com> > Unless I'm misreading the code an absent serial number file is an error. I was looking at load_serial() in apps.c, with the |create| parameter. /r$ From roger.cuypers at technisat.de Mon Jul 6 09:34:37 2015 From: roger.cuypers at technisat.de (Dr. Roger Cuypers) Date: Mon, 6 Jul 2015 09:34:37 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> Message-ID: Tried what you suggested, but SSL_get_verify_result still returns error 20. What I did was the following: openssl x509 -in D:\certs\-.wikipedia.org.crt -out D:\certs\-.wikipedia.org.der -outform DER openssl x509 -in D:\certs\-.wikipedia.org.der -inform DER -out D:\certs\-.wikipedia.org.pem -outform PEM openssl x509 -in D:\certs\-.wikipedia.org.pem -noout -subject_hash 690deae8 Then in D:\certs: D:\certs>mklink /h 690deae8.0 -.wikipedia.org.pem Then ran the program. Regards -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von David Thompson Gesendet: Sonntag, 5. Juli 2015 14:19 An: openssl-users at openssl.org Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath From: openssl-users On Behalf Of Dr. Roger Cuypers Sent: Friday, July 03, 2015 11:01 > I'm trying to do peer client verification using the > SSL_CTX_load_verify_locations function > However, setting only CAPath will not: This will result in a > X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY error. > The cert directory D:\\certs looks like this: > -.wikipedia.org.crt > ca_client.jks > ca_server.jks > My expectation would be that the library uses -.wikipedia.org.crt As > it is the only certificate available or am I doing something wrong? A truststore generally can contain many certs, not just one. OpenSSL needs to find the correct one(s) for each connection and uses special names for this. >From manpage https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links. The semantically similar https://www.openssl.org/docs/apps/verify.html -CApath option is slightly briefer: A directory of trusted certificates. The certificates should have names of the form: hash.0 or have symbolic links to them of this form ("hash" is the hashed certificate subject name: see the -hash option of the x509 utility). Under Unix the c_rehash script will automatically create symbolic links to a directory of certificates. Note c_rehash only works on Unix, or quasi-Unix like Cygwin/Windows. For native Windows one or two is easiest done by hand: openssl x509 -in certfile.pem -noout -subject_hash (outputs hex number call it xxxxxxxx) mklink /h xxxxxxxx.0 certfile.pem To do it automatically you need a trick to capture the value, something like for %f in (*.pem) do for /v %h ('openssl x509 -in %f -noout -subject_hash') ^ do mklink /h %v.0 %f except that doesn't handle errors or collisions intelligently. (And if you want to make it a .bat file, remember all "local" % must be doubled in .bat.) Note this *method* hasn't changed for at least a decade, but the *hash* used for -subject_hash did change between 0.9.8 and 1.0.0. If you create hashlinks with 0.9.8 they won't work for 1.0.0 and up, and vice versa. And note only *one* cert per file in CApath is used. If your wikipedia.crt file has multiple certs, using it as CAfile puts them *all* in the truststore and uses them if needed, but for CApath you must split out separate file for each needed cert, each with a hashlink (or name) as above. But the server I get for wikipedia.org:443 (208.80.154.224) (as it should) provides full chain up to but excluding GlobalSign Root CA, so that root is the only cert you should need regardless of store format. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From roger.cuypers at technisat.de Mon Jul 6 14:42:40 2015 From: roger.cuypers at technisat.de (Dr. Roger Cuypers) Date: Mon, 6 Jul 2015 14:42:40 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> Message-ID: Follow up: For some reason, the X509_NAME_hash function calculates a very different hash for the server certificate: 5ad8a5d6 Renaming the certificate to 5ad8a5d6.0 causes it to be found, but I wonder where the difference in the hashes lies. Regards -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Dr. Roger Cuypers Gesendet: Montag, 6. Juli 2015 11:35 An: openssl-users at openssl.org Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath Tried what you suggested, but SSL_get_verify_result still returns error 20. What I did was the following: openssl x509 -in D:\certs\-.wikipedia.org.crt -out D:\certs\-.wikipedia.org.der -outform DER openssl x509 -in D:\certs\-.wikipedia.org.der -inform DER -out D:\certs\-.wikipedia.org.pem -outform PEM openssl x509 -in D:\certs\-.wikipedia.org.pem -noout -subject_hash 690deae8 Then in D:\certs: D:\certs>mklink /h 690deae8.0 -.wikipedia.org.pem Then ran the program. Regards -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von David Thompson Gesendet: Sonntag, 5. Juli 2015 14:19 An: openssl-users at openssl.org Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath From: openssl-users On Behalf Of Dr. Roger Cuypers Sent: Friday, July 03, 2015 11:01 > I'm trying to do peer client verification using the > SSL_CTX_load_verify_locations function > However, setting only CAPath will not: This will result in a > X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY error. > The cert directory D:\\certs looks like this: > -.wikipedia.org.crt > ca_client.jks > ca_server.jks > My expectation would be that the library uses -.wikipedia.org.crt As > it is the only certificate available or am I doing something wrong? A truststore generally can contain many certs, not just one. OpenSSL needs to find the correct one(s) for each connection and uses special names for this. >From manpage https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html If CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. If more than one CA certificate with the same name hash value exist, the extension must be different (e.g. 9d66eef0.0, 9d66eef0.1 etc). The search is performed in the ordering of the extension number, regardless of other properties of the certificates. Use the c_rehash utility to create the necessary links. The semantically similar https://www.openssl.org/docs/apps/verify.html -CApath option is slightly briefer: A directory of trusted certificates. The certificates should have names of the form: hash.0 or have symbolic links to them of this form ("hash" is the hashed certificate subject name: see the -hash option of the x509 utility). Under Unix the c_rehash script will automatically create symbolic links to a directory of certificates. Note c_rehash only works on Unix, or quasi-Unix like Cygwin/Windows. For native Windows one or two is easiest done by hand: openssl x509 -in certfile.pem -noout -subject_hash (outputs hex number call it xxxxxxxx) mklink /h xxxxxxxx.0 certfile.pem To do it automatically you need a trick to capture the value, something like for %f in (*.pem) do for /v %h ('openssl x509 -in %f -noout -subject_hash') ^ do mklink /h %v.0 %f except that doesn't handle errors or collisions intelligently. (And if you want to make it a .bat file, remember all "local" % must be doubled in .bat.) Note this *method* hasn't changed for at least a decade, but the *hash* used for -subject_hash did change between 0.9.8 and 1.0.0. If you create hashlinks with 0.9.8 they won't work for 1.0.0 and up, and vice versa. And note only *one* cert per file in CApath is used. If your wikipedia.crt file has multiple certs, using it as CAfile puts them *all* in the truststore and uses them if needed, but for CApath you must split out separate file for each needed cert, each with a hashlink (or name) as above. But the server I get for wikipedia.org:443 (208.80.154.224) (as it should) provides full chain up to but excluding GlobalSign Root CA, so that root is the only cert you should need regardless of store format. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Mon Jul 6 14:45:38 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 6 Jul 2015 14:45:38 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> Message-ID: > For some reason, the X509_NAME_hash function calculates a very different > hash for the server certificate: Ah. Have you mixed openssl versions? At one point the hashing changed from md5 to sha1. That would explain why specifying a directory works, but a specific file doesn't. From roger.cuypers at technisat.de Mon Jul 6 15:22:38 2015 From: roger.cuypers at technisat.de (Dr. Roger Cuypers) Date: Mon, 6 Jul 2015 15:22:38 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> Message-ID: For clarification: Using CAFile works, using CAPath doesn't. The OpenSSL exe ist the Windows 1.0.2c version by Eric A. Young. The dll in my program has the same number. They are from stathis . Both diestributions have exes and they all yield the 690deae8 hash. -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Salz, Rich Gesendet: Montag, 6. Juli 2015 16:46 An: openssl-users at openssl.org Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath > For some reason, the X509_NAME_hash function calculates a very > different hash for the server certificate: Ah. Have you mixed openssl versions? At one point the hashing changed from md5 to sha1. That would explain why specifying a directory works, but a specific file doesn't. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dthompson at cardconnect.com Tue Jul 7 02:56:56 2015 From: dthompson at cardconnect.com (David Thompson) Date: Tue, 7 Jul 2015 02:56:56 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> Message-ID: <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> > From: openssl-users On Behalf Of Dr. Roger Cuypers > Sent: Monday, July 06, 2015 10:43 > Follow up: > > For some reason, the X509_NAME_hash function calculates a very different > hash for the server certificate: > > 5ad8a5d6 > > Renaming the certificate to 5ad8a5d6.0 causes it to be found, but I wonder > where the difference in the hashes lies. > [reformatted] > openssl x509 -in D:\certs\-.wikipedia.org.crt -out D:\certs\-.wikipedia.org.der > -outform DER > openssl x509 -in D:\certs\-.wikipedia.org.der -inform DER -out > D:\certs\-.wikipedia.org.pem -outform PEM Aside: those first two steps accomplish nothing; -.wikipedia.org.crt was already PEM (we know it worked in CAfile). 'x509' reads PEM by default. > openssl x509 -in D:\certs\- > .wikipedia.org.pem -noout -subject_hash > 690deae8 > > Then in D:\certs: > > D:\certs>mklink /h 690deae8.0 -.wikipedia.org.pem > I bet you put the entire cert *chain* in the -.wikipedia.org.crt file. The leaf cert (currently) used by wikipedia, with subject= /C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org issuer= /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 serial=1121972E32A5E5B2E29D472DFEDB72D6276E notBefore=Dec 16 21:24:03 2014 GMT notAfter=Feb 19 12:00:00 2017 GMT has subject hash 690deae8. This cert is sent from the server. It is not looked up in the truststore and does not need to be in the truststore; if it is that copy is ignored. The *root* cert for that wikipedia chain is subject= issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=040000000001154B5AC394 notBefore=Sep 1 12:00:00 1998 GMT notAfter=Jan 28 12:00:00 2028 GMT and this has subject hash 5ad8a5d6. This is the only cert that needs to be or is looked up in the truststore, and thus for CApath needs correct hash. I thought, as the doc has (always? long?) said, that CApath must have each cert (or CRL) in a separate file. But on checking I see that by_dir.c actually calls X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or crls) in a file to the working context. Thus a hashlink to only the 3rd cert in a file, where that 3rd cert is the only one you need, actually works even though not documented and I'm not sure intended. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. From dthompson at cardconnect.com Tue Jul 7 02:57:16 2015 From: dthompson at cardconnect.com (David Thompson) Date: Tue, 7 Jul 2015 02:57:16 +0000 Subject: [openssl-users] Certificate serialnumber? In-Reply-To: <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <55990B92.30302@mathemainzel.info> <7C7B83BD5B04E744A206B6F55159E444B07FC216@MSG1.ftservice.local> <3c995b7467004bd9bf68957bf13e47a4@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <7C7B83BD5B04E744A206B6F55159E444B07FC41A@MSG1.ftservice.local> > From: openssl-users On Behalf Of Salz, Rich > Sent: Sunday, July 05, 2015 11:56 [in response to message about 'ca'] > > > the question: where does the serial number for this certificate come > from? > > > is it random by default when nothing is said about it? > > It will be random if (a) the serial file does not exist; and (b) you specify the - > create_serial flag. Otherwise it opens the file, reads the number (defaulting > to zero if not exists) and increments it, updates the file, and uses that as the > new serial number. > One point I didn't notice until you pointed me at: FOR 'ca': If the serial file exists,the current value is read (ERROR if none or bad, not zero), THAT value is used, and then the incremented value is written back. If the file doesn't exist and you specify create, a random value is used, then the incremented value written. If the file doesn't exist and you don't specify create, error. FOR 'x509' with -set_serial, that is used and serial file is ignored. Otherwise same as above, except value is incremented BEFORE it us used-- and the create option is spelled -CAcreateserial instead of -create_serial. In short, 'ca' is like N++ in C but 'x509' is like ++N . Yikes! ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. From mark at openssl.org Mon Jul 6 15:25:02 2015 From: mark at openssl.org (Mark J Cox) Date: Mon, 6 Jul 2015 16:25:02 +0100 (BST) Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM 2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ= =yVBV -----END PGP SIGNATURE----- _______________________________________________ openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce From mark at openssl.org Tue Jul 7 08:49:46 2015 From: mark at openssl.org (Mark J Cox) Date: Tue, 7 Jul 2015 09:49:46 +0100 (BST) Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM 2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ= =yVBV -----END PGP SIGNATURE----- From roger.cuypers at technisat.de Tue Jul 7 11:06:06 2015 From: roger.cuypers at technisat.de (Dr. Roger Cuypers) Date: Tue, 7 Jul 2015 11:06:06 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> Message-ID: After downloading the root certificate GlobalSignRootCA.crt and installing it in the folder with its appropriate hash everything worked fine. Thanks for your suggestion. -.wikipedia.org is the end user certificate, right? -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von David Thompson Gesendet: Dienstag, 7. Juli 2015 04:57 An: openssl-users at openssl.org Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath > From: openssl-users On Behalf Of Dr. Roger Cuypers > Sent: Monday, July 06, 2015 10:43 > Follow up: > > For some reason, the X509_NAME_hash function calculates a very > different hash for the server certificate: > > 5ad8a5d6 > > Renaming the certificate to 5ad8a5d6.0 causes it to be found, but I > wonder where the difference in the hashes lies. > [reformatted] > openssl x509 -in D:\certs\-.wikipedia.org.crt -out > D:\certs\-.wikipedia.org.der -outform DER openssl x509 -in > D:\certs\-.wikipedia.org.der -inform DER -out > D:\certs\-.wikipedia.org.pem -outform PEM Aside: those first two steps accomplish nothing; -.wikipedia.org.crt was already PEM (we know it worked in CAfile). 'x509' reads PEM by default. > openssl x509 -in D:\certs\- > .wikipedia.org.pem -noout -subject_hash > 690deae8 > > Then in D:\certs: > > D:\certs>mklink /h 690deae8.0 -.wikipedia.org.pem > I bet you put the entire cert *chain* in the -.wikipedia.org.crt file. The leaf cert (currently) used by wikipedia, with subject= /C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org issuer= /C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2 serial=1121972E32A5E5B2E29D472DFEDB72D6276E notBefore=Dec 16 21:24:03 2014 GMT notAfter=Feb 19 12:00:00 2017 GMT has subject hash 690deae8. This cert is sent from the server. It is not looked up in the truststore and does not need to be in the truststore; if it is that copy is ignored. The *root* cert for that wikipedia chain is subject= issuer= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA serial=040000000001154B5AC394 notBefore=Sep 1 12:00:00 1998 GMT notAfter=Jan 28 12:00:00 2028 GMT and this has subject hash 5ad8a5d6. This is the only cert that needs to be or is looked up in the truststore, and thus for CApath needs correct hash. I thought, as the doc has (always? long?) said, that CApath must have each cert (or CRL) in a separate file. But on checking I see that by_dir.c actually calls X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or crls) in a file to the working context. Thus a hashlink to only the 3rd cert in a file, where that 3rd cert is the only one you need, actually works even though not documented and I'm not sure intended. ________________________________ THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information protected from disclosure and intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message or any attachments is strictly prohibited. If you have received this communication in error, please notify CardConnect immediately by replying to this message and then delete this message and any attachments from your computer. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Tue Jul 7 14:36:26 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Jul 2015 14:36:26 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> Message-ID: > I thought, as the doc has (always? long?) said, that CApath must have each > cert (or CRL) in a separate file. But on checking I see that by_dir.c actually calls > X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or crls) > in a file to the working context. Thus a hashlink to only the 3rd cert in a file, > where that 3rd cert is the only one you need, actually works even though not > documented and I'm not sure intended. That's definitely sub-optimal. Can you open a ticket for this? From Michael.Wojcik at microfocus.com Tue Jul 7 15:53:03 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Jul 2015 15:53:03 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Tuesday, July 07, 2015 08:36 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] SSL_CTX_load_verify_locations only with > CAPath > > > I thought, as the doc has (always? long?) said, that CApath must have each > > cert (or CRL) in a separate file. But on checking I see that by_dir.c actually > calls > > X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or > crls) > > in a file to the working context. Thus a hashlink to only the 3rd cert in a file, > > where that 3rd cert is the only one you need, actually works even though > not > > documented and I'm not sure intended. > > That's definitely sub-optimal. Can you open a ticket for this? Is it? It could be useful - you could have multiple certificates in one or more files in the certificate directory, and make multiple hash links (hard or symbolic, on filesystems where those are both options) to that physical file. I can see use cases for that. At the very least, it saves extracting all the certificates from a PEM file when creating the certificate directory, if you use a script that gets the hash value of each certificate in the file. I personally don't much care, but I could believe that someone else might find that useful. -- Michael Wojcik Technology Specialist, Micro Focus From rsalz at akamai.com Tue Jul 7 16:08:44 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Jul 2015 16:08:44 +0000 Subject: [openssl-users] SSL_CTX_load_verify_locations only with CAPath In-Reply-To: References: <7C7B83BD5B04E744A206B6F55159E444B07FC20F@MSG1.ftservice.local> <7C7B83BD5B04E744A206B6F55159E444B07FC410@MSG1.ftservice.local> Message-ID: <79f076ae42cf4bd3a09bb070e6656360@ustx2ex-dag1mb2.msg.corp.akamai.com> Is "surprising" a better word than sub-optimal? If you and Dave didn't know about it (nor did I) then it's surprising. And therefore probably not a good thing. Yes it can be useful. But the openssl "rehash" program only read one PEM block per file. So we need to fix one of those things. From marquess at openssl.com Wed Jul 8 13:47:13 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 08 Jul 2015 09:47:13 -0400 Subject: [openssl-users] FIPS 140-2 casualty list -- Ubuntu 10.4 still MIA Message-ID: <559D29E1.7020509@openssl.com> If you don't know or care what FIPS 140-2 is then dance a little jig of joy and move on. The "hostage issue" has resulted in the forced removal[*] of a number of platforms from the #1747 validation. That removal was done by editing the "Big Blob o' Text" in the rightmost cell of the entry for the #1747 validation on the NIST CMVP web site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 Until now no one has paid any attention to the Big Blob, as it's essentially unreadable, but with this new precedent that has been set it now matters. The Big Blob as it stands contains what appear to be four typographical errors: Platform 8, "Ubuntu 10.04 Intel Pentium T4200 (x86)" deleted One of platform 20 "Linux 2.6 Broadcom BCM11107 (ARMv6)" or platform 21 "Linux 2.6 TI TMS320DM6446 (ARMv4)" deleted (the Big Blob has only one possible match for both) One of platform 45 "NetBSD 5.1 PowerPC-e500" or 46 "NetBSD 5.1 Intel Xeon 5500 (x86)" deleted (the Big Blob has only one possible match for both) Platform 71 "Linux 3.4 under Citrix XenServer Intel Xeon E5-2430L (x86)" *not* deleted I was sure those were all typographical errors, which is understandable given the constipated illegibility of the Big Blob. However, more than three weeks after those errors were reported we have no response confirming that assumption and those errors have remained uncorrected, and that web page has since been updated several times. So, it's possible that the deletion of the three platforms 8, 20/25, and 45/46 was deliberate, for reasons as yet unknown. If you're using the module on platforms 20, 21, 45, 46 the ambiguity of the list of surviving platforms in the Big Blob presumably works in your favor. But, platform 8 is unambiguously "MIA" (Missing in Action) so any use of the OpenSSL FIPS module on that platform, Ubuntu 10.04 on x86, is officially non-validated. -Steve M. [*] http://openssl.com/fips/aftermath.html -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From raji.kotamraju at gmail.com Wed Jul 8 17:24:45 2015 From: raji.kotamraju at gmail.com (Rajeswari K) Date: Wed, 8 Jul 2015 22:54:45 +0530 Subject: [openssl-users] RC4-MD5 Message-ID: Hello Openssl team, We are currently facing an issue with RC4-MD5 cipher suite after upgrading from openssl0.9.8q to openssl1.0.1j. We see that on few platforms, RC4-MD5 cipher negotiation is returning bad mac record error after receiving "Client Key Exchange" message. Currently we are using proprietary md5 functions with following configuration . static const EVP_MD ios_md5_md= { NID_md5, NID_md5WithRSAEncryption, MD5_LEN, 0, md5init, md5update, md5final, NULL, NULL, EVP_PKEY_RSA_method, MD5_CBLOCK, sizeof(EVP_MD *)+sizeof(MD5_CTX), }; Is there any consideration for MD5 based on platform bits? Can anyone share? Thanks, Rajeswari. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Wed Jul 8 17:57:37 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 8 Jul 2015 13:57:37 -0400 Subject: [openssl-users] RC4-MD5 In-Reply-To: References: Message-ID: On Wed, Jul 8, 2015 at 1:24 PM, Rajeswari K wrote: > Hello Openssl team, > > We are currently facing an issue with RC4-MD5 cipher suite after upgrading > from openssl0.9.8q to openssl1.0.1j. > > We see that on few platforms, RC4-MD5 cipher negotiation is returning bad > mac record error after receiving "Client Key Exchange" message. I've seen it the other way: 0.9.8 produces a bad mac; while 1.0 clears the issue. > Currently we are using proprietary md5 functions with following > configuration . > > ... > Is there any consideration for MD5 based on platform bits? Can anyone > share? Just bike shedding, but these are the two ciphers that browsers are targeting for deprecation. See, for example, https://www.google.com/search?q=obsolete+cryptography+warning+chrome. The time might be better spent on avoiding both RC4 and MD5. That will keep your users out of of those browser security UX prompts that they don't know how to answer. But like I said, its just bike shedding. From jb-openssl at wisemo.com Wed Jul 8 18:16:48 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 08 Jul 2015 20:16:48 +0200 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <559D6910.4060405@wisemo.com> On 02/07/2015 14:35, Salz, Rich wrote: > > We are thinking about removing the old ?RSA_NET? format for private > keys. This is used by very old Netscape and IIS. > > This would remove the d2i/i2d RSA_NET API?s, and the ?nss? format flag > from the openssl program. It would not remove the SPKI stuff. > > If this would cause a problem for you, please respond soon. > 1. Is there any good reason to remove this code? 2. Is this the OpenSSL name for the private key format used by older Microsoft Authenticate tools (and thus sometimes converted to/from PKCS#12 when switching tool chains)? 3. Is this any of the formats used by SSH? 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 From rsalz at akamai.com Wed Jul 8 18:23:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Jul 2015 18:23:59 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <559D6910.4060405@wisemo.com> References: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> <559D6910.4060405@wisemo.com> Message-ID: <8d34345f8c194b8693f585353d241968@ustx2ex-dag1mb2.msg.corp.akamai.com> > 1. Is there any good reason to remove this code? Yes. If it's not tested, reviewed, or in general use, then it's more likely to be harmful (source of bugs) than useful. > 2. Is this the OpenSSL name for the private key format > used by older Microsoft Authenticate tools (and thus > sometimes converted to/from PKCS#12 when switching > tool chains)? I think only really old ISS, but that's why I asked. > 3. Is this any of the formats used by SSH? No; the seven characters "RSA_NET" do not appear in the openssh source. From steve at openssl.org Wed Jul 8 18:36:18 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 8 Jul 2015 18:36:18 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <559D6910.4060405@wisemo.com> References: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> <559D6910.4060405@wisemo.com> Message-ID: <20150708183618.GA22256@openssl.org> On Wed, Jul 08, 2015, Jakob Bohm wrote: > > 2. Is this the OpenSSL name for the private key format > used by older Microsoft Authenticate tools (and thus > sometimes converted to/from PKCS#12 when switching > tool chains)? > AFAIK they only use "PVK" format. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Wed Jul 8 18:47:43 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 08 Jul 2015 20:47:43 +0200 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <8d34345f8c194b8693f585353d241968@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> <559D6910.4060405@wisemo.com> <8d34345f8c194b8693f585353d241968@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <559D704F.6010806@wisemo.com> On 08/07/2015 20:23, Salz, Rich wrote: >> 1. Is there any good reason to remove this code? > Yes. If it's not tested, reviewed, or in general use, then it's more likely to be harmful (source of bugs) than useful. That's an overly general criteria, and may be the source of your mysterious marauding of the APIs. To objectively consider the potential harm of rarely used code, one must clearly determine if there is any way this code could be invoked inadvertently or remotely. For example the heartbeat code was obviously callable from network packets (even if it had no bugs), so needed this kind of cleanup, while the original eay DES API is only invokable from code that knows about it, and would thus not need to be removed for lack of use/testing. >> 2. Is this the OpenSSL name for the private key format >> used by older Microsoft Authenticate tools (and thus >> sometimes converted to/from PKCS#12 when switching >> tool chains)? > I think only really old ISS, but that's why I asked. I have no time to investigate, but I do not know the origin of why the existing code would call it "RSA_NET". I do know that the old format used by Authenticode was the RSA specific variant of the CryptoAPI 1 structure named simply PRIVATEKEYBLOB in Windows 2000 documentation. > >> 3. Is this any of the formats used by SSH? > No; the seven characters "RSA_NET" do not appear in the openssh source. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 8 19:00:15 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Jul 2015 19:00:15 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <559D704F.6010806@wisemo.com> References: <2788d77caa594922975db354ad712ab1@ustx2ex-dag1mb2.msg.corp.akamai.com> <559D6910.4060405@wisemo.com> <8d34345f8c194b8693f585353d241968@ustx2ex-dag1mb2.msg.corp.akamai.com> <559D704F.6010806@wisemo.com> Message-ID: <2571cc5581cf444189eefca98c204f0d@ustx2ex-dag1mb2.msg.corp.akamai.com> > That's an overly general criteria, and may be the source of your mysterious marauding of the APIs. Well there was no intent to be mysterious although I like the alliteration. We did mention it in the roadmap (https://openssl.org/about/roadmap.html) . Things are evaluated on a case-by-case basis, and I have often gone to the mailing list first. > while the original eay DES API is only invokable from code that knows about it, and would thus not need to be removed for lack of use/testing. I disagree with this viewpoint. Suppose there's a bug in the eay DES API. How would we know? And since we only distribute source, who do we know who is using it? And how do we prevent people from adding new uses of it? I know you are unhappy with this part of the OpenSSL direction. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From matthew.b.donald at gmail.com Thu Jul 9 06:14:01 2015 From: matthew.b.donald at gmail.com (Matthew Donald) Date: Thu, 9 Jul 2015 16:14:01 +1000 Subject: [openssl-users] Help with OpenSSL running on OSX Message-ID: One of Imapfilter's users is having problems verifying certificates. They are running Imapfilter on OSX, which I don't have access to. In addition, I understand that OSX runs a custom version of OpenSSL, which has changes to the way certificates are verified. Could someone help me debug the issue by telling me: 1. Does OSX use a certificates file (like other FreeBSD-style systems) to hold trusted/root certificates, or does it use some other mechanism? 2. If it uses a file, what is the file name 3. if OSX uses some other mechanism to store trusted/root certs, please give a link to documentation on how it works. regards Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Jul 9 07:30:21 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 9 Jul 2015 03:30:21 -0400 Subject: [openssl-users] Help with OpenSSL running on OSX In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 2:14 AM, Matthew Donald wrote: > One of Imapfilter's users is having problems verifying certificates. They > are running Imapfilter on OSX, which I don't have access to. In addition, I > understand that OSX runs a custom version of OpenSSL, which has changes to > the way certificates are verified. 1.1.0 added hostname verification. It affects all version of OpenSSL, and is not related to OS X or Macs. Its based on Viktor's work. See X509_check_host(3) and friends (https://www.openssl.org/docs/crypto/X509_check_host.html). OS X itself provides OpenSSL 0.9.8. Its pretty anemic by current yardsticks. OS X also has twists, like it always links to a shared version of the library is available (even if -Bstatic is used; and even on iOS, where dylibs are not allowed). It also uses DYLD_LIBRARY_PATH rather than LD_LIBRARY_PATH (see https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html). Also, OS X does not honor RPATHs. > Could someone help me debug the issue by telling me: > > 1. Does OSX use a certificates file (like other FreeBSD-style systems) to > hold trusted/root certificates, or does it use some other mechanism? > 2. If it uses a file, what is the file name > 3. if OSX uses some other mechanism to store trusted/root certs, please give > a link to documentation on how it works. Yes and no. OS X natively uses a Keychain. See, for example, these instructions at http://wiki.cacert.org/FAQ/ImportRootCert#Mac_OS_X. Just because the OS provides a Keychain, does not mean utilities actually use it. For example, cURL and Subversion, provided by Apple, does not use it. However, OpenSSL has its own mechanisms to use a trust store (re: c_hash and friends). So it depends on how OpenSSL was configured, which also depends on how ImapFilter configured things. And I seem to recall OpenSSL does not use it (the project could probably use an ENGINE to interface to it). ***** Because of issues with downlevel versions of the library on nearly all platforms, I use similar to the following to ensure I get what I compiled and linked against: ostringstream oss; long version = SSLeay(); if (version != OPENSSL_VERSION_NUMBER) { oss << "expected OpenSSL version " << std::dec << OPENSSL_VERSION_NUMBER; oss << " (" << std::hex << OPENSSL_VERSION_NUMBER << "), but got version "; oss << std::dec << version << " (" << std::hex << version << ")"; throw runtime_error(oss.str().c_str()); } You can actually relax that a bit by only comparing the high bytes. But I'm not interested in binary compatibility. I want to ensure I'm linking to precisely what I expect. For details on versioning and binary compatibility, see How does the versioning scheme work?, https://www.openssl.org/support/faq.html#MISC8. Jeff From gayathri.annur at gmail.com Thu Jul 9 09:48:48 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Thu, 9 Jul 2015 15:18:48 +0530 Subject: [openssl-users] openssh_DSA_verify_inFIPS EVP_VerifyFinal BAD SIG code:-1 ERROR Message-ID: Hi All, We are getting the below error in syslog file in FIPS mode. sshd[5939]: error: openssh_DSA_verify_inFIPS EVP_VerifyFinal BAD SIG code:-1 This is hitting when connecting between two servers using ssh authentication. Please let me know how can I solve this issue. Openssl version : 0.9.8.zf Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Jul 9 13:04:32 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 9 Jul 2015 13:04:32 +0000 Subject: [openssl-users] OpenSSL version 1.0.1p released Message-ID: <20150709130432.GA8767@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1p released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1p of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1p is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1p.tar.gz Size: 4560208 MD5 checksum: 7563e92327199e0067ccd0f79f436976 SHA1 checksum: 9d1977cc89242cd11471269ece2ed4650947c046 SHA256 checksum: bd5ee6803165c0fb60bbecbacacf244f1f90d2aa0d71353af610c29121e9b2f1 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1p.tar.gz openssl sha1 openssl-1.0.1p.tar.gz openssl sha256 openssl-1.0.1p.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVnmeDAAoJENnE0m0OYESR30AIAL5Dj1V2k1/eGDxAbThI4Ics +YEozTm8q6ymBFcInczADe3qe8mXllOu5mBCdOqesdxuuaE0VnsVo0Vm241LMUee blcelAD8pqqlHPenPRPVO+bpvqdJrWGFTOpdJbaTBCslT9E6YaTfpG1xZI1x4yrM VMR57CkdksDi4mm7TuG0m1w3liUN93pdDyIyesI+nkO7NwZpQ2xeM44z4wlUaxiB oZwnB4VTysVOOM7ZZqdZkDH2BO0nDs0SnPd4byL4AdjhrTIxf0qEKTIcm7WTvnU4 FGpkVJT7/Sm15xdJQ1keZLcRJ5oTHgWuLT7rsX01T4MLWQ8qT1afDkx/O2oF07o= =1BNN -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jul 9 13:05:00 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 9 Jul 2015 13:05:00 +0000 Subject: [openssl-users] OpenSSL version 1.0.2d released Message-ID: <20150709130500.GA8903@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2d released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2d of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2d is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2d.tar.gz Size: 5295447 MD5 checksum: 38dd619b2e77cbac69b99f52a053d25a SHA1 checksum: d01d17b44663e8ffa6a33a5a30053779d9593c3d SHA256 checksum: 671c36487785628a703374c652ad2cebea45fa920ae5681515df25d9f2c9a8c8 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2d.tar.gz openssl sha1 openssl-1.0.2d.tar.gz openssl sha256 openssl-1.0.2d.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVnmMAAAoJENnE0m0OYESRszEH/RFG+H+im2svvgRoTLI/J8YH czX5u5aNqVWDPqQCZz7OQZOq8l7c9lQ8RMuB6AZWECSzn8IUaAF7dNdKC9qSM2Ax 1Sl1fwFeWHXRASvMm4SDUIQxmU8tBmiopBWM4J2a5LWO3zK6pG8pN72HIBIjuJmk 5Sp02BUMCbI5+FpZju1SOClfkZiAappAcdvJiWhv5ef3dJfdIUE3YBtLlEhzH4Ou cfX64gHcsFHWo8ZnHSwrB+blL6Eb8SnGOn+lBAUCIJhh5MY91PSjhfUVL5e2AYY7 Xqm5EFsghLrfxOZeUUNaCHlkdodR0XAabqvq8TQkSk3QQg8N8UFKxr+HnymtMGc= =ay5A -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jul 9 13:10:24 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 9 Jul 2015 13:10:24 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20150709131024.GA9863@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [9 Jul 2015] ======================================= Alternative chains certificate forgery (CVE-2015-1793) ====================================================== Severity: High During certificate verification, OpenSSL (starting from version 1.0.1n and 1.0.2b) will attempt to find an alternative certificate chain if the first attempt to build such a chain fails. An error in the implementation of this logic can mean that an attacker could cause certain checks on untrusted certificates to be bypassed, such as the CA flag, enabling them to use a valid leaf certificate to act as a CA and "issue" an invalid certificate. This issue will impact any application that verifies certificates including SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150709.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVnml8AAoJENnE0m0OYESRlcYH/iUe62/m2oZiuBHkKQvLBUbH VrLDp7xEXEg6ozByLyxughAFwY9XD2r9WkXehxw66af2pmNHphXH3Gbfpcebki0r HuZJ3CbGD/RSomWdAqkzRfV8MjNxmN4Pyi+sTsf7F+nKv80Ts51iUN1pPjkddAR8 ooKw0VMIENeMboWQ9SyQ3r7TYYywK+lXUG71Ekva9ByzABBwC/1CzZeSLJmuewnJ +9TjwQ4otH/mUJ/klvw+G2eTSn64AnA6UEFR+sBL4aNpIgdrtjonJRt2ko05Z92N HN/ibu5okd3iUbtkM0dTMGAr2NCrNYPr2dYLMPemwkAq1cRlhjGouRDDeb6TUYk= =oUAa -----END PGP SIGNATURE----- From rsalz at akamai.com Thu Jul 9 13:13:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Jul 2015 13:13:30 +0000 Subject: [openssl-users] [openssl-dev] OpenSSL Security Advisory In-Reply-To: <20150709131024.GA9863@openssl.org> References: <20150709131024.GA9863@openssl.org> Message-ID: > This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. In other words, if you are not using those specific releases -- i.e., the ones that came out less than 30 days ago -- you do not need to upgrade. From rwelty at nwtime.org Thu Jul 9 13:29:20 2015 From: rwelty at nwtime.org (Richard Welty) Date: Thu, 09 Jul 2015 09:29:20 -0400 Subject: [openssl-users] setting content types in CMS Message-ID: <559E7730.70406@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 how does one set a content type for a signed CMS object? i am creating it with a call to CMS_sign (with flag CMS_PARTIAL set among others), then when i call CMS_set1_eContentType it crashes. thanks, richard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnncwAAoJEBg+LdNh/YEcF4kP/RCrVw4BSJciNQrGY3ObZU8N hmrUklA6IFCeuHn1LMkA8em8d5zwqvuMrse+xROTMK66ZAtklGaB7RZYduonl6qH tmn6x1wACxMGjE73dZOrwID8Ipatb0kpu/lslgkiHlHK80JyKMNU7xXRwRPbkpdI da4/CDzlaMMyBBEbGeLvvYemVnbiFmnmHX+WU7rE84r2C6FnHd1B5jjyLwRsbNsA k5c/hVewpaBCDHDGlczMLctcgBi5zUvT/EaMVh6kapInf21ndZZpss2WSLRjvLaa i6NcqxwKlsfz8m0Djc1TfuzbYyJh1zUb+EoepMV36BGz/Z7RdJsuLrgoSi5L/jr+ s1NNiaicSzVhiqZTveykcBUr77bw9ZLTRyGdxnBQAOl1GrugRNgBq1OCl6kFh+Z7 2gRAEUUG32JRG6WL6We+wbsCKD0XuVXJTu+ljvB51KF9GuxXW6KkYWoPOTQy9K+m aSA34xNTzGTsOS4u15zAtl0K1DoawEOp1halX/qAmMGRtfejkwSW/zTaEJ+xAY23 9ROOtC0azCCHF/8eukfkaHJarQB+3RWCLtvbModgA1NzqvDeSMCwlW25g48Al+vv +JPk4E1oWcE6rsCNSQbC+TFmb2uPkYK5oAXrQq/tfaRJFjz8HEELH8F+1m0PKL/+ cC/fkd00VQFyiiG6XjMy =9t4B -----END PGP SIGNATURE----- From noloader at gmail.com Thu Jul 9 13:31:29 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 9 Jul 2015 09:31:29 -0400 Subject: [openssl-users] s_client bug or expected behavior? Message-ID: On Debian and Macports, the script below returns "Verify return code: 0 (ok)". Effectively, it claims Google's CA is certifying Microsoft properties. Some folks claim this is expected behavior. s_client(3) does not discuss the expected behavior, so I'm not sure what should be expected. (I thought expected behavior was to use a default Trust Store if both -CApath and -CAfile was *not* specified; otherwise, only use what was specified). For the folks who claim its expected, I think their reasoning reduces to "s_client has a trust store, and specifying -CAfile means Trust Store + CAfile is used to verify the connection, rather than just CAfile". Is it expected behavior that s_client will effectively use Trust Store + CAfile (or Trust Store + CApath)? (I'm happy to update s_client(3) man page to remove all ambiguity once I know what the documented behavior is supposed to be). Thanks in advance. ***** $ cat s_client-test.sh #!/bin/bash wget https://pki.google.com/GIAG2.crt openssl x509 -in GIAG2.crt -inform DER -out GIAG2.pem -outform PEM # Intuitively, this should fail, but it does not. openssl s_client -connect www.microsoft.com:443 -tls1 -servername www.microsoft.com -CAfile GIAG2.pem From steve at openssl.org Thu Jul 9 13:53:35 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 9 Jul 2015 13:53:35 +0000 Subject: [openssl-users] setting content types in CMS In-Reply-To: <559E7730.70406@nwtime.org> References: <559E7730.70406@nwtime.org> Message-ID: <20150709135335.GA16353@openssl.org> On Thu, Jul 09, 2015, Richard Welty wrote: > > how does one set a content type for a signed CMS object? > i am creating it with a call to CMS_sign (with flag CMS_PARTIAL > set among others), then when i call CMS_set1_eContentType > it crashes. > That should work because that's what the cms utility does. Are you checking that the return value from CMS_sign() is not NULL? What arguments are you passing to CMS_set1_eContentType()? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Thu Jul 9 14:02:55 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Jul 2015 14:02:55 +0000 Subject: [openssl-users] [openssl-dev] OpenSSL Security Advisory In-Reply-To: References: <20150709131024.GA9863@openssl.org> Message-ID: <20150709140254.GB21534@mournblade.imrryr.org> On Thu, Jul 09, 2015 at 01:13:30PM +0000, Salz, Rich wrote: > > This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. > > In other words, if you are not using those specific releases -- i.e., the > ones that came out less than 30 days ago -- you do not need to upgrade. More accurately, you should upgrade anyway, to address the issues resolved by those earlier releases, even though the specific issue in the most recent release applies only to its immediate predecessors. -- Viktor. From rwelty at nwtime.org Thu Jul 9 14:30:10 2015 From: rwelty at nwtime.org (Richard Welty) Date: Thu, 09 Jul 2015 10:30:10 -0400 Subject: [openssl-users] setting content types in CMS In-Reply-To: <20150709135335.GA16353@openssl.org> References: <559E7730.70406@nwtime.org> <20150709135335.GA16353@openssl.org> Message-ID: <559E8572.9090203@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 7/9/15 9:53 AM, Dr. Stephen Henson wrote: > On Thu, Jul 09, 2015, Richard Welty wrote: > >> >> how does one set a content type for a signed CMS object? i am >> creating it with a call to CMS_sign (with flag CMS_PARTIAL set >> among others), then when i call CMS_set1_eContentType it >> crashes. >> > > That should work because that's what the cms utility does. Are you > checking that the return value from CMS_sign() is not NULL? What > arguments are you passing to CMS_set1_eContentType()? i had commented out the problem code in order to move forward; i just uncommented it and reran the test and now it works. there must have been some commenting error on my part. now i have a stack trace in CMS_verify to chase down. as i've spotted some things in my code that need to be adjusted, i'll not bother anyone with questions about that just now. thanks for the help, richard -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnoVyAAoJEBg+LdNh/YEcfTMQALSPliel6eFXx6xQUIp6bi+D wtR2hifU1Y6/AhvyO9osW/QiqPdXobkX94acFmj2cj5as9NwpriETNEYn3TF12Uu YYhfrEa/JP2kyDTFTR+zzS8bN0WZTxVNnTBx7zy3oZsZ/modr+1wHfBSe9BOeUc5 uwc1xLkl82b5rZGbtmjkxHEFp776lsXkzDUkZEbNLbfjLpOY+NEBTmQXr8DJvxMP Xsu6DnbRTNiM80TIi4LdMMaSBdEPiusOYYxxFygDtEwqi2vveQ9iQPCrITLsu0Zd 1M1pobRtUMcBaEE69+F5dagYDKcdJm5LiS4nkn9sGS2OQDRUWYLeJJBWI+/SmHpm t+jkP8UTVy1XaUGgknHZB435Fv1o71X+pWllDOO3L79G4Jcp7Nrs4soJrBFkgTSc K5Y3eHdfKIqG0349obghHR9uYQme90eqexA2reih3Lfy6uFqK1UZutkB70v+IdEx sxkA11zrM3DtAYBEBg7exGxyqS823USRSVXSE+CkwPghypYyalmZSxaHL0GMn+bM 3QK2OUWUqfjkizzOub1NRnTxtK1kBjrGpQpzWf6JqnToo//rn12mmJpeyIWA4m6X PBtJwLxZqkeThU49uJzm6nfM0saWdeM33IfmCj2pTvAESbf2Tfp7VOpJ1xDS03xy vq8HBJXtSomGiel31rfB =X9xM -----END PGP SIGNATURE----- From rwelty at nwtime.org Thu Jul 9 14:39:51 2015 From: rwelty at nwtime.org (Richard Welty) Date: Thu, 09 Jul 2015 10:39:51 -0400 Subject: [openssl-users] X509_STORE crash in CMS_verify Message-ID: <559E87B7.5060509@nwtime.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ok, i have a crash in CMS_verify that suggests i'm not setting up the store of CAs properly, or i may have made an error setting up the CA. what should i be looking at with this error? (gdb) bt #0 0x00007ffff7909b6c in X509_STORE_get_by_subject () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #1 0x00007ffff790a3ca in X509_STORE_CTX_get1_issuer () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #2 0x00007ffff7906055 in X509_verify_cert () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #3 0x00007ffff792a8af in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #4 0x00007ffff792aeb0 in CMS_verify () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #5 0x0000000000401f7e in nts_cms_verify (cms_content=0x6281a0, certs=0x6206d0, store=0x0, content_data=content_data at entry=0x7fffffffde88, content_length=content_length at entry=0x7fffffffde84) at cms.c:154 #6 0x0000000000401b70 in test_nts_cms_sign_and_verify () at cms.c:184 #7 0x000000000040165e in main (argc=, argv=) at run-cms.c:49 From tom.browder at gmail.com Thu Jul 9 14:47:00 2015 From: tom.browder at gmail.com (Tom Browder) Date: Thu, 9 Jul 2015 09:47:00 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d Message-ID: I get the following warnings from compiling the latest openssl with gcc 4.7.2: ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': ec_key.c:369:26: warning: variable 'is_char_two' set but not used [-Wunused-but-set-variable] ecp_nistp224.c: In function 'batch_mul': ecp_nistp224.c:1105:29: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp256.c: In function 'batch_mul': ecp_nistp256.c:1631:28: warning: array subscript is above array bounds [-Warray-bounds] ecp_nistp521.c: In function 'batch_mul': ecp_nistp521.c:1457:29: warning: array subscript is above array bounds [-Warray-bounds] I'm not real current with C so I'm not in a great position to criticize, but can't those warnings (if there is truly no problem) be eliminated (at least in gcc) with a pragma? Thanks. Best regards, -Tom From openssl-users at dukhovni.org Thu Jul 9 15:22:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Jul 2015 15:22:36 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: Message-ID: <20150709152236.GG21534@mournblade.imrryr.org> On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: > I get the following warnings from compiling the latest openssl with gcc 4.7.2: > > ecp_nistp224.c: In function 'batch_mul': > ecp_nistp224.c:1105:29: warning: array subscript is above array bounds > [-Warray-bounds] In my copy of 1.0.2d, line 1105 of that file is in select_point(), not batch_mul(). Are you sure you're compiling the right code? -- Viktor. From matt at openssl.org Thu Jul 9 15:25:32 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 09 Jul 2015 16:25:32 +0100 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: Message-ID: <559E926C.9070701@openssl.org> On 09/07/15 15:47, Tom Browder wrote: > I get the following warnings from compiling the latest openssl with gcc 4.7.2: > > ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': > ec_key.c:369:26: warning: variable 'is_char_two' set but not used > [-Wunused-but-set-variable] I don't get this by default, but can force it by compiling with no-ec2m. I assume that is what you are using? Its harmless but should be fixed. > > ecp_nistp224.c: In function 'batch_mul': > ecp_nistp224.c:1105:29: warning: array subscript is above array bounds > [-Warray-bounds] > > ecp_nistp256.c: In function 'batch_mul': > ecp_nistp256.c:1631:28: warning: array subscript is above array bounds > [-Warray-bounds] > > ecp_nistp521.c: In function 'batch_mul': > ecp_nistp521.c:1457:29: warning: array subscript is above array bounds > [-Warray-bounds] These only get compiled with enable-ec_nistp_64_gcc_128, but even with that I don't see these warnings. Perhaps a gcc issue fixed in later versions? I'm using gcc 4.9.2 Matt From tom.browder at gmail.com Thu Jul 9 16:50:25 2015 From: tom.browder at gmail.com (Tom Browder) Date: Thu, 9 Jul 2015 11:50:25 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <20150709152236.GG21534@mournblade.imrryr.org> References: <20150709152236.GG21534@mournblade.imrryr.org> Message-ID: On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni wrote: > On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: ... >> ecp_nistp224.c: In function 'batch_mul': >> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds ... > In my copy of 1.0.2d, line 1105 of that file is in select_point(), > not batch_mul(). Are you sure you're compiling the right code? Yes, and you're right about the function--weird, but maybe Matt's e-mail points out the real problem. Thanks, Viktor. -Tom From tom.browder at gmail.com Thu Jul 9 16:56:46 2015 From: tom.browder at gmail.com (Tom Browder) Date: Thu, 9 Jul 2015 11:56:46 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <559E926C.9070701@openssl.org> References: <559E926C.9070701@openssl.org> Message-ID: On Thu, Jul 9, 2015 at 10:25 AM, Matt Caswell wrote: > > > On 09/07/15 15:47, Tom Browder wrote: >> I get the following warnings from compiling the latest openssl with gcc 4.7.2: >> >> ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': >> ec_key.c:369:26: warning: variable 'is_char_two' set but not used >> [-Wunused-but-set-variable] > > I don't get this by default, but can force it by compiling with no-ec2m. > I assume that is what you are using? Its harmless but should be fixed. Yes, you are correct. I should have been more specific: I am using openssl version 1.0.2d, and here is my configuration script: $ cat openssl-config.sh SSLDIR=/opt/openssl ./config \ no-ec2m \ no-rc5 \ no-idea \ threads \ zlib-dynamic \ shared \ --prefix=${SSLDIR} \ --openssldir=${SSLDIR} \ enable-ec_nistp_64_gcc_128 >> ecp_nistp521.c: In function 'batch_mul': >> ecp_nistp521.c:1457:29: warning: array subscript is above array bounds >> [-Warray-bounds] > These only get compiled with enable-ec_nistp_64_gcc_128, but even with > that I don't see these warnings. Perhaps a gcc issue fixed in later > versions? I'm using gcc 4.9.2 Hm, I've been looking for an excuse to build the latest gcc, now I have. But I haven't tried clang yet so here goes... Thanks, Matt. Best, -Tom From openssl-users at dukhovni.org Thu Jul 9 17:00:11 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Jul 2015 17:00:11 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> Message-ID: <20150709170010.GA28047@mournblade.imrryr.org> On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote: > On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni > wrote: > > On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: > ... > >> ecp_nistp224.c: In function 'batch_mul': > >> ecp_nistp224.c:1105:29: warning: array subscript is above array bounds > ... > > In my copy of 1.0.2d, line 1105 of that file is in select_point(), > > not batch_mul(). Are you sure you're compiling the right code? > > Yes, and you're right about the function--weird, but maybe Matt's > e-mail points out the real problem. That surely means that you're compiling some patched version or not even 1.0.2d. -- Viktor. From vogelke at pobox.com Thu Jul 9 19:52:46 2015 From: vogelke at pobox.com (Karl Vogel) Date: Thu, 9 Jul 2015 15:52:46 -0400 Subject: [openssl-users] Old "RSA_NET" key format Message-ID: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> >> On 08/07/2015 20:23, Salz, Rich wrote: > 1. Is there any good reason to remove this code? R> Yes. If it's not tested, reviewed, or in general use, then it's R> more likely to be harmful (source of bugs) than useful. >> On Wed, 08 Jul 2015 20:47:43 +0200, Jakob Bohm replied: J> That's an overly general criteria... Nope, Rich is right on the money. J> To objectively consider the potential harm of rarely used code, J> one must clearly determine if there is any way this code could be J> invoked inadvertently or remotely. How do stack-smashers work? Don't they trick a system into running part of a program inadvertently, often with elevated privileges? How many of us build and run OpenSSL using compiler optimization? Have a look at http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf From the blurb: What if you put security into your code but your compiler took it out without you realizing it? That's exactly what's happening when you use most compilers on the market, according to researchers at MIT as disclosed in a 2013 paper. The authors describe some security operations (null pointer checks, buffer overflow safeguards, etc) seen by the compiler as being unnecessary, and hence removed. I don't know that this is actually happening anywhere in the codebase, but it's a *big* codebase, and that's the problem. How about the NTP reflection attacks we saw recently? From http://www.mail-archive.com/tech at openbsd.org/msg21729.html [...] openntpd is a modern piece of code <5000 lines long written using best known practices of the time, whereas ntp.org's codebase is reportedly 100,000 lines of unknown or *largely unused code*, poorly smithed in the past when these kinds of programming mistakes were not a significant consideration. J> For example the heartbeat code was obviously callable from network J> packets (even if it had no bugs), so needed this kind of cleanup, Was this only obvious after the fact? J> while the original eay DES API is only invokable from code that J> knows about it, and would thus not need to be removed for lack of J> use/testing. What about Apple's SSL/TLS bug (AKA CVE-2014-1266, or the "goto fail bug") in February 2014? That was caused by unreachable code that needed to be reached in order to work properly. The point is, more code == more eyes and mind-share that have to be devoted to finding unintended consequences. Have a look here for more reasons to trim out old code: http://www.techrepublic.com/blog/software-engineer/why-you-need-to-clean-out-dead-code-paths/ Cliff-notes version: * Code changes gets ugly because you are trying to keep orphaned code in line with the rest of the system, but there is often no real regression testing or anything else. * Maintaining code after a long period away from it (or by someone else) is very difficult, because no one really knows why a piece of code is there, they just know that it is there. * The code is no longer a faithful representation of the business logic, because it contains logic that the specifications and business logic are not aware of. * It presents potential security risks, as unmaintained code can be reached (especially in Web applications, where tweaking parameters may trigger something you never intended). OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. -- Karl Vogel I don't speak for the USAF or my company Sign on a long-established New Mexico dry cleaners: "38 years on the same spot" From jb-openssl at wisemo.com Thu Jul 9 21:05:16 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 09 Jul 2015 23:05:16 +0200 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> References: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> Message-ID: <559EE20C.1080601@wisemo.com> On 09/07/2015 21:52, Karl Vogel wrote: >>> On 08/07/2015 20:23, Salz, Rich wrote: > > 1. Is there any good reason to remove this code? > > R> Yes. If it's not tested, reviewed, or in general use, then it's > R> more likely to be harmful (source of bugs) than useful. > >>> On Wed, 08 Jul 2015 20:47:43 +0200, Jakob Bohm replied: > J> That's an overly general criteria... > > Nope, Rich is right on the money. You are obviously quoting others without deep understanding. > > J> To objectively consider the potential harm of rarely used code, > J> one must clearly determine if there is any way this code could be > J> invoked inadvertently or remotely. > > How do stack-smashers work? Don't they trick a system into running > part of a program inadvertently, often with elevated privileges? Actually, mostly they work by tricking a system into running code that was *part of* the stack smasher itself. Second most popular option is to use parts of the general system code (libc etc.) loaded in every process (because attackers like their attack code to be reusable across different victims). Reusing part of whichever program or library that had the remote code execution flaw is typically last on their list, because it is so much more work. > > How many of us build and run OpenSSL using compiler optimization? > Have a look at http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf > From the blurb: > > What if you put security into your code but your compiler took it > out without you realizing it? That's exactly what's happening when > you use most compilers on the market, according to researchers at > MIT as disclosed in a 2013 paper. > > The authors describe some security operations (null pointer checks, > buffer overflow safeguards, etc) seen by the compiler as being > unnecessary, and hence removed. I don't know that this is actually > happening anywhere in the codebase, but it's a *big* codebase, and > that's the problem. That paper was hopefully a major wake up for compiler writers, nothing anyone else can do about (short of writing pure assembler or turning off optimizations, both very ugly "solutions"). > How about the NTP reflection attacks we saw recently? From > http://www.mail-archive.com/tech at openbsd.org/msg21729.html > > [...] openntpd is a modern piece of code <5000 lines long written > using best known practices of the time, whereas ntp.org's codebase > is reportedly 100,000 lines of unknown or *largely unused code*, > poorly smithed in the past when these kinds of programming mistakes > were not a significant consideration. Generalization beyond relevance, yes ntpd contains lots of hard to fathom code, and yes some of that may have been involved in attacks. But most of the recent ntpd related attacks didn't actually involve bugs in the code *at all*. Those were attacks on the protocol and on the incompetent ISPs not implementing standard anti- spoofing filters. So by sending a *valid* but obscure query with a false return address, people got the ntp servers to respond with *valid* larger replies to the victims whose address had been falsified. The primary changes added to ntpd were to actively detect and block overly frequent info queries pretending to be from the same address. Openntpd just happened not to support the diagnostic protocolcommands used in the attacks, it was too simple to fall victim. The code in question was probably some of the most heavily tested in ntpd, since its heaviest users are the NTP expert teams diagnosing and fine tuning production servers. > J> For example the heartbeat code was obviously callable from network > J> packets (even if it had no bugs), so needed this kind of cleanup, > > Was this only obvious after the fact? By definition, this code was intended to handle specific network packets and generate responses. The bug was a massive input validation failure. The code could *only* beinvoked from the network. > > J> while the original eay DES API is only invokable from code that > J> knows about it, and would thus not need to be removed for lack of > J> use/testing. > > What about Apple's SSL/TLS bug (AKA CVE-2014-1266, or the "goto fail > bug") in February 2014? That was caused by unreachable code that > needed to be reached in order to work properly. The point is, more > code == more eyes and mind-share that have to be devoted to finding > unintended consequences. I have not reviewed that in detail, but it sounds like there was a bug in a primary code path, not in a rarely invoked separate function. > > Have a look here for more reasons to trim out old code: > http://www.techrepublic.com/blog/software-engineer/why-you-need-to-clean-out-dead-code-paths/ Just some guys opinion on a site that carries all sorts of opinion pieces. Not even worth reading. > Cliff-notes version: > > * Code changes gets ugly because you are trying to keep orphaned code in > line with the rest of the system, but there is often no real regression > testing or anything else. Applies in general, but may or may not apply to any specific case, therefore must be evaluated on a case- by-case basis. > * Maintaining code after a long period away from it (or by someone else) > is very difficult, because no one really knows why a piece of code > is there, they just know that it is there. Is equally much an argument not to remove unknown code, if you don't understand, you don't know what you are breaking. > * The code is no longer a faithful representation of the business logic, > because it contains logic that the specifications and business logic > are not aware of. This assumes that there is a specification, *and* that this specification does not cover the code in question. Also assumes a completely different world (enterprise development as opposed to general purpose development, where the term "business logic" is nonsense). In contrast, the code in question implements an actual specification, and is there (amongst others) to exchange data with anyone else using that specification. The discussion is that someone wants to stop supporting that specification because *he* doesn't know its purpose. > * It presents potential security risks, as unmaintained code can be > reached (especially in Web applications, where tweaking parameters > may trigger something you never intended). This is not a web application. This code is not reachable except by explicit reference. It may or may not be reachable via a format-detecting data import function or a format- selecting output function, in which case it may be debatable if it should be demoted to explicit invocation only (as in data conversion programs and programs that specifically need that format). > > OpenSSL is a critical part of security in too many places for us to > take on any unnecessary technical debt. This is a somewhat empty argument as long as no one bothers to properly determine if a piece of code is a debt or an asset. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jul 9 21:09:44 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Jul 2015 21:09:44 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <559EE20C.1080601@wisemo.com> References: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> <559EE20C.1080601@wisemo.com> Message-ID: <0dbe965a0cd8417fa77ccc37a5f3211d@ustx2ex-dag1mb2.msg.corp.akamai.com> >> OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. >>This is a somewhat empty argument as long as no one bothers to properly determine if a piece of code is a debt or an asset. I claim that we are being careful and doing the proper determination. Consensus seems to agree. From jb-openssl at wisemo.com Thu Jul 9 21:18:19 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 09 Jul 2015 23:18:19 +0200 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <0dbe965a0cd8417fa77ccc37a5f3211d@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> <559EE20C.1080601@wisemo.com> <0dbe965a0cd8417fa77ccc37a5f3211d@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <559EE51B.6090701@wisemo.com> On 09/07/2015 23:09, Salz, Rich wrote: >>> OpenSSL is a critical part of security in too many places for us to take on any unnecessary technical debt. >>> This is a somewhat empty argument as long as no one bothers to properly determine if a piece of code is a debt or an asset. > I claim that we are being careful and doing the proper determination. Consensus seems to agree. However, it seems that your determination process goes like this: 1. If you think you know, you don't ask anyone if they use the feature. 2. If you do bother to ask the customers if there is a "business case" for a feature, you still ignore all arguments as to why it is an asset. Because both methods confirm your prior decisions, you therefore conclude that you were always right in the first place. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jul 9 21:29:24 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Jul 2015 21:29:24 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <559EE51B.6090701@wisemo.com> References: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> <559EE20C.1080601@wisemo.com> <0dbe965a0cd8417fa77ccc37a5f3211d@ustx2ex-dag1mb2.msg.corp.akamai.com> <559EE51B.6090701@wisemo.com> Message-ID: <15ad4b5613fa4dfc87ceb71f09f0baa7@ustx2ex-dag1mb2.msg.corp.akamai.com> > Because both methods confirm your prior decisions, you therefore conclude that you were always right in the first place. Provably wrong. I wanted to get rid of Netware support as the first example that comes to mind. As the second, I want to move all uses of RC4 and MD5 to LOW strength ciphers. Neither one of those things is happening. From jb-openssl at wisemo.com Thu Jul 9 21:46:45 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 09 Jul 2015 23:46:45 +0200 Subject: [openssl-users] [openssl-announce] OpenSSL Security Advisory In-Reply-To: <20150709131024.GA9863@openssl.org> References: <20150709131024.GA9863@openssl.org> Message-ID: <559EEBC5.7090407@wisemo.com> On 09/07/2015 15:10, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OpenSSL Security Advisory [9 Jul 2015] > ======================================= > > Alternative chains certificate forgery (CVE-2015-1793) > ====================================================== > > Severity: High > > During certificate verification, OpenSSL (starting from version 1.0.1n and > 1.0.2b) will attempt to find an alternative certificate chain if the first > attempt to build such a chain fails. An error in the implementation of this > logic can mean that an attacker could cause certain checks on untrusted > certificates to be bypassed, such as the CA flag, enabling them to use a valid > leaf certificate to act as a CA and "issue" an invalid certificate. Why was this introduced in a patch release? I thought improved chain building was a new feature, and thus delineated by a library version number such as 1.0.2or 1.0.3. In fact, I thought that was the reason we all had to wait ages before this long standing shortcoming was fixed. > This issue will impact any application that verifies certificates including > SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. Does this vulnerability also affect applications that use OpenSSL or the openssl command line to handle S/MIME or other CMS messages? For example, the mail client mutt handles S/MIME by invoking the openssl command line via macros in the default configuration file. P.S. Sorry for first trying to send to -announce, MUA must have ignored the Reply-To. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jul 9 22:47:21 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 09 Jul 2015 23:47:21 +0100 Subject: [openssl-users] [openssl-announce] OpenSSL Security Advisory In-Reply-To: <559EEBC5.7090407@wisemo.com> References: <20150709131024.GA9863@openssl.org> <559EEBC5.7090407@wisemo.com> Message-ID: <559EF9F9.3070004@openssl.org> On 09/07/15 22:46, Jakob Bohm wrote: > On 09/07/2015 15:10, OpenSSL wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> OpenSSL Security Advisory [9 Jul 2015] >> ======================================= >> >> Alternative chains certificate forgery (CVE-2015-1793) >> ====================================================== >> >> Severity: High >> >> During certificate verification, OpenSSL (starting from version 1.0.1n and >> 1.0.2b) will attempt to find an alternative certificate chain if the first >> attempt to build such a chain fails. An error in the implementation of this >> logic can mean that an attacker could cause certain checks on untrusted >> certificates to be bypassed, such as the CA flag, enabling them to use a valid >> leaf certificate to act as a CA and "issue" an invalid certificate. > Why was this introduced in a patch release? I thought > improved chain building was a new feature, and thus > delineated by a library version number such as 1.0.2or > 1.0.3. In fact, I thought that was the reason we all > had to wait ages before this long standing shortcoming > was fixed. Is it a new feature or a defect fix? On the one hand OpenSSL has never been able to handle alternative certificate chains. If the first chain attempted fails to verify then we stop. Its always been done that way and from that point of view the ability to handle alternative cert chains is a new feature. On the other hand, from a users perspective, if you present OpenSSL with a perfectly valid certificate, and a perfectly valid trust store, then you expect it to successfully verify the certificate no matter what. OpenSSL was failing to do that, and therefore this would suggest it is a defect. My initial view was the former. This issue was raised a number of times within RT and on the openssl-dev list and also via other routes. It was clearly causing real problems for end users (and increasingly so). There was much discussion on this topic, but ultimately the decision was taken to change our mind, and treat it as a defect. For that reason it was included in a patch release. >> This issue will impact any application that verifies certificates including >> SSL/TLS/DTLS clients and SSL/TLS/DTLS servers using client authentication. > Does this vulnerability also affect applications that > use OpenSSL or the openssl command line to handle S/MIME > or other CMS messages? Yes. Ultimately it affects all applications that verify certificates. That includes the openssl command line applications. Matt From sudarshan.t.raghavan at gmail.com Fri Jul 10 10:40:04 2015 From: sudarshan.t.raghavan at gmail.com (Sudarshan Raghavan) Date: Fri, 10 Jul 2015 16:10:04 +0530 Subject: [openssl-users] Transferring SSL Connections from one process to another. Message-ID: Hi, I have been trying to transfer SSL connections (that are in accept state with handshake completed and some data already sent/received prior to the transfer) from one process to another so that it would allow me to seamlessly receive and send over the SSL connection (from an SSL Client) once it has been transferred to the new process. Let me try to explain what I did to achieve this. 1) Created a UNIX domain socket pair between the two processes. 2) Transferred the socket descriptors from one process to another (used sendmsg and recvmsg APIs for this) 3) Retrieved the SSL_SESSION from SSL structure instance and converted this to a sequence of bytes using the OpenSSL API "i2d_SSL_Session". Sent this information from the first process using the sendmsg API (and received at the other process using the recvmsg API). 4) Converted the raw bytes to SSL_SESSION using the OpenSSL API "d2i_SSL_Session". 5) On the new process instead of doing a handshake (using the OpenSSL API SSL_do_handshake), I first set the session to the SSL_CTX structure instance using the API SSL_CTX_add_session and then set the session on on the SSL structure (by calling SSL_new with the context) instance using SSL_set_session. 6) Finally added read & write events for the socket descriptor and set the read and write handlers appropriately (to read and write plain text data). Used epoll mechanism to do so. I was able to transfer the TCP connections across the processes (confirmed by sending data over the passed over TCP Connection). However when i tried sending data (using openssl s_client) over this SSL connection it gave me the following errors followed by a close notify. 1) Got the following error when a stream cipher (RC4SHA) was used. *SSL3 alert write:fatal:decode error* *3074365640:error:1408F0A0:SSL routines:SSL3_GET_RECORD:length too short:s3_pkt.c:445* 2) Got a "decryption failed" error when a block cipher was used. I do not have the entire error description with me right now. I am not sure why I received this error. Could you help me out with the following queries? 1) Have I missed out something that I should have done to transfer SSL connections from one process to another? Is it possible to do so in the first place? If so, could you let me know how? 2) The API documentation for SSL_set_session says that it is only useful for SSL/TLS clients. I am not sure what this means. Can i use it on SSL Connections at the server side? Is it that this API can only be used to cache sessions and resume the SSL sessions at a later point in time. Regards, Sudarshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdelgado05 at gmail.com Fri Jul 10 12:09:03 2015 From: rcdelgado05 at gmail.com (R C Delgado) Date: Fri, 10 Jul 2015 13:09:03 +0100 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 Message-ID: Hello, With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. How deep does the certificate chain have to be? If I have 2 self-signed CA certificates, and a non-CA certificate is received for verification, will this hit the problem? Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? Many thanks for your help. RCD -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jul 10 12:55:24 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 10 Jul 2015 12:55:24 +0000 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: References: Message-ID: <3e6d9e4f0107411f8bcb8928f7ce9d86@ustx2ex-dag1mb2.msg.corp.akamai.com> >How deep does the?certificate?chain have to be? It does not matter. >If I have 2 self-signed CA certificates, and a non-CA?certificate?is received for?verification, will this hit?the?problem? >Also, is it a condition of the bug that both CA certificates have to have the same subject names and keys, as suggested in the file? I think you are confused. The bug is not about CA's. It's about a non-CA fooling the runtime into treating it as if it were a CA and being able to issue a certificate. From matt at openssl.org Fri Jul 10 13:32:35 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 10 Jul 2015 14:32:35 +0100 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: References: Message-ID: <559FC973.5000808@openssl.org> On 10/07/15 13:09, R C Delgado wrote: > Hello, > > With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. > How deep does the certificate chain have to be? > If I have 2 self-signed CA certificates, and a non-CA certificate is > received for verification, will this hit the problem? > > Also, is it a condition of the bug that both CA certificates have to > have the same subject names and keys, as suggested in the file? The conditions for triggering the bug are a little complicated, but I'll do my best to explain it. Under normal circumstances things work as follows: We are provided with a certificate to verify from a remote peer. Lets call the certificate we are trying to verify Leaf. As well as Leaf that has been provided from the remote peer, they also supply us with a set of untrusted certs. Finally we also have a store of trusted certs. OpenSSL will first attempt to build a certificate chain. The chain building works as follows (much simplified): 1. Set Leaf as the top of the chain 2. Look for the issuer of the cert at the top of the chain from within the untrusted set. If we find it add it to the top of the chain 3. Repeat (2) until we can't find any more certs from the untrusted set 4. Look for the issuer of the top of the chain from the set of trusted certs 5. Repeat (4) until we can't find any more certs from the trusted set If we've found a valid chain with a trusted self signed cert at the top, then we stop there. If not, then we continue to look to see if there is an alternative chain that can be built. This works as follows: Pop all the trusted certs off the top of the chain, then start popping the untrusted certs off. Each time we pop an untrusted cert off start the chain building again from step 4. The bug occurs when during the initial chain building: 1) We have added at least one cert from the untrusted set 2) We have added at least one cert from the trusted store For 1.0.2 there is the additional condition: 3) After doing (1) and (2) above we do not have a valid chain Finally (for both 1.0.1 and 1.0.2) 4) After popping off at least one untrusted cert from the chain we can build an alternative valid chain Under the above conditions the end entity cert Leaf could "issue" a new certificate even though it is not supposed to (I'll call that invalid certificate "Bad"). So these certs would need to be present (at a minimum): Chain 1: Trusted Cert 1 | Untrusted Cert 1 | Leaf | Bad Chain 2: Trusted Cert 2 | Leaf | Bad There are other possible longer chains, but this is the minimum set. For 1.0.2, Chain 1 would have to be non-trusted, even though we have added a trusted cert. This can occur if Trusted Cert 1 is not self signed and its issuer is not in the trusted store. For 1.0.1 any chain will do. Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers of Leaf (i.e. they have the same subject names and public keys). Chain 2 must be trusted (so Trusted Cert 2 has to be a self-signed root). Matt From lgrosenthal at 2rosenthals.com Fri Jul 10 14:16:58 2015 From: lgrosenthal at 2rosenthals.com (Lewis Rosenthal) Date: Fri, 10 Jul 2015 10:16:58 -0400 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: <559FC973.5000808@openssl.org> References: <559FC973.5000808@openssl.org> Message-ID: <559FD3DA.9010609@2rosenthals.com> On 07/10/2015 09:32 AM, Matt Caswell wrote: > > On 10/07/15 13:09, R C Delgado wrote: >> Hello, >> >> With regards to CVE-2015-1793, I've seen the example in verify_extra_test.c. >> How deep does the certificate chain have to be? >> If I have 2 self-signed CA certificates, and a non-CA certificate is >> received for verification, will this hit the problem? >> >> Also, is it a condition of the bug that both CA certificates have to >> have the same subject names and keys, as suggested in the file? > > The conditions for triggering the bug are a little complicated, but I'll > do my best to explain it. > > So these certs would need to be present (at a minimum): > > Chain 1: > > Trusted Cert 1 > | > Untrusted Cert 1 > | > Leaf > | > Bad > > Chain 2: > > Trusted Cert 2 > | > Leaf > | > Bad > > There are other possible longer chains, but this is the minimum set. For > 1.0.2, Chain 1 would have to be non-trusted, even though we have added a > trusted cert. This can occur if Trusted Cert 1 is not self signed and > its issuer is not in the trusted store. For 1.0.1 any chain will do. > Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers > of Leaf (i.e. they have the same subject names and public keys). Chain 2 > must be trusted (so Trusted Cert 2 has to be a self-signed root). > Thanks, Matt. This is the most cogent explanation I've seen to date. Cheers -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress IRS Circular 230 Disclosure applies see www.2rosenthals.com ------------------------------------------------------------- From rcdelgado05 at gmail.com Fri Jul 10 14:48:38 2015 From: rcdelgado05 at gmail.com (R C Delgado) Date: Fri, 10 Jul 2015 15:48:38 +0100 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: <559FC973.5000808@openssl.org> References: <559FC973.5000808@openssl.org> Message-ID: Thank you very much. It really helps. On Fri, Jul 10, 2015 at 2:32 PM, Matt Caswell wrote: > > > On 10/07/15 13:09, R C Delgado wrote: > > Hello, > > > > With regards to CVE-2015-1793, I've seen the example in > verify_extra_test.c. > > How deep does the certificate chain have to be? > > If I have 2 self-signed CA certificates, and a non-CA certificate is > > received for verification, will this hit the problem? > > > > Also, is it a condition of the bug that both CA certificates have to > > have the same subject names and keys, as suggested in the file? > > > The conditions for triggering the bug are a little complicated, but I'll > do my best to explain it. > > Under normal circumstances things work as follows: > > We are provided with a certificate to verify from a remote peer. Lets > call the certificate we are trying to verify Leaf. > As well as Leaf that has been provided from the remote peer, they also > supply us with a set of untrusted certs. > Finally we also have a store of trusted certs. > > OpenSSL will first attempt to build a certificate chain. The chain > building works as follows (much simplified): > > 1. Set Leaf as the top of the chain > 2. Look for the issuer of the cert at the top of the chain from within > the untrusted set. If we find it add it to the top of the chain > 3. Repeat (2) until we can't find any more certs from the untrusted set > 4. Look for the issuer of the top of the chain from the set of trusted > certs > 5. Repeat (4) until we can't find any more certs from the trusted set > > If we've found a valid chain with a trusted self signed cert at the top, > then we stop there. If not, then we continue to look to see if there is > an alternative chain that can be built. This works as follows: > > Pop all the trusted certs off the top of the chain, then start popping > the untrusted certs off. Each time we pop an untrusted cert off start > the chain building again from step 4. > > The bug occurs when during the initial chain building: > 1) We have added at least one cert from the untrusted set > 2) We have added at least one cert from the trusted store > > For 1.0.2 there is the additional condition: > 3) After doing (1) and (2) above we do not have a valid chain > > Finally (for both 1.0.1 and 1.0.2) > 4) After popping off at least one untrusted cert from the chain we can > build an alternative valid chain > > Under the above conditions the end entity cert Leaf could "issue" a new > certificate even though it is not supposed to (I'll call that invalid > certificate "Bad"). > > So these certs would need to be present (at a minimum): > > Chain 1: > > Trusted Cert 1 > | > Untrusted Cert 1 > | > Leaf > | > Bad > > Chain 2: > > Trusted Cert 2 > | > Leaf > | > Bad > > There are other possible longer chains, but this is the minimum set. For > 1.0.2, Chain 1 would have to be non-trusted, even though we have added a > trusted cert. This can occur if Trusted Cert 1 is not self signed and > its issuer is not in the trusted store. For 1.0.1 any chain will do. > Untrusted Cert 1 and Trusted Cert 2 would both have to be valid issuers > of Leaf (i.e. they have the same subject names and public keys). Chain 2 > must be trusted (so Trusted Cert 2 has to be a self-signed root). > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Jul 10 15:43:47 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 10 Jul 2015 15:43:47 +0000 Subject: [openssl-users] Old "RSA_NET" key format In-Reply-To: <15ad4b5613fa4dfc87ceb71f09f0baa7@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150709195246.GA29553@bsd118.area52.afnoapps.usaf.mil> <559EE20C.1080601@wisemo.com> <0dbe965a0cd8417fa77ccc37a5f3211d@ustx2ex-dag1mb2.msg.corp.akamai.com> <559EE51B.6090701@wisemo.com> <15ad4b5613fa4dfc87ceb71f09f0baa7@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, July 09, 2015 15:29 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Old "RSA_NET" key format > > > Because both methods confirm your prior decisions, you therefore > conclude that you were always right in the first place. > > Provably wrong. I wanted to get rid of Netware support as the first example > that comes to mind. As the second, I want to move all uses of RC4 and MD5 > to LOW strength ciphers. Neither one of those things is happening. As one of the people who complained (publicly) about the proposal to move RC4 to LOW, I have to support Rich here. He did ask about it on the list, there were complaints, and the mooted change was abandoned (at that time; it may of course come up again, which I think is reasonable). In the flurry of changes to the OpenSSL development staff and processes after Heartbleed, some people - myself included - had the impression that the team was making changes to OpenSSL too quickly, with insufficient community input. Since then I for one have come to feel that they're being more measured and careful about making those changes than I originally believed. Removing little-used, archaic features always poses some danger of breaking existing applications. However, it's also a potent way to retire technical debt and refactor other parts of the code base, making the whole easier to maintain, which is a benefit to people not using those features. It's a procedure that shouldn't be undertaken lightly, but software development is always a matter of compromises, and sometimes it's the best compromise available. -- Michael Wojcik Technology Specialist, Micro Focus From remy.grunblatt at ens-lyon.fr Fri Jul 10 16:05:01 2015 From: remy.grunblatt at ens-lyon.fr (=?UTF-8?Q?R=c3=a9my_Gr=c3=bcnblatt?=) Date: Fri, 10 Jul 2015 18:05:01 +0200 Subject: [openssl-users] Adding ECDH_METHODs to OpenSSL ? Message-ID: <559FED2D.6020101@ens-lyon.fr> Hello. OpenSSL already multiple operations like ECDSA_METHOD_set_sign or ECDSA_METHOD_set_sign_setup that facilitate the work of creating Engines for ECDSA operations. Could you provide a way to do the same thing with ECDH ? Or at least, providing the definition of ecdh_method in public headers, so one doesn't have to provide it ? manually ? when creating ECDH performing engines ? Thank you for your work, anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From james at jamesbillingham.com Fri Jul 10 17:01:02 2015 From: james at jamesbillingham.com (James Billingham) Date: Fri, 10 Jul 2015 18:01:02 +0100 Subject: [openssl-users] Vulnerability Disclosures Message-ID: Hi, I apologize if this is the wrong place for this email - it seemed to be the most suitable of the mailing lists. I wanted to suggest that when notifying of new vulnerabilities, in addition to the severity level, information is also provided about how widespread the issue is expected to be. For example, the statement might say "this high severity bug is expected to affect around 70% of cases?, or for CVE-2015-1788 it would presumably state ?around 1%? as it affects only client-side uses. This would help OpenSSL users gauge whether the upcoming vulnerability is ?heartbleed?-level, or less serious/widespread. Currently a wide variety of vulnerabilities are just indicated as ?high? severity, which could mean anything from a relatively minor DoS affecting 5 implementations to MITM affecting all servers/browsers. Thanks, James From m.j at mailbox.org Fri Jul 10 18:05:34 2015 From: m.j at mailbox.org (Tanisha Fuentes) Date: Fri, 10 Jul 2015 20:05:34 +0200 (CEST) Subject: [openssl-users] -Wconversion Message-ID: <2022412785.1931.1436551534786.JavaMail.open-xchange@ox2app> Hello, I just compiled with openssl-1.0.2c with "-Wextra -Wconversion -Wno-unused-parameter" and a got many (1251) -Wconversion-related warnings. I checked few source code lines but haven't found something mentionable. Still -Wconversion-warnings can be an indicator of conversion bugs, which could affect the code correctness. Is it planned to tackle the warnings, for example by checking the involved code lines and (carefully) replace them by explicit casting to achieve clean compiles when using stricter warnings? Best regards, M.J. From rsalz at akamai.com Fri Jul 10 18:09:14 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 10 Jul 2015 18:09:14 +0000 Subject: [openssl-users] -Wconversion In-Reply-To: <2022412785.1931.1436551534786.JavaMail.open-xchange@ox2app> References: <2022412785.1931.1436551534786.JavaMail.open-xchange@ox2app> Message-ID: > Is it planned to tackle the warnings, for example by checking the involved > code lines and (carefully) replace them by explicit casting to achieve clean > compiles when using stricter warnings? Yes. Timetable TBD. From rcdelgado05 at gmail.com Fri Jul 10 18:34:30 2015 From: rcdelgado05 at gmail.com (R C Delgado) Date: Fri, 10 Jul 2015 19:34:30 +0100 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: <559FC973.5000808@openssl.org> References: <559FC973.5000808@openssl.org> Message-ID: Hello, One further question. Can you please confirm that the alternative certificate chain feature is enabled by default? It seems to be implied in all emails regarding this matter, and I'm assuming the Advisory email would have mentioned it otherwise. I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS exists but is not set in the "flags" member by default when a new X509 context is initialised. And my code does not modify the context to include this flag. Please let me know if I'm missing something. (I'm using OpenSSL 1.0.1o) Many thanks, RCD > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Jul 10 21:03:24 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 10 Jul 2015 17:03:24 -0400 Subject: [openssl-users] [openssl-announce] OpenSSL Security Advisory In-Reply-To: <559EEBC5.7090407@wisemo.com> References: <20150709131024.GA9863@openssl.org> <559EEBC5.7090407@wisemo.com> Message-ID: > During certificate verification, OpenSSL (starting from version 1.0.1n and > 1.0.2b) will attempt to find an alternative certificate chain if the first > attempt to build such a chain fails. An error in the implementation of this > logic can mean that an attacker could cause certain checks on untrusted > certificates to be bypassed, such as the CA flag, enabling them to use a > valid > leaf certificate to act as a CA and "issue" an invalid certificate. > > Why was this introduced in a patch release? I thought > improved chain building was a new feature, and thus > delineated by a library version number such as 1.0.2 or > 1.0.3 . I *think* "improved" chain building should have present in the library earlier. The methods always exited. See, for example, 4158, https://www.ietf.org/rfc/rfc4158.txt. Here's a real world failure due to previous, "naive" path building: https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. The CA re-issued a root by changing the hash and serial number, but recertifying the same public key and DN. Then, the server sent the old root too as an intermediate. So there were two roots available, each with the same DN. > In fact, I thought that was the reason we all > had to wait ages before this long standing shortcoming > was fixed. It almost sound like you are complaining you did not have to wait ages :) Jeff From matt at openssl.org Fri Jul 10 21:10:37 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 10 Jul 2015 22:10:37 +0100 Subject: [openssl-users] OpenSSL Security Advisory - CVE-2015-1793 In-Reply-To: References: <559FC973.5000808@openssl.org> Message-ID: <55A034CD.8060709@openssl.org> On 10/07/15 19:34, R C Delgado wrote: > Hello, > > One further question. Can you please confirm that the alternative > certificate chain feature is enabled by default? It seems to be implied > in all emails regarding this matter, and I'm assuming the Advisory email > would have mentioned it otherwise. Yes, it is enabled by default. Matt > > I've searched the OpenSSL code and seen that X509_V_FLAG_NO_ALT_CHAINS > exists but is not set in the "flags" member by default when a new X509 > context is initialised. And my code does not modify the context to > include this flag. > > Please let me know if I'm missing something. > > (I'm using OpenSSL 1.0.1o) > > Many thanks, > RCD > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From e.soliz24 at yahoo.com Sat Jul 11 21:51:13 2015 From: e.soliz24 at yahoo.com (choliz) Date: Sat, 11 Jul 2015 14:51:13 -0700 (MST) Subject: [openssl-users] FIPS mode entropy callback for rsa key Message-ID: <1436651473074-59114.post@n7.nabble.com> Hello, I currently have a FIPS module where I'm trying to add entropy to RSA key generation pair. I've overwritten the callbacks within my application but I'm not seeing them being executed when I generate an RSA key. When I call RSA_generate_key_ex shouldn't my entropy callback function be invoked that I set in FIPS_drbg_set_callbacks? The only way I can get the callback to be invoked is if I call FIPS_drbg_instantiate. Can someone please explain how RSA_generate_key_ex can use my specific get_entropy callback? Thanks! -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-mode-entropy-callback-for-rsa-key-tp59114.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From noloader at gmail.com Sun Jul 12 00:53:20 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 11 Jul 2015 20:53:20 -0400 Subject: [openssl-users] Vulnerability Disclosures In-Reply-To: References: Message-ID: > I wanted to suggest that when notifying of new vulnerabilities, in addition to the severity level, information is also provided about how widespread the issue is expected to be. > > For example, the statement might say "this high severity bug is expected to affect around 70% of cases?, or for CVE-2015-1788 it would presumably state ?around 1%? as it affects only client-side uses. > > This would help OpenSSL users gauge whether the upcoming vulnerability is ?heartbleed?-level, or less serious/widespread. Currently a wide variety of vulnerabilities are just indicated as ?high? severity, which could mean anything from a relatively minor DoS affecting 5 implementations to MITM affecting all servers/browsers. > Wide-spread-ness is an interesting factoid, but I kind of feel like its not really relevant. OpenSSL is kind of ubiquitous, so adverse events are kind of widespread by definition. I've worked in Risk as a Security Architect. An organization has a risk posture, and they will choose to remediate a vulnerability that applies to them; or they will choose to do nothing and accept the risk. An organization will also assess their partners, and ensure compatible security postures as a matter of governance. If their partner is deficient, then they will have to address that risk too or do nothing and accept the risk. The monoculture based on OpenSSL's success is a hindrance, too. Its kind of like a genome that's lost its genetic diversification. A interesting talk about it is Dan Geer's "Heartbleed as Metaphor", http://www.lawfareblog.com/heartbleed-metaphor. Jeff From rsalz at akamai.com Sun Jul 12 02:31:16 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 12 Jul 2015 02:31:16 +0000 Subject: [openssl-users] Vulnerability Disclosures In-Reply-To: References: Message-ID: <2c84ef58c1e9464bae3f70fa08e22ff8@ustx2ex-dag1mb2.msg.corp.akamai.com> > > I wanted to suggest that when notifying of new vulnerabilities, in addition > to the severity level, information is also provided about how widespread the > issue is expected to be. I'd be concerned about doing that. While this one seemed pretty rare -- only folks running a release less than 30 days old in production -- as a general rule, it's impossible to tell. For example, we THINK that PSK isn't used much, but we have no idea -- it's real popular in the Internet of Things, for example. It seems safer to say nothing, then to say something misleading or wrong. We'd like to give as much information as possible, but not enough to expose the vulnerability exploit and not anything that could be misleading. It's a very hard point to triangulate. /r$ From richmoore44 at gmail.com Sun Jul 12 10:31:32 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Sun, 12 Jul 2015 11:31:32 +0100 Subject: [openssl-users] Vulnerability Disclosures In-Reply-To: <2c84ef58c1e9464bae3f70fa08e22ff8@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2c84ef58c1e9464bae3f70fa08e22ff8@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 12 July 2015 at 03:31, Salz, Rich wrote: > I'd be concerned about doing that. While this one seemed pretty rare -- > only folks running a release less than 30 days old in production -- as a > general rule, it's impossible to tell. For example, we THINK that PSK > isn't used much, but we have no idea -- it's real popular in the Internet > of Things, for example. It seems safer to say nothing, then to say > something misleading or wrong. > > We'd like to give as much information as possible, but not enough to > expose the vulnerability exploit and not anything that could be > misleading. It's a very hard point to triangulate. > ?I don't really see this being feasible. For example many of our clients get confused when we report openssl vulnerabilities against some SSL accelerator or proxy device simply because they're unaware that the code in the device is based on openssl. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From therchek at fiberlink.com Sun Jul 12 20:01:31 2015 From: therchek at fiberlink.com (Thomas Herchek) Date: Sun, 12 Jul 2015 16:01:31 -0400 Subject: [openssl-users] Error condition at a customer site Message-ID: Hi, Sometimes, during the processing of an HTTP cert response from the Symantec PKI Manager SCEP server, our application encounters an error condition while validating the certs attributes. The error that we see is "Transaction not permitted or supported". It appears that this error is detected either in the ASN1_TYPE_get() function or the OBJ_nid2obj() function. Can you tell me, what conditions might cause this type of failure when unwrapping and validating a cert response? Here is a snippet of our code that detects this condition: /* Get signed attributes */ attribs = PKCS7_get_signed_attributes(si); if (attribs == NULL) { ReportAPIError("[PKCS7_UnWrap] No attributes found in PKCS#7 data", szErr); goto cleanup; } ... /* Get pkiStatus */ if ((i = get_signed_attribute(attribs, nid_pkiStatus, V_ASN1_PRINTABLESTRING, &p)) == 1) { ReportAPIError("[PKCS7_UnWrap] Failed to get the signer pkiStatus attributes", szErr); goto cleanup; } /* Get failInfo */ if (atoi(p)!= SCEP_PKISTATUS_SUCCESS) { if (atoi(p) == SCEP_PKISTATUS_FAILURE) { if ((i = get_signed_attribute(attribs, nid_failInfo, V_ASN1_PRINTABLESTRING, &p)) == 1) { ReportError("[PKCS7_UnWrap] Cannot find failInfo", szErr); goto cleanup; } switch (atoi(p)) { case SCEP_FAILINFO_BADALG: ReportError("[PKCS7_UnWrap] Unrecognized or unsupported algorithm ident", szErr); break; case SCEP_FAILINFO_BADMSGCHK: ReportError("[PKCS7_UnWrap] Integrity check failed", szErr); break; case SCEP_FAILINFO_BADREQ: ReportError("[PKCS7_UnWrap] Transaction not permitted or supported", szErr); break; case SCEP_FAILINFO_BADTIME: ReportError("[PKCS7_UnWrap] Message time field was not sufficiently close to the system time", szErr); break; case SCEP_FAILINFO_BADCERTID: ReportError("[PKCS7_UnWrap] No certificate could be identified matching", szErr); break; default: ReportError("[PKCS7_UnWrap] Wrong failInfo in reply", szErr); } } else { ReportAPIError("[PKCS7_UnWrap] PKI Status: Not success", szErr); } goto cleanup; ________________________________ Fiberlink Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Jul 13 00:27:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 13 Jul 2015 02:27:55 +0200 Subject: [openssl-users] [openssl-announce] OpenSSL Security Advisory In-Reply-To: References: <20150709131024.GA9863@openssl.org> <559EEBC5.7090407@wisemo.com> Message-ID: <55A3060B.6060604@wisemo.com> On 10/07/2015 23:03, Jeffrey Walton wrote: >> During certificate verification, OpenSSL (starting from version 1.0.1n and >> 1.0.2b) will attempt to find an alternative certificate chain if the first >> attempt to build such a chain fails. An error in the implementation of this >> logic can mean that an attacker could cause certain checks on untrusted >> certificates to be bypassed, such as the CA flag, enabling them to use a >> valid >> leaf certificate to act as a CA and "issue" an invalid certificate. >> >> Why was this introduced in a patch release? I thought >> improved chain building was a new feature, and thus >> delineated by a library version number such as 1.0.2 or >> 1.0.3 . > I *think* "improved" chain building should have present in the library > earlier. The methods always exited. See, for example, 4158, > https://www.ietf.org/rfc/rfc4158.txt. > > Here's a real world failure due to previous, "naive" path building: > https://groups.google.com/d/msg/mailing.openssl.users/72_VQJmCmCU/hUMtemRNvRoJ. > The CA re-issued a root by changing the hash and serial number, but > recertifying the same public key and DN. Then, the server sent the old > root too as an intermediate. So there were two roots available, each > with the same DN. > >> In fact, I thought that was the reason we all >> had to wait ages before this long standing shortcoming >> was fixed. > It almost sound like you are complaining you did not have to wait ages :) It's the inconsistency of first insisting this cannot go into a patch and then pushing out a broken implementation inside a patch which was only supposed to fix security and build issues. This is the kind of event which has caused many dists to cherry pickindividual changes rather than just following the official releases. 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 From noloader at gmail.com Mon Jul 13 00:36:59 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 12 Jul 2015 20:36:59 -0400 Subject: [openssl-users] [openssl-announce] OpenSSL Security Advisory In-Reply-To: <55A3060B.6060604@wisemo.com> References: <20150709131024.GA9863@openssl.org> <559EEBC5.7090407@wisemo.com> <55A3060B.6060604@wisemo.com> Message-ID: >>> In fact, I thought that was the reason we all >>> had to wait ages before this long standing shortcoming >>> was fixed. >> >> It almost sound like you are complaining you did not have to wait ages :) > > It's the inconsistency of first insisting this cannot go > into a patch and then pushing out a broken implementation > inside a patch which was only supposed to fix security > and build issues. OK.. so that's a legitimate gripe. OpenSSL has opportunities for improvements in their testing and release process. There is ***absolutely no reason**** a patch should not be tested before being released. Its been a chronic problem with the project. For what its worth, I've given up on the Testing Group (https://groups.google.com/forum/#!forum/openssl-testing). No meaningful change came from it. The devs are still undisciplined in this area, and they still do what they want. Jeff From jb-openssl at wisemo.com Mon Jul 13 00:58:10 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 13 Jul 2015 02:58:10 +0200 Subject: [openssl-users] Error condition at a customer site In-Reply-To: References: Message-ID: <55A30D22.7030100@wisemo.com> On 12/07/2015 22:01, Thomas Herchek wrote: > Hi, > > Sometimes, during the processing of an HTTP cert response from the > Symantec PKI Manager SCEP server, our application encounters an error > condition while validating the certs attributes. The error that we > see is "Transaction not permitted or supported". > > It appears that this error is detected either in the ASN1_TYPE_get() > function or the OBJ_nid2obj() function. > > Can you tell me, what conditions might cause this type of failure when > unwrapping and validating a cert response? > > Here is a snippet of our code that detects this condition: > > /* Get signed attributes */ > > attribs = PKCS7_get_signed_attributes(si); > > if (attribs == NULL) > > { > > ReportAPIError("[PKCS7_UnWrap] No attributes found in PKCS#7 data", > szErr); > > goto cleanup; > > } > > ... > > /* Get pkiStatus */ > > if ((i = get_signed_attribute(attribs, nid_pkiStatus, > V_ASN1_PRINTABLESTRING, &p)) == 1) > > { > > ReportAPIError("[PKCS7_UnWrap] Failed to get the signer pkiStatus > attributes", szErr); > > goto cleanup; > > } > > /* Get failInfo */ > > if (atoi(p)!= SCEP_PKISTATUS_SUCCESS) > > { > > if (atoi(p) == SCEP_PKISTATUS_FAILURE) > > { > > if ((i = > get_signed_attribute(attribs, nid_failInfo, V_ASN1_PRINTABLESTRING, > &p)) == 1) > > { > > ReportError("[PKCS7_UnWrap] Cannot find failInfo", szErr); > > goto cleanup; > > } > > switch (atoi(p)) > > { > > case SCEP_FAILINFO_BADALG: > > ReportError("[PKCS7_UnWrap] Unrecognized or unsupported algorithm > ident", szErr); > > break; > > case > SCEP_FAILINFO_BADMSGCHK: > > ReportError("[PKCS7_UnWrap] Integrity check failed", szErr); > > break; > > case SCEP_FAILINFO_BADREQ: > > ReportError("[PKCS7_UnWrap] Transaction not permitted or supported", > szErr); > > break; > > case > SCEP_FAILINFO_BADTIME: > > ReportError("[PKCS7_UnWrap] Message time field was not sufficiently > close to the system time", szErr); > > break; > > case > SCEP_FAILINFO_BADCERTID: > > ReportError("[PKCS7_UnWrap] No certificate could be identified > matching", szErr); > > break; > > default: > > ReportError("[PKCS7_UnWrap] Wrong failInfo in reply", szErr); > > } > > } > > else > > { > > ReportAPIError("[PKCS7_UnWrap] PKI Status: Not success", szErr); > > } > > goto cleanup; > As I read the code you quoted above, all values of pkiStatus come from whomever signed the PKCS#7 message (Symantec?). Specifically, the message contained inside it a digitally signed extension attribute of type "pkiStatus" with a value of SCEP_FAILINFO_BADREQ . If my interpretation is right, this means you need to look at why the SCEP server (or whatever else returns that PKCS#7 message) returned SCEP_FAILINFO_BADREQ. I don't know much about SCEP specifically, so I cannot dig deeper into this myself. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From naynjain at in.ibm.com Mon Jul 13 06:55:40 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Mon, 13 Jul 2015 12:25:40 +0530 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj Message-ID: Hi all, I am programmatically generating the self signed certificate and need to specify the "Not Before" and "Not After" date, Wanted to understand what all formats are acceptable by this API ? Also, similarly while using API , what exactly is the time format expected by X509_cmp_time(X509_get_notAfter(iv_pX509), .......); Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Mon Jul 13 10:22:13 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Mon, 13 Jul 2015 13:22:13 +0300 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: References: Message-ID: <20150713132213.05ffe5c3@arkturus.wagner.home> On Mon, 13 Jul 2015 12:25:40 +0530 Nayna Jain wrote: > > Hi all, > > I am programmatically generating the self signed certificate and need > to specify the "Not Before" and "Not After" date, > > Wanted to understand what all formats are acceptable by this API ? X509_set_notAfter and X509_set_notBefore API expect ASN1_TIME structure. You can use ASN1_TIME_set function to fill this structure. It expects integer time_t value. X509_cmp_time also expects integer time_t value. So integer number of seconds since the beginning of the epoch (1.1.1970 GMT) is everything you need. There is also ASN1_TINE_set_string function, which does deal with some datetime format, but I suggest never use it. Use C runtime library function strptime, which allows to specify format explicitely or mktime to prepare time_t value from the user input. And use OpenSSL ASN1_TIME_print function to convert ASN1_TIME to human-readble form. > > Also, similarly while using API , what exactly is the time format > expected by X509_cmp_time(X509_get_notAfter(iv_pX509), .......); > > Thanks & Regards, > Nayna Jain From gayathri.annur at gmail.com Mon Jul 13 12:03:23 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Mon, 13 Jul 2015 17:33:23 +0530 Subject: [openssl-users] openssl-.0.9.8zg issue while compiling with fips library Message-ID: Hi, I am getting the below error while compliling openssl-0.9.8zg with fips canister library. make[2]: Entering directory `open_source/openssl/0_9_8zg_new1/fips' ../libcrypto.a(err_def.o): In function `ERR_get_state': err_def.c:(.text+0x710): multiple definition of `ERR_get_state' ../libcrypto.a(err_def.o): In function `ERR_remove_state': err_def.c:(.text+0xa60): multiple definition of `ERR_remove_state' collect2: ld returned 1 exit status make[2]: *** [fips_premain_dso] Error 1 Using the same procedure, I am able to compile with 0.9.8zf. Please let me know how can i solve this issue. Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.p.edwards at gmail.com Mon Jul 13 17:03:09 2015 From: colin.p.edwards at gmail.com (Colin Edwards) Date: Mon, 13 Jul 2015 13:03:09 -0400 Subject: [openssl-users] CVE-2015-1793 only on cert-based client auth? Message-ID: I've been reading/hearing different opinions on the recent vulnerability for cert chain forging that was patched (CVE-2015-1793). Some people are saying the vulnerability only exists if a system is using certificate-based client authentication (mutual auth, where both server and client are authenticated). Basically, that the chain forging can only be done on the client side. Others are saying certs can be forged on the server, on implementations that use only server-side authentication, and if the client is using OpenSSL it will verify/accept the forged chain. The could effectively result in MitM against OpenSSL clients. Can anyone on this list clarify with details? Thanks, Colin sent from mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Tue Jul 14 07:41:45 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 14 Jul 2015 01:41:45 -0600 Subject: [openssl-users] Issue with openssl 1.0.2 20150713 SNAP Message-ID: <20150714073648.GA5624@doctor.nl2k.ab.ca> Script started on Mon Jul 13 09:31:31 2015 doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150713$ make test testing... (cd ..; make build_libcrypto) 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... ------snip ---- B->A s2 Alice's key = B068AC36CDC90250641AF4606E0048DF3A0561553C08B83C99C789BB39B939A684107038372C535A0705643C3F2851F566479DEF3C793D73051940EC874CD99524B381D048E165AD8F7BEF0A319C02C2CA573BB677CEC4ADAAAC20D3572953446879ACC3D7AFBCDA30CE5D763513C1341E4140D6F0943532C200D930EA11670 Bob's key = 9EA673E21E39CE73EBEA90F05BA0D27E98AEC0656F7965BC53288161B0650EC39DB113A9B9934C09F992F510B30213D78FA9CDC060EDAC89DEAFD0567A9DC96AF16DA36EED7E2C3260452EDBB9FFB865604468214A2585356AAAF8DA6DB692A5462EE70130B33815E99CB2EDE1869228D6B412A052B723105B0967BF7D3B1634 A->B s3a Bob fails to process Alice's step 3a 134523940:error:3106706A:lib(49):JPAKE_STEP3A_process:hash of hash of key mismatch:jpake.c:468: Test SRP ../util/shlib_wrap.sh ./srptest ls: error initializing month strings N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 g = 2 Salt = CA7A12BF214AD8B48AFFA57DCF53C7C0C61A54 Verifier = 7066AEA8AB18B0821E5D3CD00F7F98CB94C78DB253AA06575FBC03E7520F88A467E99EA465C3C8A097088EDE96B29C736352E99BCE732873AFFAB3598E7AE1D257B9AD904D962352CF6342FEB3327BC1E502AB3D74BF45DB2AA861881BFCDCC8F51C70B4630D540C13E87907C9E23444FFE343839A871B87407B47F9EEFF2403 b = 3F3EED693B0D07C9634D5F85D892973F35D06EF19FE3271AD01DC28955487B2F B = DF16088E6D7FC3EB530D871CC409C8540E574E67C37E2C14CDE8E9FB438F0B0CCAF4C828B20FA3120DD480E9055274293A222CCBEDDE81C4933644C26FB37CC40576A5D8FF79819692D387D5BA93C30EAE81DD17CDFC27EFB09B3EFA6756715553173CC10F95F87A4589A1B4EFD5352A11399F30D5CED778C21AE3D86BB98F14 a = 2A4108A36B01C8AC1AC717476D07F7252C6363CA496067FEA674EEA26C5BDA7C A = E7BB81797A777379FE47D5DFDBE4068F428D62C995A8B807C3169AEB50BE9C26D2CEA69B1629C7BBE8F32832D789E75FEEE4ED58168BF2705C81654D1CC49C2F7C89EA2C60485CA8423C1805C0C9777DE435A80C3EDD68BC88330AA56ACF31BE11197D49DFB535B0A8B49A8A00BBFF28B5E4CE1F1E415A1DBB4D31572F2207E2 Client's key = B78BA41033BAE5A590D21D8FBE32123D3A83E74B0133B93A197471A5F7326222114683CED5462D37C815B786929C477E4AF9B38B43B319E7010ACE79257CCC878391AF7FB3F31AB91135206C51DFAB660B15A9ADAFB4DE68C9B36A69B07088551F54110D7C850908778B8722CD1D2AB6EEA4D86EC964CB9417201F6363864CF0 Server's key = 18C1C2AB1FDC019A6A1232D757067112351DB1595E2CA72482A99B8C10EA7143CB5902C5EE54032FBBB74E24DF82D494D64D0A770EE5DFB1A7E5DCC254D95A3355627CC89EE5068BA27742BB7D7161F96F4168B7D11CF096FD58B98952BCB951A4370795BAA3DF0B50E42D3A6E5292ED6ABA90823D3E443E19ECFAC2A20BCE87 Keys mismatch N = EEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D674DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B46154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3 g = 2 Salt = 2A2BF6FB6389674026167D5FF7B927BBD064C7B9 Verifier = 180623D9BD188CC0F1894A3904E1104A40ED12C04971E9F490963FEDAD1AB2C7321BA3BE917647EB3F1C1DD37B31C8E042C87A107CA365548F74D8F7CED9B69EABDCF431EEC3A31683C707D3D03FC50AF7B8ADEABE8EBB79B5804C4AC5E4CE25D170412C7C4C5A5C647374DC87B8477144409192850785847CC33CFC6C6829BE b = 6EFC82296DC581D66CE1215E92880C1488CC8D3D119C2B6E9D75404B44FA4485 B = 1A522B755B2109D112BA6C021A909A981A9EC97A0D9D8CCDAAC56DCDD12D6279240DC49660347A4D5C32B04D186D27E8B7986DDF5228E2063D48CD82AC3A6E871EDFE6D7F1A630D8255A793A2603A7FF499A0A82E2D786CE7CC11800EE330EF545278C3A5990282590682D054DBADC56CD21432C661D1B2E67DFD1E631343E00 a = 1C38E9768B7C774C5FD19B7DF566D245741525FDEBA8D97C2C6B3FE08EC9391C A = DBE7BD72650C98D39F9F17842E7EA989D8F795B870E4F72D6A36A5A17C8E7A1DE5D1F372405EF46A51641F91B678E563D042B12E22D1BE65299B79EF725DCD7FF2AFD51D560D1A82190781D8AACC411A64C6DF2934BD88B81E567AFC801F6DDA3CEE7D37D170A6A7878EBBC2F71716612364CCD53BAFB98B6D6BDDB99D163B7A Client's key = B2B40F4E998845AC21E57FBD0446DF0E7B44CDAA903C8027E143C891482B93D7DB51C7AD52587679F2A72BCB2848DF1BE5327C4337332292EC436C335795813E21F607A803FCF31703B6C7BF3FBD58F3310055D8D8D9FDF39C574A30A283AD3BD713DE86DDE1BCF0A97A160FC9693AE9C9700332BBD3030D5F01BDF390A12F28 Server's key = B2B40F4E998845AC21E57FBD0446DF0E7B44CDAA903C8027E143C891482B93D7DB51C7AD52587679F2A72BCB2848DF1BE5327C4337332292EC436C335795813E21F607A803FCF31703B6C7BF3FBD58F3310055D8D8D9FDF39C574A30A283AD3BD713DE86DDE1BCF0A97A160FC9693AE9C9700332BBD3030D5F01BDF390A12F28 CMS consistency test /root/bin/perl5 cms-test.pl ls: error initializing month strings ls: error initializing month strings ls: error initializing month strings ls: error initializing month strings CMS => PKCS#7 compatibility tests signed content DER format, RSA key: OK signed detached content DER format, RSA key: OK signed content test streaming BER format, RSA: OK signed content DER format, DSA key: OK signed detached content DER format, DSA key: OK signed detached content DER format, add RSA signer: OK signed content test streaming BER format, DSA key: OK signed content test streaming BER format, 2 DSA and 2 RSA keys: OK signed content test streaming BER format, 2 DSA and 2 RSA keys, no attributes: OK signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error *** Error code 1 Stop. *** Error code 1 Stop. doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150713$ x sh: x: command not found doctor.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150713$ exit exit Script done on Mon Jul 13 09:52:44 2015 Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From gayathri.annur at gmail.com Tue Jul 14 10:35:14 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Tue, 14 Jul 2015 16:05:14 +0530 Subject: [openssl-users] openssl fips package for openssl-0.9.8zg Message-ID: Hi All, Please let me know what is the compatible openssl-fips package for the 0.9.8zg version. When i try with with openssl-1_2_4, I am getting the below error bash 3.2:90>gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DHMAC_EXT=\"${HMAC_EXT:-sha1}\" -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c ../libcrypto.a -ldl ../libcrypto.a(err_def.o): In function `ERR_get_state': err_def.c:(.text+0x710): multiple definition of `ERR_get_state' ../libcrypto.a(fipscanister.o):(.text+0x10c30): first defined here /auto/cmtools/i686-pc-linux-gnu/linuxtoolchain-r5/u3m/usr/bin/ld: Warning: size of symbol `ERR_get_state' changed from 28 in ../libcrypto.a(fipscanister.o) to 839 in ../libcrypto.a(err_def.o) ../libcrypto.a(err_def.o): In function `ERR_remove_state': err_def.c:(.text+0xa60): multiple definition of `ERR_remove_state' ../libcrypto.a(fipscanister.o):(.text+0x10cc0): first defined here /auto/cmtools/i686-pc-linux-gnu/linuxtoolchain-r5/u3m/usr/bin/ld: Warning: size of symbol `ERR_remove_state' changed from 41 in ../libcrypto.a(fipscanister.o) to 189 in ../libcrypto.a(err_def.o) collect2: ld returned 1 exit status bash 3.2:91> Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Jul 14 17:06:20 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 14 Jul 2015 19:06:20 +0200 Subject: [openssl-users] CVE-2015-1793 only on cert-based client auth? In-Reply-To: References: Message-ID: <20150714170619.GA29187@roeckx.be> On Mon, Jul 13, 2015 at 01:03:09PM -0400, Colin Edwards wrote: > I've been reading/hearing different opinions on the recent vulnerability > for cert chain forging that was patched (CVE-2015-1793). > > Some people are saying the vulnerability only exists if a system is using > certificate-based client authentication (mutual auth, where both server and > client are authenticated). `Basically, that the chain forging can only be > done on the client side. > > Others are saying certs can be forged on the server, on implementations > that use only server-side authentication, and if the client is using > OpenSSL it will verify/accept the forged chain. The could effectively > result in MitM against OpenSSL clients. It's whenever a certificate is received (and validated). This means either: - A client is authenticating a server (server authentication) - A server is authenticating a client (client authentication) Of course both could be happening for the same connection. It's much more common that the client authenticates the server. Certainly for https client authentication is uncommon. Also, for https the client ussually isn't OpenSSL based, except for android. Kurt From colin.p.edwards at gmail.com Tue Jul 14 17:23:52 2015 From: colin.p.edwards at gmail.com (Colin Edwards) Date: Tue, 14 Jul 2015 13:23:52 -0400 Subject: [openssl-users] CVE-2015-1793 only on cert-based client auth? In-Reply-To: <20150714170619.GA29187@roeckx.be> References: <20150714170619.GA29187@roeckx.be> Message-ID: <008701d0be59$db04b530$910e1f90$@gmail.com> Thank you, Kurt. The information I was getting (from some sources) was that the vulnerability was only present in configurations where the server was authenticating a client certificate. The fact is, the vulnerability applies to certificate validation regardless of if it's on the client or server side. I'm going to assume what those sources were probably augmenting their assessment with their own risk analysis and decided that the only place the risk exists (not vulnerability) is in clients presenting forged certificates in situations where client auth is implemented. That would make sense (like you said) if we're talking about https, because basically no browsers are implemented using OpenSSL, so presenting a forged server cert to a client is basically a scenario that will not happen. But it could happen for other apps that use OpenSSL in their comm stack, even if they are only using server authentication. Thanks again, Colin Edwards CISSP, GCIH, GCWN, GSEC, MCSE -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx Sent: Tuesday, July 14, 2015 1:06 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] CVE-2015-1793 only on cert-based client auth? On Mon, Jul 13, 2015 at 01:03:09PM -0400, Colin Edwards wrote: > I've been reading/hearing different opinions on the recent > vulnerability for cert chain forging that was patched (CVE-2015-1793). > > Some people are saying the vulnerability only exists if a system is > using certificate-based client authentication (mutual auth, where both > server and client are authenticated). `Basically, that the chain > forging can only be done on the client side. > > Others are saying certs can be forged on the server, on > implementations that use only server-side authentication, and if the > client is using OpenSSL it will verify/accept the forged chain. The > could effectively result in MitM against OpenSSL clients. It's whenever a certificate is received (and validated). This means either: - A client is authenticating a server (server authentication) - A server is authenticating a client (client authentication) Of course both could be happening for the same connection. It's much more common that the client authenticates the server. Certainly for https client authentication is uncommon. Also, for https the client ussually isn't OpenSSL based, except for android. Kurt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jb-openssl at wisemo.com Tue Jul 14 18:35:31 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 14 Jul 2015 20:35:31 +0200 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: <20150713132213.05ffe5c3@arkturus.wagner.home> References: <20150713132213.05ffe5c3@arkturus.wagner.home> Message-ID: <55A55673.6090003@wisemo.com> On 13/07/2015 12:22, Victor Wagner wrote: > On Mon, 13 Jul 2015 12:25:40 +0530 > Nayna Jain wrote: > >> Hi all, >> >> I am programmatically generating the self signed certificate and need >> to specify the "Not Before" and "Not After" date, >> >> Wanted to understand what all formats are acceptable by this API ? > X509_set_notAfter and X509_set_notBefore API expect ASN1_TIME structure. > You can use ASN1_TIME_set function to fill this structure. It expects > integer time_t value. > > X509_cmp_time also expects integer time_t value. > > So integer number of seconds since the beginning of the epoch (1.1.1970 > GMT) is everything you need. > > There is also ASN1_TINE_set_string function, which does deal with some > datetime format, but I suggest never use it. Use C runtime library > function strptime, which allows to specify format explicitely or mktime > to prepare time_t value from the user input. And use OpenSSL > ASN1_TIME_print function to convert ASN1_TIME to human-readble form. Does ASN1_TIME_set_string() support dates outside the time_t range of the local libc? This is important when creating root certs with expiry dates after 2038 (specifically, any time >= epoch+2**31). It is also important when creating self-signed Android apk signing certificates (which /must/ be valid for at least 30 years). 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 From jb-openssl at wisemo.com Tue Jul 14 19:06:41 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 14 Jul 2015 21:06:41 +0200 Subject: [openssl-users] openssl fips package for openssl-0.9.8zg In-Reply-To: References: Message-ID: <55A55DC1.1080501@wisemo.com> On 14/07/2015 12:35, Gayathri Manoj wrote: > Hi All, > > Please let me know what is the compatible openssl-fips package for the > 0.9.8zg version. > As far as I know you need to use the file http://www.openssl.org/source/openssl-fips-1.2.4.tar.gz with the specific HMAC checksum specified in the applicable FIPS security policy as securely downloaded from the US GovernmentCMVP web page under the applicable certification listing. Once you have obtained and checked that document and file, compile the downloaded file *exactly* as specified in the securely downloaded security policy. Only then can you start using the resulting fipscanister with openSSL 0.9.8zg source code to create a fips-capable OpenSSL library. 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 From jb-openssl at wisemo.com Tue Jul 14 19:19:29 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 14 Jul 2015 21:19:29 +0200 Subject: [openssl-users] beginner needs advice on data signature/verification In-Reply-To: References: <558528C7.90403@watz.at> <55899D76.2060706@watz.at> <558A45C1.6060406@wisemo.com> Message-ID: <55A560C1.2020209@wisemo.com> (continuing top posting to keep thread consistent) Note that the point of using an X.509 signature at file creation time and/or client approval time was to reuse the internal file structure that is already designed to hold that particular signature format (specifically, the internal file structure that would eventually hold the final signature, which was already specified to be in that format). Thus the idea was to simplify and reuse code, given the existence of code, tools and data formats to sign those particular files with X.509 signatures. This was also (presumably) the reason Microsoft did it this way. But yes, of cause if the file generation is already secure, then the secure file generation machine should apply an initial signature and the client just add some kind of counter-signature authorizing this particular one of the securely generated files. On 24/06/2015 15:24, Michael Wojcik wrote: > > In Marco's original description, the file is created by a trusted > system and then transmitted to the client. Then, later, the client > transmits it to the server, which verifies the contents. If the file > is signed by the creating system, it doesn't matter if the client is > compromised. A compromised client can refuse to send the file, or it > can send a forged or corrupted file, but the server can dectect all of > those cases. > > It's not clear from Marco's description whether the system that > creates the file can perform the signing process, but I don't see any > reason (in the description) why not. It would help if this point were > clarified. > > The Windows driver-signing process and similar look wildly > overengineered for Marco's purposes, if my understanding of his > requirements is correct. They have a very different threat model - and > that's why this isn't "a common requirement". Windows drivers are > created by thousands of organizations and consumed by thousands of end > users. Marco has files created on a trusted system (or handful of > trusted systems) he controls, and verified by trusted systems he controls. > > His followup message below says "data has to be signed with an X.509 > certificates public key that already exists". I'm guessing this > actually means "data has to be signed with the private key > corresponding to a public key that happens to be in an X.509 > certificate that already exists". That doesn't mean X.509 PKI must be > used; X.509 isn't some sort of virus that infects everything it > touches (appearances to the contrary). There's an asymmetric key pair > of some sort - RSA probably - and we need to use it for signing. Fine. > > Here's what I'd do: the originating trusted system creates the data > and runs "openssl rsautl -sign" with appropriate parameters to create > a signature. (Just script the openssl command-line utility; this is a > trusted system, so why reimplement the code?) Add the signature to the > proprietary file format. Send the whole thing to the client. > > Client subsequently sends the signed data and signature to the server, > as part of a file in the proprietary format, along with whatever > unsigned data is included. > > Server extracts the signed data and signature, and uses "openssl > rsautl -verify" to verify it. > > Michael Wojcik > Technology Specialist, Micro Focus > > (original text snipped) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jul 14 19:50:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Jul 2015 19:50:50 +0000 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: <55A55673.6090003@wisemo.com> References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> Message-ID: > This is important when creating root certs with expiry dates after 2038 Not an issue for openssl. As long as you use ASN1_TIME values, it's okay. Might be an issue if converting to time_t on 32-bit platforms. From kurt at roeckx.be Tue Jul 14 21:45:14 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 14 Jul 2015 23:45:14 +0200 Subject: [openssl-users] CVE-2015-1793 only on cert-based client auth? In-Reply-To: <008701d0be59$db04b530$910e1f90$@gmail.com> References: <20150714170619.GA29187@roeckx.be> <008701d0be59$db04b530$910e1f90$@gmail.com> Message-ID: <20150714214514.GA2250@roeckx.be> On Tue, Jul 14, 2015 at 01:23:52PM -0400, Colin Edwards wrote: > Thank you, Kurt. The information I was getting (from some sources) was that > the vulnerability was only present in configurations where the server was > authenticating a client certificate. The fact is, the vulnerability applies > to certificate validation regardless of if it's on the client or server > side. Right, and validation doesn't even have to be about TLS either. It's about any check of a certificate chain. Kurt From jb-openssl at wisemo.com Wed Jul 15 01:05:00 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 15 Jul 2015 03:05:00 +0200 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> Message-ID: <55A5B1BC.6040105@wisemo.com> On 14/07/2015 21:50, Salz, Rich wrote: >> This is important when creating root certs with expiry dates after 2038 > Not an issue for openssl. As long as you use ASN1_TIME values, it's okay. Might be an issue if converting to time_t on 32-bit platforms. Victor suggested to use only ASN1_TIME_set() together with libc parsing functions. That would obviously not work outside the libc time_t range, hence my question if ASN1_TINE_set_string() avoids that limitation, despite Victor's suggestion to never use it. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at jaytrombley.net Wed Jul 15 01:14:02 2015 From: jay at jaytrombley.net (Jay Trombley) Date: Tue, 14 Jul 2015 21:14:02 -0400 Subject: [openssl-users] Disable SSL3 for Windows 32 Distros? Message-ID: Hello, I?ve made several attempts to compile various versions of OpenSSL, the latest being 1.0.2d for Win32. Although many attempts to compile have been successful and the dlls (and .exe) usable, I have not been able to successfully disable SSLv3. I attempted on a Windows 7 box using VC 2010, I can compile without no-ssl2 no-ssl3, however, when I try to use no-ssl3, I end up getting linker errors. I notice that the ssleay32.def still has references to SSLv3 and SSLv23. When I attempt to remove these and try to compile again, it continues to fail. When I could not make this work, I switched to ubuntu and did a cross compile using mingw. In this case I can pass no-ssl2 and no-ssl3 (I even tried disable-ssl2 disable-ssl3 disable-ssl3-method) and it all compiles fine. However, when I scan the application that is using the port, I can still see SSLv3 is used (accepted for a few ciphers): Rejected SSLv3 256 bits ADH-AES256-SHA Rejected SSLv3 256 bits DHE-RSA-AES256-SHA Rejected SSLv3 256 bits DHE-DSS-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Rejected SSLv3 128 bits ADH-AES128-SHA Rejected SSLv3 128 bits DHE-RSA-AES128-SHA Rejected SSLv3 128 bits DHE-DSS-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Rejected SSLv3 168 bits ADH-DES-CBC3-SHA Rejected SSLv3 56 bits ADH-DES-CBC-SHA Rejected SSLv3 40 bits EXP-ADH-DES-CBC-SHA Rejected SSLv3 128 bits ADH-RC4-MD5 Rejected SSLv3 40 bits EXP-ADH-RC4-MD5 Rejected SSLv3 168 bits EDH-RSA-DES-CBC3-SHA Rejected SSLv3 56 bits EDH-RSA-DES-CBC-SHA Rejected SSLv3 40 bits EXP-EDH-RSA-DES-CBC-SHA Rejected SSLv3 168 bits EDH-DSS-DES-CBC3-SHA Rejected SSLv3 56 bits EDH-DSS-DES-CBC-SHA Rejected SSLv3 40 bits EXP-EDH-DSS-DES-CBC-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Rejected SSLv3 56 bits DES-CBC-SHA Rejected SSLv3 40 bits EXP-DES-CBC-SHA Rejected SSLv3 128 bits IDEA-CBC-SHA Rejected SSLv3 40 bits EXP-RC2-CBC-MD5 Rejected SSLv3 128 bits RC4-SHA Rejected SSLv3 128 bits RC4-MD5 Rejected SSLv3 40 bits EXP-RC4-MD5 Rejected SSLv3 0 bits NULL-SHA Rejected SSLv3 0 bits NULL-MD5 Is there a bug for windows that prevents generating dlls that do not support sslv3? If anyone has been able to compile it and confirmed no ssl3, I would really appreciate any guidance (and a copy of your ssleay32,dll, libeay32.dll, and openssl.exe). Thanks in advance. Jay ---- Jay A Trombley, PMP Office : +1 (802) 458-0814 Mobile : +1 (415) 238.4780 Fax : +1 (802) 329.2064 Skype : jay.trombley Web : http://www.linkedin.com/in/jaytrombley -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 15 01:33:08 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 15 Jul 2015 01:33:08 +0000 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: <55A5B1BC.6040105@wisemo.com> References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> <55A5B1BC.6040105@wisemo.com> Message-ID: >if ASN1_TINE_set_string() avoids that limitation, despite Victor's suggestion to never use it. It does avoid the limitation, using only |struct tm| to hold parsed fields, and not building a |time_t| from it. Not sure why Viktor doesn't like it. It seems to me it's the only portable thing to ues. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From wangqun at alumni.nus.edu.sg Wed Jul 15 01:08:47 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Tue, 14 Jul 2015 18:08:47 -0700 (MST) Subject: [openssl-users] Has the support for SPARC architecture crypto extensions been Implemented? In-Reply-To: <1435035217195-58867.post@n7.nabble.com> References: <1435024098896-58866.post@n7.nabble.com> <1435035217195-58867.post@n7.nabble.com> Message-ID: <1436922527180-59161.post@n7.nabble.com> I am doing some tests using OpenSSL command line utility 'openssl'. My tests show regarding to the performance of executable ?openssl? there is no difference between 1.0.1p and 1.0.2d. Here is the test results. ksol1% ./1.0.1p/shared64bit/openssl/bin/openssl speed -evp aes-128-cbc WARNING: can't open config file: /usr/local/ssl/openssl.cnf Doing aes-128-cbc for 3s on 16 size blocks: 19705194 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 5257594 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 1361128 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 343333 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 43029 aes-128-cbc's in 3.00s OpenSSL 1.0.1p-fips 9 Jul 2015 built on: Thu Jul 9 23:22:11 2015 options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN - DHAVE_DLFCN_H -DOPENSSL_BUILD -KPIC -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xd epend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -I/leo_ocsdev/qun/csi/allbuilt/main10 /built/ant-generated/fips-sun_svr4/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 105094.37k 112162.01k 116149.59k 117191.00k 117497.86k ksol1% ksol1% ./1.0.2d/shared64bit/openssl/bin/openssl speed -evp aes-128-cbc WARNING: can't open config file: /usr/local/ssl/openssl.cnf Doing aes-128-cbc for 3s on 16 size blocks: 18777502 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 5066291 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 1317102 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 331672 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 40739 aes-128-cbc's in 3.00s OpenSSL 1.0.2d-fips 9 Jul 2015 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN - DHAVE_DLFCN_H -DOPENSSL_BUILD -KPIC -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xd epend -Xa -DB_ENDIAN -I/leo_ocsdev/qun/csi/allbuilt/main12/built/ant-generated/f ips-sun_svr4/include The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 100146.68k 108080.87k 112392.70k 113210.71k 111244.63k ksol1% I built 'openssl' on Solaris 11.1 using the following commands. Configure no-idea no-mdc2 no-rc5 no-asm solaris64-sparcv9-cc -KPIC make clean make make test make install Anyone knows how to let OpenSSL applications or utilities use SPARC crypto accelerator? Thanks in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Has-the-support-for-SPARC-architecture-crypto-extensions-been-Implemented-tp58866p59161.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From wangqun at alumni.nus.edu.sg Wed Jul 15 01:26:52 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Tue, 14 Jul 2015 18:26:52 -0700 (MST) Subject: [openssl-users] Has the support for SPARC architecture crypto extensions been Implemented? In-Reply-To: <1436922527180-59161.post@n7.nabble.com> References: <1435024098896-58866.post@n7.nabble.com> <1435035217195-58867.post@n7.nabble.com> <1436922527180-59161.post@n7.nabble.com> Message-ID: <1436923612376-59162.post@n7.nabble.com> Some additional information here. When testing the default openssl installed in /usr/bin/ on Solaris 11, I saw a much better result below. Hence I believe OpenSSL utility 'openssl' built by me does not use the hardware crypto accelerators at all. Anyone knows the reason? Thanks, Aaron ksol1% /usr/bin/openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 113798920 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 48425338 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 14613535 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 3768123 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 488001 aes-128-cbc's in 3.00s OpenSSL 1.0.0k 5 Feb 2013 built on: date not available options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int) aes(partial) blowf ish(ptr) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 608957.43k 1033073.88k 1247021.65k 1286185.98k 1332568.06k -- View this message in context: http://openssl.6102.n7.nabble.com/Has-the-support-for-SPARC-architecture-crypto-extensions-been-Implemented-tp58866p59162.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From wangqun at alumni.nus.edu.sg Wed Jul 15 03:13:52 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Tue, 14 Jul 2015 20:13:52 -0700 (MST) Subject: [openssl-users] How to let OpenSSL applications/utilities use SunSPARC crypto accelerators? Message-ID: <1436930032695-59163.post@n7.nabble.com> Hello OpenSSL folks, I noticed that the OpenSSL command line utility 'openssl' built in Solaris 11.1 does not use SunSPARC crypto accelerators. >From the change log of OpenSSL 1.0.2, I saw the following description. Changes between 1.0.1l and 1.0.2 [22 Jan 2015] ... *) Support for SPARC Architecture 2011 crypto extensions, first implemented in SPARC T4. This covers AES, DES, Camellia, SHA1, SHA256/512, MD5, GHASH and modular exponentiation. [Andy Polyakov, David Miller] ... My understanding is that starting from OpenSSL 1.0.2, OpenSSL applications/utilities would use SunSPARC crypto accelerator in Solaris 11.1 which has the accelerator. However my tests show there is no difference between the performance of 'openssl' 1.0.1p and that of its 1.0.2d counterpart. ksol1% ./1.0.1p/shared64bit/openssl/bin/openssl speed -evp aes-128-cbc WARNING: can't open config file: /usr/local/ssl/openssl.cnf Doing aes-128-cbc for 3s on 16 size blocks: 19705194 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 5257594 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 1361128 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 343333 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 43029 aes-128-cbc's in 3.00s OpenSSL 1.0.1p-fips 9 Jul 2015 built on: Thu Jul 9 23:22:11 2015 options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN - DHAVE_DLFCN_H -DOPENSSL_BUILD -KPIC -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xd epend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -I/leo_ocsdev/qun/csi/allbuilt/main10 /built/ant-generated/fips-sun_svr4/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 105094.37k 112162.01k 116149.59k 117191.00k 117497.86k ksol1% ./1.0.2d/shared64bit/openssl/bin/openssl speed -evp aes-128-cbc WARNING: can't open config file: /usr/local/ssl/openssl.cnf Doing aes-128-cbc for 3s on 16 size blocks: 18777502 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 5066291 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 1317102 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 331672 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 40739 aes-128-cbc's in 3.00s OpenSSL 1.0.2d-fips 9 Jul 2015 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN - DHAVE_DLFCN_H -DOPENSSL_BUILD -KPIC -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xd epend -Xa -DB_ENDIAN -I/leo_ocsdev/qun/csi/allbuilt/main12/built/ant-generated/f ips-sun_svr4/include The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 100146.68k 108080.87k 112392.70k 113210.71k 111244.63k I built 'openssl' on Solaris 11.1 using the following commands. Configure no-idea no-mdc2 no-rc5 no-asm solaris64-sparcv9-cc -KPIC make clean make make test make install When testing the default openssl installed in /usr/bin/ on Solaris 11.1, I saw a much better result below. ksol1% /usr/bin/openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 113798920 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 48425338 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 14613535 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 3768123 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 488001 aes-128-cbc's in 3.00s OpenSSL 1.0.0k 5 Feb 2013 built on: date not available options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int) aes(partial) blowf ish(ptr) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 608957.43k 1033073.88k 1247021.65k 1286185.98k 1332568.06k Hence I believe OpenSSL utility 'openssl' built by me does not use the hardware crypto accelerators at all. I wonder if anyone knows the reason. Thanks in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-let-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From gayathri.annur at gmail.com Wed Jul 15 04:59:47 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Wed, 15 Jul 2015 10:29:47 +0530 Subject: [openssl-users] openssl fips package for openssl-0.9.8zg In-Reply-To: <55A55DC1.1080501@wisemo.com> References: <55A55DC1.1080501@wisemo.com> Message-ID: Hi Jacob, I have used openssl-fips-1_2_4 with openssl 0.9.8zf and not found any issue. For my environment, just I upgraded my openssl version from 0.9.8zf to zg. Thanks, Gayathri On Wed, Jul 15, 2015 at 12:36 AM, Jakob Bohm wrote: > On 14/07/2015 12:35, Gayathri Manoj wrote: > >> Hi All, >> >> Please let me know what is the compatible openssl-fips package for the >> 0.9.8zg version. >> >> As far as I know you need to use the file > > http://www.openssl.org/source/openssl-fips-1.2.4.tar.gz > > with the specific HMAC checksum specified in the applicable > FIPS security policy as securely downloaded from the US > GovernmentCMVP web page under the applicable certification > listing. > > Once you have obtained and checked that document and file, > compile the downloaded file *exactly* as specified in the > securely downloaded security policy. > > Only then can you start using the resulting fipscanister with > openSSL 0.9.8zg source code to create a fips-capable OpenSSL > library. > > 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-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Wed Jul 15 09:13:26 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Wed, 15 Jul 2015 12:13:26 +0300 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: <55A55673.6090003@wisemo.com> References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> Message-ID: <20150715121326.7e258abe@arkturus.wagner.home> On Tue, 14 Jul 2015 20:35:31 +0200 Jakob Bohm wrote: > > Does ASN1_TIME_set_string() support dates outside the > time_t range of the local libc? Why do yo need time dates outside of 64-bit integer range? Sun would explode into red giant sooner than that amount of time passes. > This is important when creating root certs with expiry > dates after 2038 (specifically, any time >= epoch+2**31). I don't think that it is a good idea to issue certificates with expire dates after 2038 now. Notice - several years ago MD5 collision was discovered, and certificates signed with md5WithRsaEncryption was phased out. Now browser manufacturers planning to phase out sha1 certificates, even though there is no published collision generation for sha1, people are thinking it is possible enough to avoid using this hashing algorithms. There are interesting mathematic results concerning big number factorization, and experiments with quantum computing, so it seems that soon we'll have to abandon RSA at all and use only EC algorithms. So I don't think that one should issue certificates valid for more than 10 years, if he hopes to have even marginal security. > It is also important when creating self-signed Android > apk signing certificates (which /must/ be valid for at > least 30 years). Does android really have 32-bit time_t? And is it really signed? I've thought that all modern systems have already switched to 64-bit time_t or at least iterpret time_t as unsigned, which give time up to 2106. From jb-openssl at wisemo.com Wed Jul 15 11:02:42 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 15 Jul 2015 13:02:42 +0200 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: <20150715121326.7e258abe@arkturus.wagner.home> References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> <20150715121326.7e258abe@arkturus.wagner.home> Message-ID: <55A63DD2.9020905@wisemo.com> On 15/07/2015 11:13, Victor Wagner wrote: > On Tue, 14 Jul 2015 20:35:31 +0200 > Jakob Bohm wrote: > >> Does ASN1_TIME_set_string() support dates outside the >> time_t range of the local libc? > Why do yo need time dates outside of 64-bit integer range? > Sun would explode into red giant sooner than that amount of time passes. It's all about 32 bit ints, not 64 bit ints. > >> This is important when creating root certs with expiry >> dates after 2038 (specifically, any time >= epoch+2**31). > I don't think that it is a good idea to issue certificates with > expire dates after 2038 now. > > Notice - several years ago MD5 collision was discovered, and > certificates signed with md5WithRsaEncryption was phased out. > > Now browser manufacturers planning to phase out sha1 certificates, even > though there is no published collision generation for sha1, people > are thinking it is possible enough to avoid using this hashing > algorithms. On the other hand, many of the new SHA-2 root certificates also exist as cross certificates issued by (otherwise disabled) old SHA-1 and MD5 root CAs that were deployed into browsers and mobile devices before SHA-2 support was added to most browsers and operating systems. This only works because those old SHA-1/MD5 CAs were issued with long lifetimes that outlast their actual active use. At least one major CA made the mistake of originally issuing their old root cert with a lifetime that expired a few years ago, while the difficult to update mobile devices that trust that cert remains functional (hardware hasn't died). Thus an update signed by a competing CA is needed to provision those devices with the new extended lifetime of that root cert, so those devices can then trust new certificates issued with longer keys (close to the limit of the crypto libraries embedded in ROM images). A more widespread problem of this kind is that Windows 8 and Windows 8.1 do not include most of the Microsoft accepted SHA-2 roots out of the box, but will instead download those one by by one from Microsoft if and only if the system has been configured to implicitly trust any and all future changes to Microsoft's list of trusted CAs. > There are interesting mathematic results concerning big number > factorization, and experiments with quantum computing, so it seems that > soon we'll have to abandon RSA at all and use only EC algorithms. I have yet to see any convincing arguments why QC doesn't break EC too. So far the only argument I have seen is that one published QC algorithm is most easily applied to DL and RSA keys, which says very little about the applicabilityof QC speedups to other NP problems. > So I don't think that one should issue certificates valid for more than > 10 years, if he hopes to have even marginal security. > >> It is also important when creating self-signed Android >> apk signing certificates (which /must/ be valid for at >> least 30 years). > > Does android really have 32-bit time_t? And is it really signed? > I've thought that all modern systems have already switched to 64-bit > time_t or at least iterpret time_t as unsigned, which give time up to > 2106. I haven't checked the local code on Android for this, except that it does work very well with post-2038 expiry dates when validating certs. Note that most Android devices use 32-bit CPUs with 32-bit int. However the Linux/OSX/Windows workstations that are used to generate the self-signed end certificates that identify Android software packages will often be 32 bit systems with 32 bit signed time_t. And the Android Market (Google Play) upload requirements insist that the expiry is after 2038, in order to recognize future App updates as being the same app with access to previous version data. If and when the QC disaster happens, Android will presumable start requiring double signatures (the file format supports this) with both the original App cert and a new stronger cert. The specific way such a requirement will be formulated (e.g. should the new cert be issued by the old cert or not, in which relative order should it be placed in the signature collection etc.) has not yet been defined. 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 From henrie.cuijpers at gmail.com Wed Jul 15 17:34:55 2015 From: henrie.cuijpers at gmail.com (Henrie Cuijpers) Date: Wed, 15 Jul 2015 19:34:55 +0200 Subject: [openssl-users] imap.gmail.com Message-ID: <55A699BF.7090201@gmail.com> Hi all, i try to connect to the gmail imap service, but after the connection has been set up the server responds to nothing. Is there a way to investigate this further? I use this command line: openssl s_client -connect imap.gmail.com:993 After connection you should be able to type a command and the server should response with an error or an OK message. On every valid command the server stays sitting there doing nothing but keeping the line up. You only receive a reply when you type a wrong command to start with. After that there is nothing but silence..... Example: after connecting type: A1 LOGIN johndoe at gmail.com JohnsPassword This will result in silence.... Disconnect with Ctrl-C en reconnect with the same line. Then type NOTACOMMAND and you will receive: * BAD invalid tag SomeRandomNumber after this you can enter what you want the answer will be: silence... Please give me a hint how to investigate this further.... Kind regards Henrie From pbellino at mrv.com Wed Jul 15 17:34:13 2015 From: pbellino at mrv.com (Philip Bellino) Date: Wed, 15 Jul 2015 17:34:13 +0000 Subject: [openssl-users] FIPS test parse error? Message-ID: Hello, We are testing our FIPS implementation which is based on openssl-1.0.2a and openssl-fips-2.0.9. We are executing tests on the target machine (which doesn't support running perl scripts so we cannot run fipsalgtest.pl) that are included in the openssl-fips-2.0.9/fips directory, using request files provided by a test/validation company. All tests seem to run fine (no errors output to screen) except for an RSA2 KeyGen test, during which the following error text appears: ./fips_rsagtest AlgCore/KeyGen_186-3.req /tmp/KeyGen_186-3.rsp FATAL parse error processing line 16 FATAL RSAGTEST file processing error Any help would be most appreciated. Thank you, Phil [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dnsands at sandia.gov Wed Jul 15 17:49:40 2015 From: dnsands at sandia.gov (Sands, Daniel) Date: Wed, 15 Jul 2015 17:49:40 +0000 Subject: [openssl-users] [EXTERNAL] imap.gmail.com In-Reply-To: <55A699BF.7090201@gmail.com> References: <55A699BF.7090201@gmail.com> Message-ID: <1436982580.8472.1.camel@sandia.gov> IMAP is probably based on the Telnet protocol, so the server is expecting CRLF instead of just CR. Try running s_client with the -crlf option. On Wed, 2015-07-15 at 19:34 +0200, Henrie Cuijpers wrote: > Hi all, > > i try to connect to the gmail imap service, but after the connection has > been set up the server responds to nothing. Is there a way to > investigate this further? > > I use this command line: > > openssl s_client -connect imap.gmail.com:993 > > After connection you should be able to type a command and the server > should response with an error or an OK message. On every valid command > the server stays sitting there doing nothing but keeping the line up. > You only receive a reply when you type a wrong command to start with. > After that there is nothing but silence..... > > > Example: after connecting type: > > A1 LOGIN johndoe at gmail.com JohnsPassword > > This will result in silence.... > > Disconnect with Ctrl-C en reconnect with the same line. Then type > > NOTACOMMAND > > and you will receive: > > * BAD invalid tag SomeRandomNumber > > after this you can enter what you want the answer will be: silence... > > Please give me a hint how to investigate this further.... > > Kind regards > Henrie > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From henrie.cuijpers at gmail.com Wed Jul 15 18:02:44 2015 From: henrie.cuijpers at gmail.com (Henrie Cuijpers) Date: Wed, 15 Jul 2015 20:02:44 +0200 Subject: [openssl-users] [EXTERNAL] imap.gmail.com In-Reply-To: <1436982580.8472.1.camel@sandia.gov> References: <55A699BF.7090201@gmail.com> <1436982580.8472.1.camel@sandia.gov> Message-ID: <55A6A044.20707@gmail.com> Hi Daniel, You are totally right. Google must have changed this, because i'm pretty sure it worked before! Thanks anyway. Henrie Sands, Daniel schreef op 15-07-15 om 19:49: > IMAP is probably based on the Telnet protocol, so the server is > expecting CRLF instead of just CR. Try running s_client with the -crlf > option. > > On Wed, 2015-07-15 at 19:34 +0200, Henrie Cuijpers wrote: >> Hi all, >> >> i try to connect to the gmail imap service, but after the connection has >> been set up the server responds to nothing. Is there a way to >> investigate this further? >> >> I use this command line: >> >> openssl s_client -connect imap.gmail.com:993 >> >> After connection you should be able to type a command and the server >> should response with an error or an OK message. On every valid command >> the server stays sitting there doing nothing but keeping the line up. >> You only receive a reply when you type a wrong command to start with. >> After that there is nothing but silence..... >> >> >> Example: after connecting type: >> >> A1 LOGIN johndoe at gmail.com JohnsPassword >> >> This will result in silence.... >> >> Disconnect with Ctrl-C en reconnect with the same line. Then type >> >> NOTACOMMAND >> >> and you will receive: >> >> * BAD invalid tag SomeRandomNumber >> >> after this you can enter what you want the answer will be: silence... >> >> Please give me a hint how to investigate this further.... >> >> Kind regards >> Henrie >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From pbellino at mrv.com Wed Jul 15 18:10:51 2015 From: pbellino at mrv.com (Philip Bellino) Date: Wed, 15 Jul 2015 18:10:51 +0000 Subject: [openssl-users] FIPS test parse error? Message-ID: One more item of note: The code appears to be erroring out on the keyword SEED. Looking at the source code there appears to be no provision to accept that word, hence the parse error. Hello, We are testing our FIPS implementation which is based on openssl-1.0.2a and openssl-fips-2.0.9. We are executing tests on the target machine (which doesn't support running perl scripts so we cannot run fipsalgtest.pl) that are included in the openssl-fips-2.0.9/fips directory, using request files provided by a test/validation company. All tests seem to run fine (no errors output to screen) except for an RSA2 KeyGen test, during which the following error text appears: ./fips_rsagtest AlgCore/KeyGen_186-3.req /tmp/KeyGen_186-3.rsp FATAL parse error processing line 16 FATAL RSAGTEST file processing error Any help would be most appreciated. Thank you, Phil [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jul 15 18:34:52 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 15 Jul 2015 14:34:52 -0400 Subject: [openssl-users] FIPS test parse error? In-Reply-To: References: Message-ID: <55A6A7CC.4040204@openssl.com> On 07/15/2015 01:34 PM, Philip Bellino wrote: > Hello, > > We are testing our FIPS implementation which is based on openssl-1.0.2a > and openssl-fips-2.0.9. > > We are executing tests on the target machine (which doesn't support > running perl scripts so we cannot run fipsalgtest.pl) > > that are included in the openssl-fips-2.0.9/fips directory, using > request files > > provided by a test/validation company. > > > > All tests seem to run fine (no errors output to screen) except for an > RSA2 KeyGen test, during which the following error text appears: > > > > ./fips_rsagtest AlgCore/KeyGen_186-3.req /tmp/KeyGen_186-3.rsp > > FATAL parse error processing line 16 > > FATAL RSAGTEST file processing error > > > > Any help would be most appreciated. The most likely cause is defective test vectors; that's quite common and understandable given the labor intensive nature of the CAVS tool. You could test your setup by processing one of the test vector sets used for recent #1747 platform testing, for instance: http://openssl.com/testing/validation-2.0/testvectors/OSF_2859_OE36.results.tar.gz ...which is the most recent officially confirmed one, from last week. Note the the format of the test vectors changes over time, so older test vectors are of limited value. The name your test lab gave that request file could be a clue too; compare your request file against the known good one above. Also note that if you're trying for a new validation (which is the only reason I can think of for attempting to do algorithm tests) you're in for a painful surprise; some non-trivial code hacking will be necessary to meet new requirements imposed since the #1747 validation was obtained. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From steve at openssl.org Wed Jul 15 20:13:44 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 15 Jul 2015 20:13:44 +0000 Subject: [openssl-users] FIPS test parse error? In-Reply-To: References: Message-ID: <20150715201344.GA7316@openssl.org> On Wed, Jul 15, 2015, Philip Bellino wrote: > > One more item of note: > > > The code appears to be erroring out on the keyword SEED. > > Looking at the source code there appears to be no provision to accept that word, hence the parse error. > The seed line appears on provable prime generation algorithms which OpenSSL FIPS module doesn't support. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From wangqun at alumni.nus.edu.sg Thu Jul 16 01:43:26 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Wed, 15 Jul 2015 18:43:26 -0700 (MST) Subject: [openssl-users] Can OpenSSL applications/utilities use SunSPARC crypto accelerators? In-Reply-To: <1436930032695-59163.post@n7.nabble.com> References: <1436930032695-59163.post@n7.nabble.com> Message-ID: <1437011006381-59179.post@n7.nabble.com> I checked utility 'openssl' built by my in solaris 11.1 and the default 'openssl' installed in Solaris 11.1. I noticed that my 'openssl' does NOT have SPARC T4 engine support. This may be the reason why my 'openssl' is much slower. Now the question is how to build 'openssl' to let it to have SPARC T4 engine support. I checked the OpenSSL documents, but seems there are no descriptions regarding to this topic. 1) This is the 'openssl' built by me on Solaris 11.1 ksol1% ./1.0.2d/normal/openssl/bin/openssl engine (dynamic) Dynamic engine loading support (4758cca) IBM 4758 CCA hardware engine support (aep) Aep hardware engine support (atalla) Atalla hardware engine support (cswift) CryptoSwift hardware engine support (chil) CHIL hardware engine support (nuron) Nuron hardware engine support (sureware) SureWare hardware engine support (ubsec) UBSEC hardware engine support (gost) Reference implementation of GOST engine 2) This is the default 'openssl' installed in Solaris 11.1 ksol1% /usr/bin/openssl engine (t4) SPARC T4 engine support (dynamic) Dynamic engine loading support (pkcs11) PKCS #11 engine support Anybody knows the answer please? Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Can-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163p59179.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From openssl-users at dukhovni.org Thu Jul 16 05:06:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Jul 2015 05:06:52 +0000 Subject: [openssl-users] Not Before and Not After Date format for openssl API X509_gmtime_adj In-Reply-To: References: <20150713132213.05ffe5c3@arkturus.wagner.home> <55A55673.6090003@wisemo.com> <55A5B1BC.6040105@wisemo.com> Message-ID: <20150716050652.GA28047@mournblade.imrryr.org> On Wed, Jul 15, 2015 at 01:33:08AM +0000, Salz, Rich wrote: > >if ASN1_TINE_set_string() avoids that limitation, despite Victor's suggestion to never use it. > > It does avoid the limitation, using only |struct tm| to hold parsed fields, and not building a |time_t| from it. Not sure why Viktor doesn't like it. It seems to me it's the only portable thing to ues. Let's not confuse "Victor Wagner" and "Viktor Dukhovni". :-) In Victor Wagner's defense, time_t with only 32 bits should be getting increasingly rare. -- Viktor. From anirudhraghunath at rocketmail.com Thu Jul 16 12:55:49 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Thu, 16 Jul 2015 12:55:49 +0000 (UTC) Subject: [openssl-users] Loading pkcs11 engine opensc without using command line Message-ID: <1457549232.2110650.1437051349639.JavaMail.yahoo@mail.yahoo.com> Hello, I want to write a program in which I can load a certificate from a smartcard instead of having it in a file on the client machine. In order to do so I will be using the opensc's engine_pkcs11 module. The module works fine using the shell but I want to implement it as an independent program. For example if I use the rsautl module then I can provide the inkey option and keyform option to use the private key from the smartcard. Look at the snippet below: openssl rsautl -sign -in file -keyform engine -engine pkcs11 -inkey slot_1-id_54a4c9bdaf3ff82b3367b586a6658c23 -out sig In order to do so I have to load the engine first. I do that as follows: ??? openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so which yields the result: ??? (dynamic) Dynamic engine loading support ??? [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so ??? [Success]: ID:pkcs11 ??? [Success]: LIST_ADD:1 ??? [Success]: LOAD ??? [Success]: MODULE_PATH:opensc-pkcs11.so ??? Loaded: (pkcs11) pkcs11 engine I want to do the same using C code in an independent program so that I can use the: ??? static X509 *pkcs11_load_cert(ENGINE * e, const char *s_slot_cert_id) function to get the certificate from the smart card. So I tried to debug engine.c using ddd debugger to understand exactly which part of the code was required to just load the engine. In the same program I want to use the opensc function to load certificate directly from the smartcard and then use it in further server client communication. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From misaki.miyashita at oracle.com Thu Jul 16 14:37:28 2015 From: misaki.miyashita at oracle.com (Misaki Miyashita) Date: Thu, 16 Jul 2015 09:37:28 -0500 Subject: [openssl-users] Can OpenSSL applications/utilities use SunSPARC crypto accelerators? In-Reply-To: <1437011006381-59179.post@n7.nabble.com> References: <1436930032695-59163.post@n7.nabble.com> <1437011006381-59179.post@n7.nabble.com> Message-ID: <55A7C1A8.9070807@oracle.com> Hi Aaron, SPARC T4 engine is an engine developed and provided by Oracle Solaris, and therefore, it is available through Oracle Solaris. If you would like to take advantage of the SPARC T4 processors and you would like to build your own OpenSSL, OpenSSL 1.0.2 will have an inlined SPARC T4 processor support assuming you have a T4/T4+ system. Hope that answers your question. Regards. -- misaki On 7/15/2015 8:43 PM, Aaron wrote: > I checked utility 'openssl' built by my in solaris 11.1 and the default > 'openssl' installed in Solaris 11.1. I noticed that my 'openssl' does NOT > have SPARC T4 engine support. This may be the reason why my 'openssl' is > much slower. Now the question is how to build 'openssl' to let it to have > SPARC T4 engine support. I checked the OpenSSL documents, but seems there > are no descriptions regarding to this topic. > > 1) This is the 'openssl' built by me on Solaris 11.1 > ksol1% ./1.0.2d/normal/openssl/bin/openssl engine > (dynamic) Dynamic engine loading support > (4758cca) IBM 4758 CCA hardware engine support > (aep) Aep hardware engine support > (atalla) Atalla hardware engine support > (cswift) CryptoSwift hardware engine support > (chil) CHIL hardware engine support > (nuron) Nuron hardware engine support > (sureware) SureWare hardware engine support > (ubsec) UBSEC hardware engine support > (gost) Reference implementation of GOST engine > > 2) This is the default 'openssl' installed in Solaris 11.1 > ksol1% /usr/bin/openssl engine > (t4) SPARC T4 engine support > (dynamic) Dynamic engine loading support > (pkcs11) PKCS #11 engine support > > Anybody knows the answer please? > > Thanks, > Aaron > > > > > -- > View this message in context: http://openssl.6102.n7.nabble.com/Can-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163p59179.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From pratyush.parimal at gmail.com Thu Jul 16 17:19:04 2015 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Thu, 16 Jul 2015 13:19:04 -0400 Subject: [openssl-users] Disable EXPORT cipher suites during compilation Message-ID: Hi everyone, I am trying to disable the EXPORT ciphers in my OpenSSL code, during compile-time. I'm able to do so at runtime by including '!EXP' in the string I use with SSL_CTX_set_cipher_list(). However, I'm wondering is there an option (like 'no-rc5') that I can pass to Configure? ./Configure --help says that I can use no- to disable stuff, so I used no-exp, but I think that didn't work since the list of ciphers I get from SSL_get_ciphers() still includes EXP-... ciphers. So does anyone know of a way to compile them out? Thanks, Pratyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Thu Jul 16 21:27:12 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 16 Jul 2015 15:27:12 -0600 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158) Message-ID: Hi All, I am using OpenSSL library for a SSL client performing mutual authentication. RSA certificate used is signed with SHA512 digest. When I switch to FIPS mode and perform re-authentication, I am hitting an error :0409A09E:lib(4):func(154):reason(158). Cipher used is AES128-SHA. Can any one tell me what could be the possible issue? Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Thu Jul 16 22:50:38 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 16 Jul 2015 22:50:38 +0000 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158) In-Reply-To: References: Message-ID: <20150716225038.GA417@openssl.org> On Thu, Jul 16, 2015, Jayalakshmi bhat wrote: > Hi All, > > I am using OpenSSL library for a SSL client performing mutual > authentication. RSA certificate used is signed with SHA512 digest. When I > switch to FIPS mode and perform re-authentication, I am hitting an > error :0409A09E:lib(4):func(154):reason(158). Cipher used is AES128-SHA. > > Can any one tell me what could be the possible issue? > A bit more information would be helpful. When you say "SSL client" do you mean using SSL v3.0 or TLS? SSL 3.0 isn't allowed in FIPS mode but I'd expect a different error. Which version of OpenSSL are you using? Can you reproduce the error using s_client? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Fri Jul 17 00:10:27 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 17 Jul 2015 00:10:27 +0000 Subject: [openssl-users] Loading pkcs11 engine opensc without using command line In-Reply-To: <1457549232.2110650.1437051349639.JavaMail.yahoo@mail.yahoo.com> References: <1457549232.2110650.1437051349639.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150717001027.GA1747@openssl.org> On Thu, Jul 16, 2015, Anirudh Raghunath wrote: > Hello, > > I want to write a program in which I can load a certificate from a smartcard instead of having it in a file on the client machine. In order to do so I will be using the opensc's engine_pkcs11 module. The module works fine using the shell but I want to implement it as an independent program. For example if I use the rsautl module then I can provide the inkey option and keyform option to use the private key from the smartcard. Look at the snippet below: > openssl rsautl -sign -in file -keyform engine -engine pkcs11 -inkey slot_1-id_54a4c9bdaf3ff82b3367b586a6658c23 -out sig > In order to do so I have to load the engine first. I do that as follows: > > ??? openssl engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so > > which yields the result: > > > ??? (dynamic) Dynamic engine loading support > ??? [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > ??? [Success]: ID:pkcs11 > ??? [Success]: LIST_ADD:1 > ??? [Success]: LOAD > ??? [Success]: MODULE_PATH:opensc-pkcs11.so > ??? Loaded: (pkcs11) pkcs11 engine > > > I want to do the same using C code in an independent program so that I can use the: > > > ??? static X509 *pkcs11_load_cert(ENGINE * e, const char *s_slot_cert_id) > function to get the certificate from the smart card. > > So I tried to debug engine.c using ddd debugger to understand exactly which part of the code was required to just load the engine. In the same program I want to use the opensc function to load certificate directly from the smartcard and then use it in further server client communication. > You may be able to make use of the automatic dynamic engine loading mechanism to simplify things. You can pass the ENGINE DSO path as the ENGINE name or to the function ENGINE_by_id() and it should load it. I suggest you try it with the command line utility first. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From bhat.jayalakshmi at gmail.com Fri Jul 17 08:54:34 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 17 Jul 2015 14:24:34 +0530 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158) In-Reply-To: <20150716225038.GA417@openssl.org> References: <20150716225038.GA417@openssl.org> Message-ID: Hi Steve, Thanks a lot for the response. We are not using SSL 3.0. It is completely disabled in the stack. This issue is happening in TLS 1.0/ TLS 1.2 both. We are using OpenSSL 1.0.1c. I did not try using s_client. However I found the issue is fixed with the latest release of OpenSSL 1.0.2d. API's changed are EVP_MD_flags from evp_lib.c and pkey_fips_check_ctx from rsa_pmeth.c Regards Jayalakshmi On Fri, Jul 17, 2015 at 4:20 AM, Dr. Stephen Henson wrote: > On Thu, Jul 16, 2015, Jayalakshmi bhat wrote: > > > Hi All, > > > > I am using OpenSSL library for a SSL client performing mutual > > authentication. RSA certificate used is signed with SHA512 digest. When I > > switch to FIPS mode and perform re-authentication, I am hitting an > > error :0409A09E:lib(4):func(154):reason(158). Cipher used is AES128-SHA. > > > > Can any one tell me what could be the possible issue? > > > > A bit more information would be helpful. When you say "SSL client" do you > mean > using SSL v3.0 or TLS? SSL 3.0 isn't allowed in FIPS mode but I'd expect a > different error. > > Which version of OpenSSL are you using? Can you reproduce the error using > s_client? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Fri Jul 17 10:36:01 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Fri, 17 Jul 2015 13:36:01 +0300 Subject: [openssl-users] Loading pkcs11 engine opensc without using command line In-Reply-To: <20150717001027.GA1747@openssl.org> References: <1457549232.2110650.1437051349639.JavaMail.yahoo@mail.yahoo.com> <20150717001027.GA1747@openssl.org> Message-ID: <20150717133601.7002b099@arkturus.wagner.home> On Fri, 17 Jul 2015 00:10:27 +0000 "Dr. Stephen Henson" wrote: > On Thu, Jul 16, 2015, Anirudh Raghunath wrote: > > > Hello, > > > > I want to write a program in which I can load a certificate from a > > smartcard instead of having it in a file on the client machine. In > > You may be able to make use of the automatic dynamic engine loading > mechanism to simplify things. You can pass the ENGINE DSO path as the > ENGINE name or to the function ENGINE_by_id() and it should load it. > > I suggest you try it with the command line utility first. Does openssl trunk already have API to load certificate from the engine? Last time I've looked for this API I've only found int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s, STACK_OF(X509_NAME) *ca_dn, X509 **pcert, EVP_PKEY **ppkey, STACK_OF(X509) **pother, UI_METHOD *ui_method, void *callback_data); which seems to be a bit too specific (where would I get an SSL pointer if I want to use this certificate in the mail client to sign a CMS message?) and is not supported by opensc PKCS11 engine. > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Fri Jul 17 11:36:36 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 17 Jul 2015 11:36:36 +0000 Subject: [openssl-users] Loading pkcs11 engine opensc without using command line In-Reply-To: <20150717133601.7002b099@arkturus.wagner.home> References: <1457549232.2110650.1437051349639.JavaMail.yahoo@mail.yahoo.com> <20150717001027.GA1747@openssl.org> <20150717133601.7002b099@arkturus.wagner.home> Message-ID: <20150717113636.GA13905@openssl.org> On Fri, Jul 17, 2015, Victor Wagner wrote: > On Fri, 17 Jul 2015 00:10:27 +0000 > "Dr. Stephen Henson" wrote: > > > On Thu, Jul 16, 2015, Anirudh Raghunath wrote: > > > > > Hello, > > > > > > I want to write a program in which I can load a certificate from a > > > smartcard instead of having it in a file on the client machine. In > > > > You may be able to make use of the automatic dynamic engine loading > > mechanism to simplify things. You can pass the ENGINE DSO path as the > > ENGINE name or to the function ENGINE_by_id() and it should load it. > > > > I suggest you try it with the command line utility first. > > Does openssl trunk already have API to load certificate from the engine? > Last time I've looked for this API I've only found > > int ENGINE_load_ssl_client_cert(ENGINE *e, SSL *s, > STACK_OF(X509_NAME) *ca_dn, X509 **pcert, EVP_PKEY **ppkey, > STACK_OF(X509) **pother, > UI_METHOD *ui_method, void *callback_data); > > which seems to be a bit too specific (where would I get an SSL pointer > if I want to use this certificate in the mail client to sign a CMS > message?) and is not supported by opensc PKCS11 engine. > > No OpenSSL currently doesn't have an API to do that but the OP was asking about how to use an external API that took an ENGINE pointer. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From doctor at doctor.nl2k.ab.ca Sun Jul 19 12:05:26 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 19 Jul 2015 06:05:26 -0600 Subject: [openssl-users] Localised Error Message-ID: <20150719120526.GA26708@doctor.nl2k.ab.ca> What should I be looking at when signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error occurs? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From doctor at doctor.nl2k.ab.ca Sun Jul 19 13:26:11 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 19 Jul 2015 07:26:11 -0600 Subject: [openssl-users] [openssl-dev] Localised Error In-Reply-To: <20150719120526.GA26708@doctor.nl2k.ab.ca> References: <20150719120526.GA26708@doctor.nl2k.ab.ca> Message-ID: <20150719132611.GA13485@doctor.nl2k.ab.ca> On Sun, Jul 19, 2015 at 06:05:26AM -0600, The Doctor wrote: > What should I be looking at when > > signed content test streaming S/MIME format, 2 DSA and 2 RSA keys: verify error > > occurs? > Further from the code i = X509_verify_cert(&cert_ctx); if (i <= 0) j = X509_STORE_CTX_get_error(&cert_ctx); X509_STORE_CTX_cleanup(&cert_ctx); if (i <= 0) { PKCS7err(PKCS7_F_PKCS7_VERIFY, PKCS7_R_CERTIFICATE_VERIFY_ERROR); ERR_add_error_data(2, "Verify error:", X509_verify_cert_error_string(j)); sk_X509_free(signers); return 0; } I wonder what could cause such an error? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Abuse a man unjustly, and you will make friends for him. -Edgar Watson Howe From tom.browder at gmail.com Sun Jul 19 16:00:36 2015 From: tom.browder at gmail.com (Tom Browder) Date: Sun, 19 Jul 2015 11:00:36 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <20150709170010.GA28047@mournblade.imrryr.org> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> Message-ID: On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni wrote: > On Thu, Jul 09, 2015 at 11:50:25AM -0500, Tom Browder wrote: >> On Thu, Jul 9, 2015 at 10:22 AM, Viktor Dukhovni >> wrote: >> > On Thu, Jul 09, 2015 at 09:47:00AM -0500, Tom Browder wrote: >> Yes, and you're right about the function--weird, but maybe Matt's >> e-mail points out the real problem. > > That surely means that you're compiling some patched version or > not even 1.0.2d. No, it's the correct version. But just now, after building gcc-5.2.0 and using it to rebuild openssl, all the warnings went away just as Matt said (although the jobserver doesn't work for some reason). Best regards, -Tom From wangqun at alumni.nus.edu.sg Mon Jul 20 01:24:48 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Sun, 19 Jul 2015 18:24:48 -0700 (MST) Subject: [openssl-users] Can OpenSSL applications/utilities use SunSPARC crypto accelerators? In-Reply-To: <55A7C1A8.9070807@oracle.com> References: <1436930032695-59163.post@n7.nabble.com> <1437011006381-59179.post@n7.nabble.com> <55A7C1A8.9070807@oracle.com> Message-ID: <1437355488123-59198.post@n7.nabble.com> Hello Misaki, Thanks for your response. What you pointed out is exactly what I thought previously. However my test showed that OpenSSL command utility 'openssl' built by my from OpenSSL 1.0.2d source code does NOT utilize the crypto accelerator provided in Sun SPARC Solaris 11.1. I tested the default 'openssl' installed in Solaris 11.1 to verify that the machine on which I run my 'openssl' does have the accelerator. I listed my test results in my previous messages. Now my question is if I need build utility 'openssl' with some special option to utilize the crypto accelerator? Thanks again, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Can-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163p59198.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From hbugaj at forcom.com.pl Mon Jul 20 06:49:06 2015 From: hbugaj at forcom.com.pl (Hubert Bugaj) Date: Mon, 20 Jul 2015 08:49:06 +0200 Subject: [openssl-users] Borland C++ Builder 5, compile error in randfile.c Message-ID: <55AC99E2.2040907@forcom.com.pl> I'm following the instructions from INSTALL.W32 (various OpenSSL versions, but let's focus on 1.0.2d), in general it's: * Configure for building with Borland Builder: > perl Configure BC-32 * Create the appropriate makefile > ms\do_nasm * Build > make -f ms\bcb.mak When trying to build I get this error: bcc32 -otmp32\randfile.obj -Iinc32 -Itmp32 -DWIN32_LEAN_AND_MEAN -q -w-ccc -w-rch -w-pia -w-aus -w-par -w-inl -c -tWC -tWM -DOPENSSL_SYSNAME_WIN32 -DL_ENDIAN -DDSO_WIN32 -D_stricmp=stricmp -D_strnicmp=strnicmp -O2 -ff -fp -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE -c .\crypto\rand\randfile.c .\crypto\rand\randfile.c: Warning W8017 C:\CBuilder5\Include\sys/stat.h 34: Redefinition of 'S_IFMT' is not identical Warning W8017 C:\CBuilder5\Include\sys/stat.h 35: Redefinition of 'S_IFDIR' is not identical Error E2227 .\crypto\rand\randfile.c 228: Extra parameter in call to _open in function RAND_write_file Warning W8053 .\crypto\rand\randfile.c 264: '_chmod(const signed char *,int,...)' is obsolete in function RAND_write_file *** 1 errors in Compile *** Yes, I feel bad for using Borland C++ Builder 5 but I can't do anything about it. I've succesfully installed the libraries from Shining Light, (though I had to IMPLIB each .dll) but it's not the solution I want to employ. I'd be glad for any feedback. From wayming.z at gmail.com Mon Jul 20 12:49:16 2015 From: wayming.z at gmail.com (Wayming Zhang) Date: Mon, 20 Jul 2015 22:49:16 +1000 Subject: [openssl-users] Disable EXPORT cipher suites during compilation In-Reply-To: References: Message-ID: <55ACEE4C.2050104@gmail.com> Hi Pratyush, Had a quick search in the source, seems like "no-exp" doesn't change anything. OPENSSL_NO_EXP is defined(by opensslconf.h) when "no-exp" is specified with Configuration command, however, it is not used at all. Regards Way On 17/07/15 03:19, pratyush parimal wrote: > Hi everyone, > > I am trying to disable the EXPORT ciphers in my OpenSSL code, during > compile-time. > > I'm able to do so at runtime by including '!EXP' in the string I use > with SSL_CTX_set_cipher_list(). However, I'm wondering is there an > option (like 'no-rc5') that I can pass to Configure? > > ./Configure --help says that I can use no- to disable stuff, > so I used no-exp, but I think that didn't work since the list of > ciphers I get from SSL_get_ciphers() still includes EXP-... ciphers. > > So does anyone know of a way to compile them out? > > Thanks, > Pratyush > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.arivazhagan at gmail.com Tue Jul 21 06:46:43 2015 From: james.arivazhagan at gmail.com (James) Date: Tue, 21 Jul 2015 12:16:43 +0530 Subject: [openssl-users] Regarding the security of the keys Message-ID: Hi there, I have a concern regarding the private keys we use in the https (say apache) server. The https server links with openssl.so file, and uses the APIs provided by it. If some one build their own openssl and add few lines to print the keys during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH, may result in compromising the security of the keys. Does any of you faced this problem and if you could share the solution it would be helpful. regards, James Arivazhagan Ponnusamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From anirudhraghunath at rocketmail.com Tue Jul 21 06:58:24 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Tue, 21 Jul 2015 06:58:24 +0000 (UTC) Subject: [openssl-users] Getting certificates from smartcards Message-ID: <351410341.774252.1437461904923.JavaMail.yahoo@mail.yahoo.com> Hello, I would like to utilize the ENGINE_load_ssl_client_cert() function to load a certificate from my smart card. I have successfully loaded the engine and have also tried to play around with the ENGINE_load_private_key() function. It worked successfully and I was able to get the private key in an EVP_PKEY object. But I also want the certificate associated with it. I looked at the code of ENGINE_load_ssl_client_cert() but cannot understand the parameters passed to it. Can someone please guide me on how to use it and perhaps give a working example of the call to that function with the parameters clearly mentioned and explained? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Tue Jul 21 06:37:24 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 20 Jul 2015 23:37:24 -0700 (MST) Subject: [openssl-users] Can OpenSSL applications/utilities use SunSPARC crypto accelerators? In-Reply-To: <1437355488123-59198.post@n7.nabble.com> References: <1436930032695-59163.post@n7.nabble.com> <1437011006381-59179.post@n7.nabble.com> <55A7C1A8.9070807@oracle.com> <1437355488123-59198.post@n7.nabble.com> Message-ID: <1437460644422-59218.post@n7.nabble.com> I read the following description from Oracle Solaris website (https://blogs.oracle.com/DanX/entry/how_to_tell_if_sparc) OpenSSL T4 engine Availability The OpenSSL t4 engine is available with Solaris 11 and 11.1. For Solaris 10 08/11 (U10), you need to use the OpenSSL pkcs11 engine. The OpenSSL t4 engine is distributed only with the version of OpenSSL distributed with Solaris (and not third-party or self-compiled versions of OpenSSL). The following announcement is from OpenSSL. Changes between 1.0.1l and 1.0.2 [22 Jan 2015] ... *) Support for SPARC Architecture 2011 crypto extensions, first implemented in SPARC T4. This covers AES, DES, Camellia, SHA1, SHA256/512, MD5, GHASH and modular exponentiation. [Andy Polyakov, David Miller] ... I am confused. I don't know which one is right. I thought the announcement from OpenSSL was right and the description in Oracle website was obsolete. But my test results could not verify my idea. Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Can-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163p59218.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From akihana at gmail.com Tue Jul 21 07:53:51 2015 From: akihana at gmail.com (Mike Mohr) Date: Tue, 21 Jul 2015 00:53:51 -0700 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: References: Message-ID: Securing a system against this kind of attack can be done in several ways, depending on the level of assurance you desire. You might start out with Tripwire: https://en.wikipedia.org/wiki/Open_Source_Tripwire http://www.tripwire.org/ You could also implement mandatory access control and ACLs using either grsecurity or SELinux: http://grsecurity.net/ http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf https://en.wikipedia.org/wiki/Security-Enhanced_Linux Personally I prefer grsecurity, but it is not supported in mainline by any major distribution that I am aware of. You'll have to patch, build, and and support your own kernel image in order to use it. SELinux is supported out of the box on CentOS 6 and 7, so it would probably be a good place to start. If your concern is solely in the realm of protecting your RSA keys, you might consider some HSM product from e.g. Yubico: https://www.yubico.com/ https://en.wikipedia.org/wiki/Hardware_security_module These tiny USB keys store the RSA keys on a secure element which is physically tamper-resistant. The key material never leaves the hardware token. However, you'd probably have to write a custom provider for OpenSSL, and the throughput would probably only be sufficient for a very small amount of traffic. If you need something that can handle a higher load, you might consider purchasing one of Cavium's cards: http://www.cavium.com/overview.html However, they are 10 gigabit passthrough devices and will unwrap / re-wrap the SSL session in hardware. They are not cheap. Good luck! On Mon, Jul 20, 2015 at 11:46 PM, James wrote: > Hi there, > I have a concern regarding the private keys we use in the https (say > apache) server. > The https server links with openssl.so file, and uses the APIs provided by > it. > If some one build their own openssl and add few lines to print the keys > during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH, > may result in compromising the security of the keys. > > Does any of you faced this problem and if you could share the solution it > would be helpful. > > regards, > James Arivazhagan Ponnusamy > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jul 21 08:48:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Jul 2015 08:48:47 +0000 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: References: Message-ID: <59cf8010fafa44c1a32989e70e2d6fed@ustx2ex-dag1mb2.msg.corp.akamai.com> > If some one build their own openssl and add few lines to print the keys during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH, may result in compromising the security of the keys. Can anyone other than root do this? You have to trust root. They could just cat your keyfile anyway. From hokusai at gmx.ch Tue Jul 21 10:08:22 2015 From: hokusai at gmx.ch (hokusai at gmx.ch) Date: Tue, 21 Jul 2015 12:08:22 +0200 Subject: [openssl-users] Workaround for 'unexpected record' error during renegotiation Message-ID: An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Tue Jul 21 11:20:03 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Tue, 21 Jul 2015 14:20:03 +0300 Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <351410341.774252.1437461904923.JavaMail.yahoo@mail.yahoo.com> References: <351410341.774252.1437461904923.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150721142003.592190a8@arkturus.wagner.home> On Tue, 21 Jul 2015 06:58:24 +0000 (UTC) Anirudh Raghunath wrote: > Hello, > I would like to utilize the ENGINE_load_ssl_client_cert() function to > load a certificate from my smart card. I have successfully loaded the > engine and have also tried to play around with the > ENGINE_load_private_key() function. It worked successfully and I was > able to get the private key in an EVP_PKEY object. But I also want > the certificate associated with it. I looked at the code of > ENGINE_load_ssl_client_cert() but cannot understand the parameters > passed to it. Can someone please guide me on how to use it and > perhaps give a working example of the call to that function with the > parameters clearly mentioned and explained? Thanks in advance. > As far as I can understand, this function is designed to be called from the client certificate callback, set with function SSL_CTX_set_client_cert_cb. This callback gets pointer to SSL structure (which should be passed to ENGINE_load_ssl_client_cert) and can use SSL_get_client_CA_list to obtain list of CAs, which server would trust. (SSL protocol allows to send this list to client). So, you would pass to the ENGINE_load_ssl_client_certs 1. reference to engine to use 2. pointer to SSL object of your client connection (don't know why it might be needed), 3. list of CA distinguished names (ca_dn) which server would trust. You can obtain it from the SSL structure passed to your callback and possibly filter something out of it. 4. Three pointers to variables where result should be placed - one for certificate, other for private key and third for the stack of intermediate CA certificates 5. UI method and its callback data (which you should be already familiar with, because you have successfully managed to use ENGINE_load_private_key). Engine ought to find certificate-private key pair, where certificate is issued by one of the CA in the list you pass (or at least chain of trust from it to one of these CAs can be build) Then engine asks user for PIN-code of private key and returns all the objects - certificate, private key and chain of trust from this certificate to one of CAs you've passed to it. Probably, there can be situation where more than one certificate in the hardware token matches given criteria (issued by one of given CA). In this case engine should use ui_method to ask user which one of them he wants to use. Unfortunately, I do not know any engine which does all the things above. I've looked into source of OpenSC pkcs11 engine version 0.1.8 and found out that it doesn't support this function. So I have to copy certificate out of token into file using pkcs11-tool and use ENGINE_load_private_key to load key from token. . From steve at openssl.org Tue Jul 21 12:40:16 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 21 Jul 2015 12:40:16 +0000 Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <20150721142003.592190a8@arkturus.wagner.home> References: <351410341.774252.1437461904923.JavaMail.yahoo@mail.yahoo.com> <20150721142003.592190a8@arkturus.wagner.home> Message-ID: <20150721124016.GA26389@openssl.org> On Tue, Jul 21, 2015, Victor Wagner wrote: > On Tue, 21 Jul 2015 06:58:24 +0000 (UTC) > Anirudh Raghunath wrote: > > As far as I can understand, this function is designed to be called from > the client certificate callback, set with function > SSL_CTX_set_client_cert_cb. This callback gets pointer to SSL structure > (which should be passed to ENGINE_load_ssl_client_cert) and can use > SSL_get_client_CA_list to obtain list of CAs, which server would trust. > (SSL protocol allows to send this list to client). > It's intended to be called automatically when SSL_CTX_set_client_cert_engine sets up a "client authentication ENGINE". > So, you would pass to the ENGINE_load_ssl_client_certs > > 1. reference to engine to use > 2. pointer to SSL object of your client connection (don't know why it > might be needed), This is there so the ENGINE can query other properties of the connection which might decide which chain to use. For example the supported signature algorithms. > > Unfortunately, I do not know any engine which does all the things above. > I've looked into source of OpenSC pkcs11 engine version 0.1.8 and found > out that it doesn't support this function. > The CrytpoAPI ENGINE performs some of these tasks but so far it is the only one I'm aware of. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From anirudhraghunath at rocketmail.com Tue Jul 21 13:58:21 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Tue, 21 Jul 2015 13:58:21 +0000 (UTC) Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <20150721124016.GA26389@openssl.org> References: <20150721124016.GA26389@openssl.org> Message-ID: <557001310.942216.1437487101193.JavaMail.yahoo@mail.yahoo.com> Ah okay, that clears up quite a lot of doubts. But the certificate I want to load is a self signed certificate which has a private key attached to it. I used the XCA application to export the certificate-private key pair as a p12 file to the smart card. What should I do to get the certificate in this case? Thanks. On Tuesday, 21 July 2015 2:40 PM, Dr. Stephen Henson wrote: On Tue, Jul 21, 2015, Victor Wagner wrote: > On Tue, 21 Jul 2015 06:58:24 +0000 (UTC) > Anirudh Raghunath wrote: > > As far as I can understand, this function is designed to be called from > the client certificate callback, set with function > SSL_CTX_set_client_cert_cb. This callback gets pointer to SSL structure > (which should be passed to ENGINE_load_ssl_client_cert) and can use > SSL_get_client_CA_list to obtain list of CAs, which server would trust. > (SSL protocol allows to send this list to client). > It's intended to be called automatically when SSL_CTX_set_client_cert_engine sets up a "client authentication ENGINE". > So, you would pass to the ENGINE_load_ssl_client_certs > > 1. reference to engine to use > 2. pointer to SSL object of your client connection (don't know why it > might be needed), This is there so the ENGINE can query other properties of the connection which might decide which chain to use. For example the supported signature algorithms. > > Unfortunately, I do not know any engine which does all the things above. > I've looked into source of OpenSC pkcs11 engine version 0.1.8 and found > out that it doesn't support this function. > The CrytpoAPI ENGINE performs some of these tasks but so far it is the only one I'm aware of. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.browder at gmail.com Tue Jul 21 14:33:55 2015 From: tom.browder at gmail.com (Tom Browder) Date: Tue, 21 Jul 2015 09:33:55 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> Message-ID: On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder wrote: > On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni >> That surely means that you're compiling some patched version or >> not even 1.0.2d. > > No, it's the correct version. > > But just now, after building gcc-5.2.0 and using it to rebuild > openssl, all the warnings went away just as Matt said (although the > jobserver doesn't work for some reason). I lied. After rebuilding gcc 5.2.0 and rechecking I get the following warnings from building 1.0.2d: ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': ec_key.c:369:26: warning: variable 'is_char_two' set but not used [-Wunused-but-set-variable] int ok = 0, tmp_nid, is_char_two = 0; ^ d1_both.c: In function 'dtls1_retransmit_message': d1_both.c:1261:9: warning: 'save_write_sequence' may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(s->s3->write_sequence, save_write_sequence, ^ Best, -Tom From corazonprohibido242 at gmail.com Tue Jul 21 14:36:28 2015 From: corazonprohibido242 at gmail.com (ROBERTO Y MARIBEL) Date: Tue, 21 Jul 2015 10:36:28 -0400 Subject: [openssl-users] (no subject) Message-ID: WHAT ROBERTO Y MARIBEL -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Tue Jul 21 15:48:33 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Tue, 21 Jul 2015 21:18:33 +0530 Subject: [openssl-users] question on Alternative chains certificate forgery (CVE-2015-1793) Message-ID: Hi All, Does *a**lternative chains certificate forgery** issue* affects the OpenSSL stacks earlier than 1.0.1n releases Why I am asking this question is affected code seems to be available in earlier versions as well. Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Tue Jul 21 16:05:38 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 21 Jul 2015 18:05:38 +0200 Subject: [openssl-users] question on Alternative chains certificate forgery (CVE-2015-1793) In-Reply-To: References: Message-ID: <55AE6DD2.4080007@ncp-e.com> Precisely the versions as stated in https://openssl.org/news/secadv_20150709.txt are affected: This issue affects OpenSSL versions 1.0.2c, 1.0.2b, 1.0.1n and 1.0.1o. OpenSSL 1.0.2b/1.0.2c users should upgrade to 1.0.2d OpenSSL 1.0.1n/1.0.1o users should upgrade to 1.0.1p This issue was reported to OpenSSL on 24th June 2015 by Adam Langley/David Benjamin (Google/BoringSSL). The fix was developed by the BoringSSL project. In other words, the bug was introduced in 1.0.1n resp. 1.0.2b, which was roughly a month before it was fixed again. On 07/21/2015 05:48 PM, Jayalakshmi bhat wrote: > Hi All, > > Does *a**lternative chains certificate forgery** issue* affects the OpenSSL stacks earlier than 1.0.1n releases Why I am asking this question is affected code seems to be available in earlier versions as well. > > > Thanks and Regards > > Jayalakshmi > > From vitus at wagner.pp.ru Tue Jul 21 18:15:04 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Tue, 21 Jul 2015 21:15:04 +0300 Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <557001310.942216.1437487101193.JavaMail.yahoo@mail.yahoo.com> References: <20150721124016.GA26389@openssl.org> <557001310.942216.1437487101193.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150721211504.41184acf@arkturus.local> On Tue, 21 Jul 2015 13:58:21 +0000 (UTC) Anirudh Raghunath wrote: > Ah okay, that clears up quite a lot of doubts. But the certificate I > want to load is a self signed certificate which has a private key > attached to it. I used the XCA application to export the > certificate-private key pair as a p12 file to the smart card. What > should I do to get the certificate in this case? Thanks. > It doesn't matter how you've installed certificate into smart card. Once it, and its corresponding private key is installed on the card, you can access them separately, using PKCS#11 API (and command-line pkcs11-tool utility). So, you can extract just certificate from certificate-private key pair and put it into the file (but typically you cannot extract private key. You can only use PKCS11 API or OpenSSL ENGINE API on top of it to perform cryptographic operations with this private key. This is what smartcards are for). If you have opensc pkcs11 engine, you also should have pkcs11-tool from opensc project. Use pkcs11-tool --module --list-objects to find out which certificate-private key pairs are available on your card (you probably already know ID of your key pair, because you've used ENGINE_load_private_key, and it requires key id as argument). Then use pkcs11-tool --module --write-object --type cert --output-file filename.der to extract certificate from card. You can then convert it to pem format using openssl x509 -in filename.der -inform DER -out filename.pem or can just use function SSL_CTX_use_certificate_file passing SSL_FILETYPE_ASN1 as its argument. Personally I consider it ugly that one need to extract certificate from token before it can be used in openssl-based applications for any purpose except SSL-client authentication. Function int ENGINE_load_certificate(ENGINE *e, const char *key id, UI_METHOD *ui_method, void *callback_data) is clearly missing from API. Existence of such function would allow to use smartcards and other hardware tokens to be used 1. In the server applications 2. In the non-SSL (i.e. CMS signing) applications 3. For secondary protocols like OCSP or timestamping authority. From matt at openssl.org Tue Jul 21 19:16:00 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Jul 2015 20:16:00 +0100 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> Message-ID: <55AE9A70.6080405@openssl.org> On 21/07/15 15:33, Tom Browder wrote: > On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder wrote: >> On Thu, Jul 9, 2015 at 12:00 PM, Viktor Dukhovni >>> That surely means that you're compiling some patched version or >>> not even 1.0.2d. >> >> No, it's the correct version. >> >> But just now, after building gcc-5.2.0 and using it to rebuild >> openssl, all the warnings went away just as Matt said (although the >> jobserver doesn't work for some reason). > > I lied. After rebuilding gcc 5.2.0 and rechecking I get the following > warnings from building 1.0.2d: > > ec_key.c: In function 'EC_KEY_set_public_key_affine_coordinates': > ec_key.c:369:26: warning: variable 'is_char_two' set but not used > [-Wunused-but-set-variable] > int ok = 0, tmp_nid, is_char_two = 0; Like I said in my original email this one is due to compiling with no-ec2m. Its harmless (but should be fixed). > ^ > d1_both.c: In function 'dtls1_retransmit_message': > d1_both.c:1261:9: warning: 'save_write_sequence' may be used > uninitialized in this function [-Wmaybe-uninitialized] > memcpy(s->s3->write_sequence, save_write_sequence, > ^ This one is entirely bogus. "save_write_sequence" is initialized on line 1241. The compiler just isn't clever enough to figure that out. Matt From noloader at gmail.com Tue Jul 21 19:54:18 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 15:54:18 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <55AE9A70.6080405@openssl.org> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: >> ^ >> d1_both.c: In function 'dtls1_retransmit_message': >> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> memcpy(s->s3->write_sequence, save_write_sequence, >> ^ > > This one is entirely bogus. "save_write_sequence" is initialized on line > 1241. The compiler just isn't clever enough to figure that out. Right. But we need to learn to work with our tools :) The other option throws the baby out with the bath water by disabling warnings. Or, it leaves the problem in places so thousands or millions of folks have to look at the issue and clear it. Just initialize it and let the optimizer do its job. It should identify the dead store (the unneeded initialization) and optimize it out. Jeff From matt at openssl.org Tue Jul 21 20:06:32 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Jul 2015 21:06:32 +0100 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: <55AEA648.1060700@openssl.org> On 21/07/15 20:54, Jeffrey Walton wrote: >>> ^ >>> d1_both.c: In function 'dtls1_retransmit_message': >>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >>> uninitialized in this function [-Wmaybe-uninitialized] >>> memcpy(s->s3->write_sequence, save_write_sequence, >>> ^ >> >> This one is entirely bogus. "save_write_sequence" is initialized on line >> 1241. The compiler just isn't clever enough to figure that out. > > Right. But we need to learn to work with our tools :) The other option > throws the baby out with the bath water by disabling warnings. Or, it > leaves the problem in places so thousands or millions of folks have to > look at the issue and clear it. Agree to a point. I always config with --strict-warnings to add dev team flags (as do the rest of the dev team). Amongst other things this adds -Werror to treat all warnings as errors, so if a warning occurs then we know about it and squash it. However that of course only catches warnings for the particular platforms and compiler versions that the dev team uses. There will always be warnings that we don't see that others do. We could spend a huge amount of time tracking all of those down for little benefit. Matt From Michaela_Schoenbauer at gmx.at Tue Jul 21 20:07:23 2015 From: Michaela_Schoenbauer at gmx.at (Michaela Schoenbauer) Date: Tue, 21 Jul 2015 22:07:23 +0200 Subject: [openssl-users] Size of OpenSSL ECDSA/DSA Implementation Message-ID: <55AEA67B.4060904@gmx.at> Hi, I'm currently working on my Master thesis, and the topic is about ECDSA implementations and DSA implementations in the context of small embedded systems. I'd like to try out OpenSSL but I'm not sure if I can configure it to be small enough for the embedded devices I use. For my purpose a custom built of the library should exclude all SSL/TLS functionality and only include (a) ECDSA support and (b) DSA support in another built. Does anyone know how small I can make the OpenSSL library? May the results be smaller than 10KB or which results can I expect? If anyone already tried something similar or has some answers/hints I would be thankful. Michaela From tom.browder at gmail.com Tue Jul 21 20:40:37 2015 From: tom.browder at gmail.com (Tom Browder) Date: Tue, 21 Jul 2015 15:40:37 -0500 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <55AE9A70.6080405@openssl.org> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell wrote: > On 21/07/15 15:33, Tom Browder wrote: >> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder wrote: >> I lied. After rebuilding gcc 5.2.0 and rechecking I get the following >> warnings from building 1.0.2d: >> >> d1_both.c: In function 'dtls1_retransmit_message': >> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> memcpy(s->s3->write_sequence, save_write_sequence, >> ^ > > This one is entirely bogus. "save_write_sequence" is initialized on line > 1241. The compiler just isn't clever enough to figure that out. Um, that initialization is in an if block, so that's not guaranteed, right? -Tom From noloader at gmail.com Tue Jul 21 20:44:51 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 16:44:51 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <55AEA648.1060700@openssl.org> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <55AEA648.1060700@openssl.org> Message-ID: On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell wrote: > > > On 21/07/15 20:54, Jeffrey Walton wrote: >>>> ^ >>>> d1_both.c: In function 'dtls1_retransmit_message': >>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >>>> uninitialized in this function [-Wmaybe-uninitialized] >>>> memcpy(s->s3->write_sequence, save_write_sequence, >>>> ^ >>> >>> This one is entirely bogus. "save_write_sequence" is initialized on line >>> 1241. The compiler just isn't clever enough to figure that out. >> >> Right. But we need to learn to work with our tools :) The other option >> throws the baby out with the bath water by disabling warnings. Or, it >> leaves the problem in places so thousands or millions of folks have to >> look at the issue and clear it. > > Agree to a point. I always config with --strict-warnings to add dev team > flags (as do the rest of the dev team). This is a good point. You are saying "trust the developers, they know what is best." I'm fine with that because they really do know what's best. No one knows the code better. ... Then C&A creeps in. For some companies, they have to acceptance test libraries before using them. Its a matter of governance, polices and procedures. If an organization's bar is lower than OpenSSL's, then everything is fine. If the bar is higher, then its a pain pint. Folks like Rich Salz knows exactly what I am talking about and experiences the pain points regularly. (I've worn Rich's hat and walked in his shoes). > We could spend a huge amount of time tracking all of those down for > little benefit. To play devil's advocate, To Whom? If 10,000 people each spend 15 minutes looking at (and re-analyzing) one warning, then the community collectively lost 4,000 man hours. 2 minutes for a dev to clear the issue once versus 4,000 man hours seems like a very good return on investment. And to be fair, I just cleared a similar warning in Crypto++: https://github.com/weidai11/cryptopp/commit/d04b813e8b078e717992b86b8b6103db0bd2cec3. I new damn well all those variables were initialized, and the problem was with analyzer's inter-procedural analysis. For the d04b813e8 commit, I had to analyze it to ensure it was not a legitimate squawk. But my choices after analyzing it were: (1) spend 30 seconds on the clear-commit-push cycle; or (2) allow the community to spend countless hours reanalyzing it, and spend countless hours explaining the reason for the dirty compile on the mailing list (q.v.!). I opted for (1) because it was easier on me, and organizations don't have to worry about C&A and governance issues. Like I said, its learning to play well with your tools :) Jeff From noloader at gmail.com Tue Jul 21 20:53:13 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 16:53:13 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: Message-ID: > I'm not real current with C so I'm not in a great position to > criticize, but can't those warnings (if there is truly no problem) be > eliminated (at least in gcc) with a pragma? > Sadly, no. GCC pragmas to manage warnings are almost useless. Its been broken for years. See: * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943 I even offered to start a bounty and pay a GCC dev to fix the "pragma GCC diagnostic" gear (managing warnings are that important to me): * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943#c8 Jeff From anirudhraghunath at rocketmail.com Tue Jul 21 20:56:06 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Tue, 21 Jul 2015 20:56:06 +0000 (UTC) Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <20150721211504.41184acf@arkturus.local> References: <20150721211504.41184acf@arkturus.local> Message-ID: <51950785.989882.1437512166240.JavaMail.yahoo@mail.yahoo.com> Shoot, I need that functionality. Can I perhaps use the?X509 *load_cert(BIO *err, const char *file, int format, const char *pass, ENGINE *e, const char *cert_descrip) function then? If yes, then can someone elaborate on how to use this function? Thanks On Tuesday, 21 July 2015 8:19 PM, Victor Wagner wrote: On Tue, 21 Jul 2015 13:58:21 +0000 (UTC) Anirudh Raghunath wrote: > Ah okay, that clears up quite a lot of doubts. But the certificate I > want to load is a self signed certificate which has a private key > attached to it. I used the XCA application to export the > certificate-private key pair as a p12 file to the smart card. What > should I do to get the certificate in this case? Thanks. > It doesn't matter how you've installed certificate into smart card. Once it, and its corresponding private key is installed on the card, you can access them separately, using PKCS#11 API (and command-line pkcs11-tool utility). So, you can extract just certificate from certificate-private key pair and put it into the file (but typically you cannot extract private key. You can only use PKCS11 API or OpenSSL ENGINE API on top of it to perform cryptographic operations with this private key. This is what smartcards are for). If you have opensc pkcs11 engine, you also should have pkcs11-tool from opensc project. Use pkcs11-tool --module --list-objects to find out which certificate-private key pairs are available on your card (you probably already know ID of your key pair, because you've used ENGINE_load_private_key, and it requires key id as argument). Then use pkcs11-tool --module --write-object --type cert --output-file filename.der to extract certificate from card.? You can then convert it to pem format using openssl x509 -in filename.der -inform DER -out filename.pem or can just use function SSL_CTX_use_certificate_file passing SSL_FILETYPE_ASN1 as its argument. Personally I consider it ugly that one need to extract certificate from token before it can be used in openssl-based applications for any purpose except SSL-client authentication. Function int ENGINE_load_certificate(ENGINE *e, const char *key id, ? ? UI_METHOD *ui_method, void *callback_data) is clearly missing from API. Existence of such function would allow to use smartcards and other hardware tokens to be used 1. In the server applications 2. In the non-SSL (i.e. CMS signing) applications 3. For secondary protocols like OCSP or timestamping authority. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Jul 21 20:57:12 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 16:57:12 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: On Tue, Jul 21, 2015 at 4:40 PM, Tom Browder wrote: > On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell wrote: >> On 21/07/15 15:33, Tom Browder wrote: >>> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder wrote: >>> I lied. After rebuilding gcc 5.2.0 and rechecking I get the following >>> warnings from building 1.0.2d: >>> >>> d1_both.c: In function 'dtls1_retransmit_message': >>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >>> uninitialized in this function [-Wmaybe-uninitialized] >>> memcpy(s->s3->write_sequence, save_write_sequence, >>> ^ >> >> This one is entirely bogus. "save_write_sequence" is initialized on line >> 1241. The compiler just isn't clever enough to figure that out. > > Um, that initialization is in an if block, so that's not guaranteed, right? > Was that a -Wmaybe-uninitialized? A neat trick: open Configure, copy your linux-86_64 configure line, rename it to something like linux-analyze, and then change the compiler to ccc-analyze. ccc-analyze is LLVM's static analyzer, and it gives you the graph of the steps that arrive at the conclusion. Finally, run `./Configure linux-analyze`, `make` and then `make test'. Then, copy/paste the output. You don't have to explain anything. Jeff From rsalz at akamai.com Tue Jul 21 21:56:44 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Jul 2015 21:56:44 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> If it's a simple matter of adding "=0" in the declaration, we should just fix the darn thing. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From noloader at gmail.com Tue Jul 21 22:20:04 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 18:20:04 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On Tue, Jul 21, 2015 at 5:56 PM, Salz, Rich wrote: > If it's a simple matter of adding "=0" in the declaration, we should just fix the darn thing. > You know... if OpenSSL changes its policies so that C99 is the baseline, then you get to initialize all variables when declared. I think its the default for many compilers from either the compiler build or the SPEC file. So its something that's broadly already in practice. Its a small leap to codify it. For the stragglers, I don't think its a stretch to ask C99 in 2015. Jeff From rsalz at akamai.com Tue Jul 21 22:21:11 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 21 Jul 2015 22:21:11 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > For the stragglers, I don't think its a stretch to ask C99 in 2015. We agreed to support Netware; does it have C99? Anyone know? From matt at openssl.org Tue Jul 21 22:30:54 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Jul 2015 23:30:54 +0100 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> Message-ID: <55AEC81E.60609@openssl.org> On 21/07/15 21:40, Tom Browder wrote: > On Tue, Jul 21, 2015 at 2:16 PM, Matt Caswell wrote: >> On 21/07/15 15:33, Tom Browder wrote: >>> On Sun, Jul 19, 2015 at 11:00 AM, Tom Browder wrote: >>> I lied. After rebuilding gcc 5.2.0 and rechecking I get the following >>> warnings from building 1.0.2d: >>> >>> d1_both.c: In function 'dtls1_retransmit_message': >>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >>> uninitialized in this function [-Wmaybe-uninitialized] >>> memcpy(s->s3->write_sequence, save_write_sequence, >>> ^ >> >> This one is entirely bogus. "save_write_sequence" is initialized on line >> 1241. The compiler just isn't clever enough to figure that out. > > Um, that initialization is in an if block, so that's not guaranteed, right? Right, the initialization is in an if block. But the use on 1261 is also in an if block. The conditions for each of the two if blocks are identical. So both will be executed or neither will be executed (assuming nothing changes the state so that the conditions evaluate differently between the first and second if - which it doesn't). Matt From matt at openssl.org Tue Jul 21 22:47:20 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Jul 2015 23:47:20 +0100 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <55AEA648.1060700@openssl.org> Message-ID: <55AECBF8.9070105@openssl.org> On 21/07/15 21:44, Jeffrey Walton wrote: > On Tue, Jul 21, 2015 at 4:06 PM, Matt Caswell wrote: >> >> >> On 21/07/15 20:54, Jeffrey Walton wrote: >>>>> ^ >>>>> d1_both.c: In function 'dtls1_retransmit_message': >>>>> d1_both.c:1261:9: warning: 'save_write_sequence' may be used >>>>> uninitialized in this function [-Wmaybe-uninitialized] >>>>> memcpy(s->s3->write_sequence, save_write_sequence, >>>>> ^ >>>> >>>> This one is entirely bogus. "save_write_sequence" is initialized on line >>>> 1241. The compiler just isn't clever enough to figure that out. >>> >>> Right. But we need to learn to work with our tools :) The other option >>> throws the baby out with the bath water by disabling warnings. Or, it >>> leaves the problem in places so thousands or millions of folks have to >>> look at the issue and clear it. >> >> Agree to a point. I always config with --strict-warnings to add dev team >> flags (as do the rest of the dev team). > > This is a good point. You are saying "trust the developers, they know > what is best." I'm fine with that because they really do know what's > best. No one knows the code better. > > ... Then C&A creeps in. For some companies, they have to acceptance > test libraries before using them. Its a matter of governance, polices > and procedures. If an organization's bar is lower than OpenSSL's, then > everything is fine. If the bar is higher, then its a pain pint. > > Folks like Rich Salz knows exactly what I am talking about and > experiences the pain points regularly. (I've worn Rich's hat and > walked in his shoes). > >> We could spend a huge amount of time tracking all of those down for >> little benefit. > > To play devil's advocate, To Whom? If 10,000 people each spend 15 > minutes looking at (and re-analyzing) one warning, then the community > collectively lost 4,000 man hours. 2 minutes for a dev to clear the > issue once versus 4,000 man hours seems like a very good return on > investment. > > And to be fair, I just cleared a similar warning in Crypto++: > https://github.com/weidai11/cryptopp/commit/d04b813e8b078e717992b86b8b6103db0bd2cec3. > I new damn well all those variables were initialized, and the problem > was with analyzer's inter-procedural analysis. > > For the d04b813e8 commit, I had to analyze it to ensure it was not a > legitimate squawk. But my choices after analyzing it were: (1) spend > 30 seconds on the clear-commit-push cycle; or (2) allow the community > to spend countless hours reanalyzing it, and spend countless hours > explaining the reason for the dirty compile on the mailing list > (q.v.!). I opted for (1) because it was easier on me, and > organizations don't have to worry about C&A and governance issues. > > Like I said, its learning to play well with your tools :) Well I think what your saying is that we should play well with other people's tools! My tools (and presumably the rest of the dev team's as well) don't report this warning. Collectively the dev team expect a build to work with --strict-warnings which means that there should be no warnings reported at all for the team. That's quite a high bar to reach because we've all got slightly different set ups, so every now and then we encounter a problem that one person on the team gets but others don't. No matter how high we set the bar though there is always going to be some system somewhere that still reports a warning. We are never going to be able to eradicate that. I get your point about the time people spend on looking at a warning adding up (although somehow I just don't buy the idea that 10,000 people are going to spend 15 minutes each looking at it). I'm not arguing that we shouldn't fix warnings when we become aware of them - particularly if we think there is a real problem or the warning is coming from a common tool chain. I'm just saying that pro-actively tracking them down so that it always cleanly compiles with no warnings for everyone is not likely to be a useful use of time (and is actually not realistic anyway). Matt From kgoldman at us.ibm.com Tue Jul 21 22:32:35 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 21 Jul 2015 18:32:35 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: It may be correct in this case, but "simple matter of" can sometimes mask a real problem. If the function expected the value to be set earlier, but the analysis tool finds a path where it's not set, there could be a more real bug. Is zero the right value? Why not, 1, -1, or 42? =0 may be perfectly good in this case. But beware of quick code fixes to silence compiler warnings. On 7/21/2015 5:56 PM, Salz, Rich wrote: > If it's a simple matter of adding "=0" in the declaration, we should just fix the darn thing. From kgoldman at us.ibm.com Tue Jul 21 22:37:27 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 21 Jul 2015 18:37:27 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 7/21/2015 6:20 PM, Jeffrey Walton wrote: > > For the stragglers, I don't think its a stretch to ask C99 in 2015. Visual Studio is often used on Windows, and it is not C99. From bkaduk at akamai.com Tue Jul 21 23:05:57 2015 From: bkaduk at akamai.com (Kaduk, Ben) Date: Tue, 21 Jul 2015 23:05:57 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 7/21/15, 17:37, "Ken Goldman" wrote: >On 7/21/2015 6:20 PM, Jeffrey Walton wrote: >> >> For the stragglers, I don't think its a stretch to ask C99 in 2015. > >Visual Studio is often used on Windows, and it is not C99. It is getting closer, though: http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixe s-and-breaking-changes-in-vs-2013.aspx discusses the addition of several useful C99 features in VS2013, including compound literals, designated initializers, and variable declarations. -Ben Kaduk From noloader at gmail.com Tue Jul 21 23:21:23 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 19:21:23 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: >> For the stragglers, I don't think its a stretch to ask C99 in 2015. > > Visual Studio is often used on Windows, and it is not C99. > Oh my, I was not aware it was still struggling for C99 :) I guess Microsoft is still putting their energies into the "one-size, tablet interface known as Windows 8, fits all, even on desktops without a touchscreen". On the good side, MSVC does not need to be 100% compliant. It just needs to support initialization at time of declaration. That particular feature works. From noloader at gmail.com Tue Jul 21 23:27:15 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 21 Jul 2015 19:27:15 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <55AECBF8.9070105@openssl.org> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <55AEA648.1060700@openssl.org> <55AECBF8.9070105@openssl.org> Message-ID: >> Like I said, its learning to play well with your tools :) > > Well I think what your saying is that we should play well with other > people's tools! My tools (and presumably the rest of the dev team's as > well) don't report this warning. Ah, OK. So its being reported in GCC 5.1 via -Wmaybe-unitialized (I suspect). That may point to an issue in OpenSSL's engineering process. There may be a gap because no one is running, say Fedora 22 or Debian 8 (I think Debian 8 provides GCC 5.1). Can you confirm the test platform is in-place and being utilized? Jeff From Michael.Wojcik at microfocus.com Wed Jul 22 00:18:50 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 22 Jul 2015 00:18:50 +0000 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Kaduk, Ben > Sent: Tuesday, July 21, 2015 17:06 > > On 7/21/15, 17:37, "Ken Goldman" wrote: > >On 7/21/2015 6:20 PM, Jeffrey Walton wrote: > >> > >> For the stragglers, I don't think its a stretch to ask C99 in 2015. If only. > >Visual Studio is often used on Windows, and it is not C99. > > It is getting closer, though: > http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features- > fixe > s-and-breaking-changes-in-vs-2013.aspx discusses the addition of several > useful C99 features in VS2013, including compound literals, designated > initializers, and variable declarations. Still no sign of a conforming snprintf, though. MSVC isn't even really a conforming hosted-environment C90. It's debatable whether it can be called C at all. -- Michael Wojcik Technology Specialist, Micro Focus From akihana at gmail.com Wed Jul 22 04:09:01 2015 From: akihana at gmail.com (Mike Mohr) Date: Tue, 21 Jul 2015 21:09:01 -0700 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: <59cf8010fafa44c1a32989e70e2d6fed@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <59cf8010fafa44c1a32989e70e2d6fed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: Actually that isn't quite right. A properly configured and tuned RBAC policy, when combined with PaX , can very effectively limit all userspace activity (including root access!). It helps if you can also use a hardware security module to protect your key material. On Tue, Jul 21, 2015 at 1:48 AM, Salz, Rich wrote: > > If some one build their own openssl and add few lines to print the keys > during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH, > may result in compromising the security of the keys. > > Can anyone other than root do this? You have to trust root. They could > just cat your keyfile anyway. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 22 04:46:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Jul 2015 04:46:22 +0000 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: References: <59cf8010fafa44c1a32989e70e2d6fed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <37468782b8fd47139743dc1db2639ca5@ustx2ex-dag1mb2.msg.corp.akamai.com> > Actually that isn't quite right.? A properly configured and tuned?RBAC?policy, when combined with?PaX, can very effectively limit all userspace activity (including root access!).? How do you know that the module is installed and actually doing things? How do you know what kernel is actually booted? > It helps if you can also use a?hardware security module?to protect your key material. How do you know that the operations that YOU request are actually the ones being performed? How do you know that the operating system isn't making additional requests of its own? You have to trust root. No two ways about it. From noloader at gmail.com Wed Jul 22 05:39:10 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 22 Jul 2015 01:39:10 -0400 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: References: Message-ID: > If some one build their own openssl and add few lines to print the keys > during encrypt and decrypt and put in the library in the LD_LIBRARY_PATH, > may result in compromising the security of the keys. > > Does any of you faced this problem and if you could share the solution it > would be helpful. Also see http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/. From akihana at gmail.com Wed Jul 22 06:50:17 2015 From: akihana at gmail.com (Mike Mohr) Date: Tue, 21 Jul 2015 23:50:17 -0700 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: <37468782b8fd47139743dc1db2639ca5@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <59cf8010fafa44c1a32989e70e2d6fed@ustx2ex-dag1mb2.msg.corp.akamai.com> <37468782b8fd47139743dc1db2639ca5@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On Tue, Jul 21, 2015 at 9:46 PM, Salz, Rich wrote: > > > Actually that isn't quite right. A properly configured and > tuned RBAC policy, when combined with PaX, can very effectively limit all > userspace activity (including root access!). > > How do you know that the module is installed and actually doing things? > How do you know what kernel is actually booted? > Of course you're right. One might also consider attack vectors from an unsecured BMC or the IME - they probably have undetectable DMA access to the host, after all. But that isn't the point ... steps can and should be taken to lock down the host operating system. > > > It helps if you can also use a hardware security module to protect your > key material. > > How do you know that the operations that YOU request are actually the ones > being performed? How do you know that the operating system isn't making > additional requests of its own? > > You have to trust root. No two ways about it. > The first question has no bearing on the second statement. With or without grsecurity/selinux, you have no way to guarantee that the kernel is operating the way you expect it to at any given time. I suppose it boils down to the threat model. However, limiting root's power is a good idea, and grsecurity provides an excellent framework in which to do so. Caveat emptor. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anirudhraghunath at rocketmail.com Wed Jul 22 07:49:45 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 07:49:45 +0000 (UTC) Subject: [openssl-users] Getting certificates from smartcards In-Reply-To: <51950785.989882.1437512166240.JavaMail.yahoo@mail.yahoo.com> References: <51950785.989882.1437512166240.JavaMail.yahoo@mail.yahoo.com> Message-ID: <910803604.213307.1437551385151.JavaMail.yahoo@mail.yahoo.com> Shoot, I need that functionality. Can I perhaps use the?X509 *load_cert(BIO *err, const char *file, int format, const char *pass, ENGINE *e, const char *cert_descrip) function then? If yes, then can someone elaborate on how to use this function? Thanks. On Tuesday, 21 July 2015 10:56 PM, Anirudh Raghunath wrote: Shoot, I need that functionality. Can I perhaps use the?X509 *load_cert(BIO *err, const char *file, int format, const char *pass, ENGINE *e, const char *cert_descrip) function then? If yes, then can someone elaborate on how to use this function? Thanks On Tuesday, 21 July 2015 8:19 PM, Victor Wagner wrote: On Tue, 21 Jul 2015 13:58:21 +0000 (UTC) Anirudh Raghunath wrote: > Ah okay, that clears up quite a lot of doubts. But the certificate I > want to load is a self signed certificate which has a private key > attached to it. I used the XCA application to export the > certificate-private key pair as a p12 file to the smart card. What > should I do to get the certificate in this case? Thanks. > It doesn't matter how you've installed certificate into smart card. Once it, and its corresponding private key is installed on the card, you can access them separately, using PKCS#11 API (and command-line pkcs11-tool utility). So, you can extract just certificate from certificate-private key pair and put it into the file (but typically you cannot extract private key. You can only use PKCS11 API or OpenSSL ENGINE API on top of it to perform cryptographic operations with this private key. This is what smartcards are for). If you have opensc pkcs11 engine, you also should have pkcs11-tool from opensc project. Use pkcs11-tool --module --list-objects to find out which certificate-private key pairs are available on your card (you probably already know ID of your key pair, because you've used ENGINE_load_private_key, and it requires key id as argument). Then use pkcs11-tool --module --write-object --type cert --output-file filename.der to extract certificate from card.? You can then convert it to pem format using openssl x509 -in filename.der -inform DER -out filename.pem or can just use function SSL_CTX_use_certificate_file passing SSL_FILETYPE_ASN1 as its argument. Personally I consider it ugly that one need to extract certificate from token before it can be used in openssl-based applications for any purpose except SSL-client authentication. Function int ENGINE_load_certificate(ENGINE *e, const char *key id, ? ? UI_METHOD *ui_method, void *callback_data) is clearly missing from API. Existence of such function would allow to use smartcards and other hardware tokens to be used 1. In the server applications 2. In the non-SSL (i.e. CMS signing) applications 3. For secondary protocols like OCSP or timestamping authority. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From anirudhraghunath at rocketmail.com Wed Jul 22 09:17:43 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 09:17:43 +0000 (UTC) Subject: [openssl-users] Converting Bin format to X509 format Message-ID: <876140824.268488.1437556663757.JavaMail.yahoo@mail.yahoo.com> Hello, I have used rsault -sign option to sign a text file which gives me a binary file. I would like to convert this to X509 so that I can use it in a ssl handshake. I understand the command: openssl x509 -inform -in -out ? is used. I want to know what the parameters would be for a binary input file. Thanks in advance.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erwann.abalea at opentrust.com Wed Jul 22 09:52:10 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 22 Jul 2015 11:52:10 +0200 Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <876140824.268488.1437556663757.JavaMail.yahoo@mail.yahoo.com> References: <876140824.268488.1437556663757.JavaMail.yahoo@mail.yahoo.com> Message-ID: <3B84C119-B7F1-4FC7-A9CB-F798A7A4891A@opentrust.com> Bonjour, An X.509 certificate is: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } What you produced with ? openssl rsautl -sign ? is the content of the ? signatureValue ? element (not its BIT STRING structure, only the inner content). What is missing is all the rest, and it can?t be produced by the sole ? openssl x509 ? ? command. Please refine your question. Cordialement, Erwann Abalea > Le 22 juil. 2015 ? 11:17, Anirudh Raghunath a ?crit : > > Hello, > > I have used rsault -sign option to sign a text file which gives me a binary file. I would like to convert this to X509 so that I can use it in a ssl handshake. I understand the command: > > openssl x509 -inform -in -out > > is used. I want to know what the parameters would be for a binary input file. > > Thanks in advance. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From anirudhraghunath at rocketmail.com Wed Jul 22 09:57:16 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 09:57:16 +0000 (UTC) Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <3B84C119-B7F1-4FC7-A9CB-F798A7A4891A@opentrust.com> References: <3B84C119-B7F1-4FC7-A9CB-F798A7A4891A@opentrust.com> Message-ID: <1937901886.290059.1437559036881.JavaMail.yahoo@mail.yahoo.com> Thanks for the quick response. I am currently working with smart cards and am using the engine provided by openSC to access the private key in the smart card. Long story short I have the EVP_PKEY object with me. Can I use this to sign a certificate or some file which can be used for SSL client verification.? Merci On Wednesday, 22 July 2015 11:52 AM, Erwann Abalea wrote: Bonjour, An X.509 certificate is: Certificate ?::= ?SEQUENCE ?{? ? ? ? tbsCertificate ? ? ? TBSCertificate,? ? ? ? signatureAlgorithm ? AlgorithmIdentifier,? ? ? ? signatureValue ? ? ? BIT STRING ?} What you produced with ? openssl rsautl -sign?? is the content of the ??signatureValue?? element (not its BIT STRING structure, only the inner content).What is missing is all the rest, and it can?t be produced by the sole ??openssl x509 ??? command. Please refine your question. Cordialement,Erwann Abalea Le 22 juil. 2015 ? 11:17, Anirudh Raghunath a ?crit : Hello, I have used rsault -sign option to sign a text file which gives me a binary file. I would like to convert this to X509 so that I can use it in a ssl handshake. I understand the command: openssl x509 -inform -in -out ? is used. I want to know what the parameters would be for a binary input file. Thanks in advance.?_______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jul 22 10:08:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 12:08:55 +0200 Subject: [openssl-users] Size of OpenSSL ECDSA/DSA Implementation In-Reply-To: <55AEA67B.4060904@gmx.at> References: <55AEA67B.4060904@gmx.at> Message-ID: <55AF6BB7.8010706@wisemo.com> On 21/07/2015 22:07, Michaela Schoenbauer wrote: > Hi, > > I'm currently working on my Master thesis, and the topic is about > ECDSA implementations and DSA implementations in the context of small > embedded systems. > > I'd like to try out OpenSSL but I'm not sure if I can configure it to > be small enough for the embedded devices I use. > For my purpose a custom built of the library should exclude all > SSL/TLS functionality and only include (a) ECDSA support and (b) DSA > support in another built. > > Does anyone know how small I can make the OpenSSL library? May the > results be smaller than 10KB or which results can I expect? > > If anyone already tried something similar or has some answers/hints I > would be thankful. Unfortunately, since the introduction (many years ago) of the EVP interface abstraction, it has gotten a lot harder to link libcrypto (the non-SSL part of OpenSSL) with just a few algorithms and little else. Best chance is to: 1. Use OpenSSL 1.0.2, not the future 1.1.0 which has removed some of what you need for this. 2. Build OpenSSL as "static" libraries, not as "shared libraries"/DLLs. 3. Use the "raw" ecdsa/dsa functions from ecdsa.h/dsa.h 4. Write your test program to only do the signing OR verification, not the key generation or other functions. 5. Write your test program to operate directly on the internal structures so you don't need the code space for the i2d/d2i conversion functions. 6. Use linker diagnostics and/or object dumper programs to see which functions and source files get linked into your embedded binary. 7. Look at the actual implementation code in the OpenSSL source code to see if there is even more that can be trimmed out, e.g. by splitting some source files that contain multiple functions so one file contains the functions you use, and another file ther other. 8. Look at the actual ecdsa/dsa implementation code to see if it invokes the RNG for each signature or uses a cryptographic formula to deterministically generate a message/key dependent adversary unknowable per-signature key. This makes a big size difference because the RNG itself needs so much non-dsa code. 9. For ecdsa, look at the implementation code to see if it branches into different implementations depending on the curve used for the public/private key pair. If so, create a special version supporting only the curve you use for your test. With all this, you might be able to get a code size a lot smaller than what you would get by just following the official guides on how to do the same operation with supported high level functions. But I am not at all sure if you can still get as low as you need. A completely different approach is to just cut and paste snippets from the OpenSSL ecdsa/dsa code and hand optimize it for minimum size. As another datapoint for your investigation, the ECDSA-like signature scheme recently promoted by D.J.Bernstein apparently hand optimized assembler code, yet I seem to recall it being larger than 10Kio code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitus at wagner.pp.ru Wed Jul 22 10:08:12 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Wed, 22 Jul 2015 13:08:12 +0300 Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <876140824.268488.1437556663757.JavaMail.yahoo@mail.yahoo.com> References: <876140824.268488.1437556663757.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150722130812.1e8c9f37@arkturus.local> On Wed, 22 Jul 2015 09:17:43 +0000 (UTC) Anirudh Raghunath wrote: > Hello, > I have used rsault -sign option to sign a text file which gives me a > binary file. I would like to convert this to X509 so that I can use > it in a ssl handshake. I understand the command: openssl x509 -inform > -in -out is used. I want to know what > the parameters would be for a binary input file. Thanks in advance.? Unfortunately signed text file and certificate are quite different things. Of course, certificate is signed electronic document. But it is document of special binary format, which contains public key and information about owner of corresponding private key. And typically, it is not signed by you, it is signed by Certificate Authority (known to server). When you use certificate (and corresponding private key) during SSL handshake, it means than server sends you something, you sign this something using your private key and send signature to server along with certificate. Server verifies signature under data, which it remembers it have been sent to you, using public key contained in the certificate, and says "Ok, this guy really owns private key corresponding to public key in this certificate". It also verifies signature under certificate using known beforehand and trusted CA certificates, to make sure that public key stored in the certificate really belongs to person mentioned in the certificate subject field. So, if you sign some text file using your certificate, this signature cannot be used in the SSL handshake any way. Because you've signed some text file, not a challenge send by server during SSL handshake. This signature proves that you, owner of private key, have had access to this text file (provided your private key is not compromised), but there is no way to use this signature to prove that your are one, who established connection with server. To prove so, you have to sign something send to your from server, not some data, known beforehand. Really, option -sign of this utility may produce some signed document format such as PKCS#7 or CMS, which contains signer's certificate. For same purpose which I've described above. If someone wants to verify if you've signed this file, one should have your certificate, with public key and your name in it. Simplest way to ensure this is to attach certificate to the signed message. Then recipient of message can validate certificate, extracted from message with known and trusted CA and then use it to verify signature under message. If you want use such a curved way to extract certificate from card, it is possbile, provided that your rsautl produces standard signed message format, i.e PKCS#7 may be openssl pkcs7 -inform der -in signedfile.bin -print_certs would do the trick and write certificate of one who signed the file into filename.pem But this is not called "convert signed file to X509 format", it is called "extract X509 certificate from signed file". From jb-openssl at wisemo.com Wed Jul 22 10:19:46 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 12:19:46 +0200 Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <1937901886.290059.1437559036881.JavaMail.yahoo@mail.yahoo.com> References: <3B84C119-B7F1-4FC7-A9CB-F798A7A4891A@opentrust.com> <1937901886.290059.1437559036881.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55AF6E42.3080605@wisemo.com> (top posting for consistency) Look at the functions named X509_sign(), X509_CRL_sign() and X509_REQ_to_X509(), those should get you started. On 22/07/2015 11:57, Anirudh Raghunath wrote: > Thanks for the quick response. I am currently working with smart cards > and am using the engine provided by openSC to access the private key > in the smart card. Long story short I have the EVP_PKEY object with > me. Can I use this to sign a certificate or some file which can be > used for SSL client verification. > > On Wednesday, 22 July 2015 11:52 AM, Erwann Abalea > wrote: > > > Bonjour, > > An X.509 certificate is: > > Certificate ::= SEQUENCE { > tbsCertificate TBSCertificate, > signatureAlgorithm AlgorithmIdentifier, > signatureValue BIT STRING } > > What you produced with ? openssl rsautl -sign ? is the content of the > ? signatureValue ? element (not its BIT STRING structure, only the > inner content). > What is missing is all the rest, and it can?t be produced by the sole > ? openssl x509 ? ? command. > > Please refine your question. > > >> Le 22 juil. 2015 ? 11:17, Anirudh Raghunath >> > > a ?crit : >> >> Hello, >> >> I have used rsault -sign option to sign a text file which gives me a >> binary file. I would like to convert this to X509 so that I can use >> it in a ssl handshake. I understand the command: >> >> openssl x509 -inform -in -out >> >> is used. I want to know what the parameters would be for a binary >> input file. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank.thater at tscons.de Wed Jul 22 10:24:33 2015 From: frank.thater at tscons.de (Frank Thater) Date: Wed, 22 Jul 2015 12:24:33 +0200 Subject: [openssl-users] Regarding the security of the keys In-Reply-To: References: Message-ID: <55AF6F61.40601@tscons.de> Hi, I my opinion the only way to securely handle your keys is the usage of some kind of Hardware Security Module, e.g. www.smartcard-hsm.com www.yubico.com These lightweight HSMs provide a PKCS#11 interface which can be integrated using the PKCS#11 engine of OpenSSL. In addition the SmartCard-HSM supports key replication to build some kind of load-balancing cluster where all HSMs share the same key. Depending on the load of the server these "small" HSMs might be suitable. Otherwise you should spent some money for a complete and full HSM solution. Regards, Frank Am 21.07.2015 um 09:53 schrieb Mike Mohr: > Securing a system against this kind of attack can be done in several > ways, depending on the level of assurance you desire. You might start > out with Tripwire: > > https://en.wikipedia.org/wiki/Open_Source_Tripwire > http://www.tripwire.org/ > > You could also implement mandatory access control and ACLs using either > grsecurity or SELinux: > > http://grsecurity.net/ > http://www.cs.virginia.edu/~jcg8f/SELinux%20grsecurity%20paper.pdf > https://en.wikipedia.org/wiki/Security-Enhanced_Linux > > Personally I prefer grsecurity, but it is not supported in mainline by > any major distribution that I am aware of. You'll have to patch, build, > and and support your own kernel image in order to use it. SELinux is > supported out of the box on CentOS 6 and 7, so it would probably be a > good place to start. > > If your concern is solely in the realm of protecting your RSA keys, you > might consider some HSM product from e.g. Yubico: > > https://www.yubico.com/ > https://en.wikipedia.org/wiki/Hardware_security_module > > These tiny USB keys store the RSA keys on a secure element which is > physically tamper-resistant. The key material never leaves the hardware > token. However, you'd probably have to write a custom provider for > OpenSSL, and the throughput would probably only be sufficient for a very > small amount of traffic. If you need something that can handle a higher > load, you might consider purchasing one of Cavium's cards: > > http://www.cavium.com/overview.html > > However, they are 10 gigabit passthrough devices and will unwrap / > re-wrap the SSL session in hardware. They are not cheap. > > Good luck! > > > On Mon, Jul 20, 2015 at 11:46 PM, James > wrote: > > Hi there, > I have a concern regarding the private keys we use in the https (say > apache) server. > The https server links with openssl.so file, and uses the APIs > provided by it. > If some one build their own openssl and add few lines to print the > keys during encrypt and decrypt and put in the library in the > LD_LIBRARY_PATH, may result in compromising the security of the keys. > > Does any of you faced this problem and if you could share the > solution it would be helpful. > > regards, > James Arivazhagan Ponnusamy > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Thater & Schwier Consulting GbR Frank Thater M.Sc. in Applied IT Security, Dipl.-Wirt.-Inf. Sch?lerweg 38 32429 Minden, Germany Phone +49 160 6316655 http://www.tscons.de Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From erwann.abalea at opentrust.com Wed Jul 22 10:24:49 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 22 Jul 2015 12:24:49 +0200 Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <1937901886.290059.1437559036881.JavaMail.yahoo@mail.yahoo.com> References: <3B84C119-B7F1-4FC7-A9CB-F798A7A4891A@opentrust.com> <1937901886.290059.1437559036881.JavaMail.yahoo@mail.yahoo.com> Message-ID: Long response short, yes, you can. Prepare and fill in your X509 object, perform the signature with your EVP_PKEY private key, format the resulting signature into a BIT STRING, place this BIT STRING into your previous X509 object, complete it with the AlgorithmIdentifier you choose when signing (it should already have been set in the TBSCertificate structure, just copy it from there). The resulting X.509 certificate can be used for anything and is not limited for a SSL client verification usage. In the previous paragraph, I assume your smart card contains the CA private key, and you want to sign certificates (either subCA or subscriber, it doesn?t matter). That?s how I understood your question. If you want to do all this using only openssl CLI, that?s doable with a specially crafted config file declaring your engine and its parameters. Cordialement, Erwann Abalea > Le 22 juil. 2015 ? 11:57, Anirudh Raghunath a ?crit : > > Thanks for the quick response. I am currently working with smart cards and am using the engine provided by openSC to access the private key in the smart card. Long story short I have the EVP_PKEY object with me. Can I use this to sign a certificate or some file which can be used for SSL client verification. > > Merci > > > > On Wednesday, 22 July 2015 11:52 AM, Erwann Abalea wrote: > > > Bonjour, > > An X.509 certificate is: > > Certificate ::= SEQUENCE { > tbsCertificate TBSCertificate, > signatureAlgorithm AlgorithmIdentifier, > signatureValue BIT STRING } > > What you produced with ? openssl rsautl -sign ? is the content of the ? signatureValue ? element (not its BIT STRING structure, only the inner content). > What is missing is all the rest, and it can?t be produced by the sole ? openssl x509 ? ? command. > > Please refine your question. > > Cordialement, > Erwann Abalea > > > >> Le 22 juil. 2015 ? 11:17, Anirudh Raghunath > a ?crit : >> >> Hello, >> >> I have used rsault -sign option to sign a text file which gives me a binary file. I would like to convert this to X509 so that I can use it in a ssl handshake. I understand the command: >> >> openssl x509 -inform -in -out >> >> is used. I want to know what the parameters would be for a binary input file. >> >> Thanks in advance. >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jul 22 10:29:28 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 12:29:28 +0200 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <55AEA648.1060700@openssl.org> <55AECBF8.9070105@openssl.org> Message-ID: <55AF7088.60809@wisemo.com> On 22/07/2015 01:27, Jeffrey Walton wrote: >>> Like I said, its learning to play well with your tools :) >> Well I think what your saying is that we should play well with other >> people's tools! My tools (and presumably the rest of the dev team's as >> well) don't report this warning. > Ah, OK. So its being reported in GCC 5.1 via -Wmaybe-unitialized (I > suspect). That may point to an issue in OpenSSL's engineering process. > There may be a gap because no one is running, say Fedora 22 or Debian > 8 (I think Debian 8 provides GCC 5.1). F.Y.I. Debian 8 (Jessie) uses GCC 4.9.2 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 From anirudhraghunath at rocketmail.com Wed Jul 22 10:32:02 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 10:32:02 +0000 (UTC) Subject: [openssl-users] Converting Bin format to X509 format In-Reply-To: <20150722130812.1e8c9f37@arkturus.local> References: <20150722130812.1e8c9f37@arkturus.local> Message-ID: <528906286.314939.1437561122687.JavaMail.yahoo@mail.yahoo.com> Thank you for the extremely elaborate answer. Now I understand the big picture. I want to attach a file from the server side which can be collected in the client program(the test) and I want to sign it and send it back. I have the ssl server client connection ready through socket and ssl code. I want to know if there is a function to load the random file to the SSL_CTX object the way we do with certificates. Thanks anyways for taking the time to answer my trivial doubts :). On Wednesday, 22 July 2015 12:12 PM, Victor Wagner wrote: On Wed, 22 Jul 2015 09:17:43 +0000 (UTC) Anirudh Raghunath wrote: > Hello, > I have used rsault -sign option to sign a text file which gives me a > binary file. I would like to convert this to X509 so that I can use > it in a ssl handshake. I understand the command: openssl x509 -inform > -in -out is used. I want to know what > the parameters would be for a binary input file. Thanks in advance.? Unfortunately signed text file and certificate are quite different things. Of course, certificate is signed electronic document. But it is document of special binary format, which contains public key and information about owner of corresponding private key. And typically, it is not signed by you, it is signed by Certificate Authority (known to server). When you use certificate (and corresponding private key) during SSL handshake, it means than server sends you something, you sign this something using your private key and send signature to server along with certificate. Server verifies signature under data, which it remembers it have been sent to you, using public key contained in the certificate, and says "Ok, this guy really owns private key corresponding to public key in this certificate". It also verifies signature under certificate using known beforehand and trusted CA certificates, to make sure that? public key stored in the certificate really belongs to person mentioned in the certificate subject field. So, if you sign some text file using your certificate, this signature cannot be used in the SSL handshake any way. Because you've signed some text file, not a challenge send by server during SSL handshake. This signature proves that you, owner of private key, have had access to this text file (provided your private key is not compromised), but there is no way to use this signature to prove that your are one, who established connection with server. To prove so, you have to sign something send to your from server, not some data, known beforehand. Really, option -sign of this utility may produce some signed document format such as PKCS#7 or CMS, which contains signer's certificate. For same purpose which I've described above. If someone wants to verify if you've signed this file, one should have your certificate, with public key and your name in it. Simplest way to ensure this is to attach certificate to the signed message. Then recipient of message can validate certificate, extracted from message with known and trusted CA and then use it to verify signature under message. If you want use such a curved way to extract certificate from card, it is possbile, provided that your? rsautl produces standard signed message format, i.e PKCS#7 may be openssl pkcs7 -inform der -in signedfile.bin -print_certs would do the trick and write certificate of one who signed the file into filename.pem But this is not called "convert signed file to X509 format", it is called "extract X509 certificate from signed file". _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jul 22 10:40:49 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 12:40:49 +0200 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55AF7331.8000601@wisemo.com> On 22/07/2015 01:21, Jeffrey Walton wrote: >>> For the stragglers, I don't think its a stretch to ask C99 in 2015. >> Visual Studio is often used on Windows, and it is not C99. >> > Oh my, I was not aware it was still struggling for C99 :) I guess > Microsoft is still putting their energies into the "one-size, tablet > interface known as Windows 8, fits all, even on desktops without a > touchscreen". > > On the good side, MSVC does not need to be 100% compliant. It just > needs to support initialization at time of declaration. That > particular feature works. Isn't that a C89 (or maybe even K&R) feature? There is another problem though: Blindly initializing every variable with dummy values (because the correct value comes from one or more if() branches), only achieves two things, both bad: - It hides correct warnings in case one of those if() branches forgets to set the variable, before it is read. - It potentially confuses less-than-halting-problem- solving optimizers to needlessly generate code that allocates and initializes the variable because they cannot detect (within their compile time resource limits) that the dummy value is (hopefully) never used. The second problem is almost guaranteed to happen on any compiler/option combination that would otherwise falsely warn about the variable being maybe- uninitialized. This is because most compilers generate that warning as a side effect of the optimizer trying to figure out if the garbage or dummy value will be used by the code. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Wed Jul 22 11:14:50 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 22 Jul 2015 07:14:50 -0400 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: <55AF7331.8000601@wisemo.com> References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> <55AF7331.8000601@wisemo.com> Message-ID: On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm wrote: > On 22/07/2015 01:21, Jeffrey Walton wrote: > > For the stragglers, I don't think its a stretch to ask C99 in 2015. > > Visual Studio is often used on Windows, and it is not C99. > > Oh my, I was not aware it was still struggling for C99 :) I guess > Microsoft is still putting their energies into the "one-size, tablet > interface known as Windows 8, fits all, even on desktops without a > touchscreen". > > On the good side, MSVC does not need to be 100% compliant. It just > needs to support initialization at time of declaration. That > particular feature works. > > Isn't that a C89 (or maybe even K&R) feature? I thought that was C99. I think Ben Laurie even corrected me with some OpenSSL sample code because I initialized a variable without using -std=c99. > There is another problem though: Blindly initializing > every variable with dummy values (because the correct > value comes from one or more if() branches), only > achieves two things, both bad: > > - It hides correct warnings in case one of those if() > branches forgets to set the variable, before it is > read. > > - It potentially confuses less-than-halting-problem- > solving optimizers to needlessly generate code that > allocates and initializes the variable because they > cannot detect (within their compile time resource > limits) that the dummy value is (hopefully) never > used. > > The second problem is almost guaranteed to happen on > any compiler/option combination that would otherwise > falsely warn about the variable being maybe- > uninitialized. This is because most compilers > generate that warning as a side effect of the > optimizer trying to figure out if the garbage or > dummy value will be used by the code. > What, exactly is the problem? The program is in a known state. As far as I know, that's the best state to be in. And that's why managed languages like Java and .Net are so popular. When a variable is declared, it gets placed in a known state immediately. It relieves the programmer of remembering pesky details like, "remember to initialize your variables to a known state". Jeff From anirudhraghunath at rocketmail.com Wed Jul 22 11:22:41 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 11:22:41 +0000 (UTC) Subject: [openssl-users] Sending files in SSL communication Message-ID: <961278385.330763.1437564161206.JavaMail.yahoo@mail.yahoo.com> Hello all, I have a ssl server client connection set up which I have written in C using sockets and openssl. I understand that I can attach a certificate of the server and send it to the client by attaching it to the SSL_CTX object. I used the SSL_CTX_use_certificate_file to do so. Now I can retrieve that certificate by using SSL_get_peer_certificate function on the client side. I also want to send a test( say a text file) from the server to the client for the client to sign it and send it back. What function do I use to do so? Is it similar to the way we attach certificates to the SSL_CTX? And how do I retrieve it on the client side?Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 22 11:27:29 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Jul 2015 11:27:29 +0000 Subject: [openssl-users] Sending files in SSL communication In-Reply-To: <961278385.330763.1437564161206.JavaMail.yahoo@mail.yahoo.com> References: <961278385.330763.1437564161206.JavaMail.yahoo@mail.yahoo.com> Message-ID: What you want is application-specific, not part of the TLS protocol. So you have to use SSL_read/SSL_write and pull the data out as needed. From anirudhraghunath at rocketmail.com Wed Jul 22 11:29:21 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 11:29:21 +0000 (UTC) Subject: [openssl-users] Sending files in SSL communication In-Reply-To: References: Message-ID: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> But is there a way to send text files through SSL_write()? If so, can you please give a small example? Thanks. On Wednesday, 22 July 2015 1:27 PM, "Salz, Rich" wrote: What you want is application-specific, not part of the TLS protocol.? So you have to use SSL_read/SSL_write and pull the data out as needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 22 11:30:32 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Jul 2015 11:30:32 +0000 Subject: [openssl-users] Sending files in SSL communication In-Reply-To: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> References: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> Message-ID: > But is there a way to send text files through SSL_write()? No. From anirudhraghunath at rocketmail.com Wed Jul 22 11:33:45 2015 From: anirudhraghunath at rocketmail.com (Anirudh Raghunath) Date: Wed, 22 Jul 2015 11:33:45 +0000 (UTC) Subject: [openssl-users] Sending files in SSL communication In-Reply-To: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> References: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> Message-ID: <964543949.335353.1437564825472.JavaMail.yahoo@mail.yahoo.com> But there is a way in which the server sends a test( for example a random number) and the client signs it with his private key right? On Wednesday, 22 July 2015 1:30 PM, Anirudh Raghunath wrote: But is there a way to send text files through SSL_write()? If so, can you please give a small example? Thanks. On Wednesday, 22 July 2015 1:27 PM, "Salz, Rich" wrote: What you want is application-specific, not part of the TLS protocol.? So you have to use SSL_read/SSL_write and pull the data out as needed. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jul 22 11:35:43 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 22 Jul 2015 11:35:43 +0000 Subject: [openssl-users] Sending files in SSL communication In-Reply-To: <964543949.335353.1437564825472.JavaMail.yahoo@mail.yahoo.com> References: <1359572702.335790.1437564561639.JavaMail.yahoo@mail.yahoo.com> <964543949.335353.1437564825472.JavaMail.yahoo@mail.yahoo.com> Message-ID: <179df4fb825c485b975c385cfa6ad618@ustx2ex-dag1mb2.msg.corp.akamai.com> > But there is a way in which the server sends a test( for example a random number) and the client signs it with his private key right? It's called mutual (or client-side) authentication and is part of the TLS protocol. The client must have an X.509-style certificate. From jonetsu at teksavvy.com Wed Jul 22 12:12:24 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 22 Jul 2015 08:12:24 -0400 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS Message-ID: Hello, Our Nessus version ?6.4.1 is detecting a BEAST vulnerability against OpenSSL?1.0.1e. ?The source code defines?SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS as 0x00000800L and several tests are made for this value in the code. ?The CHANGES mentions though that this had some side effects, the option now being part of SSL_OP_ALL. ?It would look like, from the scan, that the fragments are not enabled by default, could it be ? Thanks. From foleyj at cisco.com Wed Jul 22 12:47:18 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 22 Jul 2015 08:47:18 -0400 Subject: [openssl-users] Extended key usage keyAgreement bit in certificate In-Reply-To: <55AE5C28.1080004@cisco.com> References: <55AE5C28.1080004@cisco.com> Message-ID: <55AF90D6.1050903@cisco.com> The following commit changed the behavior of checking the extended key usage bits in a server certificate when using X509_PURPOSE_SSL_SERVER: http://marc.info/?l=openssl-cvs&m=132759007026375&w=2 This commit was put into 1.0.2 on April 6, 2012. Therefore, 1.0.1 and 1.0.2 behave differently in this regard. When using 1.0.2, the server certificate needs to include the keyAgreement bit. Otherwise the client will reject the server certificate when checking the purpose (X509_PURPOSE_SSL_SERVER). Does this behavior in 1.0.2 comply with RFC 5246? Reading section 7.4.2 on pages 47/48, the server certificate should include the keyAgreement bit when using DH key exchange cipher suites. The wording on page 48 is: DH_DSS Diffie-Hellman public key; the keyAgreement bit DH_RSA MUST be set if the key usage extension is present. Given there's no other mention of using the keyAgreement bit in RFC 5246, does this imply the keyAgreement bit doesn't need to be set when not using a DH cipher suite? Given the commit noted above will always check the keyAgreement bit, and the logic in v3_purp.c is unaware of the negotiated cipher suite, would this be considered a bug? If not, would it be appropriate to back-port this commit to 1.0.1 so that we would have consistent behavior between 1.0.1 and 1.0.2? From jb-openssl at wisemo.com Wed Jul 22 13:27:56 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 15:27:56 +0200 Subject: [openssl-users] Warnings Compiling openssl 1.0.2d In-Reply-To: References: <20150709152236.GG21534@mournblade.imrryr.org> <20150709170010.GA28047@mournblade.imrryr.org> <55AE9A70.6080405@openssl.org> <65b986e367194314bd28356c834df3ed@ustx2ex-dag1mb2.msg.corp.akamai.com> <55AF7331.8000601@wisemo.com> Message-ID: <55AF9A5C.4080705@wisemo.com> On 22/07/2015 13:14, Jeffrey Walton wrote: > On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm wrote: >> On 22/07/2015 01:21, Jeffrey Walton wrote: >> >> For the stragglers, I don't think its a stretch to ask C99 in 2015. >> >> Visual Studio is often used on Windows, and it is not C99. >> >> Oh my, I was not aware it was still struggling for C99 :) I guess >> Microsoft is still putting their energies into the "one-size, tablet >> interface known as Windows 8, fits all, even on desktops without a >> touchscreen". >> >> On the good side, MSVC does not need to be 100% compliant. It just >> needs to support initialization at time of declaration. That >> particular feature works. >> >> Isn't that a C89 (or maybe even K&R) feature? > I thought that was C99. I think Ben Laurie even corrected me with some > OpenSSL sample code because I initialized a variable without using > -std=c99. There is a C99 feature backported from C++: Allow declarations after/between statements, thus allowing unconditional initialization formulas to be used even if code is needed before them. E.g. int foo61(void) { int a = 1; int b = 5; do { a *= b; } while (--b); int c = a / 2; // C99/C++ only return c + 1; } >> There is another problem though: Blindly initializing >> every variable with dummy values (because the correct >> value comes from one or more if() branches), only >> achieves two things, both bad: >> >> - It hides correct warnings in case one of those if() >> branches forgets to set the variable, before it is >> read. >> >> - It potentially confuses less-than-halting-problem- >> solving optimizers to needlessly generate code that >> allocates and initializes the variable because they >> cannot detect (within their compile time resource >> limits) that the dummy value is (hopefully) never >> used. >> >> The second problem is almost guaranteed to happen on >> any compiler/option combination that would otherwise >> falsely warn about the variable being maybe- >> uninitialized. This is because most compilers >> generate that warning as a side effect of the >> optimizer trying to figure out if the garbage or >> dummy value will be used by the code. >> > What, exactly is the problem? The program is in a known state. As far > as I know, that's the best state to be in. In the first case, the program is in a wrong state, and no tool will tell you about it. Silently producing a wrong result is quite unpleasant. In the second case we have inefficient code. And if the compiler *can* detect the situation correctly, and the code *is* correct without the extra initialization, the compiler is likely to emit a warning that variable is assigned a value which is never used. So if the goal is to avoid warnings, you can't win anyway. If as in the case under discussion, the value is set and used only under a (common) condition, one may consider a structural change so the condition is checked only once, then move the variable inside that conditional block. On pipelined processors, this may even result in faster code, though it will be larger, this however depends on a closer analysis of the particular code. > > And that's why managed languages like Java and .Net are so popular. > When a variable is declared, it gets placed in a known state > immediately. It relieves the programmer of remembering pesky details > like, "remember to initialize your variables to a known state". But it also makes it harder to auto-detect bugs where a variable is left in that default state when it should have been in a different state. In fact for languages without implicit initialization, there are often debug tools that can set the variables to a known impossible value and report if those values are ever used. Typical choices include 0xBAADF00D (where 32 bit pointers are restricted to the range 0x00001000 to 0x7fffFFFF) etc. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jul 22 13:35:06 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 22 Jul 2015 15:35:06 +0200 Subject: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS In-Reply-To: References: Message-ID: <55AF9C0A.2070901@wisemo.com> On 22/07/2015 14:12, jonetsu wrote: > Hello, > > > Our Nessus version 6.4.1 is detecting a BEAST vulnerability against OpenSSL 1.0.1e. The source code defines SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS as 0x00000800L and several tests are made for this value in the code. The CHANGES mentions though that this had some side effects, the option now being part of SSL_OP_ALL. It would look like, from the scan, that the fragments are not enabled by default, could it be ? Yep, for some silly reason, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS was/is included in the default value SSL_OP_ALL. This is in the same header as SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. The proper solution, as just about everybody knows by now would have been to insert 1-byte fragments (known as the 1/n-1 solution) which some other SSL/TLS implementations do. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From soul.great at me.com Thu Jul 23 08:47:39 2015 From: soul.great at me.com (Song Geng) Date: Thu, 23 Jul 2015 16:47:39 +0800 Subject: [openssl-users] compile error Message-ID: Hi guys, I am a novice about openssl. I encounter linker error when I try to compile evp demos which locate openssl/demos/evp. My computer info is: Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 And I use both gcc and clang with command ?cc -g -Wall -I../../include -lcrypto aesgcm.c" to compile the source code. The error info shows: Undefined symbols for architecture x86_64: "_EVP_aes_256_gcm", referenced from: _aes_gcm_encrypt in aesgcm-093314.o _aes_gcm_decrypt in aesgcm-093314.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Please help me. I will be very appreciate. Br, Great Soul soul.great at me.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Jul 23 14:44:50 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 23 Jul 2015 16:44:50 +0200 Subject: [openssl-users] compile error In-Reply-To: References: Message-ID: <55B0FDE2.2090609@wisemo.com> On 23/07/2015 10:47, Song Geng wrote: > Hi guys, > > I am a novice about openssl. I encounter linker error when I try to > compile evp demos which locate openssl/demos/evp. > > My computer info is: > Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015; > root:xnu-2782.30.5~1/RELEASE_X86_64 > > And I use both gcc and clang with command ?cc -g -Wall -I../../include > -lcrypto aesgcm.c" to compile the source code. > > The error info shows: > Undefined symbols for architecture x86_64: > "_EVP_aes_256_gcm", referenced from: > _aes_gcm_encrypt in aesgcm-093314.o > _aes_gcm_decrypt in aesgcm-093314.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > Please help me. I will be very appreciate. > Try adding a compiler option to also take libraries from the local copy of OpenSSL (I assume you did build OpenSSL itself first). Without such an option, you might be accidentally linking against a too old libcrypto from Apple. 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 From wangqun at alumni.nus.edu.sg Fri Jul 24 01:29:32 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Thu, 23 Jul 2015 18:29:32 -0700 (MST) Subject: [openssl-users] Can OpenSSL applications/utilities use SunSPARC crypto accelerators? In-Reply-To: <1437460644422-59218.post@n7.nabble.com> References: <1436930032695-59163.post@n7.nabble.com> <1437011006381-59179.post@n7.nabble.com> <55A7C1A8.9070807@oracle.com> <1437355488123-59198.post@n7.nabble.com> <1437460644422-59218.post@n7.nabble.com> Message-ID: <1437701372103-59351.post@n7.nabble.com> Hello Andy and David, As the feature owners, would you please give me some tips for how to use the functionality of the feature? Thanks, Aaron The Changes between 1.0.1l and 1.0.2 [22 Jan 2015] ... *) Support for SPARC Architecture 2011 crypto extensions, first implemented in SPARC T4. This covers AES, DES, Camellia, SHA1, SHA256/512, MD5, GHASH and modular exponentiation. [Andy Polyakov, David Miller] ... -- View this message in context: http://openssl.6102.n7.nabble.com/Can-OpenSSL-applications-utilities-use-SunSPARC-crypto-accelerators-tp59163p59351.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From andrewcarp at gmail.com Fri Jul 24 12:32:06 2015 From: andrewcarp at gmail.com (Andrew Carpenter) Date: Fri, 24 Jul 2015 08:32:06 -0400 Subject: [openssl-users] Verifying a signature - format problems Message-ID: Hello, I am trying to verify a signature using EVP_digestVerifyInit/Update/Final, and I keep getting the errors ASN1_get_object:too long or ASN1_CHEKC_TLEN: Bad Object Header or Wrong Tag, and finally ASN1_ITEM_EX_D2I: Nested asn1 error. I believe that these errors indicate that the formatting on my signature is incorrect. So my question is: What format should the signature file be in? base64? DER? PKCS7? raw binary? Specifically I am talking about the function EVP_DigestVerifyFinal(), What format should the *sig parameter be in? The DiestVerifyInit and DigestVerifyUpdate are working with no errors, so I have narrowed it down to this function. Thanks, -- Andrew Carpenter, -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Fri Jul 24 15:55:46 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 24 Jul 2015 16:55:46 +0100 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: On 24 July 2015 at 13:32, Andrew Carpenter wrote: > So my question is: What format should the signature file be in? > base64? DER? PKCS7? raw binary? Specifically I am talking about the > function EVP_DigestVerifyFinal(), What format should the *sig parameter be > in? The DiestVerifyInit and DigestVerifyUpdate are working with no errors, > so I have narrowed it down to this function. > Thanks, > > ?You might find this change I've recently written for Qt useful: https://codereview.qt-project.org/#/c/113855/ It implements exactly this and has lots of test cases. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewcarp at gmail.com Fri Jul 24 18:30:57 2015 From: andrewcarp at gmail.com (Andrew Carpenter) Date: Fri, 24 Jul 2015 14:30:57 -0400 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: Well That's interesting. when I download and use your .sig file, I get the same errors. How do you go about picking up your signature form the file system? On Fri, Jul 24, 2015 at 11:55 AM, Richard Moore wrote: > > > On 24 July 2015 at 13:32, Andrew Carpenter wrote: > >> So my question is: What format should the signature file be in? >> base64? DER? PKCS7? raw binary? Specifically I am talking about the >> function EVP_DigestVerifyFinal(), What format should the *sig parameter be >> in? The DiestVerifyInit and DigestVerifyUpdate are working with no errors, >> so I have narrowed it down to this function. >> Thanks, >> >> > ?You might find this change I've recently written for Qt useful: > https://codereview.qt-project.org/#/c/113855/ > It implements exactly this and has lots of test cases. > > Cheers > > Rich. > ? > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Andrew Carpenter, -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Fri Jul 24 18:59:29 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 24 Jul 2015 19:59:29 +0100 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: On 24 July 2015 at 19:30, Andrew Carpenter wrote: > Well That's interesting. when I download and use your .sig file, I get > the same errors. How do you go about picking up your signature form the > file system? > > ?Nothing special: https://codereview.qt-project.org/#/c/113855/27/tests/auto/network/ssl/qssl/tst_qssl.cpp,unified around line 170 for example. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrewcarp at gmail.com Fri Jul 24 19:04:38 2015 From: andrewcarp at gmail.com (Andrew Carpenter) Date: Fri, 24 Jul 2015 15:04:38 -0400 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: Thanks so much for your response Richard. I appreciate your time. That's pretty much the same thing I'm doing.... On Fri, Jul 24, 2015 at 2:59 PM, Richard Moore wrote: > > > On 24 July 2015 at 19:30, Andrew Carpenter wrote: > >> Well That's interesting. when I download and use your .sig file, I get >> the same errors. How do you go about picking up your signature form the >> file system? >> >> > ?Nothing special: > https://codereview.qt-project.org/#/c/113855/27/tests/auto/network/ssl/qssl/tst_qssl.cpp,unified > around line 170 for example. > > Cheers > > Rich. > ? > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Andrew Carpenter, -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at openssl.org Sat Jul 25 19:45:21 2015 From: openssl-users at openssl.org (openssl-users at openssl.org) Date: Sat, 25 Jul 2015 19:45:21 +0000 (UTC) Subject: Não perca tempo, Aproveite! (371) Message-ID: <20150725194521.B9DC8217D3@idsuer646.idsuer646.b1.internal.cloudapp.net> An HTML attachment was scrubbed... URL: From wrightway4u at msn.com Sat Jul 25 19:52:00 2015 From: wrightway4u at msn.com (wrightway4u at msn.com) Date: Sat, 25 Jul 2015 12:52:00 -0700 Subject: [openssl-users] Vacation reply Message-ID: An HTML attachment was scrubbed... URL: From andrewcarp at gmail.com Mon Jul 27 16:30:41 2015 From: andrewcarp at gmail.com (Andrew Carpenter) Date: Mon, 27 Jul 2015 12:30:41 -0400 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: Thanks again Richard for your help. I found out that I was using std::string::append in my code, and that append stopped reading when it reached a NULL byte in the signature(which is a valid byte given the hash function) and that was truncating the signature. On Fri, Jul 24, 2015 at 3:04 PM, Andrew Carpenter wrote: > Thanks so much for your response Richard. I appreciate your time. That's > pretty much the same thing I'm doing.... > > On Fri, Jul 24, 2015 at 2:59 PM, Richard Moore > wrote: > >> >> >> On 24 July 2015 at 19:30, Andrew Carpenter wrote: >> >>> Well That's interesting. when I download and use your .sig file, I get >>> the same errors. How do you go about picking up your signature form the >>> file system? >>> >>> >> ?Nothing special: >> https://codereview.qt-project.org/#/c/113855/27/tests/auto/network/ssl/qssl/tst_qssl.cpp,unified >> around line 170 for example. >> >> Cheers >> >> Rich. >> ? >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > > > -- > Andrew Carpenter, > -- Andrew Carpenter, -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavneetjauhal at gmail.com Mon Jul 27 19:50:11 2015 From: pavneetjauhal at gmail.com (Pavneet Jauhal) Date: Mon, 27 Jul 2015 15:50:11 -0400 Subject: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d Message-ID: Hi All, When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an unexpected failure. Error looks something like this; openssl-1.0.2d/VMS/VMSify-conf.pl openssl-1.0.2d/VMS/WISHLIST.TXT tar: A lone zero block at 52140 I only see this with GNU tar. Regards, Pav Jauhal -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jul 27 21:21:07 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Jul 2015 22:21:07 +0100 Subject: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d In-Reply-To: References: Message-ID: <55B6A0C3.7080800@openssl.org> On 27/07/15 20:50, Pavneet Jauhal wrote: > Hi All, > > When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an unexpected > failure. Error looks something like this; > > openssl-1.0.2d/VMS/VMSify-conf.pl > openssl-1.0.2d/VMS/WISHLIST.TXT > tar: A lone zero block at 52140 > > I only see this with GNU tar. GNU tar is stricter than other tar programs. It expects to see a double zero block at the end of the tar file, and in this case there is only one. This is caused by a bug in a program called tardy which we use during the release process to clean up our tar files. Due to this problem we have now dropped its use so (hopefully) this shouldn't happen again. The error message is actually only a warning. The tar file should have still extracted successfully. It is safe to ignore this. Matt From richmoore44 at gmail.com Mon Jul 27 22:01:21 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 27 Jul 2015 23:01:21 +0100 Subject: [openssl-users] Verifying a signature - format problems In-Reply-To: References: Message-ID: On 27 July 2015 at 17:30, Andrew Carpenter wrote: > Thanks again Richard for your help. I found out that I was using > std::string::append in my code, and that append stopped reading when it > reached a NULL byte in the signature(which is a valid byte given the hash > function) and that was truncating the signature. > > ?Glad you got it sorted. Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsteck at symsysresearch.com Wed Jul 29 00:54:08 2015 From: rsteck at symsysresearch.com (Randy Steck) Date: Tue, 28 Jul 2015 20:54:08 -0400 Subject: [openssl-users] RSA key generation in FIPS mode Message-ID: <1a04c3c8c9b7ef3ec757ae32e6462920@symsysresearch.com> I posted this to openssl-dev, but didn't get a reply. Perhaps it's more appropriate here. In the FIPS Security Policy there are listed two functions for generating RSA keys: FIPS_rsa_generate_key_ex() (renamed from RSA_generate_key_ex()) and FIPS_rsa_x931_generate_key_ex() (renamed from RSA_X931_generate_key_ex()) The later is a complete implementation, according to X9.31, and an approved method in FIPS 186-2. The former is a wrapper function for either a custom keygen contained in the RSA struct, or the static "rsa_builtin_keygen". This builtin function does not conform to X9.31 (and therefor is not acceptable under 186-2). In testing, it appears when running in FIPS mode and calling the wrapper function, the non-approved builtin function is the one that is called. The default RSA struct creation function, defined in "fips/fips_rsa_lib.c:FIPS_rsa_new()" sets a mechanism parameter ("RSA_PKCS1_SSLeay()") that doesn't specify any key construction method (see cryupto/rsa/rsa_eay.c). Without this specified in the struct, the default (builtin; non-approved) method is used. Thus, it appears that there is a function in the FIPS API that allows for the creation of RSA keys in a non-approved manner. Am I missing something? Is this by design, or is it a bug? Assuming I was to remediate this for one of my clients (hardware validation), the wrapper function within the canister should replace the call to the builtin function with a call to the RSA_X931_generate_key_ex() function, and/or the struct creation function should explicitly set the rsa_keygen method. Correct? Thanks, Randy From steve at openssl.org Wed Jul 29 14:59:15 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 29 Jul 2015 14:59:15 +0000 Subject: [openssl-users] RSA key generation in FIPS mode In-Reply-To: <1a04c3c8c9b7ef3ec757ae32e6462920@symsysresearch.com> References: <1a04c3c8c9b7ef3ec757ae32e6462920@symsysresearch.com> Message-ID: <20150729145915.GA27873@openssl.org> On Tue, Jul 28, 2015, Randy Steck wrote: > Thus, it appears that there is a function in the FIPS API that allows > for the creation of RSA keys in a non-approved manner. > > Am I missing something? Is this by design, or is it a bug? > Yes you're right it uses the unapproved keygen algorithm by default. The FIPS capable OpenSSL does this too which I'd say this was a bug which should be fixed. > Assuming I was to remediate this for one of my clients (hardware > validation), > the wrapper function within the canister should replace the call to the > builtin function with a call to the RSA_X931_generate_key_ex() function, > and/or the struct creation function should explicitly set the rsa_keygen > method. Correct? > Well you don't have to modify the FIPS module at all. The FIPS capable OpenSSL can be modified to call FIPS_rsa_x931_generate_key_ex in FIPS mode. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From Michaela_Schoenbauer at gmx.at Fri Jul 31 09:00:50 2015 From: Michaela_Schoenbauer at gmx.at (Michaela Schoenbauer) Date: Fri, 31 Jul 2015 11:00:50 +0200 Subject: [openssl-users] Size of OpenSSL ECDSA/DSA Implementation In-Reply-To: <55AF6BB7.8010706@wisemo.com> References: <55AEA67B.4060904@gmx.at> <55AF6BB7.8010706@wisemo.com> Message-ID: <55BB3942.7070300@gmx.at> Am 22.07.2015 um 12:08 schrieb Jakob Bohm: > On 21/07/2015 22:07, Michaela Schoenbauer wrote: >> Hi, >> >> I'm currently working on my Master thesis, and the topic is about >> ECDSA implementations and DSA implementations in the context of small >> embedded systems. >> >> I'd like to try out OpenSSL but I'm not sure if I can configure it to >> be small enough for the embedded devices I use. >> For my purpose a custom built of the library should exclude all >> SSL/TLS functionality and only include (a) ECDSA support and (b) DSA >> support in another built. >> >> Does anyone know how small I can make the OpenSSL library? May the >> results be smaller than 10KB or which results can I expect? >> >> If anyone already tried something similar or has some answers/hints I >> would be thankful. > Unfortunately, since the introduction (many years ago) > of the EVP interface abstraction, it has gotten a lot > harder to link libcrypto (the non-SSL part of OpenSSL) > with just a few algorithms and little else. > > Best chance is to: > > 1. Use OpenSSL 1.0.2, not the future 1.1.0 which has > removed some of what you need for this. > > 2. Build OpenSSL as "static" libraries, not as "shared > libraries"/DLLs. > > 3. Use the "raw" ecdsa/dsa functions from ecdsa.h/dsa.h > > 4. Write your test program to only do the signing OR > verification, not the key generation or other > functions. > > 5. Write your test program to operate directly on the > internal structures so you don't need the code space > for the i2d/d2i conversion functions. > > 6. Use linker diagnostics and/or object dumper programs > to see which functions and source files get linked > into your embedded binary. > > 7. Look at the actual implementation code in the OpenSSL > source code to see if there is even more that can be > trimmed out, e.g. by splitting some source files that > contain multiple functions so one file contains the > functions you use, and another file ther other. > > 8. Look at the actual ecdsa/dsa implementation code to > see if it invokes the RNG for each signature or uses > a cryptographic formula to deterministically generate > a message/key dependent adversary unknowable > per-signature key. > This makes a big size difference because the RNG > itself needs so much non-dsa code. > > 9. For ecdsa, look at the implementation code to see > if it branches into different implementations > depending on the curve used for the public/private > key pair. If so, create a special version > supporting only the curve you use for your test. > > With all this, you might be able to get a code size a > lot smaller than what you would get by just following > the official guides on how to do the same operation > with supported high level functions. But I am not > at all sure if you can still get as low as you need. > > A completely different approach is to just cut and > paste snippets from the OpenSSL ecdsa/dsa code and > hand optimize it for minimum size. > > As another datapoint for your investigation, the > ECDSA-like signature scheme recently promoted by > D.J.Bernstein apparently hand optimized assembler > code, yet I seem to recall it being larger than > 10Kio code. > > > 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-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Thank you so much for your detailed answer and your help! I will try your tips. Michaela -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jul 31 14:37:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 31 Jul 2015 14:37:30 +0000 Subject: [openssl-users] We're working on license changes Message-ID: <70db214b09054cf1897cacf512a5f54d@ustx2ex-dag1mb2.msg.corp.akamai.com> Please see https://www.openssl.org/blog/blog/2015/08/01/cla/ for some more details. Summary: Moving to Apache 2, CLA's coming, it will take time. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mancha1 at zoho.com Fri Jul 31 18:12:53 2015 From: mancha1 at zoho.com (mancha) Date: Fri, 31 Jul 2015 18:12:53 +0000 Subject: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d In-Reply-To: <55B6A0C3.7080800@openssl.org> References: <55B6A0C3.7080800@openssl.org> Message-ID: <20150731181253.GA7416@zoho.com> On Mon, Jul 27, 2015 at 10:21:07PM +0100, Matt Caswell wrote: > > > On 27/07/15 20:50, Pavneet Jauhal wrote: > > Hi All, > > > > When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an unexpected > > failure. Error looks something like this; > > > > openssl-1.0.2d/VMS/VMSify-conf.pl openssl-1.0.2d/VMS/WISHLIST.TXT > > tar: A lone zero block at 52140 > > > > I only see this with GNU tar. > > GNU tar is stricter than other tar programs. It expects to see a > double zero block at the end of the tar file, and in this case there > is only one. > > This is caused by a bug in a program called tardy which we use during > the release process to clean up our tar files. Due to this problem we > have now dropped its use so (hopefully) this shouldn't happen again. > > The error message is actually only a warning. The tar file should have > still extracted successfully. It is safe to ignore this. Hi Matt. I took a look at tardy after reading your email. If the OpenSSL project would benefit from continued usage of tardy, you can re-build tardy 1.28 after applying my POSIX trailing zero-records fix [1]. Cheers. --mancha [1] http://sf.net/projects/mancha/files/misc/tardy-1.28_posix-eoa.diff -- https://twitter.com/mancha140 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matt at openssl.org Fri Jul 31 19:02:20 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 31 Jul 2015 20:02:20 +0100 Subject: [openssl-users] Unexpected error when I untar OpenSSL 1.0.2d In-Reply-To: <20150731181253.GA7416@zoho.com> References: <55B6A0C3.7080800@openssl.org> <20150731181253.GA7416@zoho.com> Message-ID: <55BBC63C.8050408@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/07/15 19:12, mancha wrote: > On Mon, Jul 27, 2015 at 10:21:07PM +0100, Matt Caswell wrote: >> >> >> On 27/07/15 20:50, Pavneet Jauhal wrote: >>> Hi All, >>> >>> When I attempt to untar OpenSSL 1.0.2d tar-ball, I get an >>> unexpected failure. Error looks something like this; >>> >>> openssl-1.0.2d/VMS/VMSify-conf.pl >>> openssl-1.0.2d/VMS/WISHLIST.TXT tar: A lone zero block at >>> 52140 >>> >>> I only see this with GNU tar. >> >> GNU tar is stricter than other tar programs. It expects to see a >> double zero block at the end of the tar file, and in this case >> there is only one. >> >> This is caused by a bug in a program called tardy which we use >> during the release process to clean up our tar files. Due to this >> problem we have now dropped its use so (hopefully) this shouldn't >> happen again. >> >> The error message is actually only a warning. The tar file should >> have still extracted successfully. It is safe to ignore this. > > Hi Matt. > > I took a look at tardy after reading your email. > > If the OpenSSL project would benefit from continued usage of tardy, > you can re-build tardy 1.28 after applying my POSIX trailing > zero-records fix [1]. That's cool. I did try to contact the original dev to get it fixed but got no response. After that we made the necessary changes so that we could remove the dependence so I don't think we will put it back in again now. It's good you've got a fix though for other users who run into this. Thanks Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVu8Y8AAoJENnE0m0OYESR/icIAIZbtlHyueMXd5ZzyYgT5S6/ dotbRjtE1iCaF/hxxPSMozIS80EfL4Ukww6zyd6UfSAszMg7fFLXPlWk66QBgRzs wNtG19pw15xrD/Aw5qz3VUZerGGmxi2OOE7r0jFIdrOOgZGVvXMepz7hRYR7kjTN qoIe7uYAmXtvnoagzZKukXA31sRS6MUYnji8cftGfcOcd7Ao6ARDt2R4c3RMC9B1 fIEBvQ/KTRDgRJOc7dUr8eB6SbY8YbWC/CMHpbAk85h7rIkqHETEuZXMO34rPfAG 3i0kYSOnGe7IBmDjEy8pxKaFhOeAEB/mCsZZCqC+FrWAZ0pywiNqtJBwopWiwAs= =l17J -----END PGP SIGNATURE----- From Felix.Almeida at rci.rogers.com Fri Jul 31 18:43:18 2015 From: Felix.Almeida at rci.rogers.com (Felix Almeida) Date: Fri, 31 Jul 2015 18:43:18 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails Message-ID: Hello, I was trying to establish a secure connection from an old Linux box to an internal AD server (via LDAPS) but it was failing during the handshake. The AD server accepts SSL2, SSL3 and TLS1. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem CONNECTED(00000003) 182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 318 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated --- However, if I add any of the following command line options then it works: -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem -tls1 CONNECTED(00000003) depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture verify return:1 depth=0 CN = MYSERVER.rogers.com verify return:1 --- Certificate chain 0 s:/CN=MSERVER.rogers.com i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/CN=MYSERVER.rogers.com issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Acceptable client certificate CA names ... Client Certificate Types: RSA sign, DSA sign --- SSL handshake has read 4746 bytes and written 404 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: 6D0500005CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99 Session-ID-ctx: Master-Key: 707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1438364635 Timeout : 7200 (sec) Verify return code: 0 (ok) --- This is the OpenSSL version I'm using: $ openssl version -a OpenSSL 1.0.2d 9 Jul 2015 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/home/myuser/openssl" My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 9). Below is a little extra info on it, in case it helps: $ uname -a Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 x86_64 GNU/Linux $ ldd ~/bin/openssl libssl.so.1.0.0 => /home/myuser/lib/libssl.so.1.0.0 (0x0000002a95558000) libcrypto.so.1.0.0 => /home/myuser/lib/libcrypto.so.1.0.0 (0x0000002a956c9000) libdl.so.2 => /lib64/libdl.so.2 (0x00000035ebe00000) libz.so.1 => /home/myuser/lib/libz.so.1 (0x0000002a959e2000) libc.so.6 => /lib64/tls/libc.so.6 (0x00000035eb900000) /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) One final additional information is that I tried to do the exact same thing from a CentOS 6.6 client server and it just worked without any issues using CentOS standard RPMs. However the OpenSSL version there is the following: $ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jun 15 18:29:40 UTC 2015 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic Since my ultimate goal is to connect to the server via LDAPS but apparently OpenLDAP doesn't let me force a particular protocol (TLS1) then I feel I'm stuck. Perhaps I will recompile OpenSSL without TLS to see if it works, but I really don't want to this way. Any ideas how I can make this work? Is this a bug during the handshake phase? Thank you, Felix ________________________________ This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et r?ception de courriels se fait strictement suivant les modalit?s ?nonc?es dans l?avis publi? ? www.rogers.com/aviscourriel ________________________________ From openssl-users at dukhovni.org Fri Jul 31 19:47:24 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 31 Jul 2015 19:47:24 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: References: Message-ID: <20150731194723.GT4347@mournblade.imrryr.org> On Fri, Jul 31, 2015 at 06:43:18PM +0000, Felix Almeida wrote: > I was trying to establish a secure connection from an old Linux box to an > internal AD server (via LDAPS) but it was failing during the handshake. > The AD server accepts SSL2, SSL3 and TLS1. Is it Windows server 2003? It likely only supports RC4 and 3DES, and only if these appear in the first 64 elements of the client's cipherlist. When a TLS 1.2 handshake is sent, may newer ciphers appear before the server's RC4 and 3DES (the latter is broken in Microsoft Exchange on Windows 2003, but may work with LDAP). > However, if I add any of the following command line options then it works: -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. All these disable TLS 1.2 (and perhaps other protocol versions), and result in a shorter cipherlist. > SSL-Session: > Protocol : TLSv1 > Cipher : RC4-MD5 Bingo: RC4-MD5, it likely also supports RSA-SHA. Here's a sensibly trimmed, but widely interoperable cipherlist: $ c='HIGH:MEDIUM:@STRENGTH:+3DES:+RC4:!aNULL:!MD5:!SRP:!PSK:!aDSS:!kECDH:!kDH:!SEED,!IDEA:!RC2:!RC5' $ openssl s_client -cipher "$c" ... The resulting cipherlist with OpenSSL 1.0.2 is: 1:ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD 2:ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD 3:ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 4:ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 5:ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 6:ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 7:DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD 8:DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 9:DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 10:DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 11:AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD 12:AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 13:AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 14:CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 15:ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD 16:ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD 17:ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 18:ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 19:ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 20:ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 21:DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD 22:DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 23:DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 24:DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 25:AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD 26:AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 27:AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 28:CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 29:ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 30:ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 31:EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 32:DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 33:ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 34:ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 35:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Your LDAP server will choose #35: RC4-SHA. Other servers will make better choices, and nothing remotely mainstream or required for interoperability is excluded. -- Viktor. From Felix.Almeida at rci.rogers.com Fri Jul 31 20:47:45 2015 From: Felix.Almeida at rci.rogers.com (Felix Almeida) Date: Fri, 31 Jul 2015 20:47:45 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails Message-ID: I've tested other OpenSSL versions and everything goes well up to version 1.0.1o, starting from 1.0.2 I see this handshake error. I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config script, but this broke the building process (make stopped with an error). So I believe I will stick with version 1.0.1o for now. :-\ -----Original Message----- From: Felix Almeida Sent: Friday, July 31, 2015 2:43 PM To: 'openssl-users at openssl.org' Subject: [openssl-1.0.2d] default SSL handshake fails Hello, I was trying to establish a secure connection from an old Linux box to an internal AD server (via LDAPS) but it was failing during the handshake. The AD server accepts SSL2, SSL3 and TLS1. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem CONNECTED(00000003) 182899955200:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 318 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated --- However, if I add any of the following command line options then it works: -ssl2, -ssl3, -tls1, -no_tls1, -no_tls1_1, -no_tls1_2. See below the output: $ openssl s_client -connect myserver.rogers.com:636 -CAfile /home/myuser/openssl/certs/myserver_cert.pem -tls1 CONNECTED(00000003) depth=1 C = CA, O = Rogers Inc., OU = Security, CN = Architecture verify return:1 depth=0 CN = MYSERVER.rogers.com verify return:1 --- Certificate chain 0 s:/CN=MSERVER.rogers.com i:/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/CN=MYSERVER.rogers.com issuer=/C=CA/O=Rogers Inc./OU=Security/CN=Architecture --- Acceptable client certificate CA names ... Client Certificate Types: RSA sign, DSA sign --- SSL handshake has read 4746 bytes and written 404 bytes --- New, TLSv1/SSLv3, Cipher is RC4-MD5 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher : RC4-MD5 Session-ID: 6D0500005CFB1BC5194D8B3BD939EADFD5AFF2E19D92CA010A54696403E63E99 Session-ID-ctx: Master-Key: 707D5B10E21FF30B29238D6637C19ACC79382208DBE8F72A05C605424B63258B1B1C4A83C67F17B8E0A62EF67B2B6703 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1438364635 Timeout : 7200 (sec) Verify return code: 0 (ok) --- This is the OpenSSL version I'm using: $ openssl version -a OpenSSL 1.0.2d 9 Jul 2015 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/home/myuser/openssl" My client box is an old Red Hat Enterprise Linux AS release 4 (Nahant Update 9). Below is a little extra info on it, in case it helps: $ uname -a Linux elxin009 2.6.9-100.ELsmp #1 SMP Tue Feb 1 12:04:42 EST 2011 x86_64 x86_64 x86_64 GNU/Linux $ ldd ~/bin/openssl libssl.so.1.0.0 => /home/myuser/lib/libssl.so.1.0.0 (0x0000002a95558000) libcrypto.so.1.0.0 => /home/myuser/lib/libcrypto.so.1.0.0 (0x0000002a956c9000) libdl.so.2 => /lib64/libdl.so.2 (0x00000035ebe00000) libz.so.1 => /home/myuser/lib/libz.so.1 (0x0000002a959e2000) libc.so.6 => /lib64/tls/libc.so.6 (0x00000035eb900000) /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000) One final additional information is that I tried to do the exact same thing from a CentOS 6.6 client server and it just worked without any issues using CentOS standard RPMs. However the OpenSSL version there is the following: $ openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Jun 15 18:29:40 UTC 2015 platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: "/etc/pki/tls" engines: dynamic Since my ultimate goal is to connect to the server via LDAPS but apparently OpenLDAP doesn't let me force a particular protocol (TLS1) then I feel I'm stuck. Perhaps I will recompile OpenSSL without TLS to see if it works, but I really don't want to this way. Any ideas how I can make this work? Is this a bug during the handshake phase? Thank you, Felix ________________________________ This communication is confidential. We only send and receive email on the basis of the terms set out at www.rogers.com/web/content/emailnotice Ce message est confidentiel. Notre transmission et r?ception de courriels se fait strictement suivant les modalit?s ?nonc?es dans l?avis publi? ? www.rogers.com/aviscourriel ________________________________ From openssl-users at dukhovni.org Fri Jul 31 21:06:50 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 31 Jul 2015 21:06:50 +0000 Subject: [openssl-users] [openssl-1.0.2d] default SSL handshake fails In-Reply-To: References: Message-ID: <20150731210650.GW4347@mournblade.imrryr.org> On Fri, Jul 31, 2015 at 08:47:45PM +0000, Felix Almeida wrote: > I've tested other OpenSSL versions and everything goes well up to version > 1.0.1o, starting from 1.0.2 I see this handshake error. It seems you're posting follow-ups without checking whether your original post was answered. > I also tried to disable TLS on 1.0.2d by passing "no-tls" to the config > script, but this broke the building process (make stopped with an error). > So I believe I will stick with version 1.0.1o for now. :-\ Or configure a cipherlist more compatible with a long obsolete and no longer supported Windows 2003 TLS stack. -- Viktor.