From aeh at db.org Mon Jun 1 09:08:06 2015 From: aeh at db.org (Alfred E. Heggestad) Date: Mon, 01 Jun 2015 11:08:06 +0200 Subject: [openssl-users] DTLS and packet loss Message-ID: <556C20F6.9090305@db.org> Hi, we are using OpenSSL to deploy DTLS-SRTP, Ref: http://www.creytiv.com/doxygen/re-dox/html/tls__udp_8c.html it works really well, thanks for the good code. one scenario that does not work so well, is when DTLS is running in an environment with packet loss. for example, we get this error message: 140735307322128:error:1411B09F:SSL routines:ssl3_get_new_session_ticket:length mismatch:s3_clnt.c:2183: any hints of where I should start looking ? /alfred From matt at openssl.org Mon Jun 1 09:39:10 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 01 Jun 2015 10:39:10 +0100 Subject: [openssl-users] DTLS and packet loss In-Reply-To: <556C20F6.9090305@db.org> References: <556C20F6.9090305@db.org> Message-ID: <556C283E.6090900@openssl.org> On 01/06/15 10:08, Alfred E. Heggestad wrote: > Hi, > > we are using OpenSSL to deploy DTLS-SRTP, Ref: > > http://www.creytiv.com/doxygen/re-dox/html/tls__udp_8c.html > > > it works really well, thanks for the good code. > one scenario that does not work so well, is when DTLS > is running in an environment with packet loss. > for example, we get this error message: > > 140735307322128:error:1411B09F:SSL > routines:ssl3_get_new_session_ticket:length mismatch:s3_clnt.c:2183: > > > any hints of where I should start looking ? Can you confirm which version of OpenSSL you are running? Are you also running OpenSSL on the server side (and if so which version there)? The error message suggests that the NewSessionTicket message that has been received by the client is incorrectly formatted. A packet capture for a problem handshake might help diagnose the problem further. Matt From noloader at gmail.com Mon Jun 1 09:44:37 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 1 Jun 2015 05:44:37 -0400 Subject: [openssl-users] DTLS and packet loss In-Reply-To: <556C20F6.9090305@db.org> References: <556C20F6.9090305@db.org> Message-ID: > it works really well, thanks for the good code. > one scenario that does not work so well, is when DTLS > is running in an environment with packet loss. Oh man... Comcast at work is the pits (not sure what it is about their copper in the segment where I work). Its so bad, there's actually a script to mimic them. See, for example, https://github.com/tylertreat/Comcast: "Simulating shitty network connections so you can build better systems". Perhaps that should be an OpenSSL test case written into the engineering process :) Jeff From aeh at db.org Mon Jun 1 11:52:47 2015 From: aeh at db.org (Alfred E. Heggestad) Date: Mon, 01 Jun 2015 13:52:47 +0200 Subject: [openssl-users] DTLS and packet loss In-Reply-To: <556C283E.6090900@openssl.org> References: <556C20F6.9090305@db.org> <556C283E.6090900@openssl.org> Message-ID: <556C478F.5040004@db.org> On 01/06/15 11:39, Matt Caswell wrote: > > > On 01/06/15 10:08, Alfred E. Heggestad wrote: >> Hi, >> >> we are using OpenSSL to deploy DTLS-SRTP, Ref: >> >> http://www.creytiv.com/doxygen/re-dox/html/tls__udp_8c.html >> >> >> it works really well, thanks for the good code. >> one scenario that does not work so well, is when DTLS >> is running in an environment with packet loss. >> for example, we get this error message: >> >> 140735307322128:error:1411B09F:SSL >> routines:ssl3_get_new_session_ticket:length mismatch:s3_clnt.c:2183: >> >> >> any hints of where I should start looking ? > > Can you confirm which version of OpenSSL you are running? > Hey Matt, openssl version 1.0.2a on both sides (Client and Server) > Are you also running OpenSSL on the server side (and if so which version > there)? > > The error message suggests that the NewSessionTicket message that has > been received by the client is incorrectly formatted. > > A packet capture for a problem handshake might help diagnose the problem > further. > please see the attached PCAP file, in this case Packet #4 is dropped internally in the software (to simulate Packet-loss). that test-code has the following option set, to avoid fragmentation: SSL_set_options(tc->ssl, SSL_OP_NO_QUERY_MTU); DTLS_set_link_mtu(tc->ssl, 1480); please note that dropping Packet #1, #2 and #3 works as expected. but dropping the final packet (packet #4) does not work. /alfred > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_dtls_packet4_lost.pcap Type: application/octet-stream Size: 4636 bytes Desc: not available URL: From rsalz at akamai.com Mon Jun 1 14:03:09 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Jun 2015 14:03:09 +0000 Subject: [openssl-users] Do you use EGD or PRNGD? Message-ID: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> We are thinking of removing support for EGD (entropy-gathering daemon) in the next release. None of our supported platforms have needed it for some time. If this will cause an issue for you, please reply 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 Mon Jun 1 14:29:48 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 01 Jun 2015 15:29:48 +0100 Subject: [openssl-users] DTLS and packet loss In-Reply-To: <556C478F.5040004@db.org> References: <556C20F6.9090305@db.org> <556C283E.6090900@openssl.org> <556C478F.5040004@db.org> Message-ID: <556C6C5C.6090109@openssl.org> On 01/06/15 12:52, Alfred E. Heggestad wrote: > Hey Matt, > > > openssl version 1.0.2a on both sides (Client and Server) > > >> Are you also running OpenSSL on the server side (and if so which version >> there)? >> >> The error message suggests that the NewSessionTicket message that has >> been received by the client is incorrectly formatted. >> >> A packet capture for a problem handshake might help diagnose the problem >> further. >> > > please see the attached PCAP file, in this case Packet #4 is dropped > internally > in the software (to simulate Packet-loss). > > > > that test-code has the following option set, to avoid fragmentation: > > SSL_set_options(tc->ssl, SSL_OP_NO_QUERY_MTU); > DTLS_set_link_mtu(tc->ssl, 1480); > > > please note that dropping Packet #1, #2 and #3 works as expected. > but dropping the final packet (packet #4) does not work. Thanks - I've figured it out. This is a manifestation of a known issue with retransmits in 1.0.2a. It will be fixed in 1.0.2b. I have attached a patch for 1.0.2a which should solve your problems for now. The relevant 1.0.2 commits that fix this are here: https://github.com/openssl/openssl/commit/a20718fa2c0a45e6acb975cf6c0438c3ebd45b13 and here: https://github.com/openssl/openssl/commit/4285b851637a3da8bd6e96848f0deffb6be5e626 Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls-1.0.2a-retransmits.patch Type: text/x-patch Size: 3593 bytes Desc: not available URL: From jb-openssl at wisemo.com Mon Jun 1 18:28:11 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 01 Jun 2015 20:28:11 +0200 Subject: [openssl-users] Do you use EGD or PRNGD? In-Reply-To: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <556CA43B.7040202@wisemo.com> On 01/06/2015 16:03, Salz, Rich wrote: > > We are thinking of removing support for EGD (entropy-gathering daemon) > in the next release. None of our supported platforms have needed it > for some time. If this will cause an issue for you, please reply soon. > While the original EGD is needed only on platforms with no platform-provided equivalent (such as /dev/*random or Microsoft CryptGenRandom()), it should be noted that a networked variant of the EGD protocol has been used by at least one hardware RNG vendor, though I am unsure if the builtin EGD code in OpenSSL could ever talk directly to that variant anyway. Two other platforms I can think of as potentially affected are Solaris 2.4+ without the /dev/random patch and CE installations without MS CryptoAPI (this is the default for some CE 2.11 targets, and an option for any vendor configured CE installation of any version, including the latest ones, though that latter option might be as rare as building the Linux kernel without /dev/*random). 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 Mon Jun 1 18:33:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Jun 2015 18:33:01 +0000 Subject: [openssl-users] [openssl-dev] Do you use EGD or PRNGD? In-Reply-To: <00b101d09c92$600409a0$200c1ce0$@nexbridge.com> References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> <00b101d09c92$600409a0$200c1ce0$@nexbridge.com> Message-ID: <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com> > While HP NonStop is not officially supported, I have been helping to maintain > a fork for the platform since December and are current through 1.0.2a. We > do use prngd. I am looking for ways to get back on the official platform list, > looking for alternatives to prngd for that platform, and trying get vendor by- > in in this area. Thanks for the info. One possibility is to have a separate program use prngd and write it to a RANDFILE that openssl uses. Probably servers are the most important users, and you could/should have one file per server ... From rsalz at akamai.com Mon Jun 1 18:42:26 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 Jun 2015 18:42:26 +0000 Subject: [openssl-users] Do you use EGD or PRNGD? In-Reply-To: <556CA43B.7040202@wisemo.com> References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> <556CA43B.7040202@wisemo.com> Message-ID: Thanks for the info! > it should be noted that a networked variant of the EGD protocol has been used by at least one hardware RNG vendor, though I am unsure if the builtin EGD code in OpenSSL could ever talk directly to that variant anyway. I don't think so, since all the code does is open a unix-domain socket. > Two other platforms I can think of as potentially affected are Solaris 2.4+ without the /dev/random patch Yeah, my inclination is to say "get the patch." > and CE installations without MS CryptoAPI The EGD code doesn't work on Windows; we use heap-walk to seed it there. From noloader at gmail.com Mon Jun 1 15:40:07 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 1 Jun 2015 11:40:07 -0400 Subject: [openssl-users] [openssl-dev] Do you use EGD or PRNGD? In-Reply-To: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: On Mon, Jun 1, 2015 at 10:03 AM, Salz, Rich wrote: > We are thinking of removing support for EGD (entropy-gathering daemon) in > the next release. None of our supported platforms have needed it for some > time. If this will cause an issue for you, please reply soon. > Rich... At the cost of being argumentative, why is there no need for it? I had to install an entropy gather on Debian desktop because reads to /dev/random would fail on occasion when the device was opened O_NONBLOCK. I was not hitting it hard - I was just trying to grab a 32 byte one-time seed to seed an in-app generator. It was really surprising to see Debian's RNG could only supply 7 bytes or so. I was amazed it happened out of the box in 2014. After that, I switched to alternate methods to grab any entropy I could get my hands on, including things like EGD, HAVEGED and even sensor readings on mobile devices (if they are available). Jeff From richard at levitte.org Mon Jun 1 19:52:41 2015 From: richard at levitte.org (Richard Levitte) Date: Mon, 01 Jun 2015 21:52:41 +0200 (CEST) Subject: [openssl-users] [openssl-dev] Do you use EGD or PRNGD? In-Reply-To: <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <2277336fb2f546d2a39aabed88a8e9bb@ustx2ex-dag1mb2.msg.corp.akamai.com> <00b101d09c92$600409a0$200c1ce0$@nexbridge.com> <48ce1b94ef3648d990a5e253a8992fec@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150601.215241.1644886557227726719.richard@levitte.org> In message <48ce1b94ef3648d990a5e253a8992fec at ustx2ex-dag1mb2.msg.corp.akamai.com> on Mon, 1 Jun 2015 18:33:01 +0000, "Salz, Rich" said: rsalz> > While HP NonStop is not officially supported, I have been helping to maintain rsalz> > a fork for the platform since December and are current through 1.0.2a. We rsalz> > do use prngd. I am looking for ways to get back on the official platform list, rsalz> > looking for alternatives to prngd for that platform, and trying get vendor by- rsalz> > in in this area. rsalz> rsalz> Thanks for the info. rsalz> rsalz> One possibility is to have a separate program use prngd and write it to a RANDFILE that openssl uses. Probably servers are the most important users, and you could/should have one file per server ... I'd like to remind people of the possibility to make an engine module. Cheers, Richard -- Richard Levitte richard at levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish From aeh at db.org Tue Jun 2 08:58:41 2015 From: aeh at db.org (Alfred E. Heggestad) Date: Tue, 02 Jun 2015 10:58:41 +0200 Subject: [openssl-users] DTLS and packet loss In-Reply-To: <556C6C5C.6090109@openssl.org> References: <556C20F6.9090305@db.org> <556C283E.6090900@openssl.org> <556C478F.5040004@db.org> <556C6C5C.6090109@openssl.org> Message-ID: <556D7041.80508@db.org> On 01/06/15 16:29, Matt Caswell wrote: > > > On 01/06/15 12:52, Alfred E. Heggestad wrote: >> Hey Matt, >> >> >> openssl version 1.0.2a on both sides (Client and Server) >> >> >>> Are you also running OpenSSL on the server side (and if so which version >>> there)? >>> >>> The error message suggests that the NewSessionTicket message that has >>> been received by the client is incorrectly formatted. >>> >>> A packet capture for a problem handshake might help diagnose the problem >>> further. >>> >> >> please see the attached PCAP file, in this case Packet #4 is dropped >> internally >> in the software (to simulate Packet-loss). >> >> >> >> that test-code has the following option set, to avoid fragmentation: >> >> SSL_set_options(tc->ssl, SSL_OP_NO_QUERY_MTU); >> DTLS_set_link_mtu(tc->ssl, 1480); >> >> >> please note that dropping Packet #1, #2 and #3 works as expected. >> but dropping the final packet (packet #4) does not work. > > Thanks - I've figured it out. This is a manifestation of a known issue > with retransmits in 1.0.2a. It will be fixed in 1.0.2b. I have attached > a patch for 1.0.2a which should solve your problems for now. > > The relevant 1.0.2 commits that fix this are here: > https://github.com/openssl/openssl/commit/a20718fa2c0a45e6acb975cf6c0438c3ebd45b13 > > and here: > https://github.com/openssl/openssl/commit/4285b851637a3da8bd6e96848f0deffb6be5e626 > > Matt, thank you for the fast response and patches :) I can confirm that 1.0.2a + patches above fixes the DTLS packet-loss issue. keep up the good work guys! /alfred From secinterlocutor at gmail.com Tue Jun 2 11:55:51 2015 From: secinterlocutor at gmail.com (SecInterlocutor) Date: Tue, 2 Jun 2015 12:55:51 +0100 Subject: [openssl-users] Fwd: X9.31 RSA key generation for FIPS validation (180-4) In-Reply-To: References: Message-ID: Hello, Our product was FIPS-certified a few years ago. We are now about to start the re-certification process. The test for RSA X9.31 key generation have somewhat changed, or so it looks like to me anyway. A few years ago, we received test vectors with the following parameters: modulus size, e, xp1, xp2, Xp, xq1, xq2, Xq. The response we provided included the previous parameters and these generated values: p, q, n, d. We used FIPS_rsa_x931_derive_ex() to generate the values. I believe this function implements section B.3.6: Generation of Probable Primes with Conditions Based on Auxiliary Probable Primes. Prime method: Primes p1, p2, q1,q2, p and q shall all be probable primes. Is my assumption correct? If so, we?d like to minimise effort and reuse our test sw for the new tests in http://csrc.nist.gov/groups/STM/cavp/documents/dss2/rsa2vs.pdf. I?m looking at section 6.2.1 where the parameters are: modulus size, e, N=25 (number of iterations). It seems to me that we have to send a response with all of the other parameters: xp1, xp2, Xp, xq1, xq2, Xq, p, q, n, d. xp1, xp2, Xp, xq1, xq2, Xq are random numbers, some of them have to be odd. Which function(s) do you suggest to use to generate them? Or can I just use FIPS_rsa_x931_generate_key_ex() ? Is this used with a fixed exponent? Does it also implement section B.3.6? We also have to indicate to NIST the type of Probabilistic Primality Test the (specific) OpenSSL functions use: a) Table C.2. Minimum number of rounds of M-R testing when generating primes b) Table C.3. Minimum number of rounds of M-R testing when generating primes using an error probability of 2^?100 Which one(s) does OpenSSL implement? If both, how is that chosen? Many thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From remy.grunblatt at ens-lyon.fr Wed Jun 3 05:32:34 2015 From: remy.grunblatt at ens-lyon.fr (=?UTF-8?B?UsOpbXkgR3LDvG5ibGF0dA==?=) Date: Wed, 3 Jun 2015 07:32:34 +0200 Subject: [openssl-users] External encryption chip and EC{DSA, DH} (with engine?) Message-ID: <20150603073234.7c86a3ec@ens-lyon.fr> Hello. I have a custom external hardware encryption chip that can computes some operations like the addition of two points, the inverse of one point, etc. I read that if I want to move some calculus from openssl to this chip, Openssl engines are the way to go. By defining a custom EC_METHOD, for example, I can just move the inverse on the chip while keeping other functions "in openssl" (not moving them). Still, how do I ask to my Engine to use this new custom EC_METHOD ? I see functions like ENGINE_set_default_ECDSA, or ENGINE_set_default_ECDH, but I don't want to change thoses, only the underlying EC_METHOD which is "used" for calculus. I do not know if it's clear, but what i'm searching for is a kind of "ENGINE_set_default_EC_METHOD" which could be used by the tests from ectest.c, for example. Any idea ? Thank you. R?my G. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From matt at openssl.org Wed Jun 3 12:58:36 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 03 Jun 2015 13:58:36 +0100 Subject: [openssl-users] External encryption chip and EC{DSA, DH} (with engine?) In-Reply-To: <20150603073234.7c86a3ec@ens-lyon.fr> References: <20150603073234.7c86a3ec@ens-lyon.fr> Message-ID: <556EF9FC.3050801@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/15 06:32, R?my Gr?nblatt wrote: > Hello. I have a custom external hardware encryption chip that can > computes some operations like the addition of two points, the > inverse of one point, etc. > > I read that if I want to move some calculus from openssl to this > chip, Openssl engines are the way to go. > > By defining a custom EC_METHOD, for example, I can just move the > inverse on the chip while keeping other functions "in openssl" > (not moving them). Still, how do I ask to my Engine to use this > new custom EC_METHOD ? > > I see functions like ENGINE_set_default_ECDSA, or > ENGINE_set_default_ECDH, but I don't want to change thoses, only > the underlying EC_METHOD which is "used" for calculus. > > I do not know if it's clear, but what i'm searching for is a kind > of "ENGINE_set_default_EC_METHOD" which could be used by the tests > from ectest.c, for example. Any idea ? Unfortunately, I don't think such a thing exists. In fact the definition of EC_METHOD is not defined in any public header file so it is not currently possible to provide your own version without hacking OpenSSL itself. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVbvn8AAoJENnE0m0OYESRwtsH/1p941OTgrEMPuLlkyulf4DA E3HzZNqgShlGBK6y4NrI+1bwPAHNeRe1weQuaOokDqiY9k+Qh/B4ncKVKbH3kJFF c8xlKhf9GsMzsfV+sqeTSX0b16cvTbos0l6JEVGcypLib7jtcJcE9a966dC699Cz 7k6Adq6mpznm30JFFARon0Ov7htLvCvU6nRgBnV3nSh/+++5iNe1ZQht06El92Ap VPvbYz54zePaQgndI/lgtNEA9RQcI/Zsbn3dJzs9FDWyMs4JCjf0Yl2oCtzfeb2c wMX6nJFiTOMa6rMUpPedTd2QS/XrOHUpPdcRxWpz4grYklqVAizlKrtHPutwrpo= =//we -----END PGP SIGNATURE----- From thulasi.goriparthi at gmail.com Wed Jun 3 13:19:21 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 3 Jun 2015 18:49:21 +0530 Subject: [openssl-users] External encryption chip and EC{DSA, DH} (with engine?) In-Reply-To: <556EF9FC.3050801@openssl.org> References: <20150603073234.7c86a3ec@ens-lyon.fr> <556EF9FC.3050801@openssl.org> Message-ID: Thanks Remy for asking the question in my mind. "ENGINE_set_default_EC_METHOD" will be perfect to offload EC Point multiplication, doubling and addition offered by some h/w crypto accelerators. Hi Matt, What is the reason to keep ec_method, ecdh_method and ecdsa_method structure definitions in local header files ec_locl.h, ech_locl.h and ecs_locl.h respectively unlike their peers.. dh_method, dsa_method, rsa_meth_st and rand_meth_st which are defined in exported header files? ENGINE_set_default_EC_METHOD is really nice idea. Even if it is not immediate, please discuss the possibility of having this with your team. Thanks, Thulasi. On 3 June 2015 at 18:28, Matt Caswell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > On 03/06/15 06:32, R?my Gr?nblatt wrote: > > Hello. I have a custom external hardware encryption chip that can > > computes some operations like the addition of two points, the > > inverse of one point, etc. > > > > I read that if I want to move some calculus from openssl to this > > chip, Openssl engines are the way to go. > > > > By defining a custom EC_METHOD, for example, I can just move the > > inverse on the chip while keeping other functions "in openssl" > > (not moving them). Still, how do I ask to my Engine to use this > > new custom EC_METHOD ? > > > > I see functions like ENGINE_set_default_ECDSA, or > > ENGINE_set_default_ECDH, but I don't want to change thoses, only > > the underlying EC_METHOD which is "used" for calculus. > > > > I do not know if it's clear, but what i'm searching for is a kind > > of "ENGINE_set_default_EC_METHOD" which could be used by the tests > > from ectest.c, for example. Any idea ? > > Unfortunately, I don't think such a thing exists. In fact the > definition of EC_METHOD is not defined in any public header file so it > is not currently possible to provide your own version without hacking > OpenSSL itself. > > Matt > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVbvn8AAoJENnE0m0OYESRwtsH/1p941OTgrEMPuLlkyulf4DA > E3HzZNqgShlGBK6y4NrI+1bwPAHNeRe1weQuaOokDqiY9k+Qh/B4ncKVKbH3kJFF > c8xlKhf9GsMzsfV+sqeTSX0b16cvTbos0l6JEVGcypLib7jtcJcE9a966dC699Cz > 7k6Adq6mpznm30JFFARon0Ov7htLvCvU6nRgBnV3nSh/+++5iNe1ZQht06El92Ap > VPvbYz54zePaQgndI/lgtNEA9RQcI/Zsbn3dJzs9FDWyMs4JCjf0Yl2oCtzfeb2c > wMX6nJFiTOMa6rMUpPedTd2QS/XrOHUpPdcRxWpz4grYklqVAizlKrtHPutwrpo= > =//we > -----END PGP SIGNATURE----- > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt.w.heberlein at hp.com Wed Jun 3 19:59:17 2015 From: kurt.w.heberlein at hp.com (Heberlein, Kurt William) Date: Wed, 3 Jun 2015 19:59:17 +0000 Subject: [openssl-users] Question about using fipsld for shared objects Message-ID: <304F70D12CDFEB43BB9DFB8144B443A92EE70279@G2W2430.americas.hpqcorp.net> So, I am trying to create a shared object to implement some functionality in libpam. It has dependencies on a number of dynamic objects, but I am trying to include statically linked copies of libcrypto and libssl. These are coming from a FIPS capable version of OpenSSL (1.0.1)built and tested with a FIPS canister (2.0.9) that I created using the instructions in the Security Policy / User Guide. This is in Debian Linux, using gcc. I've created standalone executables this way, but cannot get past the fipsld link step while creating a shared object. After the first link (which succeeds just fine), when fipsld tries to execute the DSO, there is a segmentation violation: Program received signal SIGSEGV, Segmentation fault. 0x000055555561d1b9 in do_drbg_init () (gdb) where #0 0x000055555561d1b9 in do_drbg_init () #1 0x00005555555da14e in do_drbg_instantiate () The Makefile looks like this: # make CC=/usr/local/ssl/fips-2.0/bin/fipsld FIPSLD_CC=gcc INSTALL=/usr/bin/install CC=/usr/local/ssl/fips-2.0/bin/fipsld FIPSLD_CC=gcc DEBUG=-ggdb -DDEBUG_FINGERPRINT_PREMAIN LIB = -L/usr/local/ssl/lib LIBS = -lpam -lcrypt -lstdc++ -ldl #LIBS = -lpam -lcrypt -lstdc++ -ldl /usr/local/ssl/fips-2.0/lib/fipscanister.o INC = -I /usr/local/ssl/include -I ../../.. CFLAGS=-DFIPS_SSL -fPIC ARCS = -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic all: pam_sp_auth.so pam_sp_auth.so: pam_sp_auth.o ../../../tpdpass.o ../../../tpd_pwd_cli.o $(CC) ${DEBUG} ${INC} ${CFLAGS} ${LIB} ${LDFLAGS} -shared -o pam_sp_auth.so ${LIBS} pam_sp_auth.o ../../../tpdpass.o \ ../../../tpd_pwd_cli.o ${ARCS} pam_sp_auth.o: pam_sp_auth.c ../../../tpdpass.h ${FIPSLD_CC} ${DEBUG} ${INC} ${CFLAGS} -c -o pam_sp_auth.o pam_sp_auth.c clobber: rm -f pam_sp_auth.so pam_sp_auth.o It is invoked with: make CC=/usr/local/ssl/fips-2.0/bin/fipsld FIPSLD_CC=gcc To make certain that it was not related to the static linkage, I reworked the make to link everything dynamically and I still hit the same issue. Thoughts? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jun 4 07:04:01 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 04 Jun 2015 08:04:01 +0100 Subject: [openssl-users] External encryption chip and EC{DSA, DH} (with engine?) In-Reply-To: References: <20150603073234.7c86a3ec@ens-lyon.fr> <556EF9FC.3050801@openssl.org> Message-ID: <556FF861.60705@openssl.org> On 03/06/15 14:19, Thulasi Goriparthi wrote: > Thanks Remy for asking the question in my mind. > > "ENGINE_set_default_EC_METHOD" will be perfect to offload EC Point > multiplication, doubling and addition offered by some h/w crypto > accelerators. > > Hi Matt, > > What is the reason to keep ec_method, ecdh_method and ecdsa_method > structure definitions in local header files ec_locl.h, ech_locl.h and > ecs_locl.h respectively unlike their peers.. dh_method, dsa_method, > rsa_meth_st and rand_meth_st which are defined in exported header files? > > ENGINE_set_default_EC_METHOD is really nice idea. Even if it is not > immediate, please discuss the possibility of having this with your team. I will raise the suggestion. Matt From cathy.fauntleroy at vdtg.com Thu Jun 4 20:17:37 2015 From: cathy.fauntleroy at vdtg.com (Cathy Fauntleroy) Date: Thu, 4 Jun 2015 16:17:37 -0400 Subject: [openssl-users] OpenSSL.cnf File path Message-ID: <001301d09f03$80cb4db0$8261e910$@vdtg.com> Hello, I have OpenSSL 1.0.2a installed on my Windows 7 box. I am attempting to generate a CSR so new security certificates can be issued and am running into the following error when the command to generate the .csr file is issued from the C:\OpenSSL-Win64\bin directory: WARNING: can't open config file: /usr/local/ssl/openssl.cnf Unable to load config info from /usr/local/ssl/openssl.cnf This is not a valid path on my Windows box.openssl.cnf resides in C:\OpenSSL-Win64\bin. I verified the system PATH is correct also. Any ideas? Thanks. Cathy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at an3k.de Thu Jun 4 22:14:55 2015 From: ben at an3k.de (Ben Humpert) Date: Fri, 5 Jun 2015 00:14:55 +0200 Subject: [openssl-users] OpenSSL.cnf File path In-Reply-To: <001301d09f03$80cb4db0$8261e910$@vdtg.com> References: <001301d09f03$80cb4db0$8261e910$@vdtg.com> Message-ID: As a workaround try running openssl with the -config command line option. 2015-06-04 22:17 GMT+02:00 Cathy Fauntleroy : > Hello, > > > > I have OpenSSL 1.0.2a installed on my Windows 7 box. I am attempting to > generate a CSR so new security certificates can be issued and am running > into the following error when the command to generate the .csr file is > issued from the C:\OpenSSL-Win64\bin directory: > > > > WARNING: can't open config file: /usr/local/ssl/openssl.cnf > > Unable to load config info from /usr/local/ssl/openssl.cnf > > > > This is not a valid path on my Windows box?openssl.cnf resides in > C:\OpenSSL-Win64\bin. I verified the system PATH is correct also. Any > ideas? > > > > Thanks? > > Cathy > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From rsalz at akamai.com Thu Jun 4 22:17:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 4 Jun 2015 22:17:54 +0000 Subject: [openssl-users] OpenSSL.cnf File path In-Reply-To: References: <001301d09f03$80cb4db0$8261e910$@vdtg.com> Message-ID: > > WARNING: can't open config file: /usr/local/ssl/openssl.cnf Set OPENSSL_CONF in your environment. From cathy.fauntleroy at vdtg.com Thu Jun 4 23:19:40 2015 From: cathy.fauntleroy at vdtg.com (Cathy Fauntleroy) Date: Thu, 4 Jun 2015 19:19:40 -0400 Subject: [openssl-users] OpenSSL.cnf File path In-Reply-To: References: <001301d09f03$80cb4db0$8261e910$@vdtg.com> Message-ID: <002d01d09f1c$ef1efaf0$cd5cf0d0$@vdtg.com> Thanks for the tip. I have OPENSSL_CNF set. I'll change it and see if that makes a difference. Thanks. Cathy Fauntleroy, Security+ Van Dyke Technology Group Email: cathy.fauntleroy at vdtg.com Office: (443) 832-4768 -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Thursday, June 4, 2015 6:18 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL.cnf File path > > WARNING: can't open config file: /usr/local/ssl/openssl.cnf Set OPENSSL_CONF in your environment. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From lminiero at gmail.com Fri Jun 5 07:09:32 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 09:09:32 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO Message-ID: Hi all, first of all, apologies if this has been asked before. I've searched archives pretty much everywhere, and only came to partial indications as to how this should be dealt with. The problem I'm facing deals with using DTLS with mem BIOs, as I have to take care of transport myself. Specifically, I've implemented a WebRTC gateway called Janus, which means all the connectivity related stuff is delegated to another library (libnice in this case). This mostly works great (kudos to you guys!), but I have problems as soon as packets exceed the MTU, which can easily happen whenever, for instance, you try to handshake with certificates larger than 1024 bits. I read around that the DTLS stack in OpenSSL automatically deals with this, and in fact this seems to be happening: what isn't working is the BIO mem part of this. More specifically, OpenSSL does indeed take care of fragmenting the packets according to what is assumed to be the MTU (1472 by default, or the value as set in s->d1->mtu). The problem is that the mem BIO ignores that fragmentation info completely, and so, when you do an BIO_read, makes available at the application the whole packet anyway. This results in the whole buffer being passed to nice_agent_send (the method libnice exposes to send packets), which means it's just as not fragmenting anything: the packet is too large and the network drops it. You can verify this by using, e.g., a 4096 bits certificate, and capture the DTLS traffic with Wireshark: you'll see that the message is recognized as composed of not only multiple messages, but also fragments. Is there any way I can force the BIO to return the invididual fragments/messages when I do a BIO_read, so that I can send properly sized packets? I've tried looking around but found no insight on how to do that. The only approach that came to my mind was to manually inspect the buffer that is returned, and split messages/fragments myself, but I'd rather avoid delving within the specifics of the protocol if possible. Thanks in advance for any help you may provide me with! Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 5 08:31:54 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 05 Jun 2015 09:31:54 +0100 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: Message-ID: <55715E7A.4040109@openssl.org> On 05/06/15 08:09, Lorenzo Miniero wrote: > Hi all, > > first of all, apologies if this has been asked before. I've searched > archives pretty much everywhere, and only came to partial indications as > to how this should be dealt with. > > The problem I'm facing deals with using DTLS with mem BIOs, as I have to > take care of transport myself. Specifically, I've implemented a WebRTC > gateway called Janus, which means all the connectivity related stuff is > delegated to another library (libnice in this case). This mostly works > great (kudos to you guys!), but I have problems as soon as packets > exceed the MTU, which can easily happen whenever, for instance, you try > to handshake with certificates larger than 1024 bits. I read around that > the DTLS stack in OpenSSL automatically deals with this, and in fact > this seems to be happening: what isn't working is the BIO mem part of this. > > More specifically, OpenSSL does indeed take care of fragmenting the > packets according to what is assumed to be the MTU (1472 by default, or > the value as set in s->d1->mtu). The problem is that the mem BIO ignores > that fragmentation info completely, and so, when you do an BIO_read, > makes available at the application the whole packet anyway. This results > in the whole buffer being passed to nice_agent_send (the method libnice > exposes to send packets), which means it's just as not fragmenting > anything: the packet is too large and the network drops it. You can > verify this by using, e.g., a 4096 bits certificate, and capture the > DTLS traffic with Wireshark: you'll see that the message is recognized > as composed of not only multiple messages, but also fragments. > > Is there any way I can force the BIO to return the invididual > fragments/messages when I do a BIO_read, so that I can send properly > sized packets? I've tried looking around but found no insight on how to > do that. The only approach that came to my mind was to manually inspect > the buffer that is returned, and split messages/fragments myself, but > I'd rather avoid delving within the specifics of the protocol if possible. > > Thanks in advance for any help you may provide me with! Hmmmm. An interesting problem. The issue is that a mem BIO has no knowledge of datagram semantics (perhaps we need to add something for OpenSSL 1.1.0). In a dgram BIO each BIO_write translates to a single datagram being produced. In a mem BIO you just have a big bucket of memory, and every time you get a BIO_write you just add the data onto the end of everything that we've go so far, and so the packet boundaries are not respected. How about you create a custom filter BIO? All it would need to do is proxy all calls down to the underlying mem BIO. Along the way though it could take note of where the packet boundaries are, so when you call BIO_read it only gives it to you a datagram at a time. Matt From lminiero at gmail.com Fri Jun 5 09:20:34 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 11:20:34 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: <55715E7A.4040109@openssl.org> References: <55715E7A.4040109@openssl.org> Message-ID: 2015-06-05 10:31 GMT+02:00 Matt Caswell : > > > On 05/06/15 08:09, Lorenzo Miniero wrote: > > Hi all, > > > > first of all, apologies if this has been asked before. I've searched > > archives pretty much everywhere, and only came to partial indications as > > to how this should be dealt with. > > > > The problem I'm facing deals with using DTLS with mem BIOs, as I have to > > take care of transport myself. Specifically, I've implemented a WebRTC > > gateway called Janus, which means all the connectivity related stuff is > > delegated to another library (libnice in this case). This mostly works > > great (kudos to you guys!), but I have problems as soon as packets > > exceed the MTU, which can easily happen whenever, for instance, you try > > to handshake with certificates larger than 1024 bits. I read around that > > the DTLS stack in OpenSSL automatically deals with this, and in fact > > this seems to be happening: what isn't working is the BIO mem part of > this. > > > > More specifically, OpenSSL does indeed take care of fragmenting the > > packets according to what is assumed to be the MTU (1472 by default, or > > the value as set in s->d1->mtu). The problem is that the mem BIO ignores > > that fragmentation info completely, and so, when you do an BIO_read, > > makes available at the application the whole packet anyway. This results > > in the whole buffer being passed to nice_agent_send (the method libnice > > exposes to send packets), which means it's just as not fragmenting > > anything: the packet is too large and the network drops it. You can > > verify this by using, e.g., a 4096 bits certificate, and capture the > > DTLS traffic with Wireshark: you'll see that the message is recognized > > as composed of not only multiple messages, but also fragments. > > > > Is there any way I can force the BIO to return the invididual > > fragments/messages when I do a BIO_read, so that I can send properly > > sized packets? I've tried looking around but found no insight on how to > > do that. The only approach that came to my mind was to manually inspect > > the buffer that is returned, and split messages/fragments myself, but > > I'd rather avoid delving within the specifics of the protocol if > possible. > > > > Thanks in advance for any help you may provide me with! > > Hmmmm. An interesting problem. > > The issue is that a mem BIO has no knowledge of datagram semantics > (perhaps we need to add something for OpenSSL 1.1.0). > > In a dgram BIO each BIO_write translates to a single datagram being > produced. In a mem BIO you just have a big bucket of memory, and every > time you get a BIO_write you just add the data onto the end of > everything that we've go so far, and so the packet boundaries are not > respected. > > How about you create a custom filter BIO? All it would need to do is > proxy all calls down to the underlying mem BIO. Along the way though it > could take note of where the packet boundaries are, so when you call > BIO_read it only gives it to you a datagram at a time. > > Matt > > Thanks for the very quick answer! Your suggestion does indeed make much more sense that manually inspecting the buffer as I thought of, as you don't need to know anything about the protocol but only to be ready to index the packets you see passing by. I never tried writing a BIO filter but there's a first time for everything :-) Just one quick question about this: are messages/packets passed to the BIO actually splitted, and then just queued by the mem BIO in the buffer, or can there be cases where a larger than normal buffer is passed to the BIO anyway, meaning a manual splitting could be needed nevertheless from time to time? Thanks, Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Jun 5 10:30:30 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 05 Jun 2015 11:30:30 +0100 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> Message-ID: <55717A46.3040104@openssl.org> On 05/06/15 10:20, Lorenzo Miniero wrote: > Just one quick question about this: are messages/packets passed to the > BIO actually splitted, and then just queued by the mem BIO in the > buffer, or can there be cases where a larger than normal buffer is > passed to the BIO anyway, meaning a manual splitting could be needed > nevertheless from time to time? No, there should be no need for the BIO to do any splitting. Everything that gets written to the BIO should be a datagram. One issue that does spring to mind is that in your filter BIO you may want to implement some of the dgram ctrls that DTLS uses. This depends on how you want to manage setting your MTU. Do you set an MTU size explicitly using SSL_set_mtu(ssl, mtu) or DTLS_set_link_mtu(ssl, mtu)? Also, do you set the option SSL_OP_NO_QUERY_MTU? If you use the option then you should set an MTU size explicitly. If you don't set the SSL_OP_NO_QUERY_MTU option then the DTLS code will attempt to query the underlying BIO for information about the mtu size. That would mean you would have to implement the following additional ctrls: BIO_CTRL_DGRAM_GET_FALLBACK_MTU - returns a "default" MTU size if querying fails for some reason BIO_CTRL_DGRAM_QUERY_MTU - queries the transport for the MTU size to be used BIO_CTRL_DGRAM_SET_MTU - sets the MTU size on the underlying transport BIO_CTRL_DGRAM_MTU_EXCEEDED - returns true if the datagram we just tried to send failed because we exceeded the max MTU size Matt From aeh at db.org Fri Jun 5 10:34:27 2015 From: aeh at db.org (Alfred E. Heggestad) Date: Fri, 05 Jun 2015 12:34:27 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> Message-ID: <55717B33.8060703@db.org> On 05/06/15 11:20, Lorenzo Miniero wrote: > 2015-06-05 10:31 GMT+02:00 Matt Caswell >: > > > > On 05/06/15 08:09, Lorenzo Miniero wrote: > > Hi all, > > > > first of all, apologies if this has been asked before. I've searched > > archives pretty much everywhere, and only came to partial indications as > > to how this should be dealt with. > > > > The problem I'm facing deals with using DTLS with mem BIOs, as I have to > > take care of transport myself. Specifically, I've implemented a WebRTC > > gateway called Janus, which means all the connectivity related stuff is > > delegated to another library (libnice in this case). This mostly works > > great (kudos to you guys!), but I have problems as soon as packets > > exceed the MTU, which can easily happen whenever, for instance, you try > > to handshake with certificates larger than 1024 bits. I read around that > > the DTLS stack in OpenSSL automatically deals with this, and in fact > > this seems to be happening: what isn't working is the BIO mem part of this. > > > > More specifically, OpenSSL does indeed take care of fragmenting the > > packets according to what is assumed to be the MTU (1472 by default, or > > the value as set in s->d1->mtu). The problem is that the mem BIO ignores > > that fragmentation info completely, and so, when you do an BIO_read, > > makes available at the application the whole packet anyway. This results > > in the whole buffer being passed to nice_agent_send (the method libnice > > exposes to send packets), which means it's just as not fragmenting > > anything: the packet is too large and the network drops it. You can > > verify this by using, e.g., a 4096 bits certificate, and capture the > > DTLS traffic with Wireshark: you'll see that the message is recognized > > as composed of not only multiple messages, but also fragments. > > > > Is there any way I can force the BIO to return the invididual > > fragments/messages when I do a BIO_read, so that I can send properly > > sized packets? I've tried looking around but found no insight on how to > > do that. The only approach that came to my mind was to manually inspect > > the buffer that is returned, and split messages/fragments myself, but > > I'd rather avoid delving within the specifics of the protocol if possible. > > > > Thanks in advance for any help you may provide me with! > > Hmmmm. An interesting problem. > > The issue is that a mem BIO has no knowledge of datagram semantics > (perhaps we need to add something for OpenSSL 1.1.0). > > In a dgram BIO each BIO_write translates to a single datagram being > produced. In a mem BIO you just have a big bucket of memory, and every > time you get a BIO_write you just add the data onto the end of > everything that we've go so far, and so the packet boundaries are not > respected. > > How about you create a custom filter BIO? All it would need to do is > proxy all calls down to the underlying mem BIO. Along the way though it > could take note of where the packet boundaries are, so when you call > BIO_read it only gives it to you a datagram at a time. > > Matt > > > > Thanks for the very quick answer! > > Your suggestion does indeed make much more sense that manually inspecting the buffer as I thought of, as you don't need to know anything about the protocol but > only to be ready to index the packets you see passing by. I never tried writing a BIO filter but there's a first time for everything :-) > > Just one quick question about this: are messages/packets passed to the BIO actually splitted, and then just queued by the mem BIO in the buffer, or can there be > cases where a larger than normal buffer is passed to the BIO anyway, meaning a manual splitting could be needed nevertheless from time to time? > hey, I just want to point out that we have been using OpenSSL in the libre stack for a long time, with successful deployment. the DTLS code is here: http://www.creytiv.com/doxygen/re-dox/html/tls__udp_8c_source.html we are using 2 different BIOs; one for outgoing, one for incoming: tc->sbio_in = BIO_new(BIO_s_mem()); if (!tc->sbio_in) { ERR_clear_error(); err = ENOMEM; goto out; } tc->sbio_out = BIO_new(&bio_udp_send); if (!tc->sbio_out) { ERR_clear_error(); BIO_free(tc->sbio_in); err = ENOMEM; goto out; } /alfred From lminiero at gmail.com Fri Jun 5 11:16:03 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 13:16:03 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: <55717B33.8060703@db.org> References: <55715E7A.4040109@openssl.org> <55717B33.8060703@db.org> Message-ID: 2015-06-05 12:34 GMT+02:00 Alfred E. Heggestad : > > > On 05/06/15 11:20, Lorenzo Miniero wrote: > >> 2015-06-05 10:31 GMT+02:00 Matt Caswell > matt at openssl.org>>: >> >> >> >> >> On 05/06/15 08:09, Lorenzo Miniero wrote: >> > Hi all, >> > >> > first of all, apologies if this has been asked before. I've >> searched >> > archives pretty much everywhere, and only came to partial >> indications as >> > to how this should be dealt with. >> > >> > The problem I'm facing deals with using DTLS with mem BIOs, as I >> have to >> > take care of transport myself. Specifically, I've implemented a >> WebRTC >> > gateway called Janus, which means all the connectivity related >> stuff is >> > delegated to another library (libnice in this case). This mostly >> works >> > great (kudos to you guys!), but I have problems as soon as packets >> > exceed the MTU, which can easily happen whenever, for instance, >> you try >> > to handshake with certificates larger than 1024 bits. I read >> around that >> > the DTLS stack in OpenSSL automatically deals with this, and in >> fact >> > this seems to be happening: what isn't working is the BIO mem part >> of this. >> > >> > More specifically, OpenSSL does indeed take care of fragmenting the >> > packets according to what is assumed to be the MTU (1472 by >> default, or >> > the value as set in s->d1->mtu). The problem is that the mem BIO >> ignores >> > that fragmentation info completely, and so, when you do an >> BIO_read, >> > makes available at the application the whole packet anyway. This >> results >> > in the whole buffer being passed to nice_agent_send (the method >> libnice >> > exposes to send packets), which means it's just as not fragmenting >> > anything: the packet is too large and the network drops it. You can >> > verify this by using, e.g., a 4096 bits certificate, and capture >> the >> > DTLS traffic with Wireshark: you'll see that the message is >> recognized >> > as composed of not only multiple messages, but also fragments. >> > >> > Is there any way I can force the BIO to return the invididual >> > fragments/messages when I do a BIO_read, so that I can send >> properly >> > sized packets? I've tried looking around but found no insight on >> how to >> > do that. The only approach that came to my mind was to manually >> inspect >> > the buffer that is returned, and split messages/fragments myself, >> but >> > I'd rather avoid delving within the specifics of the protocol if >> possible. >> > >> > Thanks in advance for any help you may provide me with! >> >> Hmmmm. An interesting problem. >> >> The issue is that a mem BIO has no knowledge of datagram semantics >> (perhaps we need to add something for OpenSSL 1.1.0). >> >> In a dgram BIO each BIO_write translates to a single datagram being >> produced. In a mem BIO you just have a big bucket of memory, and every >> time you get a BIO_write you just add the data onto the end of >> everything that we've go so far, and so the packet boundaries are not >> respected. >> >> How about you create a custom filter BIO? All it would need to do is >> proxy all calls down to the underlying mem BIO. Along the way though >> it >> could take note of where the packet boundaries are, so when you call >> BIO_read it only gives it to you a datagram at a time. >> >> Matt >> >> >> >> Thanks for the very quick answer! >> >> Your suggestion does indeed make much more sense that manually inspecting >> the buffer as I thought of, as you don't need to know anything about the >> protocol but >> only to be ready to index the packets you see passing by. I never tried >> writing a BIO filter but there's a first time for everything :-) >> >> Just one quick question about this: are messages/packets passed to the >> BIO actually splitted, and then just queued by the mem BIO in the buffer, >> or can there be >> cases where a larger than normal buffer is passed to the BIO anyway, >> meaning a manual splitting could be needed nevertheless from time to time? >> >> > > hey, > > > I just want to point out that we have been using OpenSSL in the libre > stack for > a long time, with successful deployment. > > > the DTLS code is here: > > http://www.creytiv.com/doxygen/re-dox/html/tls__udp_8c_source.html > > > we are using 2 different BIOs; one for outgoing, one for incoming: > > > > tc->sbio_in = BIO_new(BIO_s_mem()); > if (!tc->sbio_in) { > ERR_clear_error(); > err = ENOMEM; > goto out; > } > > tc->sbio_out = BIO_new(&bio_udp_send); > if (!tc->sbio_out) { > ERR_clear_error(); > BIO_free(tc->sbio_in); > err = ENOMEM; > goto out; > } > > > Hi Alfred, thanks for sharing this. So you've basically created a new BIO source/sink type, and you use that one instead of a mem BIO for sending, right? That might be an interesting approach (e.g., creating a custom BIO based on BIO mem), especially if it turns out that implementing a filter will prove harder than I hope. Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mseaborn62 at hotmail.com Fri Jun 5 13:49:48 2015 From: mseaborn62 at hotmail.com (Mark) Date: Fri, 5 Jun 2015 08:49:48 -0500 Subject: [openssl-users] fipsld linker out of control forking, last step of build Message-ID: MAY BE REPOSTING TRYING TO MOVE FROM NABBLE TO OFFICIAL OPENSSL POSTINGI was wondering if someone has seen this issue before. I am guessing the problem is on my side because can replicate it on Debian 8 and Ubuntu 14.4. I am using OpenSSL 1.0.2c and the crypto module from OpenSSL ecp 2.0.9 env settings CC=/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld FIPSLD_CC=/usr/bin/gcc FIPSDIR=/usr/local/ssl/fips-2.0 for building fips canister ./config fipscanisterbuild no-asm make make install using ./config fips no-asm make make install This seemed to be pretty straight forward. I think i created the fipscanister.o correctly. Everything compiled and linked for the canister. I liked it to a small test app that worked. I then tried to build openssl, it fine but on the last linking step the linker just keep forking processes out of control on both OSs until i got a message that the linker cannot fork any new processes. Any pointers would be appreciated. /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: 174: /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: Cannot fork ../Makefile.shared:164: recipe for target 'link_app.' failed make[2]: *** [link_app.] Error 2 make[2]: Leaving directory '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:153: recipe for target 'openssl' failed make[1]: *** [openssl] Error 2 make[1]: Leaving directory '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:285: recipe for target 'build_apps' failed make: *** [build_apps] Error 1 myssluser at debian8:~/workspace/libs/openssl-1.0.2a$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lminiero at gmail.com Fri Jun 5 16:12:17 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 18:12:17 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> Message-ID: Eureka, I got it working! Thanks to the feedback from Matt and Alfred, I managed to create a filter that does what I need. To those who may be interested, it's available here: https://github.com/meetecho/janus-gateway/pull/254 Thanks for your great support! Lorenzo 2015-06-05 13:34 GMT+02:00 Lorenzo Miniero : > 2015-06-05 12:30 GMT+02:00 Matt Caswell : > >> >> >> On 05/06/15 10:20, Lorenzo Miniero wrote: >> > Just one quick question about this: are messages/packets passed to the >> > BIO actually splitted, and then just queued by the mem BIO in the >> > buffer, or can there be cases where a larger than normal buffer is >> > passed to the BIO anyway, meaning a manual splitting could be needed >> > nevertheless from time to time? >> >> No, there should be no need for the BIO to do any splitting. Everything >> that gets written to the BIO should be a datagram. >> >> One issue that does spring to mind is that in your filter BIO you may >> want to implement some of the dgram ctrls that DTLS uses. This depends >> on how you want to manage setting your MTU. >> >> Do you set an MTU size explicitly using SSL_set_mtu(ssl, mtu) or >> DTLS_set_link_mtu(ssl, mtu)? Also, do you set the option >> SSL_OP_NO_QUERY_MTU? If you use the option then you should set an MTU >> size explicitly. >> >> If you don't set the SSL_OP_NO_QUERY_MTU option then the DTLS code will >> attempt to query the underlying BIO for information about the mtu size. >> That would mean you would have to implement the following additional >> ctrls: >> BIO_CTRL_DGRAM_GET_FALLBACK_MTU - returns a "default" MTU size if >> querying fails for some reason >> BIO_CTRL_DGRAM_QUERY_MTU - queries the transport for the MTU size to be >> used >> BIO_CTRL_DGRAM_SET_MTU - sets the MTU size on the underlying transport >> BIO_CTRL_DGRAM_MTU_EXCEEDED - returns true if the datagram we just tried >> to send failed because we exceeded the max MTU size >> >> Matt >> >> > Hi Matt, > > thanks for the clarification and for the hints. > > I've started looking into filters and I have some doubts, though, also > taking into account what you suggested, and I apologize again if this turns > out to be silly. As far as I've understood, what I should do is changing > the current pattern I use for outgoing packets: > > application < memBIO < ssl > > to something like this: > > application < memBIO < filter < ssl > > or this: > > application < filter < memBIO < ssl > > that is, a new BIO filter that enforces the fragmentation I talked about. > Not exactly sure about which one should be the way to go, but I've given > this some thought. > > The first one seems conceptually correct, in the sense that the filter > receives the properly sized packets from the stack; I see issues in how to > progressively make them available to the memBIO, though, especially > considering that we cannot "relay" a BIO_read call (that is, have the mem > BIO ask for data to the next BIO in the chain when data is requested). My > guess, looking at the BIOs code, is that this is all asynchronous, that is, > the DTLS stack issues a BIO_write that reaches the filter, and then it's > the filter that forwards the written data (modified or not) to the next > BIO, in this case the mem one, using another BIO_write. My concern here is > how to figure out when to issue such a write: in fact, if we want to make > sure that the mem BIO never returns too much data when a BIO_read is > issued, we should never issue a new BIO_write to feed it with new data from > the filter until the previous one has been read, something we cannot do if > we don't know when the data has been read in the first place. > > The second one, as a consequence, may actually be more suited for the > purpose, as we can always only return what we want to in a BIO_read. The > issue there is what I mentioned in my previous post, that is, my fear being > that the memBIO could feed too much data to my filter in a BIO_write, which > would force my filter to inspect the payload and manually split packets as > I'd do in my application. But according to what you said at the beginning > of your reply, this shouldn't be the case, right? That is, the DTLS stack > will issue different BIO_writes towards the memBIO for each > packet/fragment, and this would automatically we forwarded to my filter, am > I correct? Since in this case there wouldn't be any explicit BIO_read done > from the application that may return what's been buffered so far. > > Apologies if I'm adding confusion with these questions, I'm just trying to > figure out the best approach to the new filter. As an alternative, I guess > I could just extend the existing mem BIO to a new, custom BIO, and handle > it all there, but my feeling is that a filter would be a cleaner way to do > that. > > Thanks again! > Lorenzo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lminiero at gmail.com Fri Jun 5 11:34:17 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 13:34:17 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: <55717A46.3040104@openssl.org> References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> Message-ID: 2015-06-05 12:30 GMT+02:00 Matt Caswell : > > > On 05/06/15 10:20, Lorenzo Miniero wrote: > > Just one quick question about this: are messages/packets passed to the > > BIO actually splitted, and then just queued by the mem BIO in the > > buffer, or can there be cases where a larger than normal buffer is > > passed to the BIO anyway, meaning a manual splitting could be needed > > nevertheless from time to time? > > No, there should be no need for the BIO to do any splitting. Everything > that gets written to the BIO should be a datagram. > > One issue that does spring to mind is that in your filter BIO you may > want to implement some of the dgram ctrls that DTLS uses. This depends > on how you want to manage setting your MTU. > > Do you set an MTU size explicitly using SSL_set_mtu(ssl, mtu) or > DTLS_set_link_mtu(ssl, mtu)? Also, do you set the option > SSL_OP_NO_QUERY_MTU? If you use the option then you should set an MTU > size explicitly. > > If you don't set the SSL_OP_NO_QUERY_MTU option then the DTLS code will > attempt to query the underlying BIO for information about the mtu size. > That would mean you would have to implement the following additional ctrls: > BIO_CTRL_DGRAM_GET_FALLBACK_MTU - returns a "default" MTU size if > querying fails for some reason > BIO_CTRL_DGRAM_QUERY_MTU - queries the transport for the MTU size to be > used > BIO_CTRL_DGRAM_SET_MTU - sets the MTU size on the underlying transport > BIO_CTRL_DGRAM_MTU_EXCEEDED - returns true if the datagram we just tried > to send failed because we exceeded the max MTU size > > Matt > > Hi Matt, thanks for the clarification and for the hints. I've started looking into filters and I have some doubts, though, also taking into account what you suggested, and I apologize again if this turns out to be silly. As far as I've understood, what I should do is changing the current pattern I use for outgoing packets: application < memBIO < ssl to something like this: application < memBIO < filter < ssl or this: application < filter < memBIO < ssl that is, a new BIO filter that enforces the fragmentation I talked about. Not exactly sure about which one should be the way to go, but I've given this some thought. The first one seems conceptually correct, in the sense that the filter receives the properly sized packets from the stack; I see issues in how to progressively make them available to the memBIO, though, especially considering that we cannot "relay" a BIO_read call (that is, have the mem BIO ask for data to the next BIO in the chain when data is requested). My guess, looking at the BIOs code, is that this is all asynchronous, that is, the DTLS stack issues a BIO_write that reaches the filter, and then it's the filter that forwards the written data (modified or not) to the next BIO, in this case the mem one, using another BIO_write. My concern here is how to figure out when to issue such a write: in fact, if we want to make sure that the mem BIO never returns too much data when a BIO_read is issued, we should never issue a new BIO_write to feed it with new data from the filter until the previous one has been read, something we cannot do if we don't know when the data has been read in the first place. The second one, as a consequence, may actually be more suited for the purpose, as we can always only return what we want to in a BIO_read. The issue there is what I mentioned in my previous post, that is, my fear being that the memBIO could feed too much data to my filter in a BIO_write, which would force my filter to inspect the payload and manually split packets as I'd do in my application. But according to what you said at the beginning of your reply, this shouldn't be the case, right? That is, the DTLS stack will issue different BIO_writes towards the memBIO for each packet/fragment, and this would automatically we forwarded to my filter, am I correct? Since in this case there wouldn't be any explicit BIO_read done from the application that may return what's been buffered so far. Apologies if I'm adding confusion with these questions, I'm just trying to figure out the best approach to the new filter. As an alternative, I guess I could just extend the existing mem BIO to a new, custom BIO, and handle it all there, but my feeling is that a filter would be a cleaner way to do that. Thanks again! Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mseaborn62 at hotmail.com Fri Jun 5 13:23:24 2015 From: mseaborn62 at hotmail.com (OpenSSL Curious) Date: Fri, 5 Jun 2015 06:23:24 -0700 (MST) Subject: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes In-Reply-To: <1433354131672-58444.post@n7.nabble.com> References: <1433354131672-58444.post@n7.nabble.com> Message-ID: <1433510604481-58471.post@n7.nabble.com> REPOSTING TO PUSH TO OFFICIAL GROUP I was wondering if someone has seen this issue before. I am guessing the problem is on my side because can replicate it on Debian 8 and Ubuntu 14.4. I am using OpenSSL 1.0.2a and the crypto module from OpenSSL ecp 2.0.9 env settings CC=/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld FIPSLD_CC=/usr/bin/gcc FIPSDIR=/usr/local/ssl/fips-2.0 for building fips canister ./config fipscanisterbuild no-asm make make install using ./config fips no-asm make make install This seemed to be pretty straight forward. I think i created the fipscanister.o correctly. Everything compiled and linked for the canister. I liked it to a small test app that worked. I then tried to build openssl, it fine but on the last linking step the linker just keep forking processes out of control on both OSs until i got a message that the linker cannot fork any new processes. Any pointers would be appreciated. /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: 174: /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: Cannot fork ../Makefile.shared:164: recipe for target 'link_app.' failed make[2]: *** [link_app.] Error 2 make[2]: Leaving directory '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:153: recipe for target 'openssl' failed make[1]: *** [openssl] Error 2 make[1]: Leaving directory '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' Makefile:285: recipe for target 'build_apps' failed make: *** [build_apps] Error 1 mssluser at debian8:~/workspace/libs/openssl-1.0.2a$ -- View this message in context: http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58471.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From mseaborn62 at hotmail.com Fri Jun 5 13:24:11 2015 From: mseaborn62 at hotmail.com (OpenSSL Curious) Date: Fri, 5 Jun 2015 06:24:11 -0700 (MST) Subject: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes In-Reply-To: <1433354131672-58444.post@n7.nabble.com> References: <1433354131672-58444.post@n7.nabble.com> Message-ID: <1433510651391-58472.post@n7.nabble.com> -- View this message in context: http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58472.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From foleyj at cisco.com Fri Jun 5 17:42:46 2015 From: foleyj at cisco.com (John Foley) Date: Fri, 05 Jun 2015 13:42:46 -0400 Subject: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes In-Reply-To: <1433510604481-58471.post@n7.nabble.com> References: <1433354131672-58444.post@n7.nabble.com> <1433510604481-58471.post@n7.nabble.com> Message-ID: <5571DF96.9060902@cisco.com> Well, since you're using the fips-ecp tarball, you'll need to include no-ec2m when configuring OpenSSL 1.0.2a. But this isn't why you're seeing a fork error from fipsld. I'm using Ubuntu 14.04 (Is there a 14.4?) and don't see any issue. However, I'm not setting CC, FIPSLD and FIPSDIR. You shouldn't have to set these. Also, you're not doing a "make depend" after the config for OpenSSL 1.0.2a. Here's a summary of the procedure that worked for me: wget --no-check-certificate https://www.openssl.org/source/openssl-1.0.2a.tar.gz wget --no-check-certificate https://www.openssl.org/source/openssl-fips-ecp-2.0.9.tar.gz tar -xzvf openssl-fips-ecp-2.0.9.tar.gz cd openssl-fips-ecp-2.0.9/ ./config fipscanisteronly no-asm --prefix=/nobackup/tmp/x88/fips make make install cd .. tar -xzvf openssl-1.0.2a.tar.gz cd openssl-1.0.2a/ ./config fips no-ec2m no-asm --with-fipsdir=/nobackup/tmp/x88/fips make depend make clean make On 06/05/2015 09:23 AM, OpenSSL Curious wrote: > REPOSTING TO PUSH TO OFFICIAL GROUP > I was wondering if someone has seen this issue before. I am guessing the > problem is on my side because can replicate it on Debian 8 and Ubuntu 14.4. > > I am using OpenSSL 1.0.2a and the crypto module from OpenSSL ecp 2.0.9 > > env settings > CC=/home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld > FIPSLD_CC=/usr/bin/gcc > FIPSDIR=/usr/local/ssl/fips-2.0 > > for building fips canister > ./config fipscanisterbuild no-asm > make > make install > > using ./config fips no-asm > make > make install > > This seemed to be pretty straight forward. I think i created the > fipscanister.o correctly. Everything compiled and linked for the canister. I > liked it to a small test app that worked. > > I then tried to build openssl, it fine but on the last linking step the > linker just keep forking processes out of control on both OSs until i got a > message that the linker cannot fork any new processes. Any pointers would be > appreciated. > > /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: 174: > /home/myssluser/workspace/libs/openssl-fips-ecp-2.0.9/fips/fipsld: Cannot > fork > ../Makefile.shared:164: recipe for target 'link_app.' failed > make[2]: *** [link_app.] Error 2 > make[2]: Leaving directory > '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' > Makefile:153: recipe for target 'openssl' failed > make[1]: *** [openssl] Error 2 > make[1]: Leaving directory > '/home/myssluser/workspace/libs/openssl-1.0.2a/apps' > Makefile:285: recipe for target 'build_apps' failed > make: *** [build_apps] Error 1 > mssluser at debian8:~/workspace/libs/openssl-1.0.2a$ > > > > -- > View this message in context: http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58471.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 matt at openssl.org Fri Jun 5 18:18:50 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 05 Jun 2015 19:18:50 +0100 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> Message-ID: <5571E80A.1010406@openssl.org> I see you got it working! Just some comments below On 05/06/15 12:34, Lorenzo Miniero wrote: > I've started looking into filters and I have some doubts, though, also > taking into account what you suggested, and I apologize again if this > turns out to be silly. As far as I've understood, what I should do is > changing the current pattern I use for outgoing packets: > > application < memBIO < ssl > > to something like this: > > application < memBIO < filter < ssl > > or this: > > application < filter < memBIO < ssl > > that is, a new BIO filter that enforces the fragmentation I talked > about. Not exactly sure about which one should be the way to go, but > I've given this some thought. I took a very brief look at your code and I see you went with the first option. That's fine, although I would have done it slightly differently: application <-- -- ssl | | | V filter ^ V memBIO i.e. the filter does all the reading and writing to the memBIO. libssl calls BIO_write(), the filter takes note of the packet sizes, and then writes to the membBIO. When the application wants to read data it calls BIO_read on the filter, and the filter figures out how big the packet needs to be and reads that amount out of the memBIO. Your way works too though. Matt From lminiero at gmail.com Fri Jun 5 18:42:08 2015 From: lminiero at gmail.com (Lorenzo Miniero) Date: Fri, 5 Jun 2015 20:42:08 +0200 Subject: [openssl-users] DTLS fragmentation and mem BIO In-Reply-To: <5571E80A.1010406@openssl.org> References: <55715E7A.4040109@openssl.org> <55717A46.3040104@openssl.org> <5571E80A.1010406@openssl.org> Message-ID: 2015-06-05 20:18 GMT+02:00 Matt Caswell : > > I see you got it working! Just some comments below > > On 05/06/15 12:34, Lorenzo Miniero wrote: > > I've started looking into filters and I have some doubts, though, also > > taking into account what you suggested, and I apologize again if this > > turns out to be silly. As far as I've understood, what I should do is > > changing the current pattern I use for outgoing packets: > > > > application < memBIO < ssl > > > > to something like this: > > > > application < memBIO < filter < ssl > > > > or this: > > > > application < filter < memBIO < ssl > > > > that is, a new BIO filter that enforces the fragmentation I talked > > about. Not exactly sure about which one should be the way to go, but > > I've given this some thought. > > I took a very brief look at your code and I see you went with the first > option. That's fine, although I would have done it slightly differently: > > application <-- -- ssl > | | > | V > filter > ^ V > memBIO > > i.e. the filter does all the reading and writing to the memBIO. libssl > calls BIO_write(), the filter takes note of the packet sizes, and then > writes to the membBIO. When the application wants to read data it calls > BIO_read on the filter, and the filter figures out how big the packet > needs to be and reads that amount out of the memBIO. Your way works too > though. > > Matt > Ah I didn't know that was an option: I'm quite unfamiliar with how BIO filters worked, and so I just went with what made sense to me while experimenting with them. I'll try doing something along the lines you suggested as soon as I have some time, thanks! Lorenzo -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinelight at shininglightpro.com Sat Jun 6 03:12:11 2015 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Fri, 05 Jun 2015 20:12:11 -0700 Subject: [openssl-users] OpenSSL.cnf File path In-Reply-To: <001301d09f03$80cb4db0$8261e910$@vdtg.com> References: <001301d09f03$80cb4db0$8261e910$@vdtg.com> Message-ID: <5572650B.4000601@shininglightpro.com> On 6/4/2015 1:17 PM, Cathy Fauntleroy wrote: > Hello, > > I have OpenSSL 1.0.2a installed on my Windows 7 box. I am attempting to > generate a CSR so new security certificates can be issued and am running > into the following error when the command to generate the .csr file is > issued from the C:\OpenSSL-Win64\bin directory: > > WARNING: can't open config file: /usr/local/ssl/openssl.cnf > > Unable to load config info from /usr/local/ssl/openssl.cnf > > This is not a valid path on my Windows box.openssl.cnf resides in > C:\OpenSSL-Win64\bin. I verified the system PATH is correct also. Any > ideas? > > Thanks. > > Cathy Reboot your computer. The installer failed to notify all windows of the declaration of OPENSSL_CONF. A reboot corrects the issue. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From matt at openssl.org Mon Jun 8 19:32:47 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 08 Jun 2015 20:32:47 +0100 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: <5575EDDF.1070009@openssl.org> -----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.2b, 1.0.1n, 1.0.0s and 0.9.8zg. These releases will be made available on Thursday 11th June. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as "moderate" severity (see https://www.openssl.org/about/secpolicy.html). Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVde3fAAoJENnE0m0OYESRIokH+QFLMvyyCxztRQGRm54oxOGA WugDkHsonM6meJp8TPqjnSrvk5xmKT1FFL+9lZ/7V/Y/ImhjSkxAp1j3mbA3Drw0 UoDEO59hA2ZuKtLMIIgSRH+BTUIO0wHuVDURiVRBkj0A1shlI21uoRcJFNoAuGMQ 9wymbc5lIkN3OEUYKh5QW/izmdTFEYeNBDSndTO0kg5koymRTf68gCEtQ5sh3zFB Hnmx3rEsEr8NbWxrvHly2rPLcy8TluIe/uiIG3FBF/acyW/4KWFqvf994eCQYenw JG57Hv64TZa7dTmmjBNZgkrN8wM89SEW3pLCRmqkbBfQ12IByJC8dYNR8ieOp9g= =eGiv -----END PGP SIGNATURE----- From naynjain at in.ibm.com Tue Jun 9 04:21:52 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Tue, 9 Jun 2015 09:51:52 +0530 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? Message-ID: Hi, I need to verify if the certifiate I have received is having its content in PEM/DER format. Is there any API which if given file pointer like (fp) will tell me whether it has valid format of certificate and if yes then whether it is PEM/DER format ? If no API, then what is the other way to verify this ? Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jun 9 05:03:47 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 9 Jun 2015 05:03:47 +0000 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: References: Message-ID: <20150609050347.GM5512@mournblade.imrryr.org> [ Please DO NOT post user questions to openssl-dev, that's rude. ] On Tue, Jun 09, 2015 at 09:51:52AM +0530, Nayna Jain wrote: > I need to verify if the certifiate I have received is having its content in > PEM/DER format. > > Is there any API which if given file pointer like (fp) will tell me whether > it has valid format of certificate and if yes then whether it is PEM/DER > format ? > > If no API, then what is the other way to verify this ? If the first character of the file is 0x30 (ASN.1 sequence) it is likely in DER form. With stdio you can peek at that character and use ungetc() to put it back. The only false positives for DER will be files in which the PEM '-----BEGIN ...-----' line is preceded by "comment" text that happens to start with a '0'. If your PEM files contain no "comments", the test is always accurate. A more robust test is to try PEM_read_X509() or PEM_read_bio_X509() and if that fails, rewind the file, and try d2i_X509_fp() or d2i_X509_bio(). The latter need not be tried if the first character of the file is not 0x30. -- Viktor. From Anna.Kawecka at pega.com Tue Jun 9 11:37:48 2015 From: Anna.Kawecka at pega.com (Kawecka, Anna) Date: Tue, 9 Jun 2015 11:37:48 +0000 Subject: [openssl-users] Compiling openssl fips for iOS 7.1 on Yosemite Message-ID: Hello, I have problems with compiling Openssl FIPS library for iOS 7.1 (openssl-fips 2.0.9) on Yosemite (using Xcode 6.2). After checking few build scripts available on net (mainly for older versions of openssl-fips library) I came across the testing instructions ( http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/TestingInstructions-iOS-7.1.pdf). I?ve tried to compile it with the openssl-fips 2.0.10 (which contains the patches described in instruction). Nevertheless I've stuck on cross compilation of FIPS module. The problem is: ld: building for iOS Simulator, but linking against dylib built for MacOSX file '/usr/lib/libSystem.dylib' for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) What I?m doing wrong? Is there a known issue (or maybe some workaround) about compiling the Openssl FIPS library on Yosemite? I would appreciate any help. * Instructions: http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/TestingInstructions-iOS-7.1.pdf * Source files: http://opensslfoundation.com/testing/validation-2.0/source/openssl-fips-2.0.10.tar.gz * Build scripts: http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/ * Environment: $ uname -a Darwin lkaweaosxeu.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 $ sw_vers -productVersion 10.10.3 $ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz * Error: (log files attached) ld: building for iOS Simulator, but linking against dylib built for MacOSX file '/usr/lib/libSystem.dylib' for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [../fips_standalone_sha1] Error 1 make[2]: *** [subdirs] Error 1 make[1]: *** [all] Error 2 make: *** [build_fips] Error 1 * The attached iOS-7.1.zip containing files I used for compiling. * The output from myBuild-step1-compilationOfIncoreMacho.sh (instructions from chapter 4.3) is in file log-step1-compilationOfIncoreMacho.log * The output from myBuild-step2-crossCompilationOfFIPS.sh (instructions from chapter 4.4) is in file log-step2-crossCompilationOfFIPS.log Thanks in advance, Anna Kawecka -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Jun 9 12:14:17 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 9 Jun 2015 08:14:17 -0400 Subject: [openssl-users] Compiling openssl fips for iOS 7.1 on Yosemite In-Reply-To: References: Message-ID: > The problem is: > ld: building for iOS Simulator, but linking against dylib built for MacOSX > file '/usr/lib/libSystem.dylib' for architecture i386 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) There's no reason to build the Simulator as FIPS. Its not distributed. But, if you must, then setenv-ios.sh uses the wrong SDK for the Simulator. The script uses the iOS SDK, and not the simulator SDK. ***** Going back to *not* building for the Simulator... usually, you can do something like the following. You will still need to link to an OpenSSL; you can just avoid the FIPS aggravations. # include "TargetConditionals.h" # if defined(TARGET_IPHONE_SIMULATOR) && (TARGET_IPHONE_SIMULATOR != 0) # define OPENSSL_IPHONE_SIMULATOR 1 # elif defined(TARGET_OS_IPHONE) && (TARGET_OS_IPHONE != 0) # define OPENSSL_IPHONE 1 # elif defined(TARGET_OS_MAC) && (TARGET_OS_MAC != 0) # define OPENSSL_MAC_OSX 1 # else # error Unknown Apple platform # endif // Enable FIPS for iOS. Skip if for the Simulator #ifdef OPENSSL_IPHONE int rc = FIPS_mode_set(1); assert(rc == 1); #endif // Use OpenSSL as normal... Jeff On Tue, Jun 9, 2015 at 7:37 AM, Kawecka, Anna wrote: > Hello, > > I have problems with compiling Openssl FIPS library for iOS 7.1 > (openssl-fips 2.0.9) on Yosemite (using Xcode 6.2). > > After checking few build scripts available on net (mainly for older versions > of openssl-fips library) I came across the testing instructions ( > http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/TestingInstructions-iOS-7.1.pdf). > I?ve tried to compile it with the openssl-fips 2.0.10 (which contains the > patches described in instruction). Nevertheless I've stuck on cross > compilation of FIPS module. > > The problem is: > ld: building for iOS Simulator, but linking against dylib built for MacOSX > file '/usr/lib/libSystem.dylib' for architecture i386 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > What I?m doing wrong? Is there a known issue (or maybe some workaround) > about compiling the Openssl FIPS library on Yosemite? > I would appreciate any help. > > Instructions: > http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/TestingInstructions-iOS-7.1.pdf > Source files: > http://opensslfoundation.com/testing/validation-2.0/source/openssl-fips-2.0.10.tar.gz > Build scripts: > http://opensslfoundation.com/testing/validation-2.0/platforms/ios-7.1/ > Environment: > > $ uname -a > > Darwin lkaweaosxeu.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 > 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64 > $ sw_vers -productVersion > 10.10.3 > $ sysctl -n machdep.cpu.brand_string > Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz > > > Error: (log files attached) > > ld: building for iOS Simulator, but linking against dylib built for MacOSX > file '/usr/lib/libSystem.dylib' for architecture i386 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[3]: *** [../fips_standalone_sha1] Error 1 > make[2]: *** [subdirs] Error 1 > make[1]: *** [all] Error 2 > make: *** [build_fips] Error 1 > > The attached iOS-7.1.zip containing files I used for compiling. > > The output from myBuild-step1-compilationOfIncoreMacho.sh (instructions from > chapter 4.3) is in file log-step1-compilationOfIncoreMacho.log > The output from myBuild-step2-crossCompilationOfFIPS.sh (instructions from > chapter 4.4) is in file log-step2-crossCompilationOfFIPS.log > From mseaborn62 at hotmail.com Tue Jun 9 18:38:22 2015 From: mseaborn62 at hotmail.com (OpenSSL Curious) Date: Tue, 9 Jun 2015 11:38:22 -0700 (MST) Subject: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes In-Reply-To: <5571DF96.9060902@cisco.com> References: <1433354131672-58444.post@n7.nabble.com> <1433510604481-58471.post@n7.nabble.com> <5571DF96.9060902@cisco.com> Message-ID: <1433875102741-58544.post@n7.nabble.com> Thanks for the reply and I may be getting closer to the answer. One of the steps you listed was to do a "make depend" usually did a "make clean" but, i suppose, i should get the "make depend" working. Using the commands you have posted the make depend fails to find the "fips.h" file. I see it in the /usr/local/ssl/fips-2.0/include directory and I have tried "export FIPSDIR=/usr/local/ssl/fips-2.0" but it still does not pick it up. Is there an environment variable that I am missing? Thanks -- View this message in context: http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58544.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From naynjain at in.ibm.com Wed Jun 10 03:18:41 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Wed, 10 Jun 2015 08:48:41 +0530 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: <20150609050347.GM5512@mournblade.imrryr.org> References: <20150609050347.GM5512@mournblade.imrryr.org> Message-ID: Thanks.. I think I will try with X509_read_xxx and d2i_, then probably do not have to read throu first character as 0x30. I had few more questions. Are all d2i_xxx type of APIs for DER format. And if I have to operate on DER formatted certs, do I need to first convert it to PEM and then user PEM APIs. or there are DER specific APIs also, I didn't find though, unless they are d2i_xxx types. Thanks & Regards, Nayna Jain From: Viktor Dukhovni To: openssl-users at openssl.org Date: 06/09/2015 10:34 AM Subject: Re: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? Sent by: "openssl-users" [ Please DO NOT post user questions to openssl-dev, that's rude. ] On Tue, Jun 09, 2015 at 09:51:52AM +0530, Nayna Jain wrote: > I need to verify if the certifiate I have received is having its content in > PEM/DER format. > > Is there any API which if given file pointer like (fp) will tell me whether > it has valid format of certificate and if yes then whether it is PEM/DER > format ? > > If no API, then what is the other way to verify this ? If the first character of the file is 0x30 (ASN.1 sequence) it is likely in DER form. With stdio you can peek at that character and use ungetc() to put it back. The only false positives for DER will be files in which the PEM '-----BEGIN ...-----' line is preceded by "comment" text that happens to start with a '0'. If your PEM files contain no "comments", the test is always accurate. A more robust test is to try PEM_read_X509() or PEM_read_bio_X509() and if that fails, rewind the file, and try d2i_X509_fp() or d2i_X509_bio(). The latter need not be tried if the first character of the file is not 0x30. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From naynjain at in.ibm.com Wed Jun 10 03:22:05 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Wed, 10 Jun 2015 08:52:05 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it Message-ID: Hi all, I am using X509_STORE and X509_LOOKUP to verify the certificate and its chain. But at the end when I do X509_STORE_free(store) and X509_LOOKUP_free (lookup), it is also doing free of the X509* certificate which I added. But I don't want that, because after that when I immediately try to access X509* certificate for further operation, then it results in core dump And if I don't do X509_STORE_free() then it will leave the memory leak. Let me know how to resolve this and if I misunderstood something. Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jun 10 04:18:52 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Jun 2015 06:18:52 +0200 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: Message-ID: <5577BAAC.7020208@wisemo.com> On 10/06/2015 05:22, Nayna Jain wrote: > > Hi all, > > I am using X509_STORE and X509_LOOKUP to verify the certificate and > its chain. > > But at the end when I do X509_STORE_free(store) and > X509_LOOKUP_free(lookup), it is also doing free of the X509* > certificate which I added. > But I don't want that, because after that when I immediately try to > access X509* certificate for further operation, then it results in > core dump > > And if I don't do X509_STORE_free() then it will leave the memory leak. > > Let me know how to resolve this and if I misunderstood something. > X509 objects (and many other objects in the API) are reference counted. Increment the reference count of each certificate as you add it to the X509_STORE, this should make the X509 object stay around after X509_STORE_free() frees it. However there is a shortage of documentation on the reference counting functions involved. 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 openssl-users at dukhovni.org Wed Jun 10 04:47:24 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Jun 2015 04:47:24 +0000 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: References: <20150609050347.GM5512@mournblade.imrryr.org> Message-ID: <20150610044723.GB2050@mournblade.imrryr.org> On Wed, Jun 10, 2015 at 08:48:41AM +0530, Nayna Jain wrote: > I think I will try with PEM_read_xxx and d2i_, then probably do not have > to read throu first character as 0x30. That works, provided you rewind or re-open the file. > Are all d2i_xxx type of APIs for DER format. Yes, they decode binary ASN.1 encodings of the relevant structures. And conversely i2d_... encodes a C structure to ASN.1 (typically DER) form. > > And if I have to operate on DER formatted certs, do I need to first convert > it to PEM and then user PEM APIs. or there are DER specific APIs also, I > didn't find though, unless they are d2i_xxx types. I don't see why you would need to convert to PEM first, though there are legitimate reasons to do so when you need to write configuration files to disk, as PEM is easier to work with as a configuration format. -- Viktor. From naynjain at in.ibm.com Wed Jun 10 04:50:37 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Wed, 10 Jun 2015 10:20:37 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: <5577BAAC.7020208@wisemo.com> References: <5577BAAC.7020208@wisemo.com> Message-ID: Thanks Jacob, So, does that API do not increment reference count internally itself. I mean if I have to explicitly do that, what is the API for that ? Thanks & Regards, Nayna Jain From: Jakob Bohm To: openssl-users at openssl.org Date: 06/10/2015 09:49 AM Subject: Re: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it Sent by: "openssl-users" On 10/06/2015 05:22, Nayna Jain wrote: Hi all, I am using X509_STORE and X509_LOOKUP to verify the certificate and its chain. But at the end when I do X509_STORE_free(store) ?and X509_LOOKUP_free (lookup), it is also doing free of the X509* certificate which I added. But I don't want that, because after that when I immediately try to access X509* certificate for further operation, then it results in core dump And if I don't do X509_STORE_free() then it will leave the memory leak. Let me know how to resolve this and if I misunderstood something. X509 objects (and many other objects in the API) are reference counted. Increment the reference count of each certificate as you add it to the X509_STORE, this should make the X509 object stay around after X509_STORE_free() frees it. However there is a shortage of documentation on the reference counting functions involved. 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From wangqun at alumni.nus.edu.sg Wed Jun 10 07:47:05 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Wed, 10 Jun 2015 00:47:05 -0700 (MST) Subject: [openssl-users] The default cipher of executable 'openssl' Message-ID: <1433922425304-58557.post@n7.nabble.com> Hello, We are using executable 'apps/openssl' in our test cases. We upgraded from OpenSSL 1.0.1l to OpenSSL 1.0.2a recently. Since then one of our test cases started to fail. After checking, I noticed that the default cipher of 'openssl' was changed from ECDHE-RSA-AES256-SHA to DHE-RSA-AES256-SHA in OpenSSL 1.0.2. The related description in OpenSSL 1.0.2 change log is as follows. 474 *) Support for automatic EC temporary key parameter selection. If enabled 475 the most preferred EC parameters are automatically used instead of 476 hardcoded fixed parameters. Now a server just has to call: 477 SSL_CTX_set_ecdh_auto(ctx, 1) and the server will automatically 478 support ECDH and use the most appropriate parameters. 479 [Steve Henson] My question is how to enable automatic EC temporary key parameter selection? Is it possible to change the default cipher back to ECDHE-RSA-AES256-SHA? Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/The-default-cipher-of-executable-openssl-tp58557.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From thulasi.goriparthi at gmail.com Wed Jun 10 10:41:45 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 10 Jun 2015 16:11:45 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: <5577BAAC.7020208@wisemo.com> Message-ID: X509_STORE_add_cert increments the reference count of the each cert, but only by 1. X509_STORE_free decrements the ref count by 1. So after decrementing, if ref_count is 0, certificate will be freed. Jakob is saying that if you want them to stay even after X509_STORE_free, explicitly increment the ref count before calling free using something like below. CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); decrypt the ref count when you really want to free them and call X509_free(certificate). On 10 June 2015 at 10:20, Nayna Jain wrote: > Thanks Jacob, > So, does that API do not increment reference count internally itself. > > I mean if I have to explicitly do that, what is the API for that ? > > Thanks & Regards, > Nayna Jain > > [image: Inactive hide details for Jakob Bohm ---06/10/2015 09:49:54 > AM---On 10/06/2015 05:22, Nayna Jain wrote: >]Jakob Bohm ---06/10/2015 > 09:49:54 AM---On 10/06/2015 05:22, Nayna Jain wrote: > > > From: Jakob Bohm > To: openssl-users at openssl.org > Date: 06/10/2015 09:49 AM > Subject: Re: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() > also frees the X509 certificates inside it > Sent by: "openssl-users" > ------------------------------ > > > > > On 10/06/2015 05:22, Nayna Jain wrote: > > > Hi all, > > I am using X509_STORE and X509_LOOKUP to verify the certificate and > its chain. > > But at the end when I do X509_STORE_free(store) and > X509_LOOKUP_free(lookup), it is also doing free of the X509* certificate > which I added. > But I don't want that, because after that when I immediately try to > access X509* certificate for further operation, then it results in core dump > > And if I don't do X509_STORE_free() then it will leave the memory leak. > > Let me know how to resolve this and if I misunderstood something. > > > X509 objects (and many other objects in the API) are > reference counted. > > Increment the reference count of each certificate as > you add it to the X509_STORE, this should make the > X509 object stay around after X509_STORE_free() frees > it. > > However there is a shortage of documentation on the > reference counting functions involved. > > 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 > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From jb-openssl at wisemo.com Wed Jun 10 11:17:41 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Jun 2015 13:17:41 +0200 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: <5577BAAC.7020208@wisemo.com> Message-ID: <55781CD5.9030807@wisemo.com> On 10/06/2015 12:41, Thulasi Goriparthi wrote: > X509_STORE_add_cert increments the reference count of the each cert, > but only by 1. Sounds like there should be X509_STORE_add0_cert() and X509_STORE_add1_cert() like for other parts of the library. > X509_STORE_free decrements the ref count by 1. So after decrementing, > if ref_count is 0, certificate will be freed. > > Jakob is saying that if you want them to stay even after > X509_STORE_free, explicitly increment the ref count before calling > free using something like below. > Interesting! I assumed (based on the standard refcounting paradigm) that the reference count of a new object would be 1, and that some API (perhaps X509_free()) would decrement and free if it hit 0. > CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); > Is there really no proper API wrapping this? > > decrypt the ref count when you really want to free them and call > X509_free(certificate). > Is there really no proper API wrapping this? > > On 10 June 2015 at 10:20, Nayna Jain > wrote: > > Thanks Jacob, > So, does that API do not increment reference count internally itself. > > I mean if I have to explicitly do that, what is the API for that ? > > Thanks & Regards, > Nayna Jain > > Inactive hide details for Jakob Bohm ---06/10/2015 09:49:54 > AM---On 10/06/2015 05:22, Nayna Jain wrote: >Jakob Bohm > ---06/10/2015 09:49:54 AM---On 10/06/2015 05:22, Nayna Jain wrote: > > > From: Jakob Bohm > > To: openssl-users at openssl.org > Date: 06/10/2015 09:49 AM > Subject: Re: [openssl-users] X509_STORE_free() and > X509_LOOKUP_free() also frees the X509 certificates inside it > Sent by: "openssl-users" > > > ------------------------------------------------------------------------ > > > > > On 10/06/2015 05:22, Nayna Jain wrote: > > > Hi all, > > I am using X509_STORE and X509_LOOKUP to verify the > certificate and its chain. > > But at the end when I do X509_STORE_free(store) and > X509_LOOKUP_free(lookup), it is also doing free of the X509* > certificate which I added. > But I don't want that, because after that when I immediately > try to access X509* certificate for further operation, then it > results in core dump > > And if I don't do X509_STORE_free() then it will leave the > memory leak. > > Let me know how to resolve this and if I misunderstood something. > > > X509 objects (and many other objects in the API) are > reference counted. > > Increment the reference count of each certificate as > you add it to the X509_STORE, this should make the > X509 object stay around after X509_STORE_free() frees > it. > > However there is a shortage of documentation on the > reference counting functions involved. > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 105 bytes Desc: not available URL: From oyljerry at gmail.com Wed Jun 10 11:40:54 2015 From: oyljerry at gmail.com (Jerry OELoo) Date: Wed, 10 Jun 2015 19:40:54 +0800 Subject: [openssl-users] The openssl can verify certificate chain successful when no any root CA files Message-ID: Hi, I am using openssl 1.0.2 on windows. as on windows, openssl could not use os's default root ca folder as on ubuntu (/etc/ssl/certs). and I do not use X509_STORE_add_cert() to add any root ca certificate files. But when I use X509_verify_cert() to verify certificate that I get from some url (ex. https://www.google.com), I found it will return 1. why it can be pass verified even I do not set any root CA files on windows. As I thought, we need root ca PEM files to verify certificate chain. Thanks~ -- Rejoice,I Desire! From thulasi.goriparthi at gmail.com Wed Jun 10 12:35:44 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 10 Jun 2015 18:05:44 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: <55781CD5.9030807@wisemo.com> References: <5577BAAC.7020208@wisemo.com> <55781CD5.9030807@wisemo.com> Message-ID: On 10 June 2015 at 16:47, Jakob Bohm wrote: > On 10/06/2015 12:41, Thulasi Goriparthi wrote: > > X509_STORE_add_cert increments the reference count of the each cert, > but only by 1. > > Sounds like there should be X509_STORE_add0_cert() and > X509_STORE_add1_cert() like for other parts of the library. > > X509_STORE_free decrements the ref count by 1. So after decrementing, if > ref_count is 0, certificate will be freed. > > Jakob is saying that if you want them to stay even after X509_STORE_free, > explicitly increment the ref count before calling free using something like > below. > > Interesting! I assumed (based on the standard > refcounting paradigm) that the reference count of a > new object would be 1, and that some API (perhaps > X509_free()) would decrement and free if it hit 0. > Yes. You are correct. STORE_free, just decrements the ref count and calls X509_free. X509_free in turn checks if ref count is only 1 (in reference to the one incremented by new) before proceeding with free. If it is, it will decrement ref_count and proceed to free. > CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); > > Is there really no proper API wrapping this? > I couldn't find any right now. There is X509_OBJECT_up_ref_count() which takes care of X509_OBJECT s. But that requires allocating X509_OBJECT and copying X509 over there. > > decrypt the ref count when you really want to free them and call > X509_free(certificate). > > Is there really no proper API wrapping this? > > > On 10 June 2015 at 10:20, Nayna Jain wrote: > >> Thanks Jacob, >> So, does that API do not increment reference count internally itself. >> >> I mean if I have to explicitly do that, what is the API for that ? >> >> Thanks & Regards, >> Nayna Jain >> >> [image: Inactive hide details for Jakob Bohm ---06/10/2015 09:49:54 >> AM---On 10/06/2015 05:22, Nayna Jain wrote: >]Jakob Bohm ---06/10/2015 >> 09:49:54 AM---On 10/06/2015 05:22, Nayna Jain wrote: > >> >> From: Jakob Bohm >> To: openssl-users at openssl.org >> Date: 06/10/2015 09:49 AM >> Subject: Re: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() >> also frees the X509 certificates inside it >> Sent by: "openssl-users" >> ------------------------------ >> >> >> >> >> On 10/06/2015 05:22, Nayna Jain wrote: >> >> >> Hi all, >> >> I am using X509_STORE and X509_LOOKUP to verify the certificate and >> its chain. >> >> But at the end when I do X509_STORE_free(store) and >> X509_LOOKUP_free(lookup), it is also doing free of the X509* certificate >> which I added. >> But I don't want that, because after that when I immediately try to >> access X509* certificate for further operation, then it results in core dump >> >> And if I don't do X509_STORE_free() then it will leave the memory >> leak. >> >> Let me know how to resolve this and if I misunderstood something. >> >> >> X509 objects (and many other objects in the API) are >> reference counted. >> >> Increment the reference count of each certificate as >> you add it to the X509_STORE, this should make the >> X509 object stay around after X509_STORE_free() frees >> it. >> >> However there is a shortage of documentation on the >> reference counting functions involved. >> >> > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 105 bytes Desc: not available URL: From thulasi.goriparthi at gmail.com Wed Jun 10 13:08:10 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 10 Jun 2015 18:38:10 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: <5577BAAC.7020208@wisemo.com> <55781CD5.9030807@wisemo.com> Message-ID: On 10 June 2015 at 18:05, Thulasi Goriparthi wrote: > > > On 10 June 2015 at 16:47, Jakob Bohm wrote: > >> On 10/06/2015 12:41, Thulasi Goriparthi wrote: >> >> X509_STORE_add_cert increments the reference count of the each cert, >> but only by 1. >> >> Sounds like there should be X509_STORE_add0_cert() and >> X509_STORE_add1_cert() like for other parts of the library. >> >> X509_STORE_free decrements the ref count by 1. So after decrementing, >> if ref_count is 0, certificate will be freed. >> >> Jakob is saying that if you want them to stay even after X509_STORE_free, >> explicitly increment the ref count before calling free using something like >> below. >> >> Interesting! I assumed (based on the standard >> refcounting paradigm) that the reference count of a >> new object would be 1, and that some API (perhaps >> X509_free()) would decrement and free if it hit 0. >> > > Yes. You are correct. STORE_free, just decrements the ref count and calls > X509_free. > X509_free in turn checks if ref count is only 1 (in reference to the one > incremented by new) before proceeding with free. If it is, it will > decrement ref_count and proceed to free. > Correction: X509_free or any free, just decrements the ref_count first and then if it is 0, it will proceed to real free. So, if there is any explicit up ref count, there is no need to decrement it (shouldn't be decremented) before calling X509_free > >> CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); >> >> Is there really no proper API wrapping this? >> > > I couldn't find any right now. There is X509_OBJECT_up_ref_count() which > takes care of X509_OBJECT s. But that requires allocating X509_OBJECT and > copying X509 over there. > >> >> decrypt the ref count when you really want to free them and call >> X509_free(certificate). >> >> Sorry for the confusion, decrementing ref count wouldn't be required. > Is there really no proper API wrapping this? >> >> >> On 10 June 2015 at 10:20, Nayna Jain wrote: >> >>> Thanks Jacob, >>> So, does that API do not increment reference count internally itself. >>> >>> I mean if I have to explicitly do that, what is the API for that ? >>> >>> Thanks & Regards, >>> Nayna Jain >>> >>> [image: Inactive hide details for Jakob Bohm ---06/10/2015 09:49:54 >>> AM---On 10/06/2015 05:22, Nayna Jain wrote: >]Jakob Bohm ---06/10/2015 >>> 09:49:54 AM---On 10/06/2015 05:22, Nayna Jain wrote: > >>> >>> From: Jakob Bohm >>> To: openssl-users at openssl.org >>> Date: 06/10/2015 09:49 AM >>> Subject: Re: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() >>> also frees the X509 certificates inside it >>> Sent by: "openssl-users" >>> ------------------------------ >>> >>> >>> >>> >>> On 10/06/2015 05:22, Nayna Jain wrote: >>> >>> >>> Hi all, >>> >>> I am using X509_STORE and X509_LOOKUP to verify the certificate and >>> its chain. >>> >>> But at the end when I do X509_STORE_free(store) and >>> X509_LOOKUP_free(lookup), it is also doing free of the X509* certificate >>> which I added. >>> But I don't want that, because after that when I immediately try to >>> access X509* certificate for further operation, then it results in core dump >>> >>> And if I don't do X509_STORE_free() then it will leave the memory >>> leak. >>> >>> Let me know how to resolve this and if I misunderstood something. >>> >>> >>> X509 objects (and many other objects in the API) are >>> reference counted. >>> >>> Increment the reference count of each certificate as >>> you add it to the X509_STORE, this should make the >>> X509 object stay around after X509_STORE_free() frees >>> it. >>> >>> However there is a shortage of documentation on the >>> reference counting functions involved. >>> >>> >> >> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 105 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Jun 10 13:15:27 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 10 Jun 2015 13:15:27 +0000 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: <5577BAAC.7020208@wisemo.com> Message-ID: <20150610131526.GC2050@mournblade.imrryr.org> On Wed, Jun 10, 2015 at 04:11:45PM +0530, Thulasi Goriparthi wrote: > Jakob is saying that if you want them to stay even after X509_STORE_free, > explicitly increment the ref count before calling free using something like > below. > > CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); That should be: CRYPTO_add(&certificate->references, 1, CRYPTO_LOCK_X509); the references parameter should be a pointer. -- Viktor. From thulasi.goriparthi at gmail.com Wed Jun 10 13:26:54 2015 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 10 Jun 2015 18:56:54 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: <20150610131526.GC2050@mournblade.imrryr.org> References: <5577BAAC.7020208@wisemo.com> <20150610131526.GC2050@mournblade.imrryr.org> Message-ID: On 10 June 2015 at 18:45, Viktor Dukhovni wrote: > On Wed, Jun 10, 2015 at 04:11:45PM +0530, Thulasi Goriparthi wrote: > > > Jakob is saying that if you want them to stay even after X509_STORE_free, > > explicitly increment the ref count before calling free using something > like > > below. > > > > CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); > > That should be: > > CRYPTO_add(&certificate->references, 1, CRYPTO_LOCK_X509); > > the references parameter should be a pointer. > Thank you for the correction. > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naynjain at in.ibm.com Thu Jun 11 00:29:52 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Thu, 11 Jun 2015 05:59:52 +0530 Subject: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it In-Reply-To: References: <5577BAAC.7020208@wisemo.com> <20150610131526.GC2050@mournblade.imrryr.org> Message-ID: Thanks to you all, So, I understand that when I am adding cert to the store, I should explicilty increment the count using CRYPTO_add, so that when I X509_STORE_free(), it doesn't delete my cert. This should be enough. Thanks & Regards, Nayna Jain From: Thulasi Goriparthi To: "openssl-users at openssl org" Date: 06/10/2015 06:57 PM Subject: Re: [openssl-users] X509_STORE_free() and X509_LOOKUP_free() also frees the X509 certificates inside it Sent by: "openssl-users" On 10 June 2015 at 18:45, Viktor Dukhovni wrote: On Wed, Jun 10, 2015 at 04:11:45PM +0530, Thulasi Goriparthi wrote: > Jakob is saying that if you want them to stay even after X509_STORE_free, > explicitly increment the ref count before calling free using something like > below. > > CRYPTO_add(certificate->references, 1, CRYPTO_LOCK_X509); That should be: ? ? CRYPTO_add(&certificate->references, 1, CRYPTO_LOCK_X509); the references parameter should be a pointer. Thank you for the correction. -- ? ? ? ? Viktor. _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From naynjain at in.ibm.com Thu Jun 11 00:31:26 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Thu, 11 Jun 2015 06:01:26 +0530 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: <20150610044723.GB2050@mournblade.imrryr.org> References: <20150609050347.GM5512@mournblade.imrryr.org> <20150610044723.GB2050@mournblade.imrryr.org> Message-ID: Hi, Thanks Victor, I am going to try these.. I have similar concern for private key. If I have a pem file with private key in that, how do I check if that is RSA/DSA ? Thanks & Regards, Nayna Jain From: Viktor Dukhovni To: openssl-users at openssl.org, openssl-dev at openssl.org Date: 06/10/2015 10:18 AM Subject: Re: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? Sent by: "openssl-users" On Wed, Jun 10, 2015 at 08:48:41AM +0530, Nayna Jain wrote: > I think I will try with PEM_read_xxx and d2i_, then probably do not have > to read throu first character as 0x30. That works, provided you rewind or re-open the file. > Are all d2i_xxx type of APIs for DER format. Yes, they decode binary ASN.1 encodings of the relevant structures. And conversely i2d_... encodes a C structure to ASN.1 (typically DER) form. > > And if I have to operate on DER formatted certs, do I need to first convert > it to PEM and then user PEM APIs. or there are DER specific APIs also, I > didn't find though, unless they are d2i_xxx types. I don't see why you would need to convert to PEM first, though there are legitimate reasons to do so when you need to write configuration files to disk, as PEM is easier to work with as a configuration format. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From wangqun at alumni.nus.edu.sg Thu Jun 11 05:54:51 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Wed, 10 Jun 2015 22:54:51 -0700 (MST) Subject: [openssl-users] The behavior change of command line utility -- 'openssl' In-Reply-To: <1433922425304-58557.post@n7.nabble.com> References: <1433922425304-58557.post@n7.nabble.com> Message-ID: <1434002091427-58578.post@n7.nabble.com> I wonder if this is an expected behavior change or it is a bug. Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/The-behavior-change-of-command-line-utility-openssl-tp58557p58578.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From dthompson at prinpay.com Thu Jun 11 10:03:39 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Thu, 11 Jun 2015 06:03:39 -0400 Subject: [openssl-users] [openssl-dev] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: References: <20150609050347.GM5512@mournblade.imrryr.org> <20150610044723.GB2050@mournblade.imrryr.org> Message-ID: <000d01d0a42d$e7698440$b63c8cc0$@prinpay.com> > From: openssl-dev On Behalf Of Nayna Jain > Sent: Wednesday, June 10, 2015 20:31 > If I have a pem file with private key in that, how do I check if that is RSA/DSA ? If it uses a "legacy" format, the BEGIN line specifies the algorithm -----BEGIN RSA PRIVATE KEY----- -----BEGIN DSA PRIVATE KEY----- -----BEGIN EC PRIVATE KEY----- If it uses either PKCS#8 format: if unencrypted there is an AlgorithmIdentifier field near the beginning that specifies the type of the key; if encrypted, you must first decrypt and the decrypted value contains the AlgorithmIdentifier. It's usually easier to let PEM_read_PrivateKey figure out for you. It reads all formats (encrypted only if you provide the correct passphrase) and returns an EVP_PKEY object whose type you can check with EVP_PKEY_type following the instructions on the manpage for EVP_PKEY_type. From dthompson at prinpay.com Thu Jun 11 10:03:39 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Thu, 11 Jun 2015 06:03:39 -0400 Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <1433922425304-58557.post@n7.nabble.com> References: <1433922425304-58557.post@n7.nabble.com> Message-ID: <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> > From: openssl-users On Behalf Of Aaron > Sent: Wednesday, June 10, 2015 03:47 > We are using executable 'apps/openssl' in our test cases. We upgraded from > OpenSSL 1.0.1l to OpenSSL 1.0.2a recently. Since then one of our test cases > started to fail. After checking, I noticed that the default cipher of > 'openssl' was changed from ECDHE-RSA-AES256-SHA to DHE-RSA-AES256-SHA 'openssl' doesn't have "a" default cipher; it implements over 40 subcommands which use different kinds of ciphers with different defaults or none. You appear to be talking about the 's_client' or 's_server' subcommand, which use the library's SSL/TLS default cipherLIST, which contains about 100 ciphersuites in preference order. The only differences in this list between 1.0.1l and 1.0.2a are that 1.0.2a (also 1.0.1m and 1.0.0r) removes the long-obsolete EXPORT suites (finally, perhaps due to the FREAK and Logjam attacks exploiting them) and adds newly-implemented static-DH suites, which are ignored unless your server has a certificate for a DH key, which in practice nobody does, so they don't affect you (other than further bloating the ClientHello message). Both 1.0.1 and 1.0.2 have ECDHE-RSA-AES256-SHA ordered before DHE-RSA-AES256-SHA, so s_client talking to a server that honors client preference should still get the same result, and s_server listening to a client that has the same preference should still get the same result. Whatever changed in your test this wasn't it. > OpenSSL 1.0.2. The related description in OpenSSL 1.0.2 change log is as > follows. > My question is how to enable automatic EC temporary key parameter > selection? Commandline doesn't use that feature (yet?), only updated app code using the library. Both 1.0.1 and 1.0.2 default to a fixed curve, P256, and allow you to specify any (fixed) named curve, see -named_curve. > Is it possible to change the default cipher back to ECDHE-RSA-AES256-SHA? There's no change to be changed back. All the above assumes that when you identify versions of OpenSSL you mean executables compiled from those version source releases without modification. If either or both of your executables was built with any source changes or any configuration options that alter the release behavior, all bets are off; you'll have to look at your specific builds. E.g. RedHat builds used to nobble all ECC (but that was fixed by 1.0.2a). If you ARE using release versions, try getting traces (either externally with something like wireshark or tcpdump, or internally with -msg and/or -debug in either s_client or s_server) to see if anything is materially different on the wire (and what). From gayathri.annur at gmail.com Thu Jun 11 10:35:56 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Thu, 11 Jun 2015 16:05:56 +0530 Subject: [openssl-users] Not getting "RSA" keyword for a key in fips mode Message-ID: Hi All, I am trying to create a pem format key for my existing key by using the below command. openssl rsa -in my_rsa_key -outform PEM -out my_res_newkey_pem The new key format is -----BEGIN PRIVATE KEY-----. But I am expecting -----BEGIN RSA PRIVATE KEY----- In nonFIPS mode i am getting -----BEGIN RSA PRIVATE KEY----- as expected. My openssl version is OpenSSL 0.9.8zf-fips. Please let me know how can I generate the new key in BEGIN RSA PRIVATE KEY format. Thanks, Gayathri -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jun 11 11:25:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Jun 2015 11:25:35 +0000 Subject: [openssl-users] The behavior change of command line utility -- 'openssl' In-Reply-To: <1434002091427-58578.post@n7.nabble.com> References: <1433922425304-58557.post@n7.nabble.com> <1434002091427-58578.post@n7.nabble.com> Message-ID: <5fd2afdea6ff4a2da033bbb272337063@ustx2ex-dag1mb2.msg.corp.akamai.com> > I wonder if this is an expected behavior change or it is a bug. As Dave Thompson said, you haven't yet shown that there is a "bug" or change. From openssl-users at dukhovni.org Thu Jun 11 12:29:07 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 Jun 2015 12:29:07 +0000 Subject: [openssl-users] Is there openssl API to verify certificate content is DER or PEM format ? In-Reply-To: References: <20150609050347.GM5512@mournblade.imrryr.org> <20150610044723.GB2050@mournblade.imrryr.org> Message-ID: <20150611122907.GI2050@mournblade.imrryr.org> On Thu, Jun 11, 2015 at 06:01:26AM +0530, Nayna Jain wrote: > I have similar concern for private key. > If I have a pem file with private key in that, how do I check if that is > RSA/DSA ? In almost all cases don't check. Just load and use the key as a generic EVP_PKEY. -- Viktor. From steve at openssl.org Thu Jun 11 13:57:47 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Jun 2015 13:57:47 +0000 Subject: [openssl-users] Not getting "RSA" keyword for a key in fips mode In-Reply-To: References: Message-ID: <20150611135747.GA1729@openssl.org> On Thu, Jun 11, 2015, Gayathri Manoj wrote: > Hi All, > > > I am trying to create a pem format key for my existing key by using the > below command. > > openssl rsa -in my_rsa_key -outform PEM -out my_res_newkey_pem > > The new key format is -----BEGIN PRIVATE KEY-----. > But I am expecting -----BEGIN RSA PRIVATE KEY----- > > In nonFIPS mode i am getting -----BEGIN RSA PRIVATE KEY----- as expected. > > My openssl version is OpenSSL 0.9.8zf-fips. > > Please let me know how can I generate the new key in BEGIN RSA PRIVATE KEY > format. > You can't because the format isn't allowed in FIPS mode because it uses MD5 for key derivation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl at openssl.org Thu Jun 11 14:45:55 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Jun 2015 14:45:55 +0000 Subject: [openssl-users] OpenSSL version 0.9.8zg released Message-ID: <20150611144555.GA15788@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zg 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 0.9.8zg 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-0.9.8-notes.html OpenSSL 0.9.8zg 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-0.9.8zg.tar.gz Size: 3826891 MD5 checksum: 0a912b6623ac95a8627ea2bd0e0abf1b SHA1 checksum: a73005583ba8d5edc3bdcc1f99a1e33ee0ed41f8 The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zg.tar.gz openssl sha1 openssl-0.9.8zg.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeZkpAAoJENnE0m0OYESRzLcIAKhsW3bm1latn1wLoQk0cJEf GQVf9ztRkxivgodycUYhkuGhq2O+djeYHqKMXnedso+KnkgE/FnhTbDkyX6G12bs H17ZMgWOIypjHnwGW6jT1GlH+qb9tlzJYAuqsIEbG+hwE5KIsUrwtjAb1MhUuZFC f11jP5VFf4YXsN681TdyXxlhIdmeImiIDMjsVMGLIZ12zDV6AEJ4LrLkyyaaJxnd cryKY+Ai4AqBW3Mnv/tVddDvUdgmvjyNHBXEyBUkhy8oIpHe33RMLmGyK6w4P6os rTKsQzliZ8FSmBfbrOeFUTfPh/N1POqTcWV4VEBjD7mNZbnk3dHQZ3eFLBz8QGs= =kj2n -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jun 11 14:46:33 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Jun 2015 14:46:33 +0000 Subject: [openssl-users] OpenSSL version 1.0.0s released Message-ID: <20150611144633.GA15893@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0s 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.0s 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.0-notes.html OpenSSL 1.0.0s 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.0s.tar.gz Size: 4102101 MD5 checksum: fe54d58a42c6aa1c7a587378e27072f3 SHA1 checksum: 3df4b9a87c0a37e6fd589360f9d43a6be2252b62 The checksums were calculated using the following commands: openssl md5 openssl-1.0.0s.tar.gz openssl sha1 openssl-1.0.0s.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeZeTAAoJENnE0m0OYESR/qoIAJRa63Si5UbI8hrJVsTCDAb6 VBfb40NrzOA3x7XpsS1MQxHK9ixPokdhMSHsjAkk4D3tz703I5ig9BDymWr8U2tF 2XvNKm4JBwn8SGfPgI/sy+YgaD0Adzt84eeAek+elPReAdQZGTJ83YFbycs8tSH5 g35JNrEOO8eXADq1WTsM3iqgPt4rXW7RJFQuI4yOtZZA1aqeD+d3WGQTopglt5Az /+CVViskrnlBihRiOZKfEk4qinB0s7TIJPZifPRzDFdhvMqz6VIndYsPmFhgQMSn jkhhwHhNB/NXZyNUGBdrxeq2ySX88ObXFlMvUAHFnj0CpaGuHyA2XIEL3vmHdtg= =8O7B -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jun 11 14:46:51 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Jun 2015 14:46:51 +0000 Subject: [openssl-users] OpenSSL version 1.0.1n released Message-ID: <20150611144651.GA15919@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1n 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.1n 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.1n 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.1n.tar.gz Size: 4545564 MD5 checksum: 139568bd5a56fa49b72a290d37113f30 SHA1 checksum: 2f6ea1e0f2724aca1805392e4387df8361442ace The checksums were calculated using the following commands: openssl md5 openssl-1.0.1n.tar.gz openssl sha1 openssl-1.0.1n.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeZWaAAoJENnE0m0OYESRqlwIAJ1ncajYk0swYcFxXEbCs02q dI220NF3q9ohvXSzUVvM18Az8Lrr4u/bkZUNhmWkW2GwY7HF6DHUzgg7yWTWZ3h3 pxz33OxxNhBdXA0bkIl4d8q8SW9m7Xo+JZ2Pky2BC8MO3FTd5N8p9zfyJY63dtYV W9pOV0M/LzD3CkFMyX1NdAsoy3KNxB4NFoGKxuaYyOSwyrYCkHBXsBZM5O4BhvDt JeZMAcZagu4kNZ9fdNDNo28AxSOQicGuCqW4SOYnC/XACcsVvpuZYvMFdoqDRBN4 vWS91UAoor1Ld2IsdNsqe2D7S/35NKokvxdeUjbPKzyxPMoX5sgtJJyQZ6IUM0s= =d4VL -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jun 11 14:47:08 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Jun 2015 14:47:08 +0000 Subject: [openssl-users] OpenSSL version 1.0.2b released Message-ID: <20150611144708.GA16030@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2b 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.2b 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.2b 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.2b.tar.gz Size: 5281009 MD5 checksum: 7729b259e2dea7d60b32fc3934d6984b SHA1 checksum: 9006e53ca56a14d041e3875320eedfa63d82aba7 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2b.tar.gz openssl sha1 openssl-1.0.2b.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVeZNdAAoJENnE0m0OYESRYscIAKrJik5qyPifnVhWRHVTUXot NYhfl+h+ooHequRyz9ug7Wz3vdUioftuOYlX0eJBBZ+YvskVk27U9tjY+plFnRjq vpdNKfa6bSL9rjztZObupvbCnhYRdDkcJRqLi8HfPb53UlZS/ALIbpDi1FPqIErs Bc7D/toD0nDoQUONLVQw/aSZNWWCaACO09326K2xX/jZGEsQbhCWdlkERfO3RzRW RBN0RnR+k8XBaqy6TRELF1vlYdHe83Dqxg1h3KBTBJ+yOFXvQblPoZO4GnkAyoNA 8EGhbzgWsjg6OIroUbnbbq50avvya/2eDmY+N3gNg5wOrYBNZlWShy91WGZ4378= =rcRW -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jun 11 14:49:11 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 11 Jun 2015 14:49:11 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20150611144911.GA16575@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [11 Jun 2015] ======================================= DHE man-in-the-middle protection (Logjam) ==================================================================== A vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL has added protection for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits. This limit will be increased to 1024 bits in a future release. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n Fixes for this issue were developed by Emilia K??sper and Kurt Roeckx of the OpenSSL development team. Malformed ECParameters causes infinite loop (CVE-2015-1788) =========================================================== Severity: Moderate When processing an ECParameters structure OpenSSL enters an infinite loop if the curve specified is over a specially malformed binary polynomial field. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. This includes TLS clients and TLS servers with client authentication enabled. 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. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0d (and below) users should upgrade to 1.0.0s OpenSSL 0.9.8r (and below) users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 6th April 2015 by Joseph Birr-Pixton. The fix was developed by Andy Polyakov of the OpenSSL development team. Exploitable out-of-bounds read in X509_cmp_time (CVE-2015-1789) =============================================================== Severity: Moderate X509_cmp_time does not properly check the length of the ASN1_TIME string and can read a few bytes out of bounds. In addition, X509_cmp_time accepts an arbitrary number of fractional seconds in the time string. An attacker can use this to craft malformed certificates and CRLs of various sizes and potentially cause a segmentation fault, resulting in a DoS on applications that verify certificates or CRLs. TLS clients that verify CRLs are affected. TLS clients and servers with client authentication enabled may be affected if they use custom verification callbacks. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 8th April 2015 by Robert Swiecki (Google), and independently on 11th April 2015 by Hanno B??ck. The fix was developed by Emilia K??sper of the OpenSSL development team. PKCS7 crash with missing EnvelopedContent (CVE-2015-1790) ========================================================= Severity: Moderate The PKCS#7 parsing code does not handle missing inner EncryptedContent correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 18th April 2015 by Michal Zalewski (Google). The fix was developed by Emilia K??sper of the OpenSSL development team. CMS verify infinite loop with unknown hash function (CVE-2015-1792) =================================================================== Severity: Moderate When verifying a signedData message the CMS code can enter an infinite loop if presented with an unknown hash function OID. This can be used to perform denial of service against any system which verifies signedData messages using the CMS code. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was reported to OpenSSL on 31st March 2015 by Johannes Bauer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling NewSessionTicket (CVE-2015-1791) ======================================================== Severity: Low If a NewSessionTicket is received by a multi-threaded client when attempting to reuse a previous ticket then a race condition can occur potentially leading to a double free of the ticket data. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2b OpenSSL 1.0.1 users should upgrade to 1.0.1n OpenSSL 1.0.0 users should upgrade to 1.0.0s OpenSSL 0.9.8 users should upgrade to 0.9.8zg This issue was discovered by Emilia K??sper of the OpenSSL development team. The fix was developed by Matt Caswell of the OpenSSL development team. Invalid free in DTLS (CVE-2014-8176) ==================================== Severity: Moderate This vulnerability does not affect current versions of OpenSSL. It existed in previous OpenSSL versions and was fixed in June 2014. If a DTLS peer receives application data between the ChangeCipherSpec and Finished messages, buffering of such data may cause an invalid free, resulting in a segmentation fault or potentially, memory corruption. This issue affected older OpenSSL versions 1.0.1, 1.0.0 and 0.9.8. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8za OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0m. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1h. This issue was originally reported on March 28th 2014 in https://rt.openssl.org/Ticket/Display.html?id=3286 by Praveen Kariyanahalli, and subsequently by Ivan Fratric and Felix Groebert (Google). A fix was developed by zhu qun-ying. The fix for this issue can be identified by commits bcc31166 (1.0.1), b79e6e3a (1.0.0) and 4b258e73 (0.9.8). 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_20150611.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 iQEcBAEBAgAGBQJVeZq1AAoJENnE0m0OYESRESoIAJWIeqHHDd83ONNpXGeythDj F7DTzlKkOx+URajAOBme+XNFJSqe71kBHk8uY7ZSZcindLcVxIHEXY3S0z2qGc1B 3SsOo71TsvReIuMN8mV2fq2MDEvPpbi5fSCND1OqR5C7kGafWvUtM9TneyuB4Mu6 ktvitpJtJ/TNUXo1+50HufR3boveQzZo6Sf1KFCK5jWROaiwolTTjHQNk9aPItEz fgS7YmbHToBqnhK/JyRip7T9UlBJ2LVUoCqiQoZZ3abAbAAfBycjoXfalEQ53wde V6LUE36D1viTIG5OcIGbbUEcMkWbTQU7KISz+IocZ2e1KEAU0CCP54qi6rgazrQ= =aQnm -----END PGP SIGNATURE----- From Avery.A.Tarasov at SecurityEngineer.Pro Thu Jun 11 18:56:33 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Thu, 11 Jun 2015 14:56:33 -0400 Subject: [openssl-users] cannot configure openssl-1.0.1n on Windows with msys --target already defined - (offending arg: mingw) -- the issue does not occur in openssl-1.0.1l and openssl-1.0.1m. Message-ID: <83d452f213ac894351f3cafe850e1c1e@smtp.hushmail.com> Hi All, I was able to compile openssl 1.0.1l and openssl 1.0.1m perfectly via msys in Windows 8 -- but something isn't working right with openssl 1.0.1n *Exact steps using msys causing the error:* tar xvzf openssl-1.0.1n.tar.gz cd openssl-1.0.1n export PATH=/c/mingw/bin:$PATH $ ./Configure --prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared no-threads mingw *Error is:* *target already defined - User Name/Desktop/openssl-1.0.1n/dist (offending arg: mingw)* I am not doing anything differently from what worked previously in 1.0.1l and 1.0.1m Please advise if you know how to fix this. Thanks so much for the help! Best Regards, -Avery -------------- next part -------------- An HTML attachment was scrubbed... URL: From Avery.A.Tarasov at SecurityEngineer.Pro Thu Jun 11 19:49:51 2015 From: Avery.A.Tarasov at SecurityEngineer.Pro (Avery A. Tarasov) Date: Thu, 11 Jun 2015 15:49:51 -0400 Subject: [openssl-users] cannot configure openssl-1.0.1n on Windows with msys --target already defined - (offending arg: mingw) -- the issue does not occur in openssl-1.0.1l and openssl-1.0.1m. In-Reply-To: <83d452f213ac894351f3cafe850e1c1e@smtp.hushmail.com> References: <83d452f213ac894351f3cafe850e1c1e@smtp.hushmail.com> Message-ID: <3dcb35a13e57ce7e09e8df230585da50@smtp.hushmail.com> The problem goes away if I comment out the "die" statement on line 942 from the "Configure" file: else { * #die "target already defined - $target (offending arg: $_)\n" if ($target ne "");* $target=$_; } Is the above safe and the correct fix? Does the *$target=$_; *line (#943) also need to be commented out? Best Regards, -Avery On 6/11/2015 2:56 PM, Avery A. Tarasov wrote: > Hi All, > > I was able to compile openssl 1.0.1l and openssl 1.0.1m perfectly via > msys in Windows 8 -- but something isn't working right with openssl 1.0.1n > > *Exact steps using msys causing the error:* > > tar xvzf openssl-1.0.1n.tar.gz > cd openssl-1.0.1n > export PATH=/c/mingw/bin:$PATH > $ ./Configure --prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared > no-threads mingw > > *Error is:* > > *target already defined - User Name/Desktop/openssl-1.0.1n/dist > (offending arg: mingw)* > > I am not doing anything differently from what worked previously in > 1.0.1l and 1.0.1m > > Please advise if you know how to fix this. Thanks so much for the help! > > Best Regards, > > -Avery > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggyal at gmail.com Thu Jun 11 20:05:47 2015 From: eggyal at gmail.com (Alan Egerton) Date: Thu, 11 Jun 2015 21:05:47 +0100 Subject: [openssl-users] X509_V_ERR_INVALID_PURPOSE when validating TLS client with "any purpose" EKU (2.5.29.37.0) Message-ID: Dear OpenSSL Users, When attempting to validate a TLS client whose cert has a number of EKU purposes including "any" (2.5.29.37.0), but not "Client Authentication" (1.3.6.1.5.5.7.3.2), I am seeing validation fail with X509_V_ERR_INVALID_PURPOSE. Looking at , particularly the definitions of both the check_purpose_ssl_client() function and the xku_reject() macro, it seems that OpenSSL does not check for the any purpose EKU. One presumes this is a bug? Or am I doing something wrong? Kind regards, -- Alan From wangqun at alumni.nus.edu.sg Fri Jun 12 06:19:17 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Thu, 11 Jun 2015 23:19:17 -0700 (MST) Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> References: <1433922425304-58557.post@n7.nabble.com> <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> Message-ID: <1434089957623-58631.post@n7.nabble.com> Hi Dave, Thanks for your comments. I am not really familiar with OpenSSL, so some parts of my descriptions may not be not very clear. Right, I am talking about s_server subcommand. You mentioned that there is no change in this area. However I can easily show something is change using s_server subcommand. I am using original OpenSSL code to build my 'openssl', to this change is not from me. 1) 1.0.1l ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile certdb/cafile.pem Using default temp DH parameters Using default temp ECDH parameters ACCEPT 2) 1.0.2 ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile certdb/cafile.pem Using default temp DH parameters ACCEPT Note that, in 1.0.2, openssl doesn't print out 'Using default temp ECDH parameters'. I checked related code in s_server.c and ssl_conf.c, There are some updates. Some related code is moved from s_server.c to ssl_conf.c. However I haven't found the root cause of this change. I encountered a similar issue when upgrading from OpenSSL 1.0.1l to 1.0.1m. I paste my analysis and fix below. After I applied my fix, the issue disappeared. 1) Analysis File s_server.c was updated in OpenSSL 1.0.1m. Variable 'no_ecdhe' was uninitialized after the update. This causes the condition of the if statement (if (!no_ecdheon) {...}) on line 1682 not to be true. Then ECDHE-RSA-AES256-SHA is not the default temp ECDH parameters of 'openssl s_server' any more. 2) Fix 273 diff -wruN openssl-1.0.1m.original/apps/s_server.c openssl-1.0.1m.working/apps/s_server.c 274 --- openssl-1.0.1m.original/apps/s_server.c 2015-03-19 06:37:10.000000000 -0700 275 +++ openssl-1.0.1m.working/apps/s_server.c 2015-05-25 01:46:35.000000000 -0700 276 @@ -998,7 +998,7 @@ 277 int off = 0; 278 int no_tmp_rsa = 0, no_dhe = 0, nocert = 0; 279 #ifndef OPENSSL_NO_ECDH 280 - int no_ecdhe; 281 + int no_ecdhe = 0; 282 #endif 283 int state = 0; 284 const SSL_METHOD *meth = NULL; I noticed that the issue in 1.0.2 is not the same as the issue in 1.0.1m. The issue started to appear in 1.0.2 rather than 1.0.2a. Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/The-behavior-change-of-command-line-utility-openssl-tp58557p58631.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From openssl-users at dukhovni.org Fri Jun 12 06:46:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Jun 2015 06:46:52 +0000 Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <1434089957623-58631.post@n7.nabble.com> References: <1433922425304-58557.post@n7.nabble.com> <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> <1434089957623-58631.post@n7.nabble.com> Message-ID: <20150612064652.GP2050@mournblade.imrryr.org> On Thu, Jun 11, 2015 at 11:19:17PM -0700, Aaron wrote: > Right, I am talking about s_server subcommand. You mentioned that there is > no change in this area. However I can easily show something is change using > s_server subcommand. I am using original OpenSSL code to build my 'openssl', > to this change is not from me. > > 1) 1.0.1l > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > certdb/cafile.pem > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT With SSL 3.0, no extension support, thus no supported curves extension, thus ideally no EDCHE support. If ECDHE happened anyway with earlier releases, that was a bug that is perhaps now fixed. > 2) 1.0.2 > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > certdb/cafile.pem > Using default temp DH parameters > ACCEPT > > Note that, in 1.0.2, openssl doesn't print out 'Using default temp ECDH > parameters'. To get ECDHE support, use TLSv1.0 or later. -- Viktor. From wangqun at alumni.nus.edu.sg Fri Jun 12 08:35:22 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Fri, 12 Jun 2015 01:35:22 -0700 (MST) Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <20150612064652.GP2050@mournblade.imrryr.org> References: <1433922425304-58557.post@n7.nabble.com> <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> <1434089957623-58631.post@n7.nabble.com> <20150612064652.GP2050@mournblade.imrryr.org> Message-ID: <1434098122330-58637.post@n7.nabble.com> Thanks so much, Viktor. Hence, this is an expected behavior change. In this case I will update my application. Aaron. -- View this message in context: http://openssl.6102.n7.nabble.com/The-behavior-change-of-command-line-utility-openssl-tp58557p58637.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From gayathri.annur at gmail.com Fri Jun 12 11:04:01 2015 From: gayathri.annur at gmail.com (Gayathri Manoj) Date: Fri, 12 Jun 2015 16:34:01 +0530 Subject: [openssl-users] Not getting "RSA" keyword for a key in fips mode In-Reply-To: <20150611135747.GA1729@openssl.org> References: <20150611135747.GA1729@openssl.org> Message-ID: Thanks Steve for the quick reply. On Thu, Jun 11, 2015 at 7:27 PM, Dr. Stephen Henson wrote: > On Thu, Jun 11, 2015, Gayathri Manoj wrote: > > > Hi All, > > > > > > I am trying to create a pem format key for my existing key by using the > > below command. > > > > openssl rsa -in my_rsa_key -outform PEM -out my_res_newkey_pem > > > > The new key format is -----BEGIN PRIVATE KEY-----. > > But I am expecting -----BEGIN RSA PRIVATE KEY----- > > > > In nonFIPS mode i am getting -----BEGIN RSA PRIVATE KEY----- as expected. > > > > My openssl version is OpenSSL 0.9.8zf-fips. > > > > Please let me know how can I generate the new key in BEGIN RSA PRIVATE > KEY > > format. > > > > You can't because the format isn't allowed in FIPS mode because it uses > MD5 for key derivation. > > 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 jb-openssl at wisemo.com Fri Jun 12 14:01:28 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 12 Jun 2015 16:01:28 +0200 Subject: [openssl-users] OpenSSL version 1.0.2b released In-Reply-To: <20150611144708.GA16030@openssl.org> References: <20150611144708.GA16030@openssl.org> Message-ID: <557AE638.1070104@wisemo.com> On 11/06/2015 16:47, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > OpenSSL version 1.0.2b 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.2b 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.2b 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.2b.tar.gz > Size: 5281009 > MD5 checksum: 7729b259e2dea7d60b32fc3934d6984b > SHA1 checksum: 9006e53ca56a14d041e3875320eedfa63d82aba7 > > The checksums were calculated using the following commands: > > openssl md5 openssl-1.0.2b.tar.gz > openssl sha1 openssl-1.0.2b.tar.gz > > Yours, > > The OpenSSL Project Team. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJVeZNdAAoJENnE0m0OYESRYscIAKrJik5qyPifnVhWRHVTUXot > NYhfl+h+ooHequRyz9ug7Wz3vdUioftuOYlX0eJBBZ+YvskVk27U9tjY+plFnRjq > vpdNKfa6bSL9rjztZObupvbCnhYRdDkcJRqLi8HfPb53UlZS/ALIbpDi1FPqIErs > Bc7D/toD0nDoQUONLVQw/aSZNWWCaACO09326K2xX/jZGEsQbhCWdlkERfO3RzRW > RBN0RnR+k8XBaqy6TRELF1vlYdHe83Dqxg1h3KBTBJ+yOFXvQblPoZO4GnkAyoNA > 8EGhbzgWsjg6OIroUbnbbq50avvya/2eDmY+N3gNg5wOrYBNZlWShy91WGZ4378= > =rcRW > -----END PGP SIGNATURE----- Note: Why are OpenSSL releases still signed only with MD5 and SHA1? Even the gpg signature of the tarball is SHA1-based. Why isn't there also a detached S/MIME / CMS signature for the tarballs, preferably using a code/object signingcertificate from someone like GlobalSign. i.e. Something that can be verified with the command: old-trusted-openssl smime -verify -inform PEM -in \ openssl-1.0.2b.tar.gz.sig -binary -content \ openssl-1.0.2b.tar.gz -out /dev/null -CAfile \ /etc/ssl/certificates/foo.pem (add option "-purpose codesign" once implemented by the users "old-trusted-openssl"). If old-trused-openssl is a recent version, a similar "old-trused-openssl cms" command can also be used, but verify compatibility with old copies should be maintained for a few years (don't prevent upgrading openssl because the users needs to upgrade openssl). 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 openssl-users at dukhovni.org Fri Jun 12 14:24:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 12 Jun 2015 14:24:36 +0000 Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <1434098122330-58637.post@n7.nabble.com> References: <1433922425304-58557.post@n7.nabble.com> <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> <1434089957623-58631.post@n7.nabble.com> <20150612064652.GP2050@mournblade.imrryr.org> <1434098122330-58637.post@n7.nabble.com> Message-ID: <20150612142436.GQ2050@mournblade.imrryr.org> On Fri, Jun 12, 2015 at 01:35:22AM -0700, Aaron wrote: > Thanks so much, Viktor. Hence, this is an expected behavior change. In this > case I will update my application. Does your test case result in ECDHE being used when you change only the protocol on both ends from ssl3 to tls1? If so, I think this that confirms my hunch. I've not hunted down the specific changes that might have tightened down use of ECDHE in the absense of the relevant extensions (nor even whether the change is in the server or client). So this analysis is "disturbingly plausible" (an amusing phrase borrowed from another context, too long to explain...). -- Viktor. From openssl at openssl.org Fri Jun 12 15:36:46 2015 From: openssl at openssl.org (OpenSSL) Date: Fri, 12 Jun 2015 15:36:46 +0000 Subject: [openssl-users] OpenSSL version 1.0.1o released Message-ID: <20150612153646.GA2931@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1o 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.1o 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.1o 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.1o.tar.gz Size: 4546659 MD5 checksum: af1096f500a612e2e2adacb958d7eab1 SHA1 checksum: b003e3382607ef2c6d85b51e4ed7a4c0a76b8d5a The checksums were calculated using the following commands: openssl md5 openssl-1.0.1o.tar.gz openssl sha1 openssl-1.0.1o.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVevjeAAoJENnE0m0OYESRBTYIALl9NdRXPLxB+VZtVFVmOIHq HjC5IMBJCtsNCvUg3dOogSR+ZyrY82jPimxNY1+w5XCOQQ4Ro90Auw9OMoRwRo1y 7Y9+mZkxIrJUdudlNDmfsHw8wE5peThdhZnI9vnTgJSLBKbjqqVsHsxnUJ8dzNsc M2e2qa/poSPapWakfgafRRCblM9C/9zK/++n1m+t2SLHdM1dPanbiOIodnxX7XKp t/6UQzclDAPDpnG74bYPzHTI2rfcruezD8RiB3dNpma9n0uGRjorGEHjn/6PcgFy Rn1vgybhsoXpmQWT9kEQcLeRjgHEwyzxBlmVYnC3SFItlMma3h/bGYniCR89Huo= =WGaf -----END PGP SIGNATURE----- From openssl at openssl.org Fri Jun 12 15:37:04 2015 From: openssl at openssl.org (OpenSSL) Date: Fri, 12 Jun 2015 15:37:04 +0000 Subject: [openssl-users] OpenSSL version 1.0.2c released Message-ID: <20150612153704.GA3101@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2c 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.2c 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.2c 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.2c.tar.gz Size: 5280670 MD5 checksum: 8c8d81a9ae7005276e486702edbcd4b6 SHA1 checksum: 6e4a5e91159eb32383296c7c83ac0e59b83a0a44 The checksums were calculated using the following commands: openssl md5 openssl-1.0.2c.tar.gz openssl sha1 openssl-1.0.2c.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVevZ0AAoJENnE0m0OYESRAGIIAI+OThnhcwcrZoA3pddNL5+s mVGDd+ZstNkiqLFJSOn2Enh7Hx8xvUwaONvSAGqyiuxgmkyOSmnhc9NeE2LU+knl 8vMqF4hrTWV39JJZkkqqwEv5HRr17IWtzBL3N3/1mygvFmge6SFbGeRPk+XpyP/L 0aEWRzm7g4nq+g4Oa4/HeXsVeEwldMhgHoxbS0R3RHXPOlGb3VjZUDzg+0Nwqt5O q/sncMZAaC2TGauqsAxS19C+7hVEeZdvPKgX+DClf+NMe9+j8gWz1zmD7q5zJSQ8 ZH5+4ifFaVBSn1vuxPK4cLF5j+aUnotmWFkhJ3yZOAt+tYEH95MNB2aP4k2UCgc= =QIqW -----END PGP SIGNATURE----- From levitte at openssl.org Fri Jun 12 14:55:28 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 12 Jun 2015 16:55:28 +0200 (CEST) Subject: [openssl-users] [openssl-announce] Forthcoming releases Message-ID: <20150612.165528.2137931534546421320.levitte@openssl.org> Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2c, 1.0.1o. These releases will be made available on Friday 12th June. They will fix two specific issues: 1) an HMAC ABI incompatibility with previous releases, and 2) make it possible to accept a zero length extension block in a ClientHello. These are not security releases. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce From levitte at openssl.org Fri Jun 12 15:39:43 2015 From: levitte at openssl.org (Richard Levitte) Date: Fri, 12 Jun 2015 17:39:43 +0200 (CEST) Subject: [openssl-users] [openssl-announce] Clarification on forthcoming releases Message-ID: <20150612.173943.1507279799213732121.levitte@openssl.org> Clarification on the forthcoming OpenSSL releases ================================================= To clarify, the mentioned HMAC ABI incompatibility occurred in recently released versions 1.0.2b and 1.0.1n which are security fixes but which may cause other problems due to the ABI issue. Therefore, the forthcoming releases should be used in preference to 1.0.2b and 1.0.1n. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce From layer at franz.com Fri Jun 12 18:39:07 2015 From: layer at franz.com (Kevin Layer) Date: Fri, 12 Jun 2015 11:39:07 -0700 Subject: [openssl-users] Cygwin untar of 1.0.1n gives "tar: A lone zero block at 46120" Message-ID: <10732.1434134347@franz.com> It seems to build fine, though. I downloaded it via different means (directly to a Windows machine and on CentOS 6.6) and it did it on all copies. Just curious if anyone else had the issue. I'm running Cygwin 1.7.35 on Server 2008 R2. From avery.a.tarasov at securityengineer.pro Fri Jun 12 20:10:12 2015 From: avery.a.tarasov at securityengineer.pro (avery.a.tarasov at securityengineer.pro) Date: Fri, 12 Jun 2015 15:10:12 -0500 Subject: [openssl-users] =?utf-8?q?Cygwin_untar_of_1=2E0=2E1n_gives_=22tar?= =?utf-8?q?=3A_A_lone_zero=09block_at_46120=22?= In-Reply-To: <10732.1434134347@franz.com> Message-ID: <20150612201012.D631C2319F@smtp.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Was the md5 hash of the archive matching the one on openssl website? On Fri, Jun 12 at 06:49 PM (UTC), "Kevin Layer" wrote: > It seems to build fine, though. > > I downloaded it via different means (directly to a Windows > machine and > on CentOS 6.6) and it did it on all copies. > > Just curious if anyone else had the issue. > > I'm running Cygwin 1.7.35 on Server 2008 R2. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users -----BEGIN PGP SIGNATURE----- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wsBcBAEBAgAGBQJVezykAAoJEFXbLWdqxjhau0AIAJm7ouwddcTJixc7U+eqnvZgdLcR etN9VhONFRN0zU6hmdanMUb8WAmHeujUpu+yhvolO9bP21pE7xDtdRRbyrwAwl2vYvzU 68klgLaRE2LeoPy/9iSLnr9Y1i2yXuiVaYC4TtPR4g3vbVryiLjPuVAOJejUKHq9oet1 i9DZyNZvs2X+0Qk65vjLsnN1QS8n22YbsORDV76scJ2XoGjura+Y6gKJ3spJgu8+kU3Z sQTLbnD4zJEniNvjpAbboLRBOFtrj2QnY6N4NdAY4zllwR44He93X+7w3GAEPcrShlnT eD6MnNeG0vkblVpQOEw3APGh0iK5yfl9eNaQUD/ijH0= =XZl9 -----END PGP SIGNATURE----- From layer at franz.com Fri Jun 12 20:48:58 2015 From: layer at franz.com (Kevin Layer) Date: Fri, 12 Jun 2015 13:48:58 -0700 Subject: [openssl-users] Cygwin untar of 1.0.1n gives "tar: A lone zero block at 46120" In-Reply-To: <20150612201012.D631C2319F@smtp.hushmail.com> References: <20150612201012.D631C2319F@smtp.hushmail.com> Message-ID: <19911.1434142138@franz.com> avery.a.tarasov at securityengineer.pro wrote: >> Was the md5 hash of the archive matching the one on openssl >> website? Yes. It matches. $ tar zxf openssl-1.0.1n.tar.gz tar: A lone zero block at 46120 ~ $ md5sum openssl-1.0.1n.tar.gz 139568bd5a56fa49b72a290d37113f30 *openssl-1.0.1n.tar.gz ~ $ >> >> On Fri, Jun 12 at 06:49 PM (UTC), "Kevin Layer" wrote: >> >> > It seems to build fine, though. >> > >> > I downloaded it via different means (directly to a Windows >> > machine and >> > on CentOS 6.6) and it did it on all copies. >> > >> > Just curious if anyone else had the issue. >> > >> > I'm running Cygwin 1.7.35 on Server 2008 R2. >> > >> > _______________________________________________ >> > 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 Fri Jun 12 21:02:34 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Jun 2015 21:02:34 +0000 Subject: [openssl-users] Cygwin untar of 1.0.1n gives "tar: A lone zero block at 46120" In-Reply-To: <19911.1434142138@franz.com> References: <20150612201012.D631C2319F@smtp.hushmail.com> <19911.1434142138@franz.com> Message-ID: <66f915174ee3490c940b26e521dae8ed@ustx2ex-dag1mb2.msg.corp.akamai.com> > $ tar zxf openssl-1.0.1n.tar.gz > tar: A lone zero block at 46120 Perhaps this? http://askubuntu.com/questions/169223/tar-a-lone-zero-block-at-343398 From wangqun at alumni.nus.edu.sg Mon Jun 15 08:41:47 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 15 Jun 2015 01:41:47 -0700 (MST) Subject: [openssl-users] The default cipher of executable 'openssl' In-Reply-To: <20150612142436.GQ2050@mournblade.imrryr.org> References: <1433922425304-58557.post@n7.nabble.com> <000c01d0a42d$e6c55500$b44fff00$@prinpay.com> <1434089957623-58631.post@n7.nabble.com> <20150612064652.GP2050@mournblade.imrryr.org> <1434098122330-58637.post@n7.nabble.com> <20150612142436.GQ2050@mournblade.imrryr.org> Message-ID: <1434357707066-58697.post@n7.nabble.com> >Does your test case result in ECDHE being used when you change only >the protocol on both ends from ssl3 to tls1? Yes, I tested and verified this. Thanks again, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/The-behavior-change-of-command-line-utility-openssl-tp58557p58697.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From atulthosar at gmail.com Tue Jun 16 07:21:31 2015 From: atulthosar at gmail.com (Atul Thosar) Date: Tue, 16 Jun 2015 12:51:31 +0530 Subject: [openssl-users] OpenSSL support on Solaris 11 (built on Solaris 10) Message-ID: ?Hi All, >From archives/google, I understood that the OpenSSL works/supported on Solaris 11 platform, but in our case, it's a bit different scenario. Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc) and it works well on Solaris 10 platform. We use Sun Studio 12 compiler. We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o changing the build platform. I mean we will continue to build OpenSSL on Solaris 10 and run it on Solaris 11. Has anyone encounter such situation? Appreciate any help/pointers if this mechanism will work? -- BR, Atul Thosar -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipakgaigole at rediffmail.com Tue Jun 16 08:00:01 2015 From: dipakgaigole at rediffmail.com (Dipak Gaigole) Date: Tue, 16 Jun 2015 01:00:01 -0700 (MST) Subject: [openssl-users] Application and TCP buffers with OpenSSL Message-ID: <1434441601805-58723.post@n7.nabble.com> Hello, I am writing a Client Server program. In order to achieve the Network Throughput I was playing around with the Application buffer size and TCP Buffer size (SO_SNDBUF/SO_RCVBUF) to find the best values for a specific client-server pair. I am transferring a file of size 748MB from Client to Server which are in LAN. I had tested this with Basic TCP and OpenSSL enabled Client Server program and have measured the time it takes to transfer the file. 1) In Basic TCP Client Server program I could see the gain at the different combinations of those 2 buffer values. 2) In OpenSSL enabled Client Server I couldn?t see such gain and the values are too high as compared to Basic TCP Client Server. Here are few results: ####### TCP Client ####### [root at vl-blg-dv10 dipak]# zsh [root at vl-blg-dv10]~/dipak# ./tcp-client_1 usage: ./tcp-client_1 [root at vl-blg-dv10]~/dipak# time ./tcp-client_1 10.129.85.242 32000 /tmp/748M 16384 65536 >/dev/null ./tcp-client_1 10.129.85.242 32000 /tmp/748M 16384 65536 > /dev/null 0.06s user 1.47s system 4% cpu 33.930 total [root at vl-blg-dv10]~/dipak# time ./tcp-client_1 10.129.85.242 32000 /tmp/748M 65536 131072 >/dev/null ./tcp-client_1 10.129.85.242 32000 /tmp/748M 65536 131072 > /dev/null 0.02s user 1.20s system 14% cpu 8.503 total [root at vl-blg-dv10]~/dipak# time ./tcp-client_1 10.129.85.242 32000 /tmp/748M 131072 524288 >/dev/null ./tcp-client_1 10.129.85.242 32000 /tmp/748M 131072 524288 > /dev/null 0.01s user 1.06s system 20% cpu 5.154 total [root at vl-blg-dv10]~/dipak# ####### OpenSSL Enabled Client ####### [root at vl-blg-dv10]~/dipak# ./SSL_Client_3 usage: ./SSL_Client_3 [root at vl-blg-dv10]~/dipak# time ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 16384 65536 > /dev/null ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 16384 65536 > /dev/null 68.20s user 3.68s system 86% cpu 1:23.19 total [root at vl-blg-dv10]~/dipak# time ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 65536 131072 > /dev/null ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 65536 131072 > /dev/null 59.22s user 2.20s system 86% cpu 1:11.06 total [root at vl-blg-dv10]~/dipak# time ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 131072 524288 > /dev/null ./SSL_Client_3 10.129.85.242 32000 /tmp/748M 131072 524288 > /dev/null 62.15s user 2.45s system 88% cpu 1:12.92 total [root at vl-blg-dv10]~/dipak# ####### SCP ####### With SCP it is taking around 22 Seconds. [root at vl-blg-dv10]~/dipak# time scp /tmp/748M root at 10.129.85.242:/tmp/ root at 10.129.85.242's password: 748M 100% 748MB 34.0MB/s 00:22 scp /tmp/748M root at 10.129.85.242:/tmp/ 13.66s user 6.42s system 69% cpu 28.784 total [root at vl-blg-dv10]~/dipak# I noticed that in case of OpenSSL Enabled Client the time spend in the ?User Space? is high (around 60 seconds). So I guess this is mostly because of the encryption activity. Please find the source code below for reference. Has anyone faced/noticed such issue? Is there anything wrong I am doing with my OpenSSL code or anything needs to be tweaked? Any pointers, suggestions are always welcome.... Thanks, Dipak //################SSL-Client.c ####################### #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define FAIL -1 void LoadCertificates(SSL_CTX* ctx, char* CertFile, char* KeyFile) { /* set the local certificate from CertFile */ if (SSL_CTX_use_certificate_file(ctx, CertFile, SSL_FILETYPE_PEM) <= 0) { ERR_print_errors_fp(stderr); abort(); } /* set the private key from KeyFile (may be the same as CertFile) */ if ( SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM) <= 0 ) { ERR_print_errors_fp(stderr); abort(); } /* verify private key */ if ( !SSL_CTX_check_private_key(ctx) ) { fprintf(stderr, "Private key does not match the public certificate\n"); abort(); } } int OpenConnection(const char *hostname, int port, int tbuf_size) { int sd, val; struct hostent *host; struct sockaddr_in addr; if ((host = gethostbyname(hostname)) == NULL) { perror(hostname); abort(); } sd = socket(PF_INET, SOCK_STREAM, 0); bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = *(long*)(host->h_addr); val = tbuf_size; printf ("Using TCP buffer size (SO_SNDBUF/SO_RCVBUF) = <%d>\n", val); setsockopt (sd, SOL_SOCKET, SO_RCVBUF, (char *)&val, sizeof (val)); setsockopt (sd, SOL_SOCKET, SO_SNDBUF, (char *)&val, sizeof (val)); val = 1; setsockopt (sd, IPPROTO_TCP, TCP_NODELAY, (char *)&val, sizeof(val)); val = IPTOS_THROUGHPUT | IPTOS_LOWDELAY; setsockopt (sd, IPPROTO_IP, IP_TOS, (char *)&val, sizeof(val)); if (connect(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0) { close(sd); perror(hostname); abort(); } return sd; } SSL_CTX* InitCTX(void) { SSL_METHOD *method; SSL_CTX *ctx; OpenSSL_add_all_algorithms(); /* Load cryptos, et.al. */ SSL_load_error_strings(); /* Bring in and register error messages */ method = SSLv2_client_method(); /* Create new client-method instance */ ctx = SSL_CTX_new(method); /* Create new context */ if (ctx == NULL) { ERR_print_errors_fp(stderr); abort(); } LoadCertificates(ctx, "client_cert.pem", "client_key.pem"); /* load certs */ return ctx; } int main(int count, char *argv[]) { SSL_CTX *ctx; int server; SSL *ssl; char *hostname, *portnum; char *recvBuff1; int fd=0; int rlen; long sz=0; struct stat st; int read_cnt; int data_cnt; int tobe_read_cnt; int ok; int app_buf_size = 0; int tcp_buf_size = 0; if (count != 6) { fprintf(stderr, "usage: %s \n", argv[0]); exit(0); } SSL_library_init(); OpenSSL_add_all_algorithms(); hostname=argv[1]; portnum=argv[2]; app_buf_size = atoi (argv[4]); tcp_buf_size = atoi (argv[5]); if (stat(argv[3], &st) < 0) { fprintf (stderr, "stat() failed. Error = %s\n", strerror(errno)); return -1; } printf ("Using Application buffer size = <%d>\n", app_buf_size); recvBuff1 = malloc (app_buf_size); data_cnt = st.st_size; ctx = InitCTX(); server = OpenConnection(hostname, atoi(portnum), tcp_buf_size); ssl = SSL_new(ctx); /* create new SSL connection state */ SSL_set_fd(ssl, server); /* attach the socket descriptor */ //SSL_CTX_set_cipher_list(ctx, "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"); if (SSL_connect(ssl) == FAIL) /* perform the connection */ { ERR_print_errors_fp(stderr); close(server); /* close socket */ SSL_CTX_free(ctx); /* release context */ return -1; } printf ("Connected to %s:%s\n", hostname, portnum); printf ("SSL_get_cipher_name returned <%s>\n", SSL_get_cipher_name(ssl)); fd = open (argv[3], O_RDONLY); if (fd == 0) { fprintf (stderr, "Failed to open the file <%s>\n", argv[3]); return 0; } read_cnt = 0; ok = 1; tobe_read_cnt = app_buf_size; //Send the Application buffer size to be used for read SSL_write(ssl, &app_buf_size, sizeof(app_buf_size)); /* encrypt & send message */ while (1) { if (data_cnt < read_cnt + tobe_read_cnt) tobe_read_cnt = data_cnt - read_cnt; if((rlen = read(fd, recvBuff1, tobe_read_cnt)) > 0) { read_cnt += rlen; } else break; sz = SSL_write (ssl, recvBuff1,rlen ); /* encrypt & send message */ if (sz != rlen) { fprintf (stderr, "Write data length <%ld> doesn't match input data length <%d>\n", sz, rlen); } if (data_cnt == read_cnt) { printf ("Sucessfully sent data of length %d\n", read_cnt); ok = 0; break; } } SSL_free(ssl); /* release connection state */ close(server); /* close socket */ SSL_CTX_free(ctx); /* release context */ return 0; } //######################## SSL-Server.c ######################### #include #include #include #include #include #include #include #include #include #include "openssl/ssl.h" #include "openssl/err.h" #include #include #include #include #include #include #define FAIL -1 int non_ssl; int OpenListener(int port, int tbuf_size) { int sd, val; struct sockaddr_in addr; sd = socket(PF_INET, SOCK_STREAM, 0); bzero(&addr, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = INADDR_ANY; val = tbuf_size; printf ("Using TCP buffer size (SO_SNDBUF/SO_RCVBUF) = <%d>\n", val); setsockopt (sd, SOL_SOCKET, SO_RCVBUF, (char *)&val, sizeof (val)); setsockopt (sd, SOL_SOCKET, SO_SNDBUF, (char *)&val, sizeof (val)); val = 1; setsockopt (sd, IPPROTO_TCP, TCP_NODELAY, (char *)&val, sizeof(val)); val = IPTOS_THROUGHPUT | IPTOS_LOWDELAY; setsockopt (sd, IPPROTO_IP, IP_TOS, (char *)&val, sizeof(val)); if (bind(sd, (struct sockaddr*)&addr, sizeof(addr)) != 0) { perror("can't bind port"); abort(); } if (listen(sd, 64) != 0) { perror("Can't configure listening port"); abort(); } return sd; } SSL_CTX* InitServerCTX(void) { SSL_METHOD *method; SSL_CTX *ctx; OpenSSL_add_all_algorithms(); /* load & register all cryptos, etc. */ SSL_load_error_strings(); /* load all error messages */ method = SSLv2_server_method(); /* create new server-method instance */ ctx = SSL_CTX_new(method); /* create new context from method */ if ( ctx == NULL ) { ERR_print_errors_fp(stderr); abort(); } return ctx; } void LoadCertificates(SSL_CTX* ctx, char* CertFile, char* KeyFile) { /* set the local certificate from CertFile */ if ( SSL_CTX_use_certificate_file(ctx, CertFile, SSL_FILETYPE_PEM) <= 0 ) { ERR_print_errors_fp(stderr); abort(); } /* set the private key from KeyFile (may be the same as CertFile) */ if ( SSL_CTX_use_PrivateKey_file(ctx, KeyFile, SSL_FILETYPE_PEM) <= 0 ) { ERR_print_errors_fp(stderr); abort(); } /* verify private key */ if ( !SSL_CTX_check_private_key(ctx) ) { fprintf(stderr, "Private key does not match the public certificate\n"); abort(); } } void Servlet(SSL* ssl) /* Serve the connection request*/ { char *buf; int sd, bytes; int fd=0; int len; char filename [32]; int app_buf_size = 0; if (SSL_accept(ssl) == FAIL) /* do SSL-protocol accept */ { ERR_print_errors_fp(stderr); sd = SSL_get_fd(ssl); /* get socket connection */ SSL_free(ssl); /* release SSL state */ close(sd); /* close connection */ return; } sprintf (filename, "/tmp/test1"); fd = open (filename, O_WRONLY|O_CREAT, 0666); if (fd < 0) { fprintf (stderr, "Failed to open the file %s, error = %s", filename, strerror(errno)); return; } //Get Application buffer size to be used. SSL_read(ssl, &app_buf_size, sizeof(app_buf_size)); printf ("Using Application buffer size as <%d>\n", app_buf_size); buf = malloc (app_buf_size); while(1) { bytes = SSL_read(ssl, buf, app_buf_size); /* get request */ //bytes = read(non_ssl, buf, sizeof(buf)); /* get request */ if (bytes <= 0) { ERR_print_errors_fp (stderr); break; } len=write(fd,buf,bytes); } sd = SSL_get_fd(ssl); /* get socket connection */ SSL_free(ssl); /* release SSL state */ close(sd); /* close connection */ close(fd); free(buf); unlink(filename); } int main(int count, char *argv[]) { SSL_CTX *ctx; int server; int portnum; int pid; int tcp_buf_size = 0; if (count != 3) { printf("Usage: %s \n", argv[0]); exit(0); } SSL_library_init(); portnum = atoi (argv[1]); tcp_buf_size = atoi (argv[2]); server = OpenListener(portnum, tcp_buf_size); /* create server socket */ ctx = InitServerCTX(); /* initialize SSL */ LoadCertificates(ctx, "server_cert.pem", "server_key.pem"); /* load certs */ while (1) { struct sockaddr_in addr; socklen_t len = sizeof(addr); SSL *ssl; int client = accept(server, (struct sockaddr*)&addr, &len); /* accept connection as usual */ if (client < 0) break; printf("Accepted Connection: %s:%d\n",inet_ntoa(addr.sin_addr), ntohs(addr.sin_port)); pid = fork(); if (pid == 0) { ssl = SSL_new(ctx); /* get new SSL state with context */ SSL_set_fd(ssl, client); /* set connection socket to SSL state */ OpenSSL_add_all_ciphers(); non_ssl=client; Servlet(ssl); /* service connection */ printf("Done.\n\n"); _exit (0); } else { //Parent wait for next client continue; } } SSL_CTX_free(ctx); /* release context */ close(server); /* close server socket */ return 0; } -- View this message in context: http://openssl.6102.n7.nabble.com/Application-and-TCP-buffers-with-OpenSSL-tp58723.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From fj at qsp-systems.com Tue Jun 16 14:38:16 2015 From: fj at qsp-systems.com (Fabrice) Date: Tue, 16 Jun 2015 16:38:16 +0200 Subject: [openssl-users] Certificat & CRL verification chain by callback Message-ID: <558034D8.3010709@qsp-systems.com> Hello, I explain : I would like a function like this : int X509_verify(const char *certPem, void *who, char *(*whatYouWant)(void *who, int type, const X509_NAME *subject, const X509_NAME *issuer)) where : : is a certificat in PEM format to verify : is an instance of a class whatYouWant : is a method of that can find (certificat X509_LU_X509, CRL X509_LU_CRL) with the and eventually the this function would callback on until the root CA of and do the appropriates verifications on intermediate certificats and CRLs, and return 0 succes, other error. Is there any solution to do so with the current version of openssl API otherwise how can i do ? Thanks for reply. Best regards. Fabrice JACQUET From openssl-users at dukhovni.org Tue Jun 16 15:29:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Jun 2015 15:29:43 +0000 Subject: [openssl-users] Certificat & CRL verification chain by callback In-Reply-To: <558034D8.3010709@qsp-systems.com> References: <558034D8.3010709@qsp-systems.com> Message-ID: <20150616152943.GK14121@mournblade.imrryr.org> On Tue, Jun 16, 2015 at 04:38:16PM +0200, Fabrice wrote: > I explain : > > I would like a function like this : > > int X509_verify(const char *certPem, void *who, char *(*whatYouWant)(void > *who, int type, const X509_NAME *subject, const X509_NAME *issuer)) > > where : > > : is a certificat in PEM format to verify > : is an instance of a class > whatYouWant : is a method of that can find (certificat > X509_LU_X509, CRL X509_LU_CRL) > with the and eventually the > > this function would callback on until the root CA of > and do the appropriates verifications on intermediate > certificats and CRLs, and return 0 succes, other error. > > Is there any solution to do so with the current version of openssl API > otherwise how can i do ? This is surely not really what you want, it is a means to an end, and you have not explained your *real* goal. What actual problem are you trying to solve. What would such a feature enable you to do? Are you verifying TLS peers (client or servers), signatures of CMS/SMIME messages, ... What additional checks are you looking to do beyond the standard certificate chain verification. -- Viktor. From jb-openssl at wisemo.com Tue Jun 16 15:43:02 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 16 Jun 2015 17:43:02 +0200 Subject: [openssl-users] Certificat & CRL verification chain by callback In-Reply-To: <558034D8.3010709@qsp-systems.com> References: <558034D8.3010709@qsp-systems.com> Message-ID: <55804406.8040109@wisemo.com> On 16/06/2015 16:38, Fabrice wrote: > Hello, > > I explain : > > I would like a function like this : > > int X509_verify(const char *certPem, void *who, char > *(*whatYouWant)(void *who, int type, const X509_NAME *subject, const > X509_NAME *issuer)) > > where : > > : is a certificat in PEM format to verify > : is an instance of a class > whatYouWant : is a method of that can find (certificat > X509_LU_X509, CRL X509_LU_CRL) > with the and eventually the > > this function would callback on until the root CA > of and do the appropriates verifications on intermediate > certificats and CRLs, and return 0 succes, other error. > > Is there any solution to do so with the current version of openssl API > otherwise how can i do ? > Regardless of the question raised by Mr. Dukhovni, I believe the closest thing would be the following: 1. Create an empty X509_STORE object which will hold the answers returned by "whatYouWant". 2. In the X509_STORE object, set up the method callbacks that are normally used to search "/etc/ssl/certificates" based in subject hashes to instead end up in your own whatYouWant callback. This may go beyond documented interfaces, requiring you to study the OpenSSL source code. 3. Pass this X509_STORE object to the general X509 verification functions. Of cause, in many cases, it would be easier to just: 1. Create an empty X509_STORE object. 2. Load your own sources of certificates and CRLs into this store. 3. Pass this X509_STORE object to the general X509 verification functions. One case handled by neither your callback argument list, nor by the second method is the technique promoted by Microsoft, where the certificates are sometimes downloaded on the fly from URLs specified in the AIA extension in the certificate being validated, and the classic privacy- enhanced checking where missing/outdated CRLs are downloaded from URLs specified in other extensions (there are 2 possibilities) in the certificate being validated (the surveillance-happy method is to use OCSP). -- 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 nico at cryptonector.com Tue Jun 16 15:46:16 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Jun 2015 10:46:16 -0500 Subject: [openssl-users] [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris 10) In-Reply-To: References: Message-ID: <20150616154615.GA6117@localhost> On Tue, Jun 16, 2015 at 12:51:31PM +0530, Atul Thosar wrote: > Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc) > and it works well on Solaris 10 platform. We use Sun Studio 12 compiler. > > We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o > changing the build platform. I mean we will continue to build OpenSSL on > Solaris 10 and run it on Solaris 11. > > Has anyone encounter such situation? Appreciate any help/pointers if this > mechanism will work? Historically the approach you describe has worked quite well with Solaris because the ABI is quite stable. This is particularly the case if you use only features that are extremely unlikely to be removed in a new minor release (Solaris 12 would be a minor release). (You should not build on anything older than S10 to run on S10 or later, mostly due to subtle changes in how snprintf() works.) But you should read the ABI compatibility promises that Oracle makes and decide for yourself. Nico -- From fj at qsp-systems.com Tue Jun 16 15:51:34 2015 From: fj at qsp-systems.com (Fabrice) Date: Tue, 16 Jun 2015 17:51:34 +0200 Subject: [openssl-users] Certificat & CRL verification chain by callback In-Reply-To: <20150616152943.GK14121@mournblade.imrryr.org> References: <558034D8.3010709@qsp-systems.com> <20150616152943.GK14121@mournblade.imrryr.org> Message-ID: <55804606.6060103@qsp-systems.com> Hello, I understand that, when I want to verify a certificat, I need to load the X509_STORE_CTX with all the certificats and CRLs needed by the chain verification (like the command openssl verify -CApath -CAfile ...) But, given a certificat to verify, I want to be called back to go up into the chain verification until the root CA. And at eatch step, certificat and revocation list are verified. My job is to provide at eatch step what is needed in PEM format into an allocated char * I tried to use X509_LOOKUP.get_by_subject() but I am only requested on certificats in the chain, not on CRL. I found the TOMCAT source sslutils.c that do the job on peer, but I didn't find such function in the openssl API outside peer. With such callback verifier, you can download certificats and CRLs from files, from directories, from LDAP, from HTTPS, as you want. Do you understand ? Thanks for reply. Gratefully. Fabrice JACQUET Le 16.06.2015 17:29, Viktor Dukhovni a ?crit : > On Tue, Jun 16, 2015 at 04:38:16PM +0200, Fabrice wrote: > >> I explain : >> >> I would like a function like this : >> >> int X509_verify(const char *certPem, void *who, char *(*whatYouWant)(void >> *who, int type, const X509_NAME *subject, const X509_NAME *issuer)) >> >> where : >> >> : is a certificat in PEM format to verify >> : is an instance of a class >> whatYouWant : is a method of that can find (certificat >> X509_LU_X509, CRL X509_LU_CRL) >> with the and eventually the >> >> this function would callback on until the root CA of >> and do the appropriates verifications on intermediate >> certificats and CRLs, and return 0 succes, other error. >> >> Is there any solution to do so with the current version of openssl API >> otherwise how can i do ? > This is surely not really what you want, it is a means to an end, > and you have not explained your *real* goal. What actual problem > are you trying to solve. > > What would such a feature enable you to do? Are you verifying TLS > peers (client or servers), signatures of CMS/SMIME messages, ... > What additional checks are you looking to do beyond the standard > certificate chain verification. > From nico at cryptonector.com Tue Jun 16 16:43:14 2015 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Jun 2015 11:43:14 -0500 Subject: [openssl-users] [openssl-dev] OpenSSL support on Solaris 11 (built on Solaris 10) In-Reply-To: <20150616154615.GA6117@localhost> References: <20150616154615.GA6117@localhost> Message-ID: <20150616164314.GB6117@localhost> I should add that you should read all the release notes of every update and check if your product would be affected. From director at openca.org Tue Jun 16 17:22:09 2015 From: director at openca.org (Massimiliano Pala) Date: Tue, 16 Jun 2015 13:22:09 -0400 Subject: [openssl-users] Fast DH parameters generation Message-ID: <55805B41.1060902@openca.org> Hi all, I am working on an application that would use DH to allow exchanging symmetric keys (not a TLS app), and we noticed that we could use two different approaches to generate the parameters. The first option is to use the DH_generate_parameters_ex() + DH_generate_key() - but that takes quite a long time when using 2048 bits DH. The second option, instead, is to generate DSA parameters and then copy them as DH params - i.e., using DSA_generate_parameters_ex() + DSA_dup_DH() + DH_generate_key(). Of course, the second approach is a lot faster - however, can anyone explain the warning not from the documentation "Be careful to avoid small subgroup attacks when using this." ? AFAIK, for such attacks to be effective, they require that the parameters are re-used multiple times. However, in our specific case, the generated parameters will be used only once (2048 bits) and then discarded... Cheers, Max From valerie.fenwick at oracle.com Tue Jun 16 17:07:42 2015 From: valerie.fenwick at oracle.com (Valerie Fenwick) Date: Tue, 16 Jun 2015 10:07:42 -0700 Subject: [openssl-users] OpenSSL support on Solaris 11 (built on Solaris 10) In-Reply-To: References: Message-ID: <558057DE.3000607@oracle.com> On 6/16/2015 12:21 AM, Atul Thosar wrote: > ?Hi All, > > From archives/google, I understood that the OpenSSL works/supported on Solaris > 11 platform, but in our case, it's a bit different scenario. > > Currently, we build OpenSSL v0.9.8zc on Solaris 10 (SunOS, sun4u, sparc) and it > works well on Solaris 10 platform. We use Sun Studio 12 compiler. > > We would like to run it on Solaris 11.2 (SunOS, sun4v, sparc) platform w/o > changing the build platform. I mean we will continue to build OpenSSL on Solaris > 10 and run it on Solaris 11. > > Has anyone encounter such situation?Appreciate any help/pointers if this > mechanism will work? Hi Atul What Nico and Andy say are correct, but I would like to ask why you would be interested in doing this? As is well known, 0.9.8 will be end-of-life by the end of this year. Solaris 11.2 includes 1.0.1 with patches from 1.0.2 for SPARC hardware acceleration. 1.0.1 already included Intel AESNI hardware optimizations. 0.9.8 does not have those optimizations for either platform. From a support model, we only do regression testing with the versions of OpenSSL that we are shipping without operating system. As we know, many things on Solaris to depend on OpenSSL, like SunSSH. We cannot guarantee that the SunSSH that we are shipping on Solaris 11 will work and perform well on top of 0.9.8, due to the lack of ABI compatibility that we had with OpenSSL itself between 0.9.8 and 1.0.0 (I do not offhand remember what those specific incompatibilities were). For further information about the OpenSSL version we are shipping with Solaris 11.2, see Misaki's blog: https://blogs.oracle.com/observatory/entry/openssl_on_solaris_11_2 So, while the general principle should work, your time is probably better invested in standardizing on 1.0.1. Thank you, Valerie -- NOTE: Using voice recognition software, forgive typos/grammar mistakes! Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. From matt at openssl.org Tue Jun 16 18:44:36 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Jun 2015 19:44:36 +0100 Subject: [openssl-users] OpenSSL support on Solaris 11 (built on Solaris 10) In-Reply-To: <558057DE.3000607@oracle.com> References: <558057DE.3000607@oracle.com> Message-ID: <55806E94.9060104@openssl.org> On 16/06/15 18:07, Valerie Fenwick wrote: > So, while the general principle should work, your time is probably > better invested in standardizing on 1.0.1. If you are going to the trouble of upgrading, I would go straight to 1.0.2. As previously stated in our release strategy, 1.0.1 has a lifetime until the end of 2016: https://www.openssl.org/about/releasestrat.html The end of 2016 is not really that far away. Matt From m.vinicius at samsung.com Tue Jun 16 19:19:11 2015 From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento) Date: Tue, 16 Jun 2015 16:19:11 -0300 Subject: [openssl-users] DES3 CFB1 mode Message-ID: <00b601d0a869$540d61e0$fc2825a0$@samsung.com> Hi there, I've been trying to use DES_EDE3_CFB1 encryption in openssl version 1.0.1f but I couldn't make it work correctly. My understanding is that EVP_CipherUpdate is expecting the input data length (inl) in bytes, not bits as expected. I tried digging a little the GitHub repository but I'm not sure if it has already been fixed in newer versions. According to the link below, AES seems to be handling CFB1 as an exception in crypto/evp/e_aes.c file. However I couldn't find similar exception for DES. https://github.com/openssl/openssl/search?utf8=%E2%9C%93 &q=EVP_CIPH_FLAG_LENGTH_BITS Anyone here could ever encode data with bit length which is not a multiple of 8? Example from FIPS tests: KEY1 = 04f16e92fd3b463e KEY2 = 04f16e92fd3b463e KEY3 = 04f16e92fd3b463e IV = c7203aec8a805910 PLAINTEXT = 011 CIPHERTEXT = 110 Thanks very much, Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jun 16 20:02:09 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Jun 2015 20:02:09 +0000 Subject: [openssl-users] Certificat & CRL verification chain by callback In-Reply-To: <55804606.6060103@qsp-systems.com> References: <558034D8.3010709@qsp-systems.com> <20150616152943.GK14121@mournblade.imrryr.org> <55804606.6060103@qsp-systems.com> Message-ID: <20150616200209.GS14121@mournblade.imrryr.org> On Tue, Jun 16, 2015 at 05:51:34PM +0200, Fabrice wrote: > I understand that, when I want to verify a certificate, I need to load the > X509_STORE_CTX with all the certificats and CRLs needed by the chain verification > (like the command openssl verify -CApath -CAfile ...) What is the context for this? Why are you verifying certificates (really certificate chains I hope) at all? What protocol are you securing? > But, given a certificate to verify, I want to be called back to go up into > the chain verification until the root CA. And at each step, certificate > and revocation list are verified. This is not at all clear. What extra verification are you looking to do? Are you perhaps looking for X509_STORE_CTX_set_verify_cb()? This is the underlying libcrypto mechanism that supports SSL_CTX_set_verify(). > My job is to provide at each step what is needed in PEM format into an > allocated char * Forget the PEM format detail, all the various formats are inter-convertible, that's not important. > I tried to use X509_LOOKUP.get_by_subject() but I am only requested on > certificats in the chain, not on CRL. Are you trying to provide your own store of trusted issuer certificates and CRLs and associated access methods for the OpenSSL verification routines to use? -- Viktor. From marquess at openssl.com Tue Jun 16 21:57:03 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 16 Jun 2015 17:57:03 -0400 Subject: [openssl-users] FIPS 140-2 hostages executed Message-ID: <55809BAF.8000308@openssl.com> If you don't know or care what FIPS 140-2 is then count yourself very lucky and move on. There is a new development in the long running saga of the "hostage issue"[*]; the hostages have been executed: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 Cross-referencing the Big Blob '0 Text in the rightmost cell on that NIST CMVP web site entry shows that fourteen of the original "hostages" were "executed": 47 Windows 2008 32-bit under vSphere Xeon E3-1220v2 (x86) None 48 Windows 2008 64-bit under vSphere Xeon E3-1220v2 (x86) None 49 RHEL 6 32-bit under vSphere Xeon E3-1220v2 (x86) None 50 RHEL 6 64-bit under vSphere Xeon E3-1220v2 (x86) 59 VMware Horizon Mobile 1.3 under VMware under Android 4.0 Qualcomm MSM8X60 (ARMv7) NEON 66 VMware Horizon Workspace 1.5 under vSphere Intel Xeon E3-1220 (x86) None 67 VMware Horizon Workspace 1.5 under vSphere Intel Xeon E3-1220 (x86) AES-NI 72 Linux 3.4 under Citrix XenServer Intel Xeon E5-2430L (x86) AES-NI 73 Linux 3.4 under VMware ESX Intel Xeon E5-2430L (x86) None 74 Linux 3.4 under VMware ESX Intel Xeon E5-2430L (x86) AES-NI 75 Linux 3.4 under Microsoft Hyper-V Intel Xeon E5-2430L (x86) None 76 Linux 3.4 under Microsoft Hyper-V Intel Xeon E5-2430L (x86) AES-NI 79 PexOS 1.0 under vSphere Intel Xeon E5-2430L (x86) None 80 PexOS 1.0 under vSphere Intel Xeon E5-2430L (x86) AES-NI along with what I'm guessing are accidental random bystanders: 8 Ubuntu 10.04 Intel Pentium T4200 (x86) None and one of 20 Linux 2.6 Broadcom BCM11107 (ARMv6) None 21 Linux 2.6 TI TMS320DM6446 (ARMv4) None I don't know which of 20 and 21 was executed (if deliberate) and which was spared; I have asked for clarification. I am assuming that platform 71, Linux 3.4 under Citrix XenServer Intel Xeon E5-2430L (x86), was spared only by mistake and will soon share the fate of its fellow hostages. If you are currently using a FIPS module on any of these 16 now deleted platforms, that module has retroactively become non-validated. It's my understanding from the test lab that we may be allowed to restore the deleted platforms, with modifications (once OSF has permission from the sponsors of those platforms). Obviously if those sponsors had been presented with the choice between complete removal of their platforms and restricting them to particular hypervisor versions they would have chosen the latter. Instead they were forced to choose between preserving their platforms and adding new platforms, which led us down the "ransom" path and months of delay... -Steve M. [*] See http://openssl.com/fips/hostage.html, http://openssl.com/fips/ransom.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 fj at qsp-systems.com Wed Jun 17 07:42:21 2015 From: fj at qsp-systems.com (Fabrice) Date: Wed, 17 Jun 2015 09:42:21 +0200 Subject: [openssl-users] Certificat & CRL verification chain by callback In-Reply-To: <20150616200209.GS14121@mournblade.imrryr.org> References: <558034D8.3010709@qsp-systems.com> <20150616152943.GK14121@mournblade.imrryr.org> <55804606.6060103@qsp-systems.com> <20150616200209.GS14121@mournblade.imrryr.org> Message-ID: <558124DD.1040305@qsp-systems.com> Hi, I need to encrypt CMS and, to do so, verify the certificat chain. All the certificats and CRLs are downloaded from a LDAP repository. But, I want to reuse the certificat chain verification, whatever is the origin of certificats and CRLs in the chain (database, files, LDAP, HTTP), because some others applications don't use a LDAP repository. The X509 pieces location are known by the caller. It provides them on the fly if possible. I noticed the X509_STORE lookup_certs() and lookup_crls() methods but I dont known if they could satisfy my need. I studied the sources crypto/x509/by_file.c and by_dir.c to learn how I can do, but I dont achieve in my goal. Thanks for help. Gratefully, Fabrice JACQUET Le 16.06.2015 22:02, Viktor Dukhovni a ?crit : > On Tue, Jun 16, 2015 at 05:51:34PM +0200, Fabrice wrote: > >> I understand that, when I want to verify a certificate, I need to load the >> X509_STORE_CTX with all the certificats and CRLs needed by the chain verification >> (like the command openssl verify -CApath -CAfile ...) > What is the context for this? Why are you verifying certificates > (really certificate chains I hope) at all? What protocol are you > securing? > >> But, given a certificate to verify, I want to be called back to go up into >> the chain verification until the root CA. And at each step, certificate >> and revocation list are verified. > This is not at all clear. What extra verification are you looking > to do? > > Are you perhaps looking for X509_STORE_CTX_set_verify_cb()? This > is the underlying libcrypto mechanism that supports SSL_CTX_set_verify(). > > >> My job is to provide at each step what is needed in PEM format into an >> allocated char * > Forget the PEM format detail, all the various formats are > inter-convertible, that's not important. > >> I tried to use X509_LOOKUP.get_by_subject() but I am only requested on >> certificats in the chain, not on CRL. > Are you trying to provide your own store of trusted issuer certificates > and CRLs and associated access methods for the OpenSSL verification > routines to use? > From jacques.p.florence at gmail.com Wed Jun 17 12:47:46 2015 From: jacques.p.florence at gmail.com (Jacques FLORENCE) Date: Wed, 17 Jun 2015 08:47:46 -0400 Subject: [openssl-users] How to use the default ECDSA verify operation in my engine Message-ID: I want to create an engine for ECDSA, and implement my own signing operation in hardware. But I want to use the default verify operation to be used. Is there currently a way to do that? There is an ECDSA_METHOD_set_verify function, but it looks like there is no ECDSA_METHOD_get_verify, that I could use to get the default verify operation... Is there another way to do it? Thank you for your help -------------- next part -------------- An HTML attachment was scrubbed... URL: From remy.grunblatt at ens-lyon.fr Wed Jun 17 13:03:52 2015 From: remy.grunblatt at ens-lyon.fr (=?UTF-8?B?UsOpbXkgR3LDvG5ibGF0dA==?=) Date: Wed, 17 Jun 2015 15:03:52 +0200 Subject: [openssl-users] How to use the default ECDSA verify operation in my engine In-Reply-To: References: Message-ID: <20150617150352.0fc0e46e@ens-lyon.fr> > I want to create an engine for ECDSA, and implement my own signing > operation in hardware. > But I want to use the default verify operation to be used. > Is there currently a way to do that? Yosh. I think you can declare a new ECDSA_METHOD structure and keep the references to the openssl ecdsa_do_verify function while changing the ecdsa_do_sign to your own function (it's what I do): static ECDSA_METHOD my_own_openssl_ecdsa_meth = { "OpenSSL ECDSA method", my_own_ecdsa_do_sign_function, ecdsa_sign_setup_no_digest, ecdsa_do_verify, ECDSA_FLAG_FIPS_METHOD, /* flags */ NULL /* app_data */ }; Then, in your engine, use something like ENGINE_set_ECDSA(e, &my_own_openssl_ecdsa_meth). Is that what you are searching for ? You'll have to include some headers like ./crypto/ec/ec_lcl.h, I think. -- R?my Gr?nblatt ENS Lyon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From beldmit at gmail.com Wed Jun 17 13:12:20 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 17 Jun 2015 16:12:20 +0300 Subject: [openssl-users] How to use the default ECDSA verify operation in my engine In-Reply-To: References: Message-ID: Hello Jacques, On Wed, Jun 17, 2015 at 3:47 PM, Jacques FLORENCE < jacques.p.florence at gmail.com> wrote: > I want to create an engine for ECDSA, and implement my own signing > operation in hardware. > But I want to use the default verify operation to be used. > Is there currently a way to do that? > There is an ECDSA_METHOD_set_verify function, but it looks like there is > no ECDSA_METHOD_get_verify, that I could use to get the default verify > operation... > Is there another way to do it? > > Thank you for your help > Why not just use ECDSA_METHOD_set_sign_setup/ECDSA_METHOD_set_sign for your own callback? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From mseaborn62 at hotmail.com Wed Jun 17 16:52:53 2015 From: mseaborn62 at hotmail.com (Mark) Date: Wed, 17 Jun 2015 09:52:53 -0700 (MST) Subject: [openssl-users] Building OpenSSL with FIPS crypto Module Linker forking too many processes In-Reply-To: <1433354131672-58444.post@n7.nabble.com> References: <1433354131672-58444.post@n7.nabble.com> Message-ID: <1434559973922-58762.post@n7.nabble.com> Ok, I finally figure out my issues. I was setting the environment variables when I should not have been. The "make depend" set will setup all the fips dependencies you need. So I was shooting myself in the foot so to speak. Using the commands listed in the Security Policy for OpenSSL worked fine once I ran them without the environment variables. Everything is working fine now. Thanks for the help. -- View this message in context: http://openssl.6102.n7.nabble.com/Building-OpenSSL-with-FIPS-crypto-Module-Linker-forking-too-many-processes-tp58444p58762.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Thu Jun 18 15:17:12 2015 From: marquess at openssl.com (Steve Marquess) Date: Thu, 18 Jun 2015 11:17:12 -0400 Subject: [openssl-users] Provisional FIPS 140-2 casualty list Message-ID: <5582E0F8.40404@openssl.com> If you don't know or care what FIPS 140-2 is then count yourself very lucky and move on. I've created a new web page to summarize the current status of the long-running hostage saga: http://openssl.com/fips/aftermath.html If you use the OpenSSL FIPS Object Module 2.0 (validation #1747), you should confirm that any platforms you use that module on are among the survivors. However, don't panic quite yet if you're using one of the deleted platforms. I'm pretty sure that the "Big Blob 'o Text" list as currently posted has several clerical errors that the CMVP will eventually correct. Also, I expect to receive permission from at least some of the directly impacted platform sponsors to supply information for revised platform descriptions. Once those are up, then you can panic. New developments will be noted in this new web page. -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 jayf0ster at roadrunner.com Thu Jun 18 23:46:49 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Thu, 18 Jun 2015 16:46:49 -0700 Subject: [openssl-users] Windows Compile Fails Message-ID: <55835869.1030002@roadrunner.com> I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL 1.0.2c for Windows, but get a linking error tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' I googled for this error, but the solutions mention changing parameters in the VC Studio project, but I'm building from the command line with nmake. I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the Windows system I'm compiling on is a 64-bit OS. I know I have built 32-bit applications on it in the past from VC Studio. Is there some obvious fix? Jay From shinelight at shininglightpro.com Fri Jun 19 02:55:56 2015 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Thu, 18 Jun 2015 19:55:56 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <55835869.1030002@roadrunner.com> References: <55835869.1030002@roadrunner.com> Message-ID: <558384BC.5020806@shininglightpro.com> On 6/18/2015 4:46 PM, Jay Foster wrote: > I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL > 1.0.2c for Windows, but get a linking error > > tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' > conflicts with target machine type 'x64' > > I googled for this error, but the solutions mention changing parameters > in the VC Studio project, but I'm building from the command line with > nmake. > > I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the > Windows system I'm compiling on is a 64-bit OS. I know I have built > 32-bit applications on it in the past from VC Studio. Is there some > obvious fix? > > Jay What Command Prompt are you running? You have to use the correct "Native Tools" for the target hardware type. If you are building VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 Native Tools Command Prompt (not the x64 version). You can't mix and match targets. If you don't want to build it yourself, there are also prebuilt binaries and libraries. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From ben at an3k.de Fri Jun 19 14:24:52 2015 From: ben at an3k.de (Ben Humpert) Date: Fri, 19 Jun 2015 16:24:52 +0200 Subject: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting Message-ID: When the CSR contains an email address and the email_in_dn setting in the config file is set to "no" the email address is actually present in the issuer DN but not in the subject DN. This causes errors when verifying certificate chains since the subject hash is used to identify a cert but the issuer hash is different. A dirty workaround is to 1) link the subject hash to the cert file and additionally 2) link the issuer hash to the same cert file From Michael.Wojcik at microfocus.com Fri Jun 19 14:32:50 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jun 2015 14:32:50 +0000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558384BC.5020806@shininglightpro.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Thomas J. Hruska > Sent: Thursday, June 18, 2015 22:56 > > On 6/18/2015 4:46 PM, Jay Foster wrote: > > I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL > > 1.0.2c for Windows, but get a linking error > > What Command Prompt are you running? You have to use the correct > "Native Tools" for the target hardware type. If you are building > VC-WIN32, then you are targeting 32-bit hardware and need to run the x86 > Native Tools Command Prompt (not the x64 version). You can't mix and > match targets. More generally, the compiler bitness has to match the bitness you configure the OpenSSL build for. The Visual Studio "command prompt" shortcuts set up the appropriate environment, but you can also do it using the various batch files supplied with VS (vcvars32.bat, etc), or by setting the appropriate paths and other environment variables manually. (I build OpenSSL for Windows from a Cygwin bash shell, using Visual Studio, and I have bash functions that set up the appropriate build environments.) The bitness of the OS doesn't matter. You can cross-compile x64 binaries on 32-bit Windows and vice versa. When we build OpenSSL for Windows as part of our integration / automated build process, we have our own wrapper scripts that build both bitnesses in separate build directories, using the same build machine. A quick check is to run "cl" with no parameters from the command line you're using for OpenSSL. It will say something like "Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x86" or "... for x64". -- Michael Wojcik Technology Specialist, Micro Focus From jayf0ster at roadrunner.com Fri Jun 19 15:30:51 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 08:30:51 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558384BC.5020806@shininglightpro.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> Message-ID: <558435AB.1080304@roadrunner.com> On 6/18/2015 7:55 PM, Thomas J. Hruska wrote: > On 6/18/2015 4:46 PM, Jay Foster wrote: >> I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL >> 1.0.2c for Windows, but get a linking error >> >> tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' >> conflicts with target machine type 'x64' >> >> I googled for this error, but the solutions mention changing parameters >> in the VC Studio project, but I'm building from the command line with >> nmake. >> >> I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the >> Windows system I'm compiling on is a 64-bit OS. I know I have built >> 32-bit applications on it in the past from VC Studio. Is there some >> obvious fix? >> >> Jay > > What Command Prompt are you running? You have to use the correct > "Native Tools" for the target hardware type. If you are building > VC-WIN32, then you are targeting 32-bit hardware and need to run the > x86 Native Tools Command Prompt (not the x64 version). You can't mix > and match targets. > > If you don't want to build it yourself, there are also prebuilt > binaries and libraries. > I tried again, but it then failed trying to compile an assembly file (i586 something). It complained about an unknown operand. I tried again adding "no-asm" to my configuration. It seemed to compile fine, but again failed at the link with several undefined symbols: _OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, _sha1_block_data_order, _sha256_block_data_order, and _sha512_block_data_order. My goal is to obtain a static library(ies) and associated header files that I can use to compile my application that uses OpenSSL on Windows. Where can I obtain these pre-built binaries? Jay From jayf0ster at roadrunner.com Fri Jun 19 15:48:53 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 08:48:53 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558435AB.1080304@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> Message-ID: <558439E5.10509@roadrunner.com> On 6/19/2015 8:30 AM, Jay Foster wrote: > On 6/18/2015 7:55 PM, Thomas J. Hruska wrote: >> On 6/18/2015 4:46 PM, Jay Foster wrote: >>> I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL >>> 1.0.2c for Windows, but get a linking error >>> >>> tmp32dll\x86cpuid.obj : fatal error LNK1112: module machine type 'X86' >>> conflicts with target machine type 'x64' >>> >>> I googled for this error, but the solutions mention changing parameters >>> in the VC Studio project, but I'm building from the command line with >>> nmake. >>> >>> I'm configuring for 32-bit (perl Configure VC-WIN32 ...). I think the >>> Windows system I'm compiling on is a 64-bit OS. I know I have built >>> 32-bit applications on it in the past from VC Studio. Is there some >>> obvious fix? >>> >>> Jay >> >> What Command Prompt are you running? You have to use the correct >> "Native Tools" for the target hardware type. If you are building >> VC-WIN32, then you are targeting 32-bit hardware and need to run the >> x86 Native Tools Command Prompt (not the x64 version). You can't mix >> and match targets. >> >> If you don't want to build it yourself, there are also prebuilt >> binaries and libraries. >> > I tried again, but it then failed trying to compile an assembly file > (i586 something). It complained about an unknown operand. > > I tried again adding "no-asm" to my configuration. It seemed to > compile fine, but again failed at the link with several undefined > symbols: > _OPENSSL_ia32cap_P, _OPENSSL_ia32_cpuid, _md5_block_asm_data_order, > _sha1_block_data_order, _sha256_block_data_order, and > _sha512_block_data_order. > > My goal is to obtain a static library(ies) and associated header files > that I can use to compile my application that uses OpenSSL on > Windows. Where can I obtain these pre-built binaries? > > Jay > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > I started over from a clean directory and the build completed. On linux, I would end up with two libraries (libssl, libcrypto). I don't see these on Windows in the out32dll directory. Does Windows create different library names? I'm looking for the equivalent static libraries for libssl and libcrypto to link with my application. Jay From Michael.Wojcik at microfocus.com Fri Jun 19 15:55:43 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jun 2015 15:55:43 +0000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558439E5.10509@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 11:49 > > > I started over from a clean directory and the build completed. On > linux, I would end up with two libraries (libssl, libcrypto). I don't > see these on Windows in the out32dll directory. Does Windows create > different library names? I'm looking for the equivalent static > libraries for libssl and libcrypto to link with my application. The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. -- Michael Wojcik Technology Specialist, Micro Focus From jayf0ster at roadrunner.com Fri Jun 19 17:52:22 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 10:52:22 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> Message-ID: <558456D6.7080406@roadrunner.com> On 6/19/2015 8:55 AM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jay Foster >> Sent: Friday, June 19, 2015 11:49 >> I started over from a clean directory and the build completed. On >> linux, I would end up with two libraries (libssl, libcrypto). I don't >> see these on Windows in the out32dll directory. Does Windows create >> different library names? I'm looking for the equivalent static >> libraries for libssl and libcrypto to link with my application. > The Windows static libraries are named libeay32.lib and ssleay32.lib, for historical reasons. At any rate, that's what I have in my Windows build directory; I believe those are the standard names. > Thanks, I see those. From jayf0ster at roadrunner.com Fri Jun 19 19:51:11 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 12:51:11 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558456D6.7080406@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> Message-ID: <558472AF.4060402@roadrunner.com> On 6/19/2015 10:52 AM, Jay Foster wrote: > On 6/19/2015 8:55 AM, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>> Behalf >>> Of Jay Foster >>> Sent: Friday, June 19, 2015 11:49 >>> I started over from a clean directory and the build completed. On >>> linux, I would end up with two libraries (libssl, libcrypto). I don't >>> see these on Windows in the out32dll directory. Does Windows create >>> different library names? I'm looking for the equivalent static >>> libraries for libssl and libcrypto to link with my application. >> The Windows static libraries are named libeay32.lib and ssleay32.lib, >> for historical reasons. At any rate, that's what I have in my Windows >> build directory; I believe those are the standard names. >> > Thanks, I see those. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > I got my application to compile and link. It seemed to run OK, but when I tried to run it on a different Windows machine, it failed with a pop up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was statically linking this library, but apparently not. I have no idea how it worked on the one machine. What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? Jay From Michael.Wojcik at microfocus.com Fri Jun 19 20:11:02 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jun 2015 20:11:02 +0000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558472AF.4060402@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 15:51 > > > I got my application to compile and link. It seemed to run OK, but when > I tried to run it on a different Windows machine, it failed with a pop > up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was > statically linking this library, but apparently not. I have no idea how > it worked on the one machine. What is the magic incantation to get > Visual Studio to statically link the OpenSSL libraries? The OpenSSL libraries have to be built as static libraries. If you configure the OpenSSL build for static libraries, that's what you'll get. If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get static libraries at all. Note the static libraries and the import libraries have the same name. When you link a library to a Windows executable, you provide either a static library or an import library. In the latter case, the executable will do an implicit load of the corresponding DLL at startup. So if you want to statically link with OpenSSL, you have to configure it for static linkage and build it that way. Then the libeay32.lib and ssleay32.lib you get should be true static libraries and not import libraries. I think "no-shared" is the Configure option you need. We actually have a script that changes some of the OpenSSL makefiles after configuring, so our process is a bit different from yours. -- Michael Wojcik Technology Specialist, Micro Focus From jayf0ster at roadrunner.com Fri Jun 19 21:09:22 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 14:09:22 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> Message-ID: <55848502.9060607@roadrunner.com> On 6/19/2015 1:11 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jay Foster >> Sent: Friday, June 19, 2015 15:51 >> I got my application to compile and link. It seemed to run OK, but when >> I tried to run it on a different Windows machine, it failed with a pop >> up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was >> statically linking this library, but apparently not. I have no idea how >> it worked on the one machine. What is the magic incantation to get >> Visual Studio to statically link the OpenSSL libraries? > The OpenSSL libraries have to be built as static libraries. > > If you configure the OpenSSL build for static libraries, that's what you'll get. > > If you configure it for dynamic libraries, you'll get libeay32.dll and ssleay32.dll, and a pair of "import libraries" named libeay32.lib and ssleay32.lib. You won't get static libraries at all. Note the static libraries and the import libraries have the same name. > > When you link a library to a Windows executable, you provide either a static library or an import library. In the latter case, the executable will do an implicit load of the corresponding DLL at startup. > > So if you want to statically link with OpenSSL, you have to configure it for static linkage and build it that way. Then the libeay32.lib and ssleay32.lib you get should be true static libraries and not import libraries. > > I think "no-shared" is the Configure option you need. We actually have a script that changes some of the OpenSSL makefiles after configuring, so our process is a bit different from yours. > That sounds like what I'm running into. I rebuilt the OpenSSL libraries with the "no-shared" option, but this made no difference. Does that work for Windows? Jay From jayf0ster at roadrunner.com Fri Jun 19 21:31:23 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 19 Jun 2015 14:31:23 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <55848502.9060607@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> <55848502.9060607@roadrunner.com> Message-ID: <55848A2B.8090308@roadrunner.com> On 6/19/2015 2:09 PM, Jay Foster wrote: > On 6/19/2015 1:11 PM, Michael Wojcik wrote: >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>> Behalf >>> Of Jay Foster >>> Sent: Friday, June 19, 2015 15:51 >>> I got my application to compile and link. It seemed to run OK, but >>> when >>> I tried to run it on a different Windows machine, it failed with a pop >>> up dialog complaining it could not find LIBEAY32.dll. I 'thought' I >>> was >>> statically linking this library, but apparently not. I have no idea >>> how >>> it worked on the one machine. What is the magic incantation to get >>> Visual Studio to statically link the OpenSSL libraries? >> The OpenSSL libraries have to be built as static libraries. >> >> If you configure the OpenSSL build for static libraries, that's what >> you'll get. >> >> If you configure it for dynamic libraries, you'll get libeay32.dll >> and ssleay32.dll, and a pair of "import libraries" named libeay32.lib >> and ssleay32.lib. You won't get static libraries at all. Note the >> static libraries and the import libraries have the same name. >> >> When you link a library to a Windows executable, you provide either a >> static library or an import library. In the latter case, the >> executable will do an implicit load of the corresponding DLL at startup. >> >> So if you want to statically link with OpenSSL, you have to configure >> it for static linkage and build it that way. Then the libeay32.lib >> and ssleay32.lib you get should be true static libraries and not >> import libraries. >> >> I think "no-shared" is the Configure option you need. We actually >> have a script that changes some of the OpenSSL makefiles after >> configuring, so our process is a bit different from yours. >> > That sounds like what I'm running into. I rebuilt the OpenSSL > libraries with the "no-shared" option, but this made no difference. > Does that work for Windows? > Jay > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > I see OpenSSL build output that looks like this: cl /Fotmp32dll\a_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL _THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_L EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DO PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_S SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_E NGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\asn 1\a_sign.c a_sign.c Should the "/MD" be "/MT"? Is -DOPENSSL_BUILD_SHLIBCRYPTO right? is -D_WINDLL right? Do I need to specify enable-static-engine or no-dso? Jay From Michael.Wojcik at microfocus.com Fri Jun 19 21:37:30 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jun 2015 21:37:30 +0000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <55848502.9060607@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> <55848502.9060607@roadrunner.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 17:09 > > > > I think "no-shared" is the Configure option you need. We actually have a > > script that changes some of the OpenSSL makefiles after configuring, so our > > process is a bit different from yours. > > > That sounds like what I'm running into. I rebuilt the OpenSSL libraries > with the "no-shared" option, but this made no difference. Does that work > for Windows? Hmm. I thought it did, but as I said we're using a customized process. We run Configure but then make some changes. You can check to see whether a LIB file is an import or static library using the "lib" tool that's included with Visual Studio. "lib /list libeay32.lib" will show a bunch of object file names if it's a static library; if it's an import library, it will just print "libeay32.dll" a bunch of times. The static library will also be a lot bigger. My libeay32.lib is around 14 MB. I don't have an import one here, but it should be much smaller, since it's basically just a list of function signatures. Is it possible your build created both static and dynamic versions? Do you have two different versions of libeay32.lib in the build directory? What version of OpenSSL are you building? -- Michael Wojcik Technology Specialist, Micro Focus From Michael.Wojcik at microfocus.com Fri Jun 19 21:44:27 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 19 Jun 2015 21:44:27 +0000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <55848A2B.8090308@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> <55848502.9060607@roadrunner.com> <55848A2B.8090308@roadrunner.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jay Foster > Sent: Friday, June 19, 2015 17:31 > > I see OpenSSL build output that looks like this: > > cl /Fotmp32dll\a_sign.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 > -DOPENSSL > _THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo - > DOPENSSL_SYSNAME_WIN32 > -DWIN32_L > EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE - > DOPENSSL_USE_APPLINK > -I. -DO > PENSSL_NO_IDEA -DOPENSSL_NO_RC2 -DOPENSSL_NO_RC5 - > DOPENSSL_NO_MD2 > -DOPENSSL_NO_S > SL2 -DOPENSSL_NO_SSL3 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE > -DOPENSSL_NO_STATIC_E > NGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c > .\crypto\asn > 1\a_sign.c > a_sign.c > > Should the "/MD" be "/MT"? Probably not. This depends on other considerations that are outside the scope of statically or dynamically linking OpenSSL itself. /MD tells VC to put a reference to the DLL version of the Microsoft C Runtime (CRT) into the object file; /MT tells VC to put a reference to the static version of the CRT in. Usually even static libraries should be linked with the DLL version of the CRT, unless you know the final executable will always be linked with the static CRT. > Is -DOPENSSL_BUILD_SHLIBCRYPTO right? Not sure. > is -D_WINDLL right? Probably. Again, even with OpenSSL built for static linking, it's usually best to tell VC that you're building for eventual dynamic linking, if the final executable will have a mix of static and dynamic objects. > Do I need to specify enable-static-engine No, unless you know you're using one or more engines, and you know you need them linked statically rather than loaded dynamically. Start by assuming no. The engine feature supports external cryptographic providers. Those can be software systems like Microsoft's Crypto API, or hardware systems like card readers that use the PKCS#11 API. Modern versions of OpenSSL load engines dynamically, on request; enable-static-engine links them in statically instead. > or no-dso? I don't know what that option does, off the top of my head. Doesn't look like our build uses it. -- Michael Wojcik Technology Specialist, Micro Focus From sfhacker at hotmail.com Fri Jun 19 23:44:35 2015 From: sfhacker at hotmail.com (Sergio NNX) Date: Sat, 20 Jun 2015 09:44:35 +1000 Subject: [openssl-users] Windows Compile Fails In-Reply-To: References: <55835869.1030002@roadrunner.com>, <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com>, <558439E5.10509@roadrunner.com>, , <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com>, , <55848502.9060607@roadrunner.com> <55848A2B.8090308@roadrunner.com>, Message-ID: > I'm new to building OpenSSL with Windows. I'm trying to build OpenSSL > 1.0.2c for Windows, but get a linking error > My goal is to obtain a static library(ies) and associated header files > that I can use to compile my application that uses OpenSSL on Windows. > Where can I obtain these pre-built binaries? > What is the magic incantation to get Visual Studio to statically link the OpenSSL libraries? > The OpenSSL libraries have to be built as static libraries. Dear Jay, We have been building OpenSSL on Windows, both statically and dynamically, for some time now without issues. We don't use Visual Studio though. The question is: does OpenSSL have to be built using Visual Studio only? If the answer is 'no', we could render some assistance. Just let us know. Cheers. Sergio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.farrell at oracle.com Sat Jun 20 00:32:13 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Sat, 20 Jun 2015 01:32:13 +0100 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <55848A2B.8090308@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> <55848502.9060607@roadrunner.com> <55848A2B.8090308@roadrunner.com> Message-ID: <5584B48D.4020506@oracle.com> From: Jay Foster Sent: Friday, June 19, 2015 15:51 > I got my application to compile and link. It seemed to run OK, but > when I tried to run it on a different Windows machine, it failed > with a pop up dialog complaining it could not find LIBEAY32.dll. I > 'thought' I was statically linking this library, but apparently not. > I have no idea how it worked on the one machine. What is the magic > incantation to get Visual Studio to statically link the OpenSSL > libraries? You'd save us a lot of guesswork, and probably get where you want to be more quickly, if you would 1) tell us what version of OpenSSL you're trying to build 2) tell us what build environment you're using (presumably some command prompt started from VS) 3) tell us the exact sequence of commands you're executing to build it, starting from the tarball Have you read INSTALL.W32? It's probably well out of date in detail, but still valuable to point you in the right direction. As long as you're using the nt.mak makefile, you should get static libraries. Regards, jjf -- J. J. Farrell From shinelight at shininglightpro.com Sat Jun 20 02:50:17 2015 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Fri, 19 Jun 2015 19:50:17 -0700 Subject: [openssl-users] Windows Compile Fails In-Reply-To: <558472AF.4060402@roadrunner.com> References: <55835869.1030002@roadrunner.com> <558384BC.5020806@shininglightpro.com> <558435AB.1080304@roadrunner.com> <558439E5.10509@roadrunner.com> <558456D6.7080406@roadrunner.com> <558472AF.4060402@roadrunner.com> Message-ID: <5584D4E9.9050204@shininglightpro.com> On 6/19/2015 12:51 PM, Jay Foster wrote: > On 6/19/2015 10:52 AM, Jay Foster wrote: >> On 6/19/2015 8:55 AM, Michael Wojcik wrote: >>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >>>> Behalf >>>> Of Jay Foster >>>> Sent: Friday, June 19, 2015 11:49 >>>> I started over from a clean directory and the build completed. On >>>> linux, I would end up with two libraries (libssl, libcrypto). I don't >>>> see these on Windows in the out32dll directory. Does Windows create >>>> different library names? I'm looking for the equivalent static >>>> libraries for libssl and libcrypto to link with my application. >>> The Windows static libraries are named libeay32.lib and ssleay32.lib, >>> for historical reasons. At any rate, that's what I have in my Windows >>> build directory; I believe those are the standard names. >>> >> Thanks, I see those. >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > I got my application to compile and link. It seemed to run OK, but when > I tried to run it on a different Windows machine, it failed with a pop > up dialog complaining it could not find LIBEAY32.dll. I 'thought' I was > statically linking this library, but apparently not. I have no idea how > it worked on the one machine. What is the magic incantation to get > Visual Studio to statically link the OpenSSL libraries? > > Jay Use nt.mak, not ntdll.mak. You can search the Internets for Windows binaries. Also, Dependency Walker is very useful for identifying what DLLs a DLL or EXE depends on. In my opinion, you shouldn't really link against static versions if you can avoid it. Static linking makes it harder for end-users to stay up to date. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From dthompson at prinpay.com Sat Jun 20 03:29:34 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Fri, 19 Jun 2015 23:29:34 -0400 Subject: [openssl-users] The default cipher of executable 'openssl' Message-ID: <000601d0ab09$558b43f0$00a1cbd0$@prinpay.com> > From: openssl-users On Behalf Of Viktor Dukhovni > Sent: Friday, June 12, 2015 02:47 > > 1) 1.0.1l > > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > > certdb/cafile.pem > > Using default temp DH parameters > > Using default temp ECDH parameters > > ACCEPT > > With SSL 3.0, no extension support, thus no supported curves > extension, thus ideally no EDCHE support. If ECDHE happened anyway > with earlier releases, that was a bug that is perhaps now fixed. > That is it. I'm not sure a bug, but I'd agree not ideal. 4492 says client SHOULD send the curves and pointformats extensions, but if it doesn't the server "is free to choose any one of [4492 named curves]" (no BCP14 verb). OpenSSL's old behavior of using a particular curve is permitted. I'm not sure it was an intentional change. <=1.0.1 had all the logic in ssl3_choose_cipher, with (large clumsy) code blocks of the form "if ECC suite is in intersection of client and server lists and we have ECC key&cert, but client specified curves and our curve isn't among them, don't use ECC suite", and similarly for pointformats. If client didn't send the extensions the "don't use" branch wasn't taken. 1.0.2 has new APIs for both client and server apps to restrict curves, and ssl3_choose_cipher is rearranged into several new routines, using I think some new data, with result that if the client doesn't send extensions ECC is NOT selected (and in the OPs case DHE is). > > 2) 1.0.2 > > ./apps/openssl s_server -ssl3 -cert certdb/ssl_server.pem -WWW -CAfile > > certdb/cafile.pem > > Using default temp DH parameters > > ACCEPT > > > > Note that, in 1.0.2, openssl doesn't print out 'Using default temp ECDH > > parameters'. > That's a red herring. That code was also refactored; s_server still defaults to P256, it just doesn't say so. If I run 1.0.2* s_server -ssl3 then s_client allowing at least 1.0, it sends clienthello containing ECC suites in cipherlist (by default), with applicable extensions including two for ECC; receiving this, server negotiates version=3.0, but DOES select ECDHE-RSA (given RSA cert&key) and client agrees. From watz at watz.at Sat Jun 20 08:48:07 2015 From: watz at watz.at (Marco Warga) Date: Sat, 20 Jun 2015 10:48:07 +0200 Subject: [openssl-users] beginner needs advice on data signature/verification Message-ID: <558528C7.90403@watz.at> Hi, I hope some of you could give me advice on my project using openssl. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? Thanks alot, Marco X509_verify_cert X509_verify_cert -------------- next part -------------- An HTML attachment was scrubbed... URL: From googleersatz at oliverniebuhr.de Sat Jun 20 10:20:52 2015 From: googleersatz at oliverniebuhr.de (Oliver Niebuhr) Date: Sat, 20 Jun 2015 12:20:52 +0200 Subject: [openssl-users] Bug or Not in 1.0.2b? Message-ID: <55853E84.2040200@oliverniebuhr.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I try to compile OpenSSL under Windows 7 64-bit. I am using MinGW64. All Paths to Perl x64 etc. are set. Configure Parameter: ./Configure -?prefix=/c/opensslx64 no-idea no-mdc2 no-rc5 shared mingw64 Dependencies are built fine. But when I run make to build the Library, I get the following Error Message: ghash-x86_64.s: Assembler messages: ghash-x86_64.s:931: Error: junk `.15473355479995e+19' after expression make[2]: *** [ghash-x86_64.o] Error 1 make[2]: Leaving directory `/c/opensslsrc64/crypto/modes' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/c/opensslsrc64/crypto' make: *** [build_crypto] Error 1 Is this a Bug? Or a incompatibility? Thanks :) Oliver -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVhT6CAAoJEPq9qaaq4qg9YCIQAKDfKF27d5Pra/VSg7Mo9YJZ o+wOoMzi1IbY9aUEL7TaqmvE+Fz+dZgA9S+xT9XkhNmC9N/YAPuhRnR150nafP1/ tK/Fywyqhng+mQTI7+5aPLPS7G8uwGdOiPtpgfHtnf+CNt2IK4ht7atPdQA+w6o8 T3yGWdkJ7OlIiKMl4i4GQoz/xiWz1ArYkDoeoLRBKPxENeKY7QLXuFIS+Yg1X+Dj HkMbcK3KlgaqsSciOHVf7q4+O1rEcsuwH/9rozvg4CcRluXkxP0bboAVJmKPEf1H a1TUFH1KmwmFm1hgdTCVEBkmbtEAe9G1v+gX2WxOIuCzvoNSDWRZbU9G4lXG+uoi loK8+miQgDwr27wDi0zNi3gFMIsTF0c06j6mYasSEcQg92+Kc1M3cSblFYQSQ/gK hbM7bUTayWkea5sObfYOtYfc6auF5tFMtbUzhMvveAkFoHGmm3fbufgw3tPN3dFo ZuyfhDhU/G3bbTsmcuQU9Vv7uhx3mQqQdPglq3sir9yusy/dqWeE9AFqK8C62ngo cH/AyrvAuhETvyeRaJOkewJUYKA2VmNYvKKxVC0k1S1rOX/13W30QnrvO9gXmq47 8bQ4n65BhsD64sieYy6ArGp3C7ZO6Qmvl6jRLq4ne1sDH2TWY5cBM8BOobkJWgJ1 Qc2O0TDpwBKe64FS6nE2 =P9pH -----END PGP SIGNATURE----- From naynjain at in.ibm.com Sun Jun 21 22:42:29 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Mon, 22 Jun 2015 04:12:29 +0530 Subject: [openssl-users] X509_verify() error - block type is not 01 Message-ID: Hi, I am trying to verify X509 certificate against two private keys such that atleast one of them it should match. I used the API as X509_verify(x509, pkey) where pkey is of EVP_PKEY type However, for one of the private key it is failing with error "block type is not 01" // And this key is supposed to be matching the certificate. and for other key it is failing with error "padding check failed" Can someone help me to understand these errors and how to fix, even though when I know the key with "block type error" does matches the certificate. Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sun Jun 21 23:14:11 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Jun 2015 19:14:11 -0400 Subject: [openssl-users] Suggested way to add option to both SSL_CTX* and SSL*? Message-ID: I need to add some functionality to the SSL portion of the library. I need to control when the functionality is enabled, and I was going to control it with a flag. (Existing behavior by default; option to enable behavior on SSL_CTX*; option to override on SSL*). I thought a SSL_CTX_ctrl and SSL_ctrl would be the way to approach it. I looked at how SSL_CTX_set_cipher_list and SSL_set_cipher_list operate, but they don't use SSL_{CTX}_ctrl. What is the suggested way to control the functionality through a flag? From rsalz at akamai.com Mon Jun 22 01:13:48 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 22 Jun 2015 01:13:48 +0000 Subject: [openssl-users] Suggested way to add option to both SSL_CTX* and SSL*? In-Reply-To: References: Message-ID: <638920373d9646f4a815932f75014c08@ustx2ex-dag1mb2.msg.corp.akamai.com> > I looked at how SSL_CTX_set_cipher_list and SSL_set_cipher_list operate, > but they don't use SSL_{CTX}_ctrl. That API probably predates the ctrl. It's a trade-off; you lose type-safety but have less to document :) > What is the suggested way to control the functionality through a flag? Probably the _ctrl API. Problem is we're running out of bits. Let's see what drH thinks. From openssl-users at dukhovni.org Mon Jun 22 02:08:07 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jun 2015 02:08:07 +0000 Subject: [openssl-users] X509_verify() error - block type is not 01 In-Reply-To: References: Message-ID: <20150622020807.GG14121@mournblade.imrryr.org> On Mon, Jun 22, 2015 at 04:12:29AM +0530, Nayna Jain wrote: > I am trying to verify X509 certificate against two private keys such that > atleast one of them it should match. What do you mean by "match"? Was either key used to sign the certificate, or is one of the keys the public key of the subject? > X509_verify(x509, pkey) where pkey is of EVP_PKEY type This checks whether the key signed the certificate. -- Viktor. From naynjain at in.ibm.com Mon Jun 22 02:26:37 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Mon, 22 Jun 2015 07:56:37 +0530 Subject: [openssl-users] [openssl-dev] X509_verify() error - block type is not 01 In-Reply-To: <20150622020807.GG14121@mournblade.imrryr.org> References: <20150622020807.GG14121@mournblade.imrryr.org> Message-ID: Thanks Victor, I want to match the certificate with the private key for whose public key that certificate is provided. If this verifies who signed the certificate, then how do I verify whether the certificate provided is for the private key which was generated, Thanks & Regards, Nayna Jain From: Viktor Dukhovni To: openssl-users at openssl.org, openssl-dev at openssl.org Date: 06/22/2015 07:39 AM Subject: Re: [openssl-dev] [openssl-users] X509_verify() error - block type is not 01 Sent by: "openssl-dev" On Mon, Jun 22, 2015 at 04:12:29AM +0530, Nayna Jain wrote: > I am trying to verify X509 certificate against two private keys such that > atleast one of them it should match. What do you mean by "match"? Was either key used to sign the certificate, or is one of the keys the public key of the subject? > X509_verify(x509, pkey) where pkey is of EVP_PKEY type This checks whether the key signed the certificate. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Jun 22 02:29:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jun 2015 02:29:52 +0000 Subject: [openssl-users] [openssl-dev] X509_verify() error - block type is not 01 In-Reply-To: References: <20150622020807.GG14121@mournblade.imrryr.org> Message-ID: <20150622022951.GH14121@mournblade.imrryr.org> On Mon, Jun 22, 2015 at 07:56:37AM +0530, Nayna Jain wrote: > I want to match the certificate with the private key for whose public key > that certificate is provided. That's the subject key, and unless the certificate is self-signed, the X509_verify() function is not the right interface. You want to extract the certificate's public key and compare it with the key you have. You can compare (memcmp()) the DER encoding of the public key from the certificate with the DER encoding of the desired key. > If this verifies who signed the certificate, then how do I verify whether > the certificate provided is for the private key which was generated, You compare the keys, or the key fingerprints. -- Viktor. From naynjain at in.ibm.com Mon Jun 22 03:27:08 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Mon, 22 Jun 2015 08:57:08 +0530 Subject: [openssl-users] [openssl-dev] X509_verify() error - block type is not 01 In-Reply-To: <20150622022951.GH14121@mournblade.imrryr.org> References: <20150622020807.GG14121@mournblade.imrryr.org> <20150622022951.GH14121@mournblade.imrryr.org> Message-ID: OK.. I think I understood this API wrongly then. What will X509_verify() will verify if I pass it public key. I mean in place of private key , if I try to match the public key than rather than doing keys comparision, will passing the public key to this API, help ? I mean does it check the private key with which certificate was signed, or the public key which this certificate signs. Sorry, I think I am still bit not clear on purpose of the API. Thanks & Regards, Nayna Jain From: Viktor Dukhovni To: openssl-users at openssl.org, openssl-dev at openssl.org Date: 06/22/2015 08:00 AM Subject: Re: [openssl-dev] [openssl-users] X509_verify() error - block type is not 01 Sent by: "openssl-dev" On Mon, Jun 22, 2015 at 07:56:37AM +0530, Nayna Jain wrote: > I want to match the certificate with the private key for whose public key > that certificate is provided. That's the subject key, and unless the certificate is self-signed, the X509_verify() function is not the right interface. You want to extract the certificate's public key and compare it with the key you have. You can compare (memcmp()) the DER encoding of the public key from the certificate with the DER encoding of the desired key. > If this verifies who signed the certificate, then how do I verify whether > the certificate provided is for the private key which was generated, You compare the keys, or the key fingerprints. -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Jun 22 03:31:39 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 22 Jun 2015 03:31:39 +0000 Subject: [openssl-users] [openssl-dev] X509_verify() error - block type is not 01 In-Reply-To: References: <20150622020807.GG14121@mournblade.imrryr.org> <20150622022951.GH14121@mournblade.imrryr.org> Message-ID: <20150622033139.GI14121@mournblade.imrryr.org> On Mon, Jun 22, 2015 at 08:57:08AM +0530, Nayna Jain wrote: > What will X509_verify() will verify if I pass it public key. It checks the signature of the certificate using the supplied key. > I mean does it check the private key with which certificate was signed, or > the public key which this certificate signs. It checks whether the given key *signed* the certificate. It does not examine the key in the certificate (the subject public key). > Sorry, I think I am still bit not clear on purpose of the API. X509_verify() verifies the certificate signature via the issuer public key. -- Viktor. From noloader at gmail.com Mon Jun 22 06:36:33 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jun 2015 02:36:33 -0400 Subject: [openssl-users] Provisional FIPS 140-2 casualty list In-Reply-To: <5582E0F8.40404@openssl.com> References: <5582E0F8.40404@openssl.com> Message-ID: Hi Steve, Forgive my ignorance.... >From the previous postings, I *thought* that the validation only applies to real iron, and [retroactively] was not conferred to the VMs. But it seems like this list includes real hardware, too: 12 Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) (gcc Compiler Version 4.1.3) 32 Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3) 33 Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3) Those caught my eye because I used them in the past (specifically, 12). What exactly changed? Or where is my disconnect? Jeff On Thu, Jun 18, 2015 at 11:17 AM, Steve Marquess wrote: > If you don't know or care what FIPS 140-2 is then count yourself very > lucky and move on. > > I've created a new web page to summarize the current status of the > long-running hostage saga: > > http://openssl.com/fips/aftermath.html > > If you use the OpenSSL FIPS Object Module 2.0 (validation #1747), you > should confirm that any platforms you use that module on are among the > survivors. > > However, don't panic quite yet if you're using one of the deleted > platforms. I'm pretty sure that the "Big Blob 'o Text" list as currently > posted has several clerical errors that the CMVP will eventually > correct. Also, I expect to receive permission from at least some of the > directly impacted platform sponsors to supply information for revised > platform descriptions. Once those are up, then you can panic. > > New developments will be noted in this new web page. > From marquess at openssl.com Mon Jun 22 09:34:43 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 22 Jun 2015 05:34:43 -0400 Subject: [openssl-users] Provisional FIPS 140-2 casualty list In-Reply-To: References: <5582E0F8.40404@openssl.com> Message-ID: <5587D6B3.2070103@openssl.com> On 06/22/2015 02:36 AM, Jeffrey Walton wrote: > Hi Steve, > > Forgive my ignorance.... > >>From the previous postings, I *thought* that the validation only > applies to real iron, and [retroactively] was not conferred to the > VMs. But it seems like this list includes real hardware, too: > > 12 Ubuntu 10.04 running on Intel Core i5 with AES-NI (32 bit) > (gcc Compiler Version 4.1.3) > 32 Ubuntu 10.04 (32 bit) (gcc Compiler Version 4.1.3) > 33 Ubuntu 10.04 (64 bit) (gcc Compiler Version 4.1.3) > > Those caught my eye because I used them in the past (specifically, 12). > > What exactly changed? Or where is my disconnect? CMVP requirements relating to virtualization have evolved considerably over time, and in fact it's the retroactive enforcement of those changing requirements that led to this "hostage" mess[*]. Once upon a time a virtualized OS+processor was treated the same as that OS running on that processor "bare iron", i.e. no virtualization. For instance, "AcmeOS 1.2 on x86". At the time the #1747 validation was started the CMVP required that virtualization be noted, as in an OS and a processor architecture running virtualized under some general virtualization environment (e.g. "AcmeOS 1.2 under vSphere on x86"), but there was no requirement for a hypervisor product version number. Then came a requirement for a hypervisor brand name plus version, e.g. "AcmeOS 1.2 under vSphere ESXi 4.4". This last requirement came into force after the #1747 validation was out and already had quite a few platforms. The platforms added since this requirement was introduced have the hypervisor brand name version qualification (e.g. platforms 97, 98). -Steve M. [*] retroactive requirements changes imposed on in-process validation actions have long been common, and are part of the challenge of completing any validation action with any kind of predictable budget or schedule. The imposition of retroactive changes on previously approved validations is a disturbing new development. -- 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 Michael.Wojcik at microfocus.com Mon Jun 22 12:44:17 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 22 Jun 2015 12:44:17 +0000 Subject: [openssl-users] beginner needs advice on data signature/verification In-Reply-To: <558528C7.90403@watz.at> References: <558528C7.90403@watz.at> Message-ID: Response inline below, prefixed with "MW". (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) Michael Wojcik Technology Specialist, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Marco Warga Sent: Saturday, June 20, 2015 04:48 To: openssl-users at openssl.org Subject: [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't "a very common requirement". It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - is commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. Thanks alot, Marco X509_verify_cert X509_verify_cert Click here to report this email as spam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Mon Jun 22 13:27:13 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Mon, 22 Jun 2015 09:27:13 -0400 Subject: [openssl-users] How to provide KDF to ECDH key computation when using EVP API? Message-ID: <55880D31.70708@gmail.com> 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? (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?) Thanks in advance, Reinier From marquess at openssl.com Mon Jun 22 15:27:53 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 22 Jun 2015 11:27:53 -0400 Subject: [openssl-users] Call for FIPS 140-2 stakeholders Message-ID: <55882979.6070405@openssl.com> If you don't know or care about FIPS 140-2 then count yourself very lucky and move on. In the same spirit of collaboration that underlies all of the open source based OpenSSL FIPS Object Module validations, of which the #1747 validation is the latest, some of the stakeholders impacted by the recent "hostage" issue[*] are discussing possible responses among themselves. I have been told they would like to reach out to other "interested impacted customers". We know who some of these are, but there will be many more users of the #1747 validation on those platforms we don't know about. If you are a such a stakeholder and would like to participate in those discussions please let me know (contact info below) and I'll make the appropriate introductions. -Steve M. [*] see 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 levitte at openssl.org Mon Jun 22 20:14:21 2015 From: levitte at openssl.org (Richard Levitte) Date: Mon, 22 Jun 2015 22:14:21 +0200 (CEST) Subject: [openssl-users] RT was down today, please resend Message-ID: <20150622.221421.538175214323483934.levitte@openssl.org> Hi, due to a mysql screwup, whatever was sent to openssl-bugs at openssl.org after 06:00 UTC today was lost (everything before that was safely backed up). If you did send something, I would like to kindly ask you to resend it. Sorry for the inconvenience. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steve at openssl.org Mon Jun 22 21:05:10 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 22 Jun 2015 21:05:10 +0000 Subject: [openssl-users] Suggested way to add option to both SSL_CTX* and SSL*? In-Reply-To: <638920373d9646f4a815932f75014c08@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <638920373d9646f4a815932f75014c08@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150622210510.GA11928@openssl.org> On Mon, Jun 22, 2015, Salz, Rich wrote: > > > I looked at how SSL_CTX_set_cipher_list and SSL_set_cipher_list operate, > > but they don't use SSL_{CTX}_ctrl. > > That API probably predates the ctrl. It's a trade-off; you lose type-safety but have less to document :) > > > What is the suggested way to control the functionality through a flag? > > Probably the _ctrl API. Problem is we're running out of bits. Let's see what drH thinks. We certainly are running out of options bits and will need to do something to address that at some point it hasn't been decided precisely *what* yet. However if the option is related to certificates it can use the cert_flags field in the CERT structure. If it is related to mode then it can use the mode field. Both of those have plenty to spare. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From noloader at gmail.com Mon Jun 22 21:44:28 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Jun 2015 17:44:28 -0400 Subject: [openssl-users] Fast DH parameters generation In-Reply-To: <55805B41.1060902@openca.org> References: <55805B41.1060902@openca.org> Message-ID: > Of course, the second approach is a lot faster - however, can anyone explain > the warning not from the documentation "Be careful to avoid small subgroup > attacks when using this." ? AFAIK, for such attacks to be effective, they > require that the parameters are re-used multiple times. However, in our > specific case, the generated parameters will be used only once (2048 bits) > and then discarded... No, small subgroups or confinement attacks are due to Schnorr. They are based on the size of q, not the size of p. See https://en.wikipedia.org/wiki/Small_subgroup_confinement_attack. You can have a large group (2048-bits), but a small subgroup (say 48-bits or 64-bits) that makes the problem much easier. A security level of 48-bits is well within reach of many attackers. 64-bits is within reach of some attackers, given how cheaply compute time can be purchased on Nova or EC2. And also see "On Small Subgroup Non-confinement Attack", https://eprint.iacr.org/2010/149.pdf. From wangqun at alumni.nus.edu.sg Tue Jun 23 01:48:18 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 22 Jun 2015 18:48:18 -0700 (MST) Subject: [openssl-users] Has the support for SPARC architecture crypto extensions been Implemented? Message-ID: <1435024098896-58866.post@n7.nabble.com> Hello OpenSSL folks, We have a product which is an OpenSSL 1.0.1 application. One of my customers is running my product on his SunSparc Solaris 11 platform which has a Crypto Accelerator. Around the end of last year, he complained to me that OpenSSL doesn't utilize the accelerator at all. I then checked on OpenSSL website and found the following description. Changes between 1.0.1e and 1.0.2 [xx XXX xxxx] *) Initial support for PowerISA 2.0.7, first implemented in POWER8. This covers AES, SHA256/512 and GHASH. "Initial" means that most common cases are optimized and there still is room for further improvements. Vector Permutation AES for Altivec is also added. [Andy Polyakov] *) Add support for little-endian ppc64 Linux target. [Marcelo Cerri (IBM)] *) Initial support for AMRv8 ISA crypto extensions. This covers AES, SHA1, SHA256 and GHASH. "Initial" means that most common cases are optimized and there still is room for further improvements. Both 32- and 64-bit modes are supported. [Andy Polyakov, Ard Biesheuvel (Linaro)] *) Improved ARMv7 NEON support. [Andy Polyakov] *) 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] Hence I told him to wait until OpenSSL 1.0.2 to be released officially. I promised him I would upgrade the OpenSSL used in my product to 1.0.2, so his crypto accelerator would be utilized. He came back to me recently as OpenSSL 1.0.2 has been released officially. However after checking change log of 1.0.2, 1.0.2a, 1.0.2b and 1.0.2c, I could not find any description regarding to 'Support for SPARC Architecture 2011 crypto extensions'. My question is if the support for SPARC architecture crypto extensions has been Implemented yet? 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-tp58866.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From wangqun at alumni.nus.edu.sg Tue Jun 23 04:53:37 2015 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 22 Jun 2015 21:53:37 -0700 (MST) Subject: [openssl-users] Has the support for SPARC architecture crypto extensions been Implemented? In-Reply-To: <1435024098896-58866.post@n7.nabble.com> References: <1435024098896-58866.post@n7.nabble.com> Message-ID: <1435035217195-58867.post@n7.nabble.com> Found this, so the feature has been implemented. Aaron 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/Has-the-support-for-SPARC-architecture-crypto-extensions-been-Implemented-tp58866p58867.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From watz at watz.at Tue Jun 23 17:55:02 2015 From: watz at watz.at (Marco Warga) Date: Tue, 23 Jun 2015 19:55:02 +0200 Subject: [openssl-users] beginner needs advice on data signature/verification In-Reply-To: References: <558528C7.90403@watz.at> Message-ID: <55899D76.2060706@watz.at> Many thanks for the answer. I should have been more specific on the requirements right away. The "file" was really just an example to keep it simple. Reading my own writing, I would probably have suggested what you did :-) So here are the facts: - client/server are not connected to the internet - the network protocol is existing and proprietary - the file structure is existing and proprietary, but can be extended to allow for additional signature information to be embedded that will be sent to the server - the data actually transferred (and to be signed) is part of that file - the data has to be signed with an X.509 certificates public key that already exists S/MIME does pretty much do what I want to do. However the network protocol or the data to be signed cannot be changed for compatibility reasons. Under these circumstances, I don't really see how I could achieve my goal easier than by openssl directly. Considering the "very common requirement": I was thinking of i.e. windows driver signatures, android/ios app signatures and similar mechanisms to ensure that files are from a trusted source. Am 22.06.2015 um 14:44 schrieb Michael Wojcik: > > Response inline below, prefixed with "MW". (Unfortunately Outlook is > incapable of replying to HTML messages properly, so you'll have to > excuse the formatting.) > > Michael Wojcik > Technology Specialist, Micro Focus > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Marco Warga > *Sent:* Saturday, June 20, 2015 04:48 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] beginner needs advice on data > signature/verification > > Hi, > > I hope some of you could give me advice on my project using openssl. > > MW: Why are you using OpenSSL for this application? You want to create > a file on a trusted system, pass it through an untrusted intermediary, > and process it on another trusted system. Why not simply use an > existing mechanism like secure email? (GPG is the obvious choice, > unless there are licensing issues.) If you are determined to create > your own protocol from primitives, then really all you appear to need > here is an HMAC. Don't involve the horrific mess that is X.509 PKI > unless it actually provides some benefit. > > > Lets say I have a server/service on a machine processing a file a > corresponding client sends. That file is usually created by me on a > clean third machine. The server side is assumed to be uncompromised > (no hacker). The client side may be compromised. Now I need to make > sure that the service only accepts those files that are created by me. > I believe that is a very common requirement and has been done alot of > times - I just can't find tutorials on how to implement it. Know any ? > > MW: No, but that's probably because what you've described isn't "a > very common requirement". It's too vague. We don't know what problem > you're actually trying to solve. It may be that you just need to send > a file with a verifier, which - as I noted above - /is/ commonly done, > generally using something like GPG or (for roll-your-own protocols > where both ends are controlled by the same party) an HMAC. > > > > Lets assume I have an x509 cert together with its private key signed > by a ca owned by me. The trusted ca cert will be present on the server > side. This is what I plan to do: > > 1.) Create the data files/blobs and sign them using the priv key of > the cert. Distribute the cert and the signature along with (or inside) > the data file. > 2.) Have the client send that data file to the server (cert/sig first) > 3.) Service receives the cert, builds a cert store with the local ca > cert in it and verifies the client's cert with X509_verify_cert() > 4.) if cert verifies ok, service compares the signature against the > one calculated from the incoming data using the public key that came > inside the cert just verified > > > Would this be the right approach considering that anything the client > sends may be forged (cert, sig, data...) ? > > MW: It's safe from malicious behavior by the client, under a threat > model where an attacker is not able to forge client certificates or > client signatures. In other words, it's safe as long as the private > keys are neither leaked nor forced. > > > Or would it be safer to have the cert used for signing stored on the > server side and not send with the data (instead just its subject > protected by the signature) ? > > MW: Irrelevant to the security of the scheme. Simpler from a > development and operations standpoint. But using something like > PGP/GPG or S/MIME would be simpler yet. There are any number of > examples online for signing a file and verifying its signature. > > > > Thanks alot, > Marco > > X509_verify_cert > > X509_verify_cert > > Click here > > to report this email as spam. > > > > _______________________________________________ > 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 Tue Jun 23 23:35:25 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 24 Jun 2015 01:35:25 +0200 Subject: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting In-Reply-To: References: Message-ID: <5589ED3D.9010702@wisemo.com> On 19/06/2015 16:24, Ben Humpert wrote: > When the CSR contains an email address and the email_in_dn setting in > the config file is set to "no" the email address is actually present > in the issuer DN but not in the subject DN. This causes errors when > verifying certificate chains since the subject hash is used to > identify a cert but the issuer hash is different. Are you sure, I have not seen this behavior in current versions when making self-signed certificates, could you provide step by step reproduction procedures to cause this misbehavior? > A dirty workaround is to 1) link the subject hash to the cert file and > additionally 2) link the issuer hash to the same cert file Such a workaround would be absolutely no help for anyone using any other crypto library to verify the certificate chain. If OpenSSL certificate verification accepts an invalid certificate chain by simply linking from the wrong hash to a certificate with a different subject, then that is a minor security vulnerability in the verification code in OpenSSL, as that would also make it fail for any fake issuer name chosen to have the same (non-cryptographic) hash as an already trusted certificate. The limitation of such a vulnerability would be that the cryptographic keys still need to match. 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 Wed Jun 24 05:53:05 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 24 Jun 2015 07:53:05 +0200 Subject: [openssl-users] beginner needs advice on data signature/verification In-Reply-To: <55899D76.2060706@watz.at> References: <558528C7.90403@watz.at> <55899D76.2060706@watz.at> Message-ID: <558A45C1.6060406@wisemo.com> (Continuing top posting to keep thread consistent). First of all, if the client itself is compromised, the file content can be compromised just before you do whatever you do to assure the server that this was what the user of the client wanted. No way to fix that other than to keep the client free of compromise. Now the common solution used by driver and program signing programs such as Symbian signed (discontinued), Windows driver package signing for compatibility, Windows driver binary signing for Windows 10, and older versions of Windows Mobile 5.x/6.x signing is this: 1. Client has a unique X509 certificate with a private key known only to that client. Doesn't matter who issued the certificate, but the server needs to have its own known genuine copy of that certificate. That certificate should be such that no one except that client and that server trusts things for being signed by it. 2. Client signs the file/message with its private certificate exactly as if that would be the final signature (even though almost no one will trust it). 3. Client sends signed file/message to server. 4. Server verifies the signed file/message using its private list of trusted client certificates. 5. Server maps the verified signature to the identity to be used for the final signature. 6. Server talks to its closely related CA to get a brand new single-use-only certificate for the identity (with a serial number added as an extra subject name element). 7. Server removes the client signature and signs the file/message with the brand new certificate for the final identity. 8. Server throws away the private key, so that no more files can be signed with that certificate, ever. 9. If the server ever signs anything by mistake, it (or an admin if the server was permanently compromised) asks its closely related CA to revoke the affected single-use certificate. 10. If the client certificate needs to be revoked due to the certificate or its user being compromised on some current or past time/date, the related CA revokes all the single-use certificates for that identity since that date/time. Other/replacement client certificates for the same (visible) identity remain valid because single-use certificates for those requests were never revoked. 11. Note that in this setup, there is no need for a time stamping service, simply give the single-use certificate the long (listed) lifetime, and rely on the uncompromised server diligently deleting the private key within a few seconds after creating it. Of cause you don't need to make this entire "temporary certificate" dance (steps 6, and 8 to 11), for instance if the server will be using certificates issued by one of the pay-per-certificate public CAs, the server will instead need to keep around a certificate/private key pair for each public identity, and may need to use a public time stamping service just as if it was a normal direct end-signer. As for the format, putting S/MIME aka CMS aka PKCS#7 format signatures inside a file format, look at how Microsoft did this with its AuthentiCode concept and how Sun/Oracle did with its jar format. Its almost the same procedure with 5 minor differences: * AuthentiCode sets the PKCS#7 content-type to an AuthentiCode specific OID, jar file use the generic "data" OID. At least some members of OpenSSL team suggest that using any OID other than "data" is not allowed by more recent versions of the CMS standard. * AuthentiCode signs a custom DER encoded ASN.1 structure with the relevant attributes and secure hashes of the parts of the signed document that don't depend on the value/size of the signature blob itself. Jar signs a formatted text file with that same data. * (classic) AuthentiCode uses the original countersignature format and attribute for timestamping, requiring a timestamping service that creates "bare" signatures of the small blob sent for timestamping, jar files may or may not use a slightly different format allowing use of the newer RFC-based timestamping protocol. * Some implementations of jar signature validation (most notably the one used by Mozilla/Firefox/Thunderbird) requires the certificates to have the attributes of the historic "object signing" protocol, AuthentiCode and most other jar implementations simply require the relevant extended usage attribute in the end certificate. Commercial code/object signing certificates tend to include the extra attributes to work for both. * The two formats sometimes forget to check different obscure parts of the file being signed for some file formats. I won't elaborate on which ones. From this list of differences and similarities, it should be somewhat easy to make sane choices for how to design your own use of X.509 certificates. Note that if the items being signed are documents rather than program-like objects, you should probably check for the e-mail signing or document-signing extended usage attribute, not the object-signing one. On 23/06/2015 19:55, Marco Warga wrote: > Many thanks for the answer. > > I should have been more specific on the requirements right away. The > "file" was really just an example to keep it simple. Reading my own > writing, I would probably have suggested what you did :-) > > So here are the facts: > - client/server are not connected to the internet > - the network protocol is existing and proprietary > - the file structure is existing and proprietary, but can be extended > to allow for additional signature information to be embedded that will > be sent to the server > - the data actually transferred (and to be signed) is part of that file > - the data has to be signed with an X.509 certificates public key that > already exists > > S/MIME does pretty much do what I want to do. However the network > protocol or the data to be signed cannot be changed for compatibility > reasons. Under these circumstances, I don't really see how I could > achieve my goal easier than by openssl directly. > > Considering the "very common requirement": I was thinking of i.e. > windows driver signatures, android/ios app signatures and similar > mechanisms to ensure that files are from a trusted source. > > Am 22.06.2015 um 14:44 schrieb Michael Wojcik: >> >> Response inline below, prefixed with "MW". (Unfortunately Outlook is >> incapable of replying to HTML messages properly, so you'll have to >> excuse the formatting.) >> >> *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On >> Behalf Of *Marco Warga >> *Sent:* Saturday, June 20, 2015 04:48 >> *To:* openssl-users at openssl.org >> *Subject:* [openssl-users] beginner needs advice on data >> signature/verification >> >> Hi, >> >> I hope some of you could give me advice on my project using openssl. >> >> MW: Why are you using OpenSSL for this application? You want to >> create a file on a trusted system, pass it through an untrusted >> intermediary, and process it on another trusted system. Why not >> simply use an existing mechanism like secure email? (GPG is the >> obvious choice, unless there are licensing issues.) If you are >> determined to create your own protocol from primitives, then really >> all you appear to need here is an HMAC. Don't involve the horrific >> mess that is X.509 PKI unless it actually provides some benefit. >> >> >> Lets say I have a server/service on a machine processing a file a >> corresponding client sends. That file is usually created by me on a >> clean third machine. The server side is assumed to be uncompromised >> (no hacker). The client side may be compromised. Now I need to make >> sure that the service only accepts those files that are created by >> me. I believe that is a very common requirement and has been done >> alot of times - I just can't find tutorials on how to implement it. >> Know any ? >> >> MW: No, but that's probably because what you've described isn't "a >> very common requirement". It's too vague. We don't know what problem >> you're actually trying to solve. It may be that you just need to send >> a file with a verifier, which - as I noted above - /is/ commonly >> done, generally using something like GPG or (for roll-your-own >> protocols where both ends are controlled by the same party) an HMAC. >> >> >> >> Lets assume I have an x509 cert together with its private key signed >> by a ca owned by me. The trusted ca cert will be present on the >> server side. This is what I plan to do: >> >> 1.) Create the data files/blobs and sign them using the priv key of >> the cert. Distribute the cert and the signature along with (or >> inside) the data file. >> 2.) Have the client send that data file to the server (cert/sig first) >> 3.) Service receives the cert, builds a cert store with the local ca >> cert in it and verifies the client's cert with X509_verify_cert() >> 4.) if cert verifies ok, service compares the signature against the >> one calculated from the incoming data using the public key that came >> inside the cert just verified >> >> >> Would this be the right approach considering that anything the client >> sends may be forged (cert, sig, data...) ? >> >> MW: It's safe from malicious behavior by the client, under a threat >> model where an attacker is not able to forge client certificates or >> client signatures. In other words, it's safe as long as the private >> keys are neither leaked nor forced. >> >> >> Or would it be safer to have the cert used for signing stored on the >> server side and not send with the data (instead just its subject >> protected by the signature) ? >> >> MW: Irrelevant to the security of the scheme. Simpler from a >> development and operations standpoint. But using something like >> PGP/GPG or S/MIME would be simpler yet. There are any number of >> examples online for signing a file and verifying its signature. >> >> 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 maverick.rishi at gmail.com Wed Jun 24 09:51:17 2015 From: maverick.rishi at gmail.com (Rishi Pathak) Date: Wed, 24 Jun 2015 15:21:17 +0530 Subject: [openssl-users] Create CMS signed data only with signature(not requiring data) Message-ID: Openssl CMS command requires the actual data to be provided as an input for creating CMS signed data type. But what we have is only the signature and the certificate. Is there a way to create CMS signed data without requiring the original document. What we want is to only create and not sign as we already have signature on the hash of the document. One way we thought was to use genconf of asn1parse command, i.e. create configuration file for CMS in the format required by it. But not much help is available on that front. Any thoughts, links are welcome. -- -------------This message is sent with 100% recycled electrons----------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Jun 24 12:35:30 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 24 Jun 2015 14:35:30 +0200 Subject: [openssl-users] Create CMS signed data only with signature(not requiring data) In-Reply-To: References: Message-ID: <558AA412.5090002@wisemo.com> On 24/06/2015 11:51, Rishi Pathak wrote: > Openssl CMS command requires the actual data to be provided as an > input for creating CMS signed data type. > > But what we have is only the signature and the certificate. Is there a > way to create CMS signed data without requiring the original document. > What we want is to only create and not sign as we already have > signature on the hash of the document. > > One way we thought was to use genconf of asn1parse command, i.e. > create configuration file for CMS in the format required by it. But > not much help is available on that front. > > Any thoughts, links are welcome. > First of all, you are not limited to the command line tools in the openssl utility. OpenSSL is first and foremost a programming library and the command line tools are just a (big) taste of what you can do with that library. Second, what you really want is probably one of the following: * To verify a CMS (PKCS#7) signature on a short message containing a hash of the rest of the document. In this case, verifying the signature and checking if the document hash matches the contents of the short message are already different steps, with the CMS API and/or the "openssl cms" command only doing the verify of the signature only. * To verify a "detached" CMS signature on the document hash. Internally, this is actually a special form of a signature on a short message like above, but you may need to look deeper at the API to find the sequence of calls which verifies this separately from the step of computing a hash of the rest of the document, unfortunately, this is not currently exposed by the "openssl cms" or "openssl smime" command, though it is often a useful first step, for instance if you download the signature before the signed 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 mseaborn62 at hotmail.com Thu Jun 25 14:17:02 2015 From: mseaborn62 at hotmail.com (Mark) Date: Thu, 25 Jun 2015 07:17:02 -0700 (MST) Subject: [openssl-users] Generating FIPS Compliant libcrypto.so Message-ID: <1435241822173-58890.post@n7.nabble.com> Ok, I searched and there are a lot of topics around building the fip compliant version of openssl. My problem is with the generation of the libcrypto.so. Environment Debian 8 openssl fips 2.0.9 openssl 1.0.1o I follow the security guide and build a valid fipscanister.o file. I test it and it works fine. Then in section 3.3 of the users guide it states. "The FIPS Object Module is not directly usable as a shared library, but it can be linked into an application that is a shared library. A ?FIPS compatible? OpenSSL distribution will automatically incorporate an available FIPS Object Module into the libcrypto shared library when built using the fips option (see ?4.2.3)." Then in section 4.2.3 of the users guide it states. "Once the validated FIPS Object Module has been generated it is usually combined with an OpenSSL distribution in order to provide the standard OpenSSL API. Any 1.0.1 release can be used for this purpose. The commands ./config fips <...other options...> make <...options...> make install will build and install the new OpenSSL without overwriting the validated FIPS Object Module files." This produces a version of libcrypto.a that can be statically linked to an application and SET_FIPS_MODE(1); Returns 1. However, this does process does not create the libcrypto.so file during the build process. So my next logical step was to configure openssl-1.0.1o for shared libraries. ./config fips shared make depend make su root make install This creates libcrypto.so just fine. However here is the rub, i get the following issue trying to link the functions into a file. 140261525202608:error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported:o_fips.c:92: I am also having an issue where openssl 1.0.1o creates PEM version of the public/private keys = -----BEGIN RSA PUBLIC KEY----- MAA= -----END RSA PUBLIC KEY----- -----BEGIN PRIVATE KEY----- MBkCAQAwDQYJKoZIhvcNAQEBBQAEBTADAgEA -----END PRIVATE KEY----- -----BEGIN RSA PUBLIC KEY----- no matter what size key i ask it to create 1024, 2048, or 4096 on the statically liked version of the software. What is the right way to get openssl to generate the libcrypto.so in a "compliant" manner? -- View this message in context: http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From mseaborn62 at hotmail.com Thu Jun 25 19:32:14 2015 From: mseaborn62 at hotmail.com (Mark) Date: Thu, 25 Jun 2015 12:32:14 -0700 (MST) Subject: [openssl-users] Generating FIPS Compliant libcrypto.so In-Reply-To: <1435241822173-58890.post@n7.nabble.com> References: <1435241822173-58890.post@n7.nabble.com> Message-ID: <1435260734009-58899.post@n7.nabble.com> Ok, I will answer my own question here. The problem was that I did not have the LD_LIBRARY_PATH set correctly for openssl. -- View this message in context: http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890p58899.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From mseaborn62 at hotmail.com Thu Jun 25 21:04:48 2015 From: mseaborn62 at hotmail.com (Mark) Date: Thu, 25 Jun 2015 14:04:48 -0700 (MST) Subject: [openssl-users] Generating FIPS Compliant libcrypto.so In-Reply-To: <1435260734009-58899.post@n7.nabble.com> References: <1435241822173-58890.post@n7.nabble.com> <1435260734009-58899.post@n7.nabble.com> Message-ID: <1435266288872-58904.post@n7.nabble.com> Ok, the API call was not correct RSA_generate_key_ex was not working same. I have resolved all the issues now. -- View this message in context: http://openssl.6102.n7.nabble.com/Generating-FIPS-Compliant-libcrypto-so-tp58890p58904.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Fri Jun 26 12:30:12 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 26 Jun 2015 08:30:12 -0400 Subject: [openssl-users] New FIPS 140-2 "SE" Validation Approved Message-ID: <558D45D4.6070908@openssl.com> If you don't know or care what FIPS 140-2 is, a hysterical giggle of pure delight and whoop of relief before moving on is fully justified. The "SE" (Salavge Edition) validation has been approved: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2398 This actually appeared on the evening of the 24th or morning of the 25th, but then disappeared for several hours, and had a broken link to the Security Policy for a few hours after that. So I waited a day before concluding it was here to stay. The SE validation is one of the two "1A SUB" validations intended to "ransom"[*] the "hostage"[**] platforms in the #1747 validation. The other RE validation has not yet been approved, although it differs from the SE one by exactly six characters and was submitted at the same time. With the "execution" of the "hostages" anyway[***] these two new validations may be superfluous. We're not entirely sure and are trying to figure out what the bureaucracy will and won't do with new "change letter" updates. We've submitted a change letter update for revision 2.0.10 against both the #1747 and #2398 validations, so time will tell. The four presumed clerical errors in the list of #1747 survivors (the "Big Blob o' Text) have still not been corrected after 11 days, nor do we have any indication that they are not accidental typos. I'm still assuming clerical error, but we won't know for sure until we get some sort of response. -Steve M. [*] http://openssl.com/fips/ransom.html [**] http://openssl.com/fips/hostage.html [***] 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 thomas.francis.jr at pobox.com Fri Jun 26 14:14:48 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Fri, 26 Jun 2015 10:14:48 -0400 Subject: [openssl-users] Call for FIPS 140-2 stakeholders In-Reply-To: <55882979.6070405@openssl.com> References: <55882979.6070405@openssl.com> Message-ID: <4A2929AA-491B-4378-B697-1393B2FE1B6A@pobox.com> I'm not currently interested in the given platforms, and while I really hope to never be interested again, I can't rule it out. It'd be nice to be able to follow the discussions, without necessarily contributing. But I also understand I if those involved don't want to include those in my position, since I can just read your updates, and accept them without knowing all the reasons behind it. :) I'm ok either way. TOM -- Preserve wildlife -- pickle a squirrel! > On Jun 22, 2015, at 11:27 AM, Steve Marquess wrote: > > If you don't know or care about FIPS 140-2 then count yourself very > lucky and move on. > > In the same spirit of collaboration that underlies all of the open > source based OpenSSL FIPS Object Module validations, of which the #1747 > validation is the latest, some of the stakeholders impacted by the > recent "hostage" issue[*] are discussing possible responses among > themselves. I have been told they would like to reach out to other > "interested impacted customers". We know who some of these are, but > there will be many more users of the #1747 validation on those platforms > we don't know about. > > If you are a such a stakeholder and would like to participate in those > discussions please let me know (contact info below) and I'll make the > appropriate introductions. > > -Steve M. > > [*] see 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 > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From reinier.torenbeek at gmail.com Fri Jun 26 16:47:34 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 26 Jun 2015 12:47:34 -0400 Subject: [openssl-users] Implementing ECDSA in an engine Message-ID: <558D8226.70701@gmail.com> Hi, The mechanism for implementing ECDSA in my own engine is unclear to me. Unfortunately, none of the example engines implement ECDSA so it is hard for me to find answers. Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, sign and verify methods never get invoked. Stepping through the openssl code, it looks like I also need to register my own EVP_PKEY_EC method. That looks pretty complicated and I do not understand why that is required in the first place if I only want to replace the ECDSA signing and verification methods. Can someone confirm that registering my own EVP_PKEY_EC method is indeed the approach I have to take, or is there a shorter path to achieve my goal? Is this the right list to ask questions about engine implementations? Or would using openssl-dev be more appropriate? Thanks, Reinier From beldmit at gmail.com Fri Jun 26 16:51:42 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 26 Jun 2015 19:51:42 +0300 Subject: [openssl-users] Implementing ECDSA in an engine In-Reply-To: <558D8226.70701@gmail.com> References: <558D8226.70701@gmail.com> Message-ID: Hello Reinier, On Fri, Jun 26, 2015 at 7:47 PM, Reinier Torenbeek < reinier.torenbeek at gmail.com> wrote: > Hi, > > The mechanism for implementing ECDSA in my own engine is unclear to me. > Unfortunately, none of the example engines implement ECDSA so it is hard > for me to find answers. > > Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, > sign and verify methods never get invoked. Stepping through the openssl > code, it looks like I also need to register my own EVP_PKEY_EC method. > That looks pretty complicated and I do not understand why that is > required in the first place if I only want to replace the ECDSA signing > and verification methods. > > Can someone confirm that registering my own EVP_PKEY_EC method is indeed > the approach I have to take, or is there a shorter path to achieve my goal? > I did not find a way shorter then provide own EVP_PKEY_METHOD. But it works for me this way. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Fri Jun 26 18:09:55 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Fri, 26 Jun 2015 14:09:55 -0400 Subject: [openssl-users] Implementing ECDSA in an engine In-Reply-To: References: <558D8226.70701@gmail.com> Message-ID: <558D9573.50605@gmail.com> Hi Dmitry, Thanks for the response. I suppose I have to do the same thing as well then. I wonder why the ECDSA_METHOD structure and the associated mechanism to insert it into an engine is so much different from the DSA_METHOD struct. The latter seems more straightforward to use and does not require the whole custom PKEY to be set up. Do you know? Best regards, Reinier On 6/26/15 12:51 PM, Dmitry Belyavsky wrote: > Hello Reinier, > > On Fri, Jun 26, 2015 at 7:47 PM, Reinier Torenbeek > > wrote: > > Hi, > > The mechanism for implementing ECDSA in my own engine is unclear > to me. > Unfortunately, none of the example engines implement ECDSA so it > is hard > for me to find answers. > > Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, > sign and verify methods never get invoked. Stepping through the > openssl > code, it looks like I also need to register my own EVP_PKEY_EC method. > That looks pretty complicated and I do not understand why that is > required in the first place if I only want to replace the ECDSA > signing > and verification methods. > > Can someone confirm that registering my own EVP_PKEY_EC method is > indeed > the approach I have to take, or is there a shorter path to achieve > my goal? > > > I did not find a way shorter then provide own EVP_PKEY_METHOD. But it > works for me this way. > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Jun 26 19:08:37 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 26 Jun 2015 22:08:37 +0300 Subject: [openssl-users] Implementing ECDSA in an engine In-Reply-To: <558D9573.50605@gmail.com> References: <558D8226.70701@gmail.com> <558D9573.50605@gmail.com> Message-ID: Hello Reinier, No, I do not. And may be for your purposes you can use this or that ECDSA_METHOD setting it into the EC_KEY struct. On Fri, Jun 26, 2015 at 9:09 PM, Reinier Torenbeek < reinier.torenbeek at gmail.com> wrote: > Hi Dmitry, > > Thanks for the response. I suppose I have to do the same thing as well > then. > > I wonder why the ECDSA_METHOD structure and the associated mechanism to > insert it into an engine is so much different from the DSA_METHOD struct. > The latter seems more straightforward to use and does not require the whole > custom PKEY to be set up. Do you know? > > Best regards, > Reinier > > > On 6/26/15 12:51 PM, Dmitry Belyavsky wrote: > > Hello Reinier, > > On Fri, Jun 26, 2015 at 7:47 PM, Reinier Torenbeek < > reinier.torenbeek at gmail.com> wrote: > >> Hi, >> >> The mechanism for implementing ECDSA in my own engine is unclear to me. >> Unfortunately, none of the example engines implement ECDSA so it is hard >> for me to find answers. >> >> Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, >> sign and verify methods never get invoked. Stepping through the openssl >> code, it looks like I also need to register my own EVP_PKEY_EC method. >> That looks pretty complicated and I do not understand why that is >> required in the first place if I only want to replace the ECDSA signing >> and verification methods. >> >> Can someone confirm that registering my own EVP_PKEY_EC method is indeed >> the approach I have to take, or is there a shorter path to achieve my >> goal? >> > > I did not find a way shorter then provide own EVP_PKEY_METHOD. But it > works for me this way. > > -- > SY, Dmitry Belyavsky > > > _______________________________________________ > 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 > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Fri Jun 26 19:41:28 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Fri, 26 Jun 2015 21:41:28 +0200 Subject: [openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash Message-ID: <558DAAE8.9020200@mathemainzel.info> Hello, has anybody got a reliable source or knowledge about which mail clients - especially which Thunderbird release - should be capable of verifying such mails correctly? this openssl smime -verify -CAfile trusted.crt -in mail.eml successfully verifies such an e-Mail; Thanks, Walter -- Best regards, Ing. Walter H?hlhubmer -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5971 bytes Desc: S/MIME Cryptographic Signature URL: From steve at openssl.org Fri Jun 26 20:25:07 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 26 Jun 2015 20:25:07 +0000 Subject: [openssl-users] Implementing ECDSA in an engine In-Reply-To: <558D8226.70701@gmail.com> References: <558D8226.70701@gmail.com> Message-ID: <20150626202507.GA30031@openssl.org> On Fri, Jun 26, 2015, Reinier Torenbeek wrote: > > The mechanism for implementing ECDSA in my own engine is unclear to me. > Unfortunately, none of the example engines implement ECDSA so it is hard > for me to find answers. > > Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, > sign and verify methods never get invoked. > There are two separate ways you can implement a public key algorithm in an ENGINE. The first is a default method which is then used for every single operation. This is most suited to cryptographic accelerators. The second is a key specific method which is utilised for some (and maybe not all) operations on one key. This would be most suited for a smart card for example where signing might be performed by the card but verification performed by OpenSSL itself. The second form isn't well supported for ECDSA at present though you can sort of get that functionality using the first technique. That will be fixed at some point most likely in the master branch for OpenSSL 1.1.0. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From sanumesh at in.ibm.com Sat Jun 27 17:46:19 2015 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Sat, 27 Jun 2015 23:16:19 +0530 Subject: [openssl-users] Logjam impact on 0.9.8y version Message-ID: Hello, I see a fix for logjam has been provided from 1.0.1 and 1.0.2 versions of openssl. https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ Does that imply 0.9.8 is not impacted by logjam? Also, Is it not required to disable export cipher suites in 0.9.8 version? Thanks Regards Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From reinier.torenbeek at gmail.com Sun Jun 28 02:54:29 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sat, 27 Jun 2015 22:54:29 -0400 Subject: [openssl-users] Implementing ECDSA in an engine In-Reply-To: <20150626202507.GA30031@openssl.org> References: <558D8226.70701@gmail.com> <20150626202507.GA30031@openssl.org> Message-ID: <558F61E5.4000902@gmail.com> Hello Steve, Thank you for the response. The ECDSA_set_default_method() indeed sets up the functionality as you describe below and that seems to be good enough for me (for now...). Best regards, Reinier On 6/26/15 4:25 PM, Dr. Stephen Henson wrote: > On Fri, Jun 26, 2015, Reinier Torenbeek wrote: > >> The mechanism for implementing ECDSA in my own engine is unclear to me. >> Unfortunately, none of the example engines implement ECDSA so it is hard >> for me to find answers. >> >> Invoking ENGINE_set_ECDSA() does not seem to be sufficient: my setup, >> sign and verify methods never get invoked. >> > There are two separate ways you can implement a public key algorithm in an > ENGINE. > > The first is a default method which is then used for every single operation. > This is most suited to cryptographic accelerators. > > The second is a key specific method which is utilised for some (and maybe not > all) operations on one key. This would be most suited for a smart card for > example where signing might be performed by the card but verification > performed by OpenSSL itself. > > The second form isn't well supported for ECDSA at present though you can sort > of get that functionality using the first technique. That will be fixed > at some point most likely in the master branch for OpenSSL 1.1.0. > > 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 reinier.torenbeek at gmail.com Sun Jun 28 02:55:59 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sat, 27 Jun 2015 22:55:59 -0400 Subject: [openssl-users] How to provide KDF to ECDH key computation when using EVP API? In-Reply-To: <55847A35.2050207@gmail.com> References: <55847A35.2050207@gmail.com> Message-ID: <558F623F.60907@gmail.com> 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? > > (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?) > > Thanks in advance, > Reinier > > From reinier.torenbeek at gmail.com Sun Jun 28 03:42:46 2015 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sat, 27 Jun 2015 20:42:46 -0700 Subject: [openssl-users] How to provide KDF to ECDH key computation when using EVP API? In-Reply-To: <558F623F.60907@gmail.com> References: <55847A35.2050207@gmail.com> <558F623F.60907@gmail.com> Message-ID: Clarifying my intentions with a snippet of example code that I would like to end up with (omitting some lines as well as error checking for the sake of brevity): ctx = EVP_PKEY_CTX_new(local_key, NULL); EVP_PKEY_derive_init(ctx); /* Set digest to be used to sha256 */ EVP_PKEY_CTX_ctrl(ctx, EVP_PKEY_EC, EVP_PKEY_OP_DERIVE, EVP_PKEY_CTRL_MD, 0, (void *)EVP_sha256()); EVP_PKEY_derive_set_peer(ctx, remote_key); /* Compute shared secret and apply sha256 to it to get a usable key */ EVP_PKEY_derive(ctx, result_key, &result_len); This is all compilable and runnable code, but the EVP_PKEY_CTX_ctrl invocation is essentially ignored at this moment. Therefore the sha256 does not actually take place. On Sat, Jun 27, 2015 at 7:55 PM, Reinier Torenbeek < reinier.torenbeek at gmail.com> 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? > > > > (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?) > > > > Thanks in advance, > > Reinier > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shobha_Dashottar at symantec.com Sun Jun 28 04:02:33 2015 From: Shobha_Dashottar at symantec.com (Shobha Dashottar) Date: Sat, 27 Jun 2015 21:02:33 -0700 Subject: [openssl-users] Compiling FIPS compliant Openssl for SSE architecture Message-ID: <4FC21D5F89235547922C24CA0FEB7138203E37828C@APJ1XCHEVSPIN36.SYMC.SYMANTEC.COM> Hi All, I am trying to build fips compliant openssl 1.0.1m for SSE (nonSSE2) architecture . The last time I did this, it was not fips compliant( just built openssl for SSE ) so it worked. >From the Developer Command Prompt for VS 2012: 1. Build fips-ecp 2.0.8 executing 'ms\do_fips' after setting the PROCESSOR_ARCHITECTURE=x86 to build for SSE added the /arch:SSE flag to the CFLAG in the Configure file '$cflags = "$cflags$exp_cflags /arch:SSE"' [ Even tried to run do_fips and then recompile after setting the arch flag in the Configure script] 2. Build openssl C:\openssl-1.0.1m>perl Configure VC-WIN32 no-rc5 no-idea no-ec2m [ --with-fipslibdir= ] --prefix=c:\somedir\openssl\dir -D_USING_V110_SDK71_ C:\openssl-1.0.1m>ms\do_nasm.bat ( added the /arch:SSE flag to CFLAG in the ntdll.mak ) C:\nmake -f ntdll.mak .... The resulting opensssl libraries do not run on the SSE architecture machines and throw "Not a valid Win32 application" Does anyone have any idea what is missing? I have compiled openssl with same set of commands and versions for SSE2 and those libraries work fine. Thanks Shobha -------------- next part -------------- An HTML attachment was scrubbed... URL: From talkwithsrinivas at yahoo.co.in Sun Jun 28 12:42:45 2015 From: talkwithsrinivas at yahoo.co.in (Srinivas) Date: Sun, 28 Jun 2015 12:42:45 +0000 (UTC) Subject: [openssl-users] Query on TLS1.2 and use of DES ciphers Message-ID: <1133351434.757014.1435495365321.JavaMail.yahoo@mail.yahoo.com> Hello all, I am using TLS1.2 version between the standard openssl s_server and client and cipher set to DES-CBC-SHA. The connections from the client to the server goes through sucessfully. Referring the TLS1.2 RFC @ https://www.ietf.org/rfc/rfc5246.txt, I see the below quote there. Removed IDEA and DES cipher suites. They are now deprecated and will be documented in a separate document.I am assuming that means all DES (including 3-DES) ciphers should be removed from TLS1.2. Also the above cipher is not in the list of https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites. My question is given the above, how are my s_server and s_client able to connect through using the above cipher and TLS1.2? Is it a bug in the implementation of the s_server and s_client? Thanks. ?truly, Srinivas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Jun 28 18:03:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 Jun 2015 18:03:18 +0000 Subject: [openssl-users] Query on TLS1.2 and use of DES ciphers In-Reply-To: <1133351434.757014.1435495365321.JavaMail.yahoo@mail.yahoo.com> References: <1133351434.757014.1435495365321.JavaMail.yahoo@mail.yahoo.com> Message-ID: <6f8989428d1347898dad645951209ca3@ustx2ex-dag1mb2.msg.corp.akamai.com> Deprecated means discouraged, not disallowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From talkwithsrinivas at yahoo.co.in Mon Jun 29 05:48:05 2015 From: talkwithsrinivas at yahoo.co.in (Srinivas) Date: Mon, 29 Jun 2015 05:48:05 +0000 (UTC) Subject: [openssl-users] Query on TLS1.2 and use of DES ciphers In-Reply-To: <6f8989428d1347898dad645951209ca3@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <1133351434.757014.1435495365321.JavaMail.yahoo@mail.yahoo.com> <6f8989428d1347898dad645951209ca3@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <80861641.964434.1435556885878.JavaMail.yahoo@mail.yahoo.com> Thanks. Makes sense. But then why are the DES ciphers not listed in the supported cipher list for TLSv1.2 here?https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites ?truly, Srinivas. On Sunday, 28 June 2015 11:33 PM, "Salz, Rich" wrote: #yiv7205281614 #yiv7205281614 -- _filtered #yiv7205281614 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7205281614 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;}#yiv7205281614 #yiv7205281614 p.yiv7205281614MsoNormal, #yiv7205281614 li.yiv7205281614MsoNormal, #yiv7205281614 div.yiv7205281614MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7205281614 a:link, #yiv7205281614 span.yiv7205281614MsoHyperlink {color:blue;text-decoration:underline;}#yiv7205281614 a:visited, #yiv7205281614 span.yiv7205281614MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv7205281614 code {}#yiv7205281614 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;}#yiv7205281614 span.yiv7205281614HTMLPreformattedChar {font-family:Consolas;}#yiv7205281614 span.yiv7205281614EmailStyle20 {color:#1F497D;}#yiv7205281614 .yiv7205281614MsoChpDefault {font-size:10.0pt;} _filtered #yiv7205281614 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7205281614 div.yiv7205281614WordSection1 {}#yiv7205281614 Deprecated means discouraged, not disallowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Jun 29 08:48:28 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 29 Jun 2015 10:48:28 +0200 Subject: [openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash In-Reply-To: <558DAAE8.9020200@mathemainzel.info> References: <558DAAE8.9020200@mathemainzel.info> Message-ID: <5591065C.3040305@wisemo.com> On 26/06/2015 21:41, Walter H. wrote: > Hello, > > has anybody got a reliable source or knowledge about which > mail clients - especially which Thunderbird release - should be > capable of verifying such mails correctly? > I believe GlobalSign has a knowledge base article listing this as far as they know. It is at < https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility> 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 kurt at roeckx.be Mon Jun 29 19:59:46 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 29 Jun 2015 21:59:46 +0200 Subject: [openssl-users] Query on TLS1.2 and use of DES ciphers In-Reply-To: <80861641.964434.1435556885878.JavaMail.yahoo@mail.yahoo.com> References: <1133351434.757014.1435495365321.JavaMail.yahoo@mail.yahoo.com> <6f8989428d1347898dad645951209ca3@ustx2ex-dag1mb2.msg.corp.akamai.com> <80861641.964434.1435556885878.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150629195946.GA10522@roeckx.be> On Mon, Jun 29, 2015 at 05:48:05AM +0000, Srinivas wrote: > Thanks. Makes sense. > > But then why are the DES ciphers not listed in the supported cipher list for TLSv1.2 here?https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites Those are all ciphers that require at least TLS 1.2. Kurt From dlipubkey at gmail.com Mon Jun 29 20:51:24 2015 From: dlipubkey at gmail.com (David Li) Date: Mon, 29 Jun 2015 13:51:24 -0700 Subject: [openssl-users] How to verify a cert chain using Openssl command line? Message-ID: Hi, As a test, I have created a rootCA, a subCA (signed by the rootCA) and a client cert (signed by the subCA). Now I want to use verify, s_client and s_server to test them together. However I searched and tried a number of times but still unsure about the correct syntax format in verify command. This is what I did: cat rootCA.crt subCA.crt > caChain.crt openssl -verbose -verify -CAflie caChain.crt clientCert.crt openssl verify -CAfile caChain.crt client/clientCert.crt client/clientCert.crt: C = US, ST = California, O = David's company, CN = David's client cert, emailAddress = david.li at example.com error 47 at 0 depth lookup:permitted subtree violation However it seems my s_client and s_server test is OK: I created a caChain by cancatenating rootCA and subCA together: Server: openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 where serverComb.crt = cat of serverCert and server key Client: openssl s_client -CAfile caChina.crt -cert client/clientComb.crt where clientComb is = cat of clientCert and clientKey Anyone has any idea why verify command failed? Thanks. From ben at an3k.de Mon Jun 29 21:12:18 2015 From: ben at an3k.de (Ben Humpert) Date: Mon, 29 Jun 2015 23:12:18 +0200 Subject: [openssl-users] How to verify a cert chain using Openssl command line? In-Reply-To: References: Message-ID: Do you use nameConstraints or have specified IP in subjectAltName? Because OpenSSL can't handle that correctly. 2015-06-29 22:51 GMT+02:00 David Li : > Hi, > > As a test, I have created a rootCA, a subCA (signed by the rootCA) and > a client cert (signed by the subCA). Now I want to use verify, > s_client and s_server to test them together. > > However I searched and tried a number of times but still unsure about > the correct syntax format in verify command. This is what I did: > > cat rootCA.crt subCA.crt > caChain.crt > > openssl -verbose -verify -CAflie caChain.crt clientCert.crt > > openssl verify -CAfile caChain.crt client/clientCert.crt > client/clientCert.crt: C = US, ST = California, O = David's company, > CN = David's client cert, emailAddress = david.li at example.com > error 47 at 0 depth lookup:permitted subtree violation > > > However it seems my s_client and s_server test is OK: > > I created a caChain by cancatenating rootCA and subCA together: > > Server: > openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 > > where serverComb.crt = cat of serverCert and server key > > Client: > openssl s_client -CAfile caChina.crt -cert client/clientComb.crt > > where clientComb is = cat of clientCert and clientKey > > > Anyone has any idea why verify command failed? > > Thanks. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dlipubkey at gmail.com Mon Jun 29 21:58:07 2015 From: dlipubkey at gmail.com (David Li) Date: Mon, 29 Jun 2015 14:58:07 -0700 Subject: [openssl-users] How to verify a cert chain using Openssl command line? In-Reply-To: References: Message-ID: The subCA has nameConstraints in the subCA configuration file: [name_constraints] permitted;DNS.0 = example.com client configuration file has subjectAltName: subjectAltName = DNS: www.cs.com So is this a mismatch? How come s_client/s_server test was okay? On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert wrote: > Do you use nameConstraints or have specified IP in subjectAltName? > Because OpenSSL can't handle that correctly. > > 2015-06-29 22:51 GMT+02:00 David Li : >> Hi, >> >> As a test, I have created a rootCA, a subCA (signed by the rootCA) and >> a client cert (signed by the subCA). Now I want to use verify, >> s_client and s_server to test them together. >> >> However I searched and tried a number of times but still unsure about >> the correct syntax format in verify command. This is what I did: >> >> cat rootCA.crt subCA.crt > caChain.crt >> >> openssl -verbose -verify -CAflie caChain.crt clientCert.crt >> >> openssl verify -CAfile caChain.crt client/clientCert.crt >> client/clientCert.crt: C = US, ST = California, O = David's company, >> CN = David's client cert, emailAddress = david.li at example.com >> error 47 at 0 depth lookup:permitted subtree violation >> >> >> However it seems my s_client and s_server test is OK: >> >> I created a caChain by cancatenating rootCA and subCA together: >> >> Server: >> openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 >> >> where serverComb.crt = cat of serverCert and server key >> >> Client: >> openssl s_client -CAfile caChina.crt -cert client/clientComb.crt >> >> where clientComb is = cat of clientCert and clientKey >> >> >> Anyone has any idea why verify command failed? >> >> Thanks. >> _______________________________________________ >> 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 ben at an3k.de Tue Jun 30 01:23:14 2015 From: ben at an3k.de (Ben Humpert) Date: Tue, 30 Jun 2015 03:23:14 +0200 Subject: [openssl-users] How to verify a cert chain using Openssl command line? In-Reply-To: References: Message-ID: Yes, because nameConstraints are inherited. I don't know exactly where the bug lies but I strongly advise NOT to use nameConstraints because while there is a standard nobody has implemented full or correctly working support for it. I ran various tests some weeks ago and the result was horrible. See https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html and https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html 2015-06-29 23:58 GMT+02:00 David Li : > The subCA has nameConstraints in the subCA configuration file: > > [name_constraints] > permitted;DNS.0 = example.com > > client configuration file has subjectAltName: > subjectAltName = DNS: www.cs.com > > So is this a mismatch? How come s_client/s_server test was okay? > > > > > > On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert wrote: >> Do you use nameConstraints or have specified IP in subjectAltName? >> Because OpenSSL can't handle that correctly. >> >> 2015-06-29 22:51 GMT+02:00 David Li : >>> Hi, >>> >>> As a test, I have created a rootCA, a subCA (signed by the rootCA) and >>> a client cert (signed by the subCA). Now I want to use verify, >>> s_client and s_server to test them together. >>> >>> However I searched and tried a number of times but still unsure about >>> the correct syntax format in verify command. This is what I did: >>> >>> cat rootCA.crt subCA.crt > caChain.crt >>> >>> openssl -verbose -verify -CAflie caChain.crt clientCert.crt >>> >>> openssl verify -CAfile caChain.crt client/clientCert.crt >>> client/clientCert.crt: C = US, ST = California, O = David's company, >>> CN = David's client cert, emailAddress = david.li at example.com >>> error 47 at 0 depth lookup:permitted subtree violation >>> >>> >>> However it seems my s_client and s_server test is OK: >>> >>> I created a caChain by cancatenating rootCA and subCA together: >>> >>> Server: >>> openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 >>> >>> where serverComb.crt = cat of serverCert and server key >>> >>> Client: >>> openssl s_client -CAfile caChina.crt -cert client/clientComb.crt >>> >>> where clientComb is = cat of clientCert and clientKey >>> >>> >>> Anyone has any idea why verify command failed? >>> >>> Thanks. >>> _______________________________________________ >>> 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 > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From k.bielke at web.de Tue Jun 30 07:56:20 2015 From: k.bielke at web.de (kwhb) Date: Tue, 30 Jun 2015 00:56:20 -0700 (MST) Subject: [openssl-users] cms sign/verify Message-ID: <1435650980985-58943.post@n7.nabble.com> I am using OpenSSL version 1.0.1f and got problems while signing and verifying a file using these commands: $ openssl cms -sign -inkey Mozart.pem -signer Mozart.crt -binary -in "$DOCUMENT" -out "$DOCUMENT.p7m" $ openssl cms -verify -CAfile CAcert.pem -binary -in "$DOCUMENT.p7m" -out "$DOCUMENT.out" $ cmp "$DOCUMENT" "$DOCUMENT.out" If I omit the -binary option from both calls to openssl cms then the verified document differs from the original document because of translations LF to CR/LF. If I include the -binary option the first call to openssl works fine but the second call throws errors: Verification failure 3073672892:error:2E09A09E:CMS routines:CMS_SignerInfo_verify_content:verification failure:cms_sd.c:887: 3073672892:error:2E09D06D:CMS routines:CMS_verify:content verify error:cms_smime.c:425: How do I use openssl cms -sign/verify correctly? -- View this message in context: http://openssl.6102.n7.nabble.com/cms-sign-verify-tp58943.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jonetsu at teksavvy.com Tue Jun 30 11:15:52 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 30 Jun 2015 04:15:52 -0700 (MST) Subject: [openssl-users] New FIPS 140-2 "SE" Validation Approved In-Reply-To: <558D45D4.6070908@openssl.com> References: <558D45D4.6070908@openssl.com> Message-ID: <1435662952675-58944.post@n7.nabble.com> The validation is on the ARM platform using Linux 2.4. I am one of those 'unlucky' having to deal with FIPS so please pardon any silly questions. Would this validation be limited to these two aspects ? And, is there any money-saving advantage at using an already validated OpenSSL when the whole unit (embedded device) qill be going for validation ? Eg. will it save lab time if they know that the OpenSSL used is already validated ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/New-FIPS-140-2-SE-Validation-Approved-tp58909p58944.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From marquess at openssl.com Tue Jun 30 12:20:31 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 30 Jun 2015 08:20:31 -0400 Subject: [openssl-users] New FIPS 140-2 "SE" Validation Approved In-Reply-To: <1435662952675-58944.post@n7.nabble.com> References: <558D45D4.6070908@openssl.com> <1435662952675-58944.post@n7.nabble.com> Message-ID: <5592898F.8050608@openssl.com> On 06/30/2015 07:15 AM, jonetsu wrote: > The validation is on the ARM platform using Linux 2.4. I am one of those > 'unlucky' having to deal with FIPS so please pardon any silly questions. > Would this validation be limited to these two aspects ? The validation is limited to the "platforms" ("Operational Environments") listed for that validation, unless you are able to leverage the "user affirmation" option per section G.5 of the Implementation Guidance document (one of the canons of FIPS 140-2 scripture). > And, is there any > money-saving advantage at using an already validated OpenSSL when the whole > unit (embedded device) qill be going for validation ? Eg. will it save lab > time if they know that the OpenSSL used is already validated ? I'm going to guess that you're trying to obtain a Level 2 validation for a product that contains the OpenSSL FIPS Object Module. Yes, the fact that the OpenSSL FIPS module already has a Level 1 validation can help. But, FIPS 140-2 is a tricky business so you should consult with your accredited FIPS 140-2 test lab for advice specific to your unique circumstances. -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 mike at flyn.org Tue Jun 30 13:55:06 2015 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 30 Jun 2015 09:55:06 -0400 Subject: [openssl-users] libtlssep Message-ID: <20150630135506.GA11732@imp.flyn.org> 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. Georgiev et al., Fahl et al., and other researchers have shown that application developers often misuse existing APIs [e.g., 1, 2]. This work informs aim (1). Aim (2) attempts to bring the privilege separation work of Provos et al. [3] to the domain of TLS in an easy-to-use way. The current implementation of libtlssep sits between an application and OpenSSL. Using libtlssep requires modifying an application to use the API, but we found the amount of work nominal while we ported wget and lighttpd. Of course, new applications could benefit from libtlssep right away. If you are interested in libtlssep, you can find more information at: https://www.flyn.org/publications/2015-libtlssep.pdf A paper in submission with SPACE 2015 that includes a description of libtlssep along with performance measurements and other details. 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. Thank you, Mike Petullo [1] Georgiev et al.: The most dangerous code in the world: validating SSL certificates in non-browser software. CCS (2012) [2] Fahl et al.: Why Eve and Mallory love Android: an analysis of Android SSL (in)security. CCS (2012) [3] Provos et al.: Preventing privilege escalation. USENIX Security (2003) :wq From jb-openssl at wisemo.com Tue Jun 30 15:48:08 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 Jun 2015 17:48:08 +0200 Subject: [openssl-users] How to provide KDF to ECDH key computation when using EVP API? In-Reply-To: <558F623F.60907@gmail.com> References: <55847A35.2050207@gmail.com> <558F623F.60907@gmail.com> Message-ID: <5592BA38.2070101@wisemo.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlipubkey at gmail.com Tue Jun 30 16:13:18 2015 From: dlipubkey at gmail.com (David Li) Date: Tue, 30 Jun 2015 09:13:18 -0700 Subject: [openssl-users] How to verify a cert chain using Openssl command line? In-Reply-To: References: Message-ID: Ben, I think you are right. My verify test is okay now if I match the subjectAltName to the nameConstraints defined by the subCA. Thanks. David On Mon, Jun 29, 2015 at 6:23 PM, Ben Humpert wrote: > Yes, because nameConstraints are inherited. > > I don't know exactly where the bug lies but I strongly advise NOT to > use nameConstraints because while there is a standard nobody has > implemented full or correctly working support for it. I ran various > tests some weeks ago and the result was horrible. See > https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html > and https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html > > 2015-06-29 23:58 GMT+02:00 David Li : >> The subCA has nameConstraints in the subCA configuration file: >> >> [name_constraints] >> permitted;DNS.0 = example.com >> >> client configuration file has subjectAltName: >> subjectAltName = DNS: www.cs.com >> >> So is this a mismatch? How come s_client/s_server test was okay? >> >> >> >> >> >> On Mon, Jun 29, 2015 at 2:12 PM, Ben Humpert wrote: >>> Do you use nameConstraints or have specified IP in subjectAltName? >>> Because OpenSSL can't handle that correctly. >>> >>> 2015-06-29 22:51 GMT+02:00 David Li : >>>> Hi, >>>> >>>> As a test, I have created a rootCA, a subCA (signed by the rootCA) and >>>> a client cert (signed by the subCA). Now I want to use verify, >>>> s_client and s_server to test them together. >>>> >>>> However I searched and tried a number of times but still unsure about >>>> the correct syntax format in verify command. This is what I did: >>>> >>>> cat rootCA.crt subCA.crt > caChain.crt >>>> >>>> openssl -verbose -verify -CAflie caChain.crt clientCert.crt >>>> >>>> openssl verify -CAfile caChain.crt client/clientCert.crt >>>> client/clientCert.crt: C = US, ST = California, O = David's company, >>>> CN = David's client cert, emailAddress = david.li at example.com >>>> error 47 at 0 depth lookup:permitted subtree violation >>>> >>>> >>>> However it seems my s_client and s_server test is OK: >>>> >>>> I created a caChain by cancatenating rootCA and subCA together: >>>> >>>> Server: >>>> openssl s_server -cert server/serverComb.crt -www -CAfile caChain.crt -verify 3 >>>> >>>> where serverComb.crt = cat of serverCert and server key >>>> >>>> Client: >>>> openssl s_client -CAfile caChina.crt -cert client/clientComb.crt >>>> >>>> where clientComb is = cat of clientCert and clientKey >>>> >>>> >>>> Anyone has any idea why verify command failed? >>>> >>>> Thanks. >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 ben at an3k.de Tue Jun 30 16:32:32 2015 From: ben at an3k.de (Ben Humpert) Date: Tue, 30 Jun 2015 18:32:32 +0200 Subject: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting In-Reply-To: <5589ED3D.9010702@wisemo.com> References: <5589ED3D.9010702@wisemo.com> Message-ID: 2015-06-24 1:35 GMT+02:00 Jakob Bohm : > On 19/06/2015 16:24, Ben Humpert wrote: >> >> When the CSR contains an email address and the email_in_dn setting in >> the config file is set to "no" the email address is actually present >> in the issuer DN but not in the subject DN. This causes errors when >> verifying certificate chains since the subject hash is used to >> identify a cert but the issuer hash is different. > > Are you sure, I have not seen this behavior in current > versions when making self-signed certificates, could > you provide step by step reproduction procedures to > cause this misbehavior? I have the openssl.cnf attached. ##### Step-By-Step below ##### cd /etc/ssl/ mv /etc/ssl/ca /etc/ssl/ca_orig mkdir -p /etc/ssl/ca/db /etc/ssl/ca/private /etc/ssl/ca/certs /etc/ssl/ca/crl /etc/ssl/ca/out /etc/ssl/ca/reqs chmod 700 /etc/ssl/ca/private cp /dev/null /etc/ssl/ca/db/RootCA.db cp /dev/null /etc/ssl/ca/db/RootCA.db.attr openssl rand -hex 16 > /etc/ssl/ca/db/RootCA.crt.srl echo 1001 > /etc/ssl/ca/db/RootCA.crl.srl cd /etc/ssl/ca/ openssl req -new -out /etc/ssl/ca/RootCA.csr openssl ca -selfsign -in /etc/ssl/ca/RootCA.csr -out /etc/ssl/ca/RootCA.crt -notext -startdate 150101000000Z -enddate 191231235959Z ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -hash -noout -in RootCA.crt`.0 openssl verify /etc/ssl/ca/RootCA.crt ln -s /etc/ssl/ca/RootCA.crt /etc/ssl/certs/`openssl x509 -issuer_hash -noout -in RootCA.crt`.0 openssl verify /etc/ssl/ca/RootCA.crt ##### Step-By-Step above ##### ##### Cleanup below ##### cd /etc/ssl/ rm -rf /etc/ssl/certs/`openssl x509 -hash -noout -in RootCA.crt`.0 rm -rf /etc/ssl/certs/`openssl x509 -issuer_hash -noout -in RootCA.crt`.0 rm -rf /etc/ssl/ca mv /etc/ssl/ca_orig /etc/ssl/ca ##### Cleanup above ##### You cannot verify this certificate. OpenSSL always returns >> error 20 at 0 depth lookup:unable to get local issuer certificate << To prevent this, uncomment or completely delete the emailAddress line in your certificate request. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl.cnf Type: application/octet-stream Size: 3136 bytes Desc: not available URL: From jb-openssl at wisemo.com Tue Jun 30 16:53:11 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 Jun 2015 18:53:11 +0200 Subject: [openssl-users] Bug 1.0.1f - selfsign ignores email_in_dn setting In-Reply-To: References: <5589ED3D.9010702@wisemo.com> Message-ID: <5592C977.6090505@wisemo.com> On 30/06/2015 18:32, Ben Humpert wrote: > 2015-06-24 1:35 GMT+02:00 Jakob Bohm : >> On 19/06/2015 16:24, Ben Humpert wrote: >>> When the CSR contains an email address and the email_in_dn setting in >>> the config file is set to "no" the email address is actually present >>> in the issuer DN but not in the subject DN. This causes errors when >>> verifying certificate chains since the subject hash is used to >>> identify a cert but the issuer hash is different. >> Are you sure, I have not seen this behavior in current >> versions when making self-signed certificates, could >> you provide step by step reproduction procedures to >> cause this misbehavior? > ... > > openssl req -new -out /etc/ssl/ca/RootCA.csr > openssl ca -selfsign -in /etc/ssl/ca/RootCA.csr -out > /etc/ssl/ca/RootCA.crt -notext -startdate 150101000000Z -enddate > 191231235959Z Ah, I didn't even know about that "ca -selfsign" option, I generally create my root certs using the req or x509 command directly. I wonder if the ca -selfsign variant takes its email_in_DN option from a different section than regular cert signing. Besides, putting an e-mail attribute in a CSR for a CA seems unusual. 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 jacques.p.florence at gmail.com Tue Jun 30 17:52:36 2015 From: jacques.p.florence at gmail.com (Jacques FLORENCE) Date: Tue, 30 Jun 2015 13:52:36 -0400 Subject: [openssl-users] Use an engine in only part of my application Message-ID: Hi, I have an application A that uses a shared library S that in turn uses the OpenSSL library. But A is also using another shared lib B that in turn uses OpenSSL as well. Is there a way to make such that S uses an OpenSSL engine, but B uses the default functionality? Thank you for your help, Jacques -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Tue Jun 30 19:58:57 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Tue, 30 Jun 2015 21:58:57 +0200 Subject: [openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash In-Reply-To: <5591065C.3040305@wisemo.com> References: <558DAAE8.9020200@mathemainzel.info> <5591065C.3040305@wisemo.com> Message-ID: <5592F501.2030103@mathemainzel.info> On 29.06.2015 10:48, Jakob Bohm wrote: > On 26/06/2015 21:41, Walter H. wrote: >> Hello, >> >> has anybody got a reliable source or knowledge about which >> mail clients - especially which Thunderbird release - should be >> capable of verifying such mails correctly? >> > I believe GlobalSign has a knowledge base article > listing this as far as they know. > > It is at > > < > https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility> > > > > Enjoy > > Thanks, the reason why I was asking; there it shows, that Mozilla Thunderbird above 10.x are capable of verifying such e-mails; I recently got such an e-mail and it could not be verified; Thunderbird has shown an error; the certificate used for signing that e-mail also used an sha256-hash, too; at work I had a client capable of sending sha-256 hash signed e-mails, but only a sha1 cert; and that mail could be verfied without problems; could someone please send me an email, where both the mail signature and also the certificate have a sha256 hash; Greetings, Walter -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- 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 Michael.Wojcik at microfocus.com Wed Jun 24 13:25:03 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 24 Jun 2015 13:25:03 -0000 Subject: [openssl-users] beginner needs advice on data signature/verification In-Reply-To: <558A45C1.6060406@wisemo.com> References: <558528C7.90403@watz.at> <55899D76.2060706@watz.at> <558A45C1.6060406@wisemo.com> Message-ID: 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 From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: Wednesday, June 24, 2015 01:53 To: openssl-users at openssl.org Subject: Re: [openssl-users] beginner needs advice on data signature/verification (Continuing top posting to keep thread consistent). First of all, if the client itself is compromised, the file content can be compromised just before you do whatever you do to assure the server that this was what the user of the client wanted. No way to fix that other than to keep the client free of compromise. Now the common solution used by driver and program signing programs such as Symbian signed (discontinued), Windows driver package signing for compatibility, Windows driver binary signing for Windows 10, and older versions of Windows Mobile 5.x/6.x signing is this: 1. Client has a unique X509 certificate with a private key known only to that client. Doesn't matter who issued the certificate, but the server needs to have its own known genuine copy of that certificate. That certificate should be such that no one except that client and that server trusts things for being signed by it. 2. Client signs the file/message with its private certificate exactly as if that would be the final signature (even though almost no one will trust it). 3. Client sends signed file/message to server. 4. Server verifies the signed file/message using its private list of trusted client certificates. 5. Server maps the verified signature to the identity to be used for the final signature. 6. Server talks to its closely related CA to get a brand new single-use-only certificate for the identity (with a serial number added as an extra subject name element). 7. Server removes the client signature and signs the file/message with the brand new certificate for the final identity. 8. Server throws away the private key, so that no more files can be signed with that certificate, ever. 9. If the server ever signs anything by mistake, it (or an admin if the server was permanently compromised) asks its closely related CA to revoke the affected single-use certificate. 10. If the client certificate needs to be revoked due to the certificate or its user being compromised on some current or past time/date, the related CA revokes all the single-use certificates for that identity since that date/time. Other/replacement client certificates for the same (visible) identity remain valid because single-use certificates for those requests were never revoked. 11. Note that in this setup, there is no need for a time stamping service, simply give the single-use certificate the long (listed) lifetime, and rely on the uncompromised server diligently deleting the private key within a few seconds after creating it. Of cause you don't need to make this entire "temporary certificate" dance (steps 6, and 8 to 11), for instance if the server will be using certificates issued by one of the pay-per-certificate public CAs, the server will instead need to keep around a certificate/private key pair for each public identity, and may need to use a public time stamping service just as if it was a normal direct end-signer. As for the format, putting S/MIME aka CMS aka PKCS#7 format signatures inside a file format, look at how Microsoft did this with its AuthentiCode concept and how Sun/Oracle did with its jar format. Its almost the same procedure with 5 minor differences: * AuthentiCode sets the PKCS#7 content-type to an AuthentiCode specific OID, jar file use the generic "data" OID. At least some members of OpenSSL team suggest that using any OID other than "data" is not allowed by more recent versions of the CMS standard. * AuthentiCode signs a custom DER encoded ASN.1 structure with the relevant attributes and secure hashes of the parts of the signed document that don't depend on the value/size of the signature blob itself. Jar signs a formatted text file with that same data. * (classic) AuthentiCode uses the original countersignature format and attribute for timestamping, requiring a timestamping service that creates "bare" signatures of the small blob sent for timestamping, jar files may or may not use a slightly different format allowing use of the newer RFC-based timestamping protocol. * Some implementations of jar signature validation (most notably the one used by Mozilla/Firefox/Thunderbird) requires the certificates to have the attributes of the historic "object signing" protocol, AuthentiCode and most other jar implementations simply require the relevant extended usage attribute in the end certificate. Commercial code/object signing certificates tend to include the extra attributes to work for both. * The two formats sometimes forget to check different obscure parts of the file being signed for some file formats. I won't elaborate on which ones. >From this list of differences and similarities, it should be somewhat easy to make sane choices for how to design your own use of X.509 certificates. Note that if the items being signed are documents rather than program-like objects, you should probably check for the e-mail signing or document-signing extended usage attribute, not the object-signing one. On 23/06/2015 19:55, Marco Warga wrote: Many thanks for the answer. I should have been more specific on the requirements right away. The "file" was really just an example to keep it simple. Reading my own writing, I would probably have suggested what you did :-) So here are the facts: - client/server are not connected to the internet - the network protocol is existing and proprietary - the file structure is existing and proprietary, but can be extended to allow for additional signature information to be embedded that will be sent to the server - the data actually transferred (and to be signed) is part of that file - the data has to be signed with an X.509 certificates public key that already exists S/MIME does pretty much do what I want to do. However the network protocol or the data to be signed cannot be changed for compatibility reasons. Under these circumstances, I don't really see how I could achieve my goal easier than by openssl directly. Considering the "very common requirement": I was thinking of i.e. windows driver signatures, android/ios app signatures and similar mechanisms to ensure that files are from a trusted source. Am 22.06.2015 um 14:44 schrieb Michael Wojcik: Response inline below, prefixed with "MW". (Unfortunately Outlook is incapable of replying to HTML messages properly, so you'll have to excuse the formatting.) From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Marco Warga Sent: Saturday, June 20, 2015 04:48 To: openssl-users at openssl.org Subject: [openssl-users] beginner needs advice on data signature/verification Hi, I hope some of you could give me advice on my project using openssl. MW: Why are you using OpenSSL for this application? You want to create a file on a trusted system, pass it through an untrusted intermediary, and process it on another trusted system. Why not simply use an existing mechanism like secure email? (GPG is the obvious choice, unless there are licensing issues.) If you are determined to create your own protocol from primitives, then really all you appear to need here is an HMAC. Don't involve the horrific mess that is X.509 PKI unless it actually provides some benefit. Lets say I have a server/service on a machine processing a file a corresponding client sends. That file is usually created by me on a clean third machine. The server side is assumed to be uncompromised (no hacker). The client side may be compromised. Now I need to make sure that the service only accepts those files that are created by me. I believe that is a very common requirement and has been done alot of times - I just can't find tutorials on how to implement it. Know any ? MW: No, but that's probably because what you've described isn't "a very common requirement". It's too vague. We don't know what problem you're actually trying to solve. It may be that you just need to send a file with a verifier, which - as I noted above - is commonly done, generally using something like GPG or (for roll-your-own protocols where both ends are controlled by the same party) an HMAC. Lets assume I have an x509 cert together with its private key signed by a ca owned by me. The trusted ca cert will be present on the server side. This is what I plan to do: 1.) Create the data files/blobs and sign them using the priv key of the cert. Distribute the cert and the signature along with (or inside) the data file. 2.) Have the client send that data file to the server (cert/sig first) 3.) Service receives the cert, builds a cert store with the local ca cert in it and verifies the client's cert with X509_verify_cert() 4.) if cert verifies ok, service compares the signature against the one calculated from the incoming data using the public key that came inside the cert just verified Would this be the right approach considering that anything the client sends may be forged (cert, sig, data...) ? MW: It's safe from malicious behavior by the client, under a threat model where an attacker is not able to forge client certificates or client signatures. In other words, it's safe as long as the private keys are neither leaked nor forced. Or would it be safer to have the cert used for signing stored on the server side and not send with the data (instead just its subject protected by the signature) ? MW: Irrelevant to the security of the scheme. Simpler from a development and operations standpoint. But using something like PGP/GPG or S/MIME would be simpler yet. There are any number of examples online for signing a file and verifying its signature. 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 Click here to report this email as spam. -------------- next part -------------- An HTML attachment was scrubbed... URL: