From Walter.H at mathemainzel.info Sun Nov 1 08:21:59 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 01 Nov 2015 09:21:59 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <56353F66.6050008@stroeder.com> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> <5634AD7C.2020200@stroeder.com> <56350451.1040107@mathemainzel.info> <56353F66.6050008@stroeder.com> Message-ID: <5635CBA7.5030001@mathemainzel.info> On 31.10.2015 23:23, Michael Str?der wrote: > Walter H. wrote: >> give me a hint for finding S/MIME certificates, finding my own would be nice; > You claim that clear-text OCSP requests are not a privacy issue. yes ..., a security problem I mentioned in connection with stupid CAs some posts before is the bigger problem ... > So you should > explain how you keep your *public*-key cert from being intercepted somewhere. depends on the CA; a CA that has a directory public browseable in ithe internet this is impossible, in other words, the CA itself is the problem in this case; > You can't. really? try to find my S/MIME public key certificate ... your "update" shows only SSL certificates; and as a said, SSL certificates are not a problem ... Greetings, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From matt at openssl.org Sun Nov 1 09:25:15 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 1 Nov 2015 09:25:15 +0000 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <5635CBA7.5030001@mathemainzel.info> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> <5634AD7C.2020200@stroeder.com> <56350451.1040107@mathemainzel.info> <56353F66.6050008@stroeder.com> <5635CBA7.5030001@mathemainzel.info> Message-ID: <5635DA7B.2020800@openssl.org> On 01/11/15 08:21, Walter H. wrote: > On 31.10.2015 23:23, Michael Str?der wrote: >> Walter H. wrote: >>> give me a hint for finding S/MIME certificates, finding my own would >>> be nice; >> You claim that clear-text OCSP requests are not a privacy issue. > yes ..., a security problem I mentioned in connection with stupid CAs > some posts before is the bigger problem ... >> So you should >> explain how you keep your *public*-key cert from being intercepted >> somewhere. > depends on the CA; a CA that has a directory public browseable in ithe > internet this is impossible, > in other words, the CA itself is the problem in this case; CT is the answer to a big problem. I fail to see that CAs deploying CT is a problem. I also don't see why only a CA can do this. There might be some adversaries that are perfectly capable of building large databases of certificates that they have "collected" from the internet. >> You can't. > really? try to find my S/MIME public key certificate ... > your "update" shows only SSL certificates; and as a said, SSL > certificates are not a problem ... Sorry, I must have missed that point? Why do you believe SSL certificates are not a problem? Unless you meant your example of a cert with a large number of alt names. But if so, I fail to see why the existence of some certificates where the amount of information an attacker could gain is smaller (but not nil) means that we should not deploy OCSP over https for *all* certificates? I also very much hope that CAs will deploy CT for S/MIME too. Matt From Walter.H at mathemainzel.info Sun Nov 1 12:07:57 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 01 Nov 2015 13:07:57 +0100 Subject: [openssl-users] Thoughts about security, privacy, ... In-Reply-To: <5635DA7B.2020800@openssl.org> References: <460881694.3536517.1445892145962.JavaMail.yahoo@mail.yahoo.com> <562FDCE2.6070309@mathemainzel.info> <5630ED61.2080106@wisemo.com> <5630F982.5050209@mathemainzel.info> <56310733.8080909@wisemo.com> <563136DE.2000103@mathemainzel.info> <5631EFFE.2050405@wisemo.com> <2df14a9cef1403650fc83588b959371d.1446125421@squirrel.mail> <5633D627.607@stroeder.com> <5633DFD8.1000102@mathemainzel.info> <5634AD7C.2020200@stroeder.com> <56350451.1040107@mathemainzel.info> <56353F66.6050008@stroeder.com> <5635CBA7.5030001@mathemainzel.info> <5635DA7B.2020800@openssl.org> Message-ID: <5636009D.4070908@mathemainzel.info> On 01.11.2015 10:25, Matt Caswell wrote: > CT is the answer to a big problem. I fail to see that CAs deploying CT > is a problem. I also don't see why only a CA can do this. There might be > some adversaries that are perfectly capable of building large databases > of certificates that they have "collected" from the internet. a computer tomograph as answer for a not really existing problem? and collecting SSL certificates is not a big thing; as long as the security problems aren't really solved, the privacy concerns don't exist; >>> You can't. >> really? try to find my S/MIME public key certificate ... >> your "update" shows only SSL certificates; and as a said, SSL >> certificates are not a problem ... > Sorry, I must have missed that point? Why do you believe SSL > certificates are not a problem? because this the request contains only contain the certificate serial number and not the certificate at all; what would you know, when sniffing a request of validating a certificate with serial 575775757 from CA x? in case you have a database, where you could lookup the serial in connection with the CA x, then you have some information that raise some little privacy concerns, but without ... having tracking pixels, strange scripts raise bigger problems: in security and privacy ... > But if so, I fail to see why the > existence of some certificates where the amount of information an > attacker could gain is smaller (but not nil) means that we should not > deploy OCSP over https for *all* certificates? of course, when deploying OCSP over TLS, this must be done for ALL certificates; but relaying on OCSP Stapling which itself is a security hole, is the wrong way; (I mentioned this problem earlier) when validating if it is save to connect to a host, the information must come from third party and not from the host itself (as OCSP Stapling is done) > I also very much hope that CAs will deploy CT for S/MIME too. only in hospitals ;-) always think of this: not the defect head light caused the accident, where the car slipped of the road ;-) in other words, always think of the real cause before; OCSP and CRL downloads are not the cause for privacy concerns, so there is no need of changing this; Greetings, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4312 bytes Desc: S/MIME Cryptographic Signature URL: From michael.heide at student.uni-siegen.de Sun Nov 1 14:09:32 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Sun, 1 Nov 2015 15:09:32 +0100 Subject: [openssl-users] PKCS7_verify() <- list of used/unused certificates? Message-ID: <20151101150932.0d9424a1@tbb-phenom> Hi, with PKCS7_verify() you can provide a list of certificates which OpenSSL can use to build and verify the chain. Either within the PKCS7 *p7 or with STACK_OF(X509) *certs. Is there some way to figure out which certificates in p7/certs are used (or not used) to verify the chain? Regards Michael From Michal.Trojnara at mirt.net Mon Nov 2 13:16:05 2015 From: Michal.Trojnara at mirt.net (Michal Trojnara) Date: Mon, 2 Nov 2015 14:16:05 +0100 Subject: [openssl-users] stunnel 5.25 released Message-ID: <56376215.80204@mirt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.25 of stunnel. The ChangeLog entry: Version 5.25, 2015.11.02, urgency: MEDIUM * New features - SMTP client protocol negotiation support for "protocolUsername", "protocolPassword", and "protocolAuthentication" (thx to Douglas Harris). - New service-level option "config" to specify OpenSSL >=1.0.2 configuration commands (thx to Stephen Wall). - The global option "foreground" now also accepts "quiet" parameter, which does not enable logging to stderr. - Manual page updated. - Obsolete OpenSSL engines removed from the Windows build: 4758cca, aep, atalla, cswift, nuron, sureware. - Improved compatibility with the current OpenSSL 1.1.0-dev tree: gracefully handle symbols renamed from SSLeay* to OpenSSL*. * Bugfixes - Fixed the "s_poll_wait returned 1, but no descriptor is ready" internal error. - Fixed "exec" hangs due to incorrect thread-local storage handling (thx to Philip Craig). - Fixed PRNG initialization (thx to Philip Craig). - Setting socket options no longer performed on PTYs. - Fixed 64-bit Windows build. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 1fb2209f1e006cc01813e1688599c4d0fb0adde4434c31ab95745b1db97484b7 stunnel-5.25.tar.gz 506846a28154e5111c6f374de5861c51221a5c9ddcf012952eaf7b4819176cd9 stunnel-5.25-installer.exe 58e79879a5fa922e2ae28ef0892f447d92d27517dfc0f921095b7180a7fd6905 stunnel-5.25-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWN2IVAAoJEC78f/DUFuAUhBoP/ifLB0Bl8yz13uGyy7mFghTN qwGLfLc5Nmu/flGOnynGWj6gXdRQT7WFaVkPCEoeNpttXEHzt+Q9psNAM4syOhBx KqiGJvq3atGfwGZwrIwUKZIXWT2jZldwL2vIctNe4i2oh6iWROcuTJqVa8eyLobw NJyuWCJqs60UK6IZN0ByrrO5Hc6Z7aTgJRkKmaWYY52ZeFrEUBY56yodfw8wvzAi JL/drDdJCyx4Q7ZQR14ZjhegAIqiEJ7GsbfosxBq3eApJKX/5L7zTP+BHL/jrFCu kiU/BhnjeYIuZ+R2j4tFWVhReMYjYIvjMAvPEo7GG1Z6xuVPpCQ90VW376cPbh8N 918Q/Gh/PF60covJmNYdW8Wn4L84vJrOM5uHkDCH2ZVFWWXUBGHZ0ZxBb1lB+kVC 69AzbK5hwHwEyfs/JjXjaIW3Tih9/Ig9t/+CD/131eWEqjGAxGtCGYgJMi0JgAt0 ei/kXeNuq39DxhTquGD1QOn98rVyrFsvvvV7aaMIECPri2MTHnZyMAF+N7txpcT2 UhD8Dlfnif6nF3JJ08/KWRh7x2tvmsFyZyqNV+uw3q3unUvZD6lcW7DCWAuXK4ap 5+fFJsxdvMUlqKZWrPrA2xrpObKAVdRdlLjDTl/oD3DuT9xfW3UQ6WKB76aLlnkL MdkEcOQuN+oCQNSlAv// =WhEM -----END PGP SIGNATURE----- From jb-openssl at wisemo.com Mon Nov 2 13:37:00 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 2 Nov 2015 14:37:00 +0100 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data Message-ID: <563766FC.8040201@wisemo.com> As with most other "apps" in the openssl binary, the s_server and s_client commands are useful for multiple purposes: 1. As debug tools 2. As a way to do one-off operations without writing any code. 3. As back ends for small programs written in scripting languages that cannot really call the OpenSSL library directly. This is about the latter two uses of s_server and s_client to set up a one-off or scripted secure pipe between two machines. Unfortunately, the current (1.0.2) version of s_server will do special and problematic things when encountering some 3-byte sequences (such as "\nq\n") in the data stream. It would thus be useful for s_server (and if applicable s_client) to accept the "-binary" option (already provided by the cms/smime commands), to turn off this behavior and provide a clean data pass through to/from the other end. In "-binary" mode, no byte value or sequence of byte value is special, except that explicit use of the "-crlf" option still works. 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 richmoore44 at gmail.com Mon Nov 2 15:13:15 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 2 Nov 2015 15:13:15 +0000 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data In-Reply-To: <563766FC.8040201@wisemo.com> References: <563766FC.8040201@wisemo.com> Message-ID: There have always been special commands making s_client unsuitable for this usage - for example R followed by a newline will renegotiate, and Q will quit. According to the docs these can be disabled by -quiet and -ign_eof though I've never tested that myself. Cheers Rich. On 2 November 2015 at 13:37, Jakob Bohm wrote: > As with most other "apps" in the openssl binary, the s_server > and s_client commands are useful for multiple purposes: > > 1. As debug tools > > 2. As a way to do one-off operations without writing any > code. > > 3. As back ends for small programs written in scripting > languages that cannot really call the OpenSSL library > directly. > > This is about the latter two uses of s_server and s_client to > set up a one-off or scripted secure pipe between two machines. > > Unfortunately, the current (1.0.2) version of s_server will > do special and problematic things when encountering some > 3-byte sequences (such as "\nq\n") in the data stream. > > It would thus be useful for s_server (and if applicable > s_client) to accept the "-binary" option (already provided > by the cms/smime commands), to turn off this behavior and > provide a clean data pass through to/from the other end. > In "-binary" mode, no byte value or sequence of byte value > is special, except that explicit use of the "-crlf" option > still works. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 2 15:33:03 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 2 Nov 2015 16:33:03 +0100 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data In-Reply-To: References: <563766FC.8040201@wisemo.com> Message-ID: <5637822F.4000704@wisemo.com> On 02/11/2015 16:13, Richard Moore wrote: > There have always been special commands making s_client unsuitable for > this usage - for example R followed by a newline will renegotiate, and > Q will quit. According to the docs these can be disabled by -quiet > and -ign_eof though I've never tested that myself. > Could you point me to where this (non-obvious) relationship between options ostensibly doing something else and the desired effect is documented? The 1.0.1* man-page of s_server certainly doesn't say that. > > On 2 November 2015 at 13:37, Jakob Bohm > wrote: > > As with most other "apps" in the openssl binary, the s_server > and s_client commands are useful for multiple purposes: > > 1. As debug tools > > 2. As a way to do one-off operations without writing any > code. > > 3. As back ends for small programs written in scripting > languages that cannot really call the OpenSSL library > directly. > > This is about the latter two uses of s_server and s_client to > set up a one-off or scripted secure pipe between two machines. > > Unfortunately, the current (1.0.2) version of s_server will > do special and problematic things when encountering some > 3-byte sequences (such as "\nq\n") in the data stream. > > It would thus be useful for s_server (and if applicable > s_client) to accept the "-binary" option (already provided > by the cms/smime commands), to turn off this behavior and > provide a clean data pass through to/from the other end. > In "-binary" mode, no byte value or sequence of byte value > is special, except that explicit use of the "-crlf" option > still works. > 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 richmoore44 at gmail.com Mon Nov 2 15:36:29 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 2 Nov 2015 15:36:29 +0000 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data In-Reply-To: <5637822F.4000704@wisemo.com> References: <563766FC.8040201@wisemo.com> <5637822F.4000704@wisemo.com> Message-ID: On 2 November 2015 at 15:33, Jakob Bohm wrote: > On 02/11/2015 16:13, Richard Moore wrote: > > There have always been special commands making s_client unsuitable for > this usage - for example R followed by a newline will renegotiate, and Q > will quit. According to the docs these can be disabled by -quiet > and -ign_eof though I've never tested that myself. > > Could you point me to where this (non-obvious) relationship > between options ostensibly doing something else and the > desired effect is documented? The 1.0.1* man-page of s_server > certainly doesn't say that. > > ?It's documented in the s_client man page, but I don't see it in s_server (though the commands are listed and it has a few more than s_client). Perhaps there is no way to disable them on s_server - I'd have to check the code. Cheers Rich.? > > On 2 November 2015 at 13:37, Jakob Bohm wrote: > >> As with most other "apps" in the openssl binary, the s_server >> and s_client commands are useful for multiple purposes: >> >> 1. As debug tools >> >> 2. As a way to do one-off operations without writing any >> code. >> >> 3. As back ends for small programs written in scripting >> languages that cannot really call the OpenSSL library >> directly. >> >> This is about the latter two uses of s_server and s_client to >> set up a one-off or scripted secure pipe between two machines. >> >> Unfortunately, the current (1.0.2) version of s_server will >> do special and problematic things when encountering some >> 3-byte sequences (such as "\nq\n") in the data stream. >> >> It would thus be useful for s_server (and if applicable >> s_client) to accept the "-binary" option (already provided >> by the cms/smime commands), to turn off this behavior and >> provide a clean data pass through to/from the other end. >> In "-binary" mode, no byte value or sequence of byte value >> is special, except that explicit use of the "-crlf" option >> still works. >> >> > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Mon Nov 2 15:42:56 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 2 Nov 2015 15:42:56 +0000 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data In-Reply-To: References: <563766FC.8040201@wisemo.com> <5637822F.4000704@wisemo.com> Message-ID: On 2 November 2015 at 15:36, Richard Moore wrote: > > > On 2 November 2015 at 15:33, Jakob Bohm wrote: > >> On 02/11/2015 16:13, Richard Moore wrote: >> >> There have always been special commands making s_client unsuitable for >> this usage - for example R followed by a newline will renegotiate, and Q >> will quit. According to the docs these can be disabled by -quiet >> and -ign_eof though I've never tested that myself. >> >> Could you point me to where this (non-obvious) relationship >> between options ostensibly doing something else and the >> desired effect is documented? The 1.0.1* man-page of s_server >> certainly doesn't say that. >> >> > ?It's documented in the s_client man page, but I don't see it in s_server > (though the commands are listed and it has a few more than s_client). > Perhaps there is no way to disable them on s_server - I'd have to check the > code. > > ?I've checked the code and -quiet disables them for s_server too. Rich. ? > Cheers > > Rich.? > > > >> >> On 2 November 2015 at 13:37, Jakob Bohm wrote: >> >>> As with most other "apps" in the openssl binary, the s_server >>> and s_client commands are useful for multiple purposes: >>> >>> 1. As debug tools >>> >>> 2. As a way to do one-off operations without writing any >>> code. >>> >>> 3. As back ends for small programs written in scripting >>> languages that cannot really call the OpenSSL library >>> directly. >>> >>> This is about the latter two uses of s_server and s_client to >>> set up a one-off or scripted secure pipe between two machines. >>> >>> Unfortunately, the current (1.0.2) version of s_server will >>> do special and problematic things when encountering some >>> 3-byte sequences (such as "\nq\n") in the data stream. >>> >>> It would thus be useful for s_server (and if applicable >>> s_client) to accept the "-binary" option (already provided >>> by the cms/smime commands), to turn off this behavior and >>> provide a clean data pass through to/from the other end. >>> In "-binary" mode, no byte value or sequence of byte value >>> is special, except that explicit use of the "-crlf" option >>> still works. >>> >>> >> >> Enjoy >> >> Jakob >> -- >> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com >> Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 >> This public discussion message is non-binding and may contain errors. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 2 19:08:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 2 Nov 2015 19:08:46 +0000 Subject: [openssl-users] s_server (and maybe s_client) misbehaves with binary data In-Reply-To: <563766FC.8040201@wisemo.com> References: <563766FC.8040201@wisemo.com> Message-ID: > It would thus be useful for s_server (and if applicable > s_client) to accept the "-binary" option (already provided by the cms/smime > commands), to turn off this behavior and provide a clean data pass through > to/from the other end. This is a good idea, thanks! From oflameo2 at gmail.com Tue Nov 3 13:46:55 2015 From: oflameo2 at gmail.com (John Lewis) Date: Tue, 03 Nov 2015 08:46:55 -0500 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names Message-ID: <5638BACF.5020103@gmail.com> I created a local certification authority using this tutorial https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian and made a certification request using this tutorial and I use this tutorial to learn how to make a request with a Subject Alternate Name. I actually did manage to get lucky just now and I hypothesize that running a command like this 'openssl ca -in ldap01.req -out certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as opposed to running a command like this 'openssl ca -in ldap01.req -out certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert with subject alternate names. How do I add '-extensions v3_req' to my ca configuration and have it be not be ignored? From Walter.H at mathemainzel.info Tue Nov 3 17:04:27 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Tue, 03 Nov 2015 18:04:27 +0100 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: <5638BACF.5020103@gmail.com> References: <5638BACF.5020103@gmail.com> Message-ID: <5638E91B.8000300@mathemainzel.info> On 03.11.2015 14:46, John Lewis wrote: > I created a local certification authority using this tutorial > https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian > and made a certification request using this tutorial and I use this > tutorial to learn how to make a request with a Subject Alternate Name. > > I actually did manage to get lucky just now and I hypothesize that > running a command like this 'openssl ca -in ldap01.req -out > certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as > opposed to running a command like this 'openssl ca -in ldap01.req -out > certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert > with subject alternate names. How do I add '-extensions v3_req' to my ca > configuration and have it be not be ignored? > add the following parameter(s): -extensions sslcertext -extfile file this file is similar to the following [ sslcertext ] basicConstraints = CA:false keyUsage = critical, digitalSignature, keyEncipherment subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always, issuer:always authorityInfoAccess = OCSP;URI:#OCSP-URL#/, caIssuers;URI:#DER-CACERT-URL# issuerAltName = issuer:copy subjectAltName = #SUBJECTALTNAME# extendedKeyUsage = serverAuth, msSGC, nsSGC certificatePolicies = ia5org, @policy_section crlDistributionPoints = URI:#CRL-URL# [ policy_section ] policyIdentifier = #POLICYID# CPS.1 = #CPS-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 oflameo2 at gmail.com Tue Nov 3 17:45:41 2015 From: oflameo2 at gmail.com (John Lewis) Date: Tue, 03 Nov 2015 12:45:41 -0500 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: <5638E91B.8000300@mathemainzel.info> References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> Message-ID: <5638F2C5.8080801@gmail.com> On 11/03/2015 12:04 PM, Walter H. wrote: > On 03.11.2015 14:46, John Lewis wrote: >> I created a local certification authority using this tutorial >> https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian >> >> and made a certification request using this tutorial and I use this >> tutorial to learn how to make a request with a Subject Alternate Name. >> >> I actually did manage to get lucky just now and I hypothesize that >> running a command like this 'openssl ca -in ldap01.req -out >> certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as >> opposed to running a command like this 'openssl ca -in ldap01.req -out >> certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert >> with subject alternate names. How do I add '-extensions v3_req' to my ca >> configuration and have it be not be ignored? >> > > add the following parameter(s): > > -extensions sslcertext -extfile file > this file is similar to the following > > [ sslcertext ] > basicConstraints = CA:false > keyUsage = critical, digitalSignature, keyEncipherment > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always, issuer:always > authorityInfoAccess = OCSP;URI:#OCSP-URL#/, > caIssuers;URI:#DER-CACERT-URL# > > issuerAltName = issuer:copy > subjectAltName = #SUBJECTALTNAME# > > extendedKeyUsage = serverAuth, msSGC, nsSGC > > certificatePolicies = ia5org, @policy_section > crlDistributionPoints = URI:#CRL-URL# > > [ policy_section ] > policyIdentifier = #POLICYID# > CPS.1 = #CPS-URL# > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Do I replace my current [v3_req] section with the contents of [sslcertext]? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan.rahn at gmail.com Tue Nov 3 20:09:07 2015 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Tue, 3 Nov 2015 12:09:07 -0800 Subject: [openssl-users] Need help understanding tradeoffs of "-dsaparam" in dhparam In-Reply-To: References: Message-ID: Hello, Pinging again to try and get a response. Thanks for your time, Ethan On Tue, Oct 27, 2015 at 3:35 PM, Ethan Rahn wrote: > Hello, > > I'm trying to understand the tradeoffs of using "-dsaparam" in the openssl > "dhparam" command. I know that it won't create a strong prime > , but I'm not understanding > the tradeoffs with that very well. The wikipedia page says that primes with > the strong property are not considered necessary by some cryptography > experts, but I don't know what the tradeoffs of using "-dsaparam" are. > Please note this is being used for a ( nginx-based ) SSL server if that > helps provide context. > > I know that it is much faster. For generating a 2048-bit diffie-hellman > parameter using "-dsaparam" takes ~10 seconds vs. ~30 minutes for the > strong prime defaults on the server I'm testing it on. > > The downside is not very clear to me however. I know the man pages say "DH > parameter generation with the -dsaparam option is much faster, and the > recommended exponent length is shorter, which makes DH key exchange more > efficient. Beware that with such DSA-style DH parameters, a fresh DH key > should be created for each use to avoid small-subgroup attacks that may be > possible otherwise." This isn't clear to me if each connection the SSL > server makes should use a different dsaparam based dhparam? Is there > another meaning here? > > Any clarifications on what I should beware of when using -dsaparam and > what a "new use" is when knowing when to make fresh dh keys would be very > appreciated. > > Thanks, > > Ethan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayadev.kumar at gmail.com Tue Nov 3 23:33:17 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Tue, 3 Nov 2015 15:33:17 -0800 Subject: [openssl-users] DH-RSA and DH-DSS certificate creation Message-ID: Hi, Can i create DH-RSA and DH-DSS certificate using openssl ? If yes, Which openssl version has the support for it ? Can i use DH-RSA and DH-DSS certificate with 'openssl s_server' application ? Right now i am using openssl-1.0.1m and it is not working for me. Thanks, Jayadev. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 4 00:29:35 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 4 Nov 2015 00:29:35 +0000 Subject: [openssl-users] DH-RSA and DH-DSS certificate creation In-Reply-To: References: Message-ID: <5639516F.6050808@openssl.org> On 03/11/15 23:33, Jayadev Kumar wrote: > Hi, > > Can i create DH-RSA and DH-DSS certificate using openssl ? Yes. > > If yes, Which openssl version has the support for it ? 1.0.2 > > Can i use DH-RSA and DH-DSS certificate with 'openssl s_server' > application ? Yes from version 1.0.2. You cannot create "self-signed" DH certificates because DH is not a signing algorithm. Therefore you *must* get a certificate from some kind of CA. Dependant on what you want to use it for the easiest way is to create your own CA (using an RSA key if you want DH-RSA, or a DSS key if you want DH-DSS). Once you have set up a CA you can create the DH certificate as described in this answer on stackexchange: http://security.stackexchange.com/a/82868 Matt From Walter.H at mathemainzel.info Wed Nov 4 04:31:44 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 04 Nov 2015 05:31:44 +0100 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: <5638F2C5.8080801@gmail.com> References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> <5638F2C5.8080801@gmail.com> Message-ID: <56398A30.2050507@mathemainzel.info> On 03.11.2015 18:45, John Lewis wrote: > On 11/03/2015 12:04 PM, Walter H. wrote: >> On 03.11.2015 14:46, John Lewis wrote: >>> I created a local certification authority using this tutorial >>> https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian >>> >>> and made a certification request using this tutorial and I use this >>> tutorial to learn how to make a request with a Subject Alternate Name. >>> >>> I actually did manage to get lucky just now and I hypothesize that >>> running a command like this 'openssl ca -in ldap01.req -out >>> certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as >>> opposed to running a command like this 'openssl ca -in ldap01.req -out >>> certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert >>> with subject alternate names. How do I add '-extensions v3_req' to >>> my ca >>> configuration and have it be not be ignored? >>> >> >> add the following parameter(s): >> >> -extensions sslcertext -extfile file >> this file is similar to the following >> >> [ sslcertext ] >> basicConstraints = CA:false >> keyUsage = critical, digitalSignature, keyEncipherment >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid:always, issuer:always >> authorityInfoAccess = OCSP;URI:#OCSP-URL#/, >> caIssuers;URI:#DER-CACERT-URL# >> >> issuerAltName = issuer:copy >> subjectAltName = #SUBJECTALTNAME# >> >> extendedKeyUsage = serverAuth, msSGC, nsSGC >> >> certificatePolicies = ia5org, @policy_section >> crlDistributionPoints = URI:#CRL-URL# >> >> [ policy_section ] >> policyIdentifier = #POLICYID# >> CPS.1 = #CPS-URL# >> > > Do I replace my current [v3_req] section with the contents of > [sslcertext] > No, you add this part, because v3_req is used for the certificate request ... and I have forgotten to mention, that #...# must be replaced with the right values; -------------- 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 ben at an3k.de Wed Nov 4 15:06:57 2015 From: ben at an3k.de (Ben Humpert) Date: Wed, 4 Nov 2015 16:06:57 +0100 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: <56398A30.2050507@mathemainzel.info> References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> <5638F2C5.8080801@gmail.com> <56398A30.2050507@mathemainzel.info> Message-ID: That guide is a little bit old and not very accurate. I setup my PKI using the OpenSSL Cookbook recommended to me by Rich Salz. This free guide / documentation is here: https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read Now" below the cover image). I also used various other sources to improve and adapt the configuration files and command lines. First of all the configuration files: openssl.cnf - https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing reqs/client_sample.cnf - https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing reqs/server_sample.cnf - https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing The first initialization of the CA database is done by the following commands: cd /etc/ssl/ mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out chmod 700 ./ca/private cp /dev/null ./ca/db/SampleCA.db cp /dev/null ./ca/db/SampleCA.db.attr openssl rand -hex 16 > ./ca/db/SampleCA.crt.srl echo 1001 > ./ca/db/SampleCA.crl.srl cd /etc/ssl/ca/ To get a self-signed cert/key for the CA itself: openssl req -new -out SampleCA.csr openssl ca -selfsign -in SampleCA.csr -out SampleCA.crt -extensions RootCA_x509_ext -notext -startdate 150101000000Z -enddate 191231235959Z To get a cert/key for a server: openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -keyout out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Server_x509_ext -policy Machine_policy -notext -startdate 150101000000Z -enddate 191231235959Z To get a ECC cert/key for a server: openssl ecparam -genkey -name secp256r1 | openssl ec -out out/XXX.key -aes128 openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -key out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Server_x509_ext -policy Machine_policy -notext -startdate 150101000000Z -enddate 191231235959Z There are two methods of creating certificates for clients. You can either issue for a human being or a machine. My PKI is not for a company but a flat sharing, thus I have plenty of different device owners, thus I issue certificates for human beings. That way every device gets its unique certificate with information about the device owner. The exact differences can be seen by comparing the "distinguished_name" section in server_sample.cnf and client_sample.cnf. If you want to issue for machines instead you have to modify the following commands a bit as well as the client_sample.cnf but you can use the information for servers above to get what you need :) To get a cert/key for a client: openssl req -new -config reqs/client_sample.cnf -out out/XXX.csr -keyout out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Client_x509_ext -policy User_policy -notext -startdate 150101000000Z -enddate 151231235959Z 2015-11-04 5:31 GMT+01:00 Walter H. : > On 03.11.2015 18:45, John Lewis wrote: > > On 11/03/2015 12:04 PM, Walter H. wrote: > > On 03.11.2015 14:46, John Lewis wrote: > > I created a local certification authority using this tutorial > https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian > and made a certification request using this tutorial and I use this > tutorial to learn how to make a request with a Subject Alternate Name. > > I actually did manage to get lucky just now and I hypothesize that > running a command like this 'openssl ca -in ldap01.req -out > certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as > opposed to running a command like this 'openssl ca -in ldap01.req -out > certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert > with subject alternate names. How do I add '-extensions v3_req' to my ca > configuration and have it be not be ignored? > > > add the following parameter(s): > > -extensions sslcertext -extfile file > this file is similar to the following > > [ sslcertext ] > basicConstraints = CA:false > keyUsage = critical, digitalSignature, keyEncipherment > subjectKeyIdentifier = hash > authorityKeyIdentifier = keyid:always, issuer:always > authorityInfoAccess = OCSP;URI:#OCSP-URL#/, caIssuers;URI:#DER-CACERT-URL# > > issuerAltName = issuer:copy > subjectAltName = #SUBJECTALTNAME# > > extendedKeyUsage = serverAuth, msSGC, nsSGC > > certificatePolicies = ia5org, @policy_section > crlDistributionPoints = URI:#CRL-URL# > > [ policy_section ] > policyIdentifier = #POLICYID# > CPS.1 = #CPS-URL# > > > Do I replace my current [v3_req] section with the contents of [sslcertext] > > No, you add this part, because v3_req is used for the certificate request > ... > > and I have forgotten to mention, that #...# must be replaced with the right > values; > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From ben at an3k.de Wed Nov 4 15:13:09 2015 From: ben at an3k.de (Ben Humpert) Date: Wed, 4 Nov 2015 16:13:09 +0100 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> <5638F2C5.8080801@gmail.com> <56398A30.2050507@mathemainzel.info> Message-ID: Oh crappy Gmail stop creating broken links ... openssl.cnf is at https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing reqs/client_sample.cnf is at https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing reqs/server_sample.cnf is at https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing 2015-11-04 16:06 GMT+01:00 Ben Humpert : > That guide is a little bit old and not very accurate. I setup my PKI > using the OpenSSL Cookbook recommended to me by Rich Salz. This free > guide / documentation is here: > https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read > Now" below the cover image). I also used various other sources to > improve and adapt the configuration files and command lines. > > First of all the configuration files: > openssl.cnf - https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing > reqs/client_sample.cnf - > https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing > reqs/server_sample.cnf - > https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing > > > The first initialization of the CA database is done by the following commands: > > cd /etc/ssl/ > mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out > chmod 700 ./ca/private > cp /dev/null ./ca/db/SampleCA.db > cp /dev/null ./ca/db/SampleCA.db.attr > openssl rand -hex 16 > ./ca/db/SampleCA.crt.srl > echo 1001 > ./ca/db/SampleCA.crl.srl > cd /etc/ssl/ca/ > > > To get a self-signed cert/key for the CA itself: > > openssl req -new -out SampleCA.csr > openssl ca -selfsign -in SampleCA.csr -out SampleCA.crt -extensions > RootCA_x509_ext -notext -startdate 150101000000Z -enddate > 191231235959Z > > > To get a cert/key for a server: > > openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr > -keyout out/XXX.key > openssl ca -in out/XXX.csr -out out/XXX.crt -extensions > Server_x509_ext -policy Machine_policy -notext -startdate > 150101000000Z -enddate 191231235959Z > > > To get a ECC cert/key for a server: > > openssl ecparam -genkey -name secp256r1 | openssl ec -out out/XXX.key -aes128 > openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -key > out/XXX.key > openssl ca -in out/XXX.csr -out out/XXX.crt -extensions > Server_x509_ext -policy Machine_policy -notext -startdate > 150101000000Z -enddate 191231235959Z > > > There are two methods of creating certificates for clients. You can > either issue for a human being or a machine. My PKI is not for a > company but a flat sharing, thus I have plenty of different device > owners, thus I issue certificates for human beings. That way every > device gets its unique certificate with information about the device > owner. The exact differences can be seen by comparing the > "distinguished_name" section in server_sample.cnf and > client_sample.cnf. > > If you want to issue for machines instead you have to modify the > following commands a bit as well as the client_sample.cnf but you can > use the information for servers above to get what you need :) > > To get a cert/key for a client: > > openssl req -new -config reqs/client_sample.cnf -out out/XXX.csr > -keyout out/XXX.key > openssl ca -in out/XXX.csr -out out/XXX.crt -extensions > Client_x509_ext -policy User_policy -notext -startdate 150101000000Z > -enddate 151231235959Z > > 2015-11-04 5:31 GMT+01:00 Walter H. : >> On 03.11.2015 18:45, John Lewis wrote: >> >> On 11/03/2015 12:04 PM, Walter H. wrote: >> >> On 03.11.2015 14:46, John Lewis wrote: >> >> I created a local certification authority using this tutorial >> https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian >> and made a certification request using this tutorial and I use this >> tutorial to learn how to make a request with a Subject Alternate Name. >> >> I actually did manage to get lucky just now and I hypothesize that >> running a command like this 'openssl ca -in ldap01.req -out >> certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as >> opposed to running a command like this 'openssl ca -in ldap01.req -out >> certs/new/ldap04.pem -config ./openssl.cnf' got my CA to create a cert >> with subject alternate names. How do I add '-extensions v3_req' to my ca >> configuration and have it be not be ignored? >> >> >> add the following parameter(s): >> >> -extensions sslcertext -extfile file >> this file is similar to the following >> >> [ sslcertext ] >> basicConstraints = CA:false >> keyUsage = critical, digitalSignature, keyEncipherment >> subjectKeyIdentifier = hash >> authorityKeyIdentifier = keyid:always, issuer:always >> authorityInfoAccess = OCSP;URI:#OCSP-URL#/, caIssuers;URI:#DER-CACERT-URL# >> >> issuerAltName = issuer:copy >> subjectAltName = #SUBJECTALTNAME# >> >> extendedKeyUsage = serverAuth, msSGC, nsSGC >> >> certificatePolicies = ia5org, @policy_section >> crlDistributionPoints = URI:#CRL-URL# >> >> [ policy_section ] >> policyIdentifier = #POLICYID# >> CPS.1 = #CPS-URL# >> >> >> Do I replace my current [v3_req] section with the contents of [sslcertext] >> >> No, you add this part, because v3_req is used for the certificate request >> ... >> >> and I have forgotten to mention, that #...# must be replaced with the right >> values; >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> -------------- next part -------------- That guide is a little bit old and not very accurate. I setup my PKI using the OpenSSL Cookbook recommended to me by Rich Salz. This free guide / documentation is here: https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read Now" below the cover image). I also used various other sources to improve and adapt the configuration files and command lines. First of all the configuration files: openssl.cnf - https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing reqs/client_sample.cnf - https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing reqs/server_sample.cnf - https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing The first initialization of the CA database is done by the following commands: cd /etc/ssl/ mkdir -p ./ca/db ./ca/private ./ca/certs ./ca/crl ./ca/out chmod 700 ./ca/private cp /dev/null ./ca/db/SampleCA.db cp /dev/null ./ca/db/SampleCA.db.attr openssl rand -hex 16 > ./ca/db/SampleCA.crt.srl echo 1001 > ./ca/db/SampleCA.crl.srl cd /etc/ssl/ca/ To get a self-signed cert/key for the CA itself: openssl req -new -out SampleCA.csr openssl ca -selfsign -in SampleCA.csr -out SampleCA.crt -extensions RootCA_x509_ext -notext -startdate 150101000000Z -enddate 191231235959Z To get a cert/key for a server: openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -keyout out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Server_x509_ext -policy Machine_policy -notext -startdate 150101000000Z -enddate 191231235959Z To get a ECC cert/key for a server: openssl ecparam -genkey -name secp256r1 | openssl ec -out out/XXX.key -aes128 openssl req -new -config reqs/server_sample.cnf -out out/XXX.csr -key out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Server_x509_ext -policy Machine_policy -notext -startdate 150101000000Z -enddate 191231235959Z There are two methods of creating certificates for clients. You can either issue for a human being or a machine. My PKI is not for a company but a flat sharing, thus I have plenty of different device owners, thus I issue certificates for human beings. That way every device gets its unique certificate with information about the device owner. The exact differences can be seen by comparing the "distinguished_name" section in server_sample.cnf and client_sample.cnf. If you want to issue for machines instead you have to modify the following commands a bit as well as the client_sample.cnf but you can use the information for servers above to get what you need :) To get a cert/key for a client: openssl req -new -config reqs/client_sample.cnf -out out/XXX.csr -keyout out/XXX.key openssl ca -in out/XXX.csr -out out/XXX.crt -extensions Client_x509_ext -policy User_policy -notext -startdate 150101000000Z -enddate 151231235959Z From Walter.H at mathemainzel.info Wed Nov 4 15:41:09 2015 From: Walter.H at mathemainzel.info (Walter H.) Date: Wed, 04 Nov 2015 16:41:09 +0100 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> <5638F2C5.8080801@gmail.com> <56398A30.2050507@mathemainzel.info> Message-ID: <563A2715.7080905@mathemainzel.info> On 04.11.2015 16:13, Ben Humpert wrote: > Oh crappy Gmail stop creating broken links ... > > openssl.cnf is at > https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing > > > reqs/client_sample.cnf is at > https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing > > > reqs/server_sample.cnf is at > https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing > > 2015-11-04 16:06 GMT+01:00 Ben Humpert: > you should have attached the files instead of giving links - not everybody has a google account ;-) -------------- 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 jayadev.kumar at gmail.com Wed Nov 4 16:08:51 2015 From: jayadev.kumar at gmail.com (Jayadev Kumar) Date: Wed, 4 Nov 2015 08:08:51 -0800 Subject: [openssl-users] DH-RSA and DH-DSS certificate creation In-Reply-To: <5639516F.6050808@openssl.org> References: <5639516F.6050808@openssl.org> Message-ID: Thanks Matt ! On Tue, Nov 3, 2015 at 4:29 PM, Matt Caswell wrote: > > > On 03/11/15 23:33, Jayadev Kumar wrote: > > Hi, > > > > Can i create DH-RSA and DH-DSS certificate using openssl ? > > Yes. > > > > > If yes, Which openssl version has the support for it ? > > 1.0.2 > > > > > Can i use DH-RSA and DH-DSS certificate with 'openssl s_server' > > application ? > > Yes from version 1.0.2. > > You cannot create "self-signed" DH certificates because DH is not a > signing algorithm. Therefore you *must* get a certificate from some kind > of CA. Dependant on what you want to use it for the easiest way is to > create your own CA (using an RSA key if you want DH-RSA, or a DSS key if > you want DH-DSS). > > Once you have set up a CA you can create the DH certificate as described > in this answer on stackexchange: > http://security.stackexchange.com/a/82868 > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reichert at numachi.com Wed Nov 4 18:36:45 2015 From: reichert at numachi.com (Brian Reichert) Date: Wed, 4 Nov 2015 13:36:45 -0500 Subject: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names In-Reply-To: References: <5638BACF.5020103@gmail.com> <5638E91B.8000300@mathemainzel.info> <5638F2C5.8080801@gmail.com> <56398A30.2050507@mathemainzel.info> Message-ID: <20151104183645.GG94050@numachi.com> On Wed, Nov 04, 2015 at 04:06:57PM +0100, Ben Humpert wrote: > That guide is a little bit old and not very accurate. I setup my PKI > using the OpenSSL Cookbook recommended to me by Rich Salz. This free > guide / documentation is here: > https://www.feistyduck.com/books/openssl-cookbook/ (Click "Free: Read > Now" below the cover image). I also used various other sources to > improve and adapt the configuration files and command lines. IIRC correctly, you need to affect your ca.cf file to honor ('copy') the extensions for a SAN. Something like the detail here: http://stackoverflow.com/questions/21488845/how-can-i-generate-a-self-signed-certificate-with-subjectaltname-using-openssl Second, modify the signing parameters. Find this line under the CA_default section: # Extension copying option: use with caution. # copy_extensions = copy And change it to: # Extension copying option: use with caution. copy_extensions = copy -- Brian Reichert BSD admin/developer at large From stopletz at gmail.com Wed Nov 4 23:53:27 2015 From: stopletz at gmail.com (Steve Topletz) Date: Wed, 4 Nov 2015 15:53:27 -0800 Subject: [openssl-users] Missing ciphers Message-ID: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> I find that I'm missing many ciphers when I interrogate my openssl service. Running v1.0.2d 'openssl s_server -cert my.cer -key my.key -accept 443 -cipher TLSv1.2' offers only about 1/3 of the ciphers listed in 'openssl ciphers -V TLSv1.2'. How do I get the rest of these ciphers enabled? ST From openssl-users at dukhovni.org Thu Nov 5 00:01:31 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 5 Nov 2015 00:01:31 +0000 Subject: [openssl-users] Missing ciphers In-Reply-To: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> References: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> Message-ID: <20151105000131.GW18315@mournblade.imrryr.org> On Wed, Nov 04, 2015 at 03:53:27PM -0800, Steve Topletz wrote: > I find that I'm missing many ciphers when I interrogate my openssl service. > > Running v1.0.2d 'openssl s_server -cert my.cer -key my.key -accept 443 > -cipher TLSv1.2' offers only about 1/3 of the ciphers listed in 'openssl > ciphers -V TLSv1.2'. > > How do I get the rest of these ciphers enabled? Only ciphers found in the "DEFAULT" cipherlist that are compatible with your server certificate algorithm will be enabled in your server. For example, if you only configured an RSA certificate, you won't be using ECDSA, DSA, kECDH, kDH, PSK or SRP ciphers. Nor eNULL or aNULL ciphers... So you should not expect to see many ciphers, and this is typically for the best. -- Viktor. From matt at openssl.org Thu Nov 5 00:04:05 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Nov 2015 00:04:05 +0000 Subject: [openssl-users] Missing ciphers In-Reply-To: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> References: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> Message-ID: <563A9CF5.90902@openssl.org> On 04/11/15 23:53, Steve Topletz wrote: > I find that I'm missing many ciphers when I interrogate my openssl service. > > Running v1.0.2d 'openssl s_server -cert my.cer -key my.key -accept 443 -cipher TLSv1.2' offers only about 1/3 of the ciphers listed in 'openssl ciphers -V TLSv1.2'. > > How do I get the rest of these ciphers enabled? The ciphers available are a combination of your cipher string (in this case "TLSv1.2") and the rest of your configuration. If you only supply an RSA cert then you won't get any ciphersuites that require DSS, ECDSA, DH or ECDH certificates. You can supply more than one certificate type if you wish (see -dcert and -dkey). Also if you don't set a pre shared key (-psk option) then you won't get any PSK ciphersuites. Matt From matt at openssl.org Thu Nov 5 00:06:53 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 5 Nov 2015 00:06:53 +0000 Subject: [openssl-users] Missing ciphers In-Reply-To: <20151105000131.GW18315@mournblade.imrryr.org> References: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> <20151105000131.GW18315@mournblade.imrryr.org> Message-ID: <563A9D9D.8060905@openssl.org> On 05/11/15 00:01, Viktor Dukhovni wrote: > On Wed, Nov 04, 2015 at 03:53:27PM -0800, Steve Topletz wrote: > >> I find that I'm missing many ciphers when I interrogate my openssl service. >> >> Running v1.0.2d 'openssl s_server -cert my.cer -key my.key -accept 443 >> -cipher TLSv1.2' offers only about 1/3 of the ciphers listed in 'openssl >> ciphers -V TLSv1.2'. >> >> How do I get the rest of these ciphers enabled? > > Only ciphers found in the "DEFAULT" cipherlist that are compatible > with your server certificate algorithm will be enabled in your > server. Note that in this case an explicit cipher string of TLSv1.2 has been set. This *includes* some ciphersuites that are not in DEFAULT, e.g. some eNULL based ciphersuites Matt From openssl-users at dukhovni.org Thu Nov 5 00:14:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 5 Nov 2015 00:14:36 +0000 Subject: [openssl-users] Missing ciphers In-Reply-To: <563A9D9D.8060905@openssl.org> References: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> <20151105000131.GW18315@mournblade.imrryr.org> <563A9D9D.8060905@openssl.org> Message-ID: <20151105001436.GX18315@mournblade.imrryr.org> On Thu, Nov 05, 2015 at 12:06:53AM +0000, Matt Caswell wrote: > > Only ciphers found in the "DEFAULT" cipherlist that are compatible > > with your server certificate algorithm will be enabled in your > > server. > > Note that in this case an explicit cipher string of TLSv1.2 has been > set. This *includes* some ciphersuites that are not in DEFAULT, e.g. > some eNULL based ciphersuites Thanks, I missed the fact that the server's "cipher" option was also set to "TLSv1.2". That's rather unwise. DO NOT use the CIPHER list to control PROTOCOL versions! DO NOT use the CIPHER list to control PROTOCOL versions! DO NOT use the CIPHER list to control PROTOCOL versions! Instead, use the protocol control options. For example: SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3); to disable SSLv2 and SSLv3 (disabling TLSv1 and higher is not generally a good idea for the public Internet, but in more controlled deployments, one might also disable TLSv1 and TLSv1.1). On the command-line: openssl s_server -no_ssl2 -no_ssl3 ... -- Viktor. From stopletz at gmail.com Thu Nov 5 00:25:43 2015 From: stopletz at gmail.com (Steve Topletz) Date: Wed, 4 Nov 2015 16:25:43 -0800 Subject: [openssl-users] Missing ciphers In-Reply-To: <20151105000131.GW18315@mournblade.imrryr.org> References: <168FE823-D8B5-4EE7-BC6F-9F56855E3E8A@gmail.com> <20151105000131.GW18315@mournblade.imrryr.org> Message-ID: <1F540A56-9890-4F38-93E8-FE11D2DC9DC1@gmail.com> This makes total sense, thanks! Ultimately I want to enable as many ciphers as possible as this machine is being used to test a new TLS forensic tool, so the server security isn't an issue to consider in configuration. ST > On Nov 4, 2015, at 4:01 PM, Viktor Dukhovni wrote: > >> On Wed, Nov 04, 2015 at 03:53:27PM -0800, Steve Topletz wrote: >> >> I find that I'm missing many ciphers when I interrogate my openssl service. >> >> Running v1.0.2d 'openssl s_server -cert my.cer -key my.key -accept 443 >> -cipher TLSv1.2' offers only about 1/3 of the ciphers listed in 'openssl >> ciphers -V TLSv1.2'. >> >> How do I get the rest of these ciphers enabled? > > Only ciphers found in the "DEFAULT" cipherlist that are compatible > with your server certificate algorithm will be enabled in your > server. > > For example, if you only configured an RSA certificate, you won't > be using ECDSA, DSA, kECDH, kDH, PSK or SRP ciphers. Nor eNULL or > aNULL ciphers... > > So you should not expect to see many ciphers, and this is typically > for the best. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michal.Trojnara at mirt.net Fri Nov 6 11:34:33 2015 From: Michal.Trojnara at mirt.net (Michal Trojnara) Date: Fri, 6 Nov 2015 12:34:33 +0100 Subject: [openssl-users] stunnel 5.26 released Message-ID: <563C9049.3040600@mirt.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.26 of stunnel. The ChangeLog entry: Version 5.26, 2015.11.06, urgency: MEDIUM * Bugfixes - Compilation fixes for OSX, *BSD and Solaris. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 2c90d469011eed8dc94f003013e3c055de6fdb687ef1e71fa004281d7f7c2726 stunnel-5.26.tar.gz 797e89783bbab29d5eedbd3193da2cb2461bcf47d314a9ee671b228e207e2b15 stunnel-5.26-installer.exe cd62a3ed4818677e7eeab36017accbae697a67cfd85f58eae82d2ad2db781664 stunnel-5.26-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWPJBJAAoJEC78f/DUFuAUSWUQAKglnyE5OkITYqd7deO768mv AC7DvDrP+mwmICbl/ZQhVzuUB4E9WYUnbyrOduIbCoN3FrDr1hROcO6Tuf63DFXa 5Qal5tFFEgVm5LKi7MxPn022d5e8Q04RADtJ7DNzSrJNltyivHG3h6jAVlXcmlui BkFORjWbZAZ2AUvKBbUYYdjfR2rnpqlrUNIcZwMz0hR5e4JT5Yw5WHa3NfAcXknh XZ27+BoKg6jDyEx+mk2aXYFpeCvWPx5vaKmtAqbIkEaNKhmolpYxf02JespwmvpJ Y/rD0kko+r8zSwMQRZ8FSNncVbQ1Zir3rZM6IE78TkNeGnJKiq29H3dzrUuZP4uW Hv5qjAW7IaVMFUMUOsM/eyKTyh7ibgXLIshb7byn9zm5BHmlY4PgVUyeAXVVbYfK qgfMq43VjgXcyvFw4osQx5xYnA0P3edxFyx1v+GMeHssxh2CLv5MwrcmTcnf5SSm t2COdxi+4gA0mJwsSrdw8d7fuTLg/zhzWKSwB9XZqZ+xM+nTNVI3hzoQJ+Fhe/KP kfJ6qPrSHMj2WX740DDY/tGDTdxKnOEgJb0sJepEJyprIm8LFMSrBBt5fAdqgrPy a9znXn7RG+C71oxoaP/Q77fdAUQ9147SfGOO18ooYDzev5w5nHRg0kaPRrMDHxUg CyNsej8I/7CSXCH4PtjL =KQPP -----END PGP SIGNATURE----- From nounou.dadoun at avigilon.com Fri Nov 6 20:59:58 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Fri, 6 Nov 2015 20:59:58 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? Message-ID: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> Quick question, modifying context options on an openssl server (disabling SSLv2 and SSLv3, enabling TLSv1 (for compatibility for now), TLSv1.1 and TLSv1.2) and I had a question about which version is chosen in practice in a TLS connection. I've read that in general the client proposes the highest version it supports and the server chooses a compatible version or rejects if there isn't one. Rfc5246 basically says that the server will choose the highest version but I wanted to confirm that that's what openssl does (just to be certain). e.g. if the client proposes TLSv1.2 and the server supports TLSv1.2, will the server *ever* select TLSv1.1? thanks . N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn From openssl-users at dukhovni.org Fri Nov 6 21:32:27 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 6 Nov 2015 21:32:27 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20151106213227.GB18315@mournblade.imrryr.org> On Fri, Nov 06, 2015 at 08:59:58PM +0000, Nounou Dadoun wrote: > Quick question, modifying context options on an openssl server (disabling > SSLv2 and SSLv3, enabling TLSv1 (for compatibility for now), TLSv1.1 and > TLSv1.2) and I had a question about which version is chosen in practice > in a TLS connection. On the server side, if at all possible, the selected protocol will be the highest one not disabled. On the client side, it is more complicated, because the client can't propose a discrete list of protocols, rather it proposes a minimum and a maximum. Therefore, with SSLv23_client_method() aka TLS_client_method() when you disable some set of protocols via: SSL_CTX_set_options(ctx, SSL_OP_NO_<...>) lowest protocol that you *don't* disable becomes the minimum, and then the maximum is either one less than the first higher version that is disabled or else the maximum version supported. Thus, for example, with; SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_TLSv1_1); The minimum is then SSL 3.0 and the maximum is TLS 1.0, thus this has the side-effect of disabling TLS 1.2 (and in the future also TLS 1.3). > I've read that in general the client proposes the highest version it > supports and the server chooses a compatible version or rejects if there > isn't one. The client proposes a range from lowest to highest. > Rfc5246 basically says that the server will choose the highest > version but I wanted to confirm that that's what openssl does (just to be > certain). OpenSSL may be unable to choose the highest version if none of the enabled ciphersuites are compatible with that version. That should be rare, so in practice the server will choose the highest version proposed by the client and supported by the server. > e.g. if the client proposes TLSv1.2 and the server supports TLSv1.2, will > the server *ever* select TLSv1.1? thanks. It could, if none of the shared ciphersuites were compatible with TLS 1.2. However, TLS 1.2 essentially supports a superset of the ciphersuites of TLS 1.0 and TLS 1.1 so this condition is unlikely. The exception is EXPORT ciphersuites which were removed from TLS 1.2, but until quite recently was still willing to negotiate them even with TLS 1.2. So if a client offers some EXPORT ciphers and the server is configured to use only EXPORT ciphers, I'm not sure whether these versions of OpenSSL will abort the handshake, or will choose a lower protocol version. -- Viktor. From nounou.dadoun at avigilon.com Fri Nov 6 21:37:01 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Fri, 6 Nov 2015 21:37:01 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <20151106213227.GB18315@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DEFAC9@mbx027-w1-ca-4.exch027.domain.local> Thanks for the detailed explanation, that's very useful ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Friday, November 06, 2015 1:32 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Does openssl server always choose highest TLS version offered? On Fri, Nov 06, 2015 at 08:59:58PM +0000, Nounou Dadoun wrote: > Quick question, modifying context options on an openssl server > (disabling > SSLv2 and SSLv3, enabling TLSv1 (for compatibility for now), TLSv1.1 > and > TLSv1.2) and I had a question about which version is chosen in > practice in a TLS connection. On the server side, if at all possible, the selected protocol will be the highest one not disabled. On the client side, it is more complicated, because the client can't propose a discrete list of protocols, rather it proposes a minimum and a maximum. Therefore, with SSLv23_client_method() aka TLS_client_method() when you disable some set of protocols via: SSL_CTX_set_options(ctx, SSL_OP_NO_<...>) lowest protocol that you *don't* disable becomes the minimum, and then the maximum is either one less than the first higher version that is disabled or else the maximum version supported. Thus, for example, with; SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_TLSv1_1); The minimum is then SSL 3.0 and the maximum is TLS 1.0, thus this has the side-effect of disabling TLS 1.2 (and in the future also TLS 1.3). > I've read that in general the client proposes the highest version it > supports and the server chooses a compatible version or rejects if > there isn't one. The client proposes a range from lowest to highest. > Rfc5246 basically says that the server will choose the highest version > but I wanted to confirm that that's what openssl does (just to be > certain). OpenSSL may be unable to choose the highest version if none of the enabled ciphersuites are compatible with that version. That should be rare, so in practice the server will choose the highest version proposed by the client and supported by the server. > e.g. if the client proposes TLSv1.2 and the server supports TLSv1.2, > will the server *ever* select TLSv1.1? thanks. It could, if none of the shared ciphersuites were compatible with TLS 1.2. However, TLS 1.2 essentially supports a superset of the ciphersuites of TLS 1.0 and TLS 1.1 so this condition is unlikely. The exception is EXPORT ciphersuites which were removed from TLS 1.2, but until quite recently was still willing to negotiate them even with TLS 1.2. So if a client offers some EXPORT ciphers and the server is configured to use only EXPORT ciphers, I'm not sure whether these versions of OpenSSL will abort the handshake, or will choose a lower protocol version. -- Viktor. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Fri Nov 6 23:58:44 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 6 Nov 2015 23:58:44 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <20151106213227.GB18315@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> Message-ID: <563D3EB4.6020905@openssl.org> On 06/11/15 21:32, Viktor Dukhovni wrote: > On Fri, Nov 06, 2015 at 08:59:58PM +0000, Nounou Dadoun wrote: > >> Quick question, modifying context options on an openssl server (disabling >> SSLv2 and SSLv3, enabling TLSv1 (for compatibility for now), TLSv1.1 and >> TLSv1.2) and I had a question about which version is chosen in practice >> in a TLS connection. > > On the server side, if at all possible, the selected protocol will > be the highest one not disabled. On the server side the selected protocol will *always* be the highest one not disabled. >> I've read that in general the client proposes the highest version it >> supports and the server chooses a compatible version or rejects if there >> isn't one. > > The client proposes a range from lowest to highest. OpenSSL only considers the version provided by the client in the ClientHello itself. The server will select the highest protocol version that it supports and is not disabled. The selected version could be lower than the one set by the client in the record layer, i.e. from OpenSSL's point of view the client provides an upper bound only not a range. Consider this (OpenSSL version 1.0.2 config'd with enable-ssl-trace): $ openssl s_server -no_tls1_2 -trace Using default temp DH parameters ACCEPT Received Record Header: Version = TLS 1.2 (0x303) Content Type = Handshake (22) Length = 312 ClientHello, Length=308 client_version=0x303 (TLS 1.2) Sent Record Header: Version = TLS 1.1 (0x302) Content Type = Handshake (22) Length = 66 ServerHello, Length=62 server_version=0x302 (TLS 1.1) In the above I used a hacked OpenSSL client to advertise TLSv1.2 in the ClientHello *and* to use TLSv1.2 in the record layer. OpenSSL server has had TLSv1.2 disabled so it selected TLSv1.1. >> Rfc5246 basically says that the server will choose the highest >> version but I wanted to confirm that that's what openssl does (just to be >> certain). > > OpenSSL may be unable to choose the highest version if none of the > enabled ciphersuites are compatible with that version. That should > be rare, so in practice the server will choose the highest version > proposed by the client and supported by the server. OpenSSL selects the version it is going to use regardless of the available ciphersuites. Only after selecting its version will the server select the ciphersuite to use. If there aren't any compatible with the selected version then it will fail with a "no shared cipher" error. For example consider the following: $ openssl version OpenSSL 1.0.2e-dev xx XXX xxxx $ openssl s_server -cipher DES-CBC-MD5 $ openssl s_client -cipher DES-CBC-MD5 The above fails with a "no shared cipher" error even though both client and server do have a shared cipher. The reason is that both client and server support TLSv1.2 so that is the version that is selected. Only then does the server try to select a ciphersuite. At that point it will disregard DES-CBC-MD5 because that is an SSLv2 ciphersuite that is incompatible with TLSv1.2. It now has no ciphersuites left to use and fails. In practice this doesn't ever happen. > >> e.g. if the client proposes TLSv1.2 and the server supports TLSv1.2, will >> the server *ever* select TLSv1.1? thanks. > > It could, if none of the shared ciphersuites were compatible with > TLS 1.2. However, TLS 1.2 essentially supports a superset of the > ciphersuites of TLS 1.0 and TLS 1.1 so this condition is unlikely. No. It will always select TLSv1.2. However, with the exception of the SSLv2 ciphersuites, *all* ciphersuites are upwardly compatible. > > The exception is EXPORT ciphersuites which were removed from TLS > 1.2, but until quite recently was still willing to negotiate them > even with TLS 1.2. So if a client offers some EXPORT ciphers and > the server is configured to use only EXPORT ciphers, I'm not sure > whether these versions of OpenSSL will abort the handshake, or will > choose a lower protocol version. > All released versions of OpenSSL will still negotiate EXPORT ciphersuites in TLSv1.2 if it has been configured to enable those ciphersuites. All recent versions of OpenSSL have no EXPORT ciphersuites in the DEFAULT cipher string so you would have to explicitly enable them for this to occur. This is quite a recent change though. Matt From openssl-users at dukhovni.org Sat Nov 7 02:54:17 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 7 Nov 2015 02:54:17 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <563D3EB4.6020905@openssl.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> Message-ID: <20151107025417.GE18315@mournblade.imrryr.org> On Fri, Nov 06, 2015 at 11:58:44PM +0000, Matt Caswell wrote: > > On the server side, if at all possible, the selected protocol will > > be the highest one not disabled. > > On the server side the selected protocol will *always* be the highest > one not disabled. True, at present. And yet this may not be the correct long-term strategy. There may be future situations in which selecting the highest protocol is not the right approach, and the right choice might be to select the highest protocol that does not fail. There was some discussion of this on the TLS WG list a moth or two back. So I did not feel that we can guarantee the present behaviour in perpetuity. > > The client proposes a range from lowest to highest. This is a correct description of the client-sider behaviour. IIRC uses the lowest supported version at the record layer, and proposes the highest in the HELLO message. In any case, the range of versions of versions accepted by the client is always contiguous, and the highest offerred will not be the highest supported when there are "holes" created by disabling versions in the middle of the range supported by the library. > OpenSSL only considers the version provided by the client in the > ClientHello itself. That's server behaviour. The server will indeed only look at the version in the client HELLO, and choose at most that, and if the choice is too low, the client will object. https://tools.ietf.org/html/rfc5246#appendix-E Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. I don't recall what version OpenSSL clients use for initial handshakes at the record layer, it is either 3.0 (fixed) or lowested supported (the minimum I alluded to). > In the above I used a hacked OpenSSL client to advertise TLSv1.2 in the > ClientHello *and* to use TLSv1.2 in the record layer. OpenSSL server has > had TLSv1.2 disabled so it selected TLSv1.1. Right the server ignores the record layer version, which is what RFC 5246 recommends, though IIRC "unhacked" OpenSSL does send the minimum at the record layer. > OpenSSL selects the version it is going to use regardless of the > available ciphersuites. Only after selecting its version will the server > select the ciphersuite to use. If there aren't any compatible with the > selected version then it will fail with a "no shared cipher" error. Will we always do that. I am not confident we can promise this, but this is not at present about to change. -- Viktor. From matt at openssl.org Sat Nov 7 23:04:49 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 7 Nov 2015 23:04:49 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <20151107025417.GE18315@mournblade.imrryr.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> <20151107025417.GE18315@mournblade.imrryr.org> Message-ID: <563E8391.9020807@openssl.org> On 07/11/15 02:54, Viktor Dukhovni wrote: > On Fri, Nov 06, 2015 at 11:58:44PM +0000, Matt Caswell wrote: > >>> On the server side, if at all possible, the selected protocol will >>> be the highest one not disabled. >> >> On the server side the selected protocol will *always* be the highest >> one not disabled. > > True, at present. And yet this may not be the correct long-term > strategy. There may be future situations in which selecting the > highest protocol is not the right approach, and the right choice > might be to select the highest protocol that does not fail. There > was some discussion of this on the TLS WG list a moth or two back. > > So I did not feel that we can guarantee the present behaviour in > perpetuity. Agreed. I described current behaviour. Anything could change in the future. > >>> The client proposes a range from lowest to highest. > > This is a correct description of the client-sider behaviour. IIRC > uses the lowest supported version at the record layer, and proposes > the highest in the HELLO message. In any case, the range of versions > of versions accepted by the client is always contiguous, and the > highest offerred will not be the highest supported when there are > "holes" created by disabling versions in the middle of the range > supported by the library. There are 3 scenarios for the record layer version used by an OpenSSL client in the initial ClientHello (at least this is the case for 1.0.2 and I believe it is also the case for 1.0.1 and 1.0.0. 0.9.8 is slightly different): - the lowest supported non-disabled version is SSL2 and there are SSL2 ciphers offered by the client, in which case an SSL2 compat ClientHello is used and there is no record layer version. - there are no SSL2 ciphers offered, SSLv3 is enabled and TLSv1.0 is disabled in which case SSLv3.0 is used as the record layer version. - in all other cases TLSv1.0 is used as the record layer version regardless of which protocols are disabled. Note that the last scenario means that TLS1.0 can be used as the initial ClientHello record version even if TLS1.0 has been disabled. You are correct about the contiguous range and "holes". > >> OpenSSL only considers the version provided by the client in the >> ClientHello itself. > > That's server behaviour. The server will indeed only look at the > version in the client HELLO, and choose at most that, and if the > choice is too low, the client will object. > > https://tools.ietf.org/html/rfc5246#appendix-E > > Earlier versions of the TLS specification were not fully clear on > what the record layer version number (TLSPlaintext.version) should > contain when sending ClientHello (i.e., before it is known which > version of the protocol will be employed). Thus, TLS servers > compliant with this specification MUST accept any value {03,XX} as > the record layer version number for ClientHello. > > TLS clients that wish to negotiate with older servers MAY send any > value {03,XX} as the record layer version number. Typical values > would be {03,00}, the lowest version number supported by the client, > and the value of ClientHello.client_version. No single value will > guarantee interoperability with all old servers, but this is a > complex topic beyond the scope of this document. > > I don't recall what version OpenSSL clients use for initial handshakes > at the record layer, it is either 3.0 (fixed) or lowested supported > (the minimum I alluded to). > >> In the above I used a hacked OpenSSL client to advertise TLSv1.2 in the >> ClientHello *and* to use TLSv1.2 in the record layer. OpenSSL server has >> had TLSv1.2 disabled so it selected TLSv1.1. > > Right the server ignores the record layer version, which is what > RFC 5246 recommends, though IIRC "unhacked" OpenSSL does send the > minimum at the record layer. > >> OpenSSL selects the version it is going to use regardless of the >> available ciphersuites. Only after selecting its version will the server >> select the ciphersuite to use. If there aren't any compatible with the >> selected version then it will fail with a "no shared cipher" error. > > Will we always do that. I am not confident we can promise this, > but this is not at present about to change. > I think it is very unlikely to change for the currently available released versions - and it is the behaviour of those versions that I am describing. It could possibly change for future versions (as could anything) - although I'm not aware of any plans to do so. Matt From openssl-users at dukhovni.org Sat Nov 7 23:25:17 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 7 Nov 2015 23:25:17 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <563E8391.9020807@openssl.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> <20151107025417.GE18315@mournblade.imrryr.org> <563E8391.9020807@openssl.org> Message-ID: <20151107232516.GM18315@mournblade.imrryr.org> On Sat, Nov 07, 2015 at 11:04:49PM +0000, Matt Caswell wrote: > There are 3 scenarios for the record layer version used by an OpenSSL > client in the initial ClientHello (at least this is the case for 1.0.2 > and I believe it is also the case for 1.0.1 and 1.0.0. 0.9.8 is slightly > different): > > - the lowest supported non-disabled version is SSL2 and there are SSL2 > ciphers offered by the client, in which case an SSL2 compat ClientHello > is used and there is no record layer version. > - there are no SSL2 ciphers offered, SSLv3 is enabled and TLSv1.0 is > disabled in which case SSLv3.0 is used as the record layer version. > - in all other cases TLSv1.0 is used as the record layer version > regardless of which protocols are disabled. > > Note that the last scenario means that TLS1.0 can be used as the initial > ClientHello record version even if TLS1.0 has been disabled. > > You are correct about the contiguous range and "holes". Thanks for the clarification. My understanding was based on exploring the semantics of "holes" in the range of supported protocols. It seems I jumped to the conclusion that the client always uses the low end of its supported versions at the record layer, based only on observations with SSL 2.0, SSL 3.0 and TLS 1.0 where this happens to agree with the more complete picture. A three-way choice between SSL 2.0, SSL 3.0 or TLS 1.0 for the initial record layer version makes sense. -- Viktor. From joshi.sanjaya at gmail.com Mon Nov 9 06:44:57 2015 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Mon, 9 Nov 2015 12:14:57 +0530 Subject: [openssl-users] Reg. SHA512WithRSAEncryption support in TLSv1.0 Message-ID: Hello, I use a server certificate that is signed by the CA with SHA512WithRSAEncryption as the signature-algorithm. During the TLS communication, my client is not able to verify the server certificate, and in the wireshark trace, i can see the error "Decrypt Error". Does it mean that my client does not support SHA512 ? I use TLSv1.0. Could someone please let me know, if SHA512 is not supported by TLSv1.0 ? Thanks in advance. Regards, Sanjaya Joshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 9 13:47:49 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 9 Nov 2015 14:47:49 +0100 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <563E8391.9020807@openssl.org> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> <20151107025417.GE18315@mournblade.imrryr.org> <563E8391.9020807@openssl.org> Message-ID: <5640A405.8050501@wisemo.com> On 08/11/2015 00:04, Matt Caswell wrote: > On 07/11/15 02:54, Viktor Dukhovni wrote: >> On Fri, Nov 06, 2015 at 11:58:44PM +0000, Matt Caswell wrote: >>> OpenSSL selects the version it is going to use regardless of the >>> available ciphersuites. Only after selecting its version will the server >>> select the ciphersuite to use. If there aren't any compatible with the >>> selected version then it will fail with a "no shared cipher" error. >> Will we always do that. I am not confident we can promise this, >> but this is not at present about to change. >> > I think it is very unlikely to change for the currently available > released versions - and it is the behaviour of those versions that I am > describing. It could possibly change for future versions (as could > anything) - although I'm not aware of any plans to do so. I have seen rumors (nothing reliable) that the TLS WG is proposing to disable a whole lot of good cipher suites in TLS 1.3. If this happens in the final spec, then some lists of enabled ciphers would make TLS 1.2 the most secure choice even though TLS 1.3 is the highest shared version. More specifically, they seem to deprecate the suites that use separate MAC and CRYPT keys in favor of AEAD suites that are designed very close to the margins of being secure. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 p.pan48711 at gmail.com Mon Nov 9 23:46:30 2015 From: p.pan48711 at gmail.com (Peter P.) Date: Mon, 9 Nov 2015 18:46:30 -0500 Subject: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format Message-ID: Hi, I'm writing an application using Openssl 1.0.2d where I am trying to take a DER encoded unsigned CSR and read it into an X509_REQ data structure via the d2i_X509_REQ_bio() function. This function errors out during when I attempt to read in my unsigned CSR and I would like to know if there is any other way to read in an unsigned CSR into an X509_REQ data structure. Thank you, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrf-ssl at itg.hitachi.co.jp Tue Nov 10 04:46:19 2015 From: hrf-ssl at itg.hitachi.co.jp (=?iso-2022-jp?B?GyRCNiZETDRwSFcjUyNTI0whTjZITDMjSSNEIU8bKEIgLyBDT01NT05T?= =?iso-2022-jp?B?U0wbJEIhJBsoQkdZT1VNVQ==?=) Date: Tue, 10 Nov 2015 04:46:19 +0000 Subject: [openssl-users] Does OpenSSL1.0.2d support for Windows 10? Message-ID: <15CFFC2F2156164FA093C04D7DB5BFB3DD64FA@GSjpTK1DCembx01.service.hitachi.net> Hello, Does OpenSSL1.0.2d support for Windows 10? Please let me know if you have any problem running on Windows 10. Thanks in advance. Regards, Dang From Daniel.Cabrera at IGT.com Tue Nov 10 04:37:06 2015 From: Daniel.Cabrera at IGT.com (Cabrera.Daniel) Date: Tue, 10 Nov 2015 04:37:06 +0000 Subject: [openssl-users] openssl and windows 10 iot (ARM) Message-ID: Hi, I downloaded the latest openssl and I could not find the right target for Windows 10 Iot (Raspberry Pi 2) which is an ARM base board. Any plans to support such platform ? Is there any patches or way to use openssl on this platform? Cheers CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinelight at shininglightpro.com Tue Nov 10 06:33:24 2015 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Mon, 9 Nov 2015 23:33:24 -0700 Subject: [openssl-users] Does OpenSSL1.0.2d support for Windows 10? In-Reply-To: <15CFFC2F2156164FA093C04D7DB5BFB3DD64FA@GSjpTK1DCembx01.service.hitachi.net> References: <15CFFC2F2156164FA093C04D7DB5BFB3DD64FA@GSjpTK1DCembx01.service.hitachi.net> Message-ID: <56418FB4.6020309@shininglightpro.com> On 11/9/2015 9:46 PM, ????????????? / COMMONSSL?GYOUMU wrote: > Hello, > > Does OpenSSL1.0.2d support for Windows 10? > Please let me know if you have any problem running on Windows 10. > > Thanks in advance. > > Regards, > Dang Running Win10 here just fine. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From steve at openssl.org Tue Nov 10 14:18:26 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 10 Nov 2015 14:18:26 +0000 Subject: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format In-Reply-To: References: Message-ID: <20151110141826.GA31444@openssl.org> On Mon, Nov 09, 2015, Peter P. wrote: > Hi, > I'm writing an application using Openssl 1.0.2d where I am trying to take a > DER encoded unsigned CSR and read it into an X509_REQ data structure via > the d2i_X509_REQ_bio() function. This function errors out during when I > attempt to read in my unsigned CSR and I would like to know if there is any > other way to read in an unsigned CSR into an X509_REQ data structure. > The signature on a CSR is mandatory so if it is not present it isn't a valid CSR structure any more: that will cause the parser to reject it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From p.pan48711 at gmail.com Tue Nov 10 14:40:56 2015 From: p.pan48711 at gmail.com (Peter P.) Date: Tue, 10 Nov 2015 09:40:56 -0500 Subject: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format In-Reply-To: <20151110141826.GA31444@openssl.org> References: <20151110141826.GA31444@openssl.org> Message-ID: Hi Dr. Henson, Thank you for your reply. To work around this issue in my application, I have considered attempting to re-sign an already signed CSR. Is this possible with OpenSSL? Thank you again, Peter On Tue, Nov 10, 2015 at 9:18 AM, Dr. Stephen Henson wrote: > On Mon, Nov 09, 2015, Peter P. wrote: > > > Hi, > > I'm writing an application using Openssl 1.0.2d where I am trying to > take a > > DER encoded unsigned CSR and read it into an X509_REQ data structure via > > the d2i_X509_REQ_bio() function. This function errors out during when I > > attempt to read in my unsigned CSR and I would like to know if there is > any > > other way to read in an unsigned CSR into an X509_REQ data structure. > > > > The signature on a CSR is mandatory so if it is not present it isn't a > valid > CSR structure any more: that will cause the parser to reject it. > > 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 noadsplease at web.de Tue Nov 10 16:09:11 2015 From: noadsplease at web.de (Dirk Menstermann) Date: Tue, 10 Nov 2015 17:09:11 +0100 Subject: [openssl-users] Available ciphers Message-ID: <564216A7.1010206@web.de> Hi, I'm using openssl 1.0.2 (as web server application) and utilize the APLN callback to react on protocols offered by the client. In this callback I need a way to get the list of ciphers that the client sends within the client_hello. Background is that http2 should only be negotiated if client supports "ECDHE-RSA-AES128-GCM-SHA256" (like Firefox). Any idea how I can get this information? Thanks a lot Dirk From cpservicespb at gmail.com Tue Nov 10 20:58:08 2015 From: cpservicespb at gmail.com (CpServiceSPb .) Date: Tue, 10 Nov 2015 23:58:08 +0300 Subject: [openssl-users] OpenSSL as OCSP server (responder) ! Message-ID: I have Ubuntu 14.04 LTS x32 and not big Lan. I have by myself generated Root->Intermediate->Server/Clients certificate by OpenSSL. I want to do some looks like OCSP server (responder) for Lan. I looked at OpenSSL man and saw that OpenSSL can be as OCSP responder listening some TCP port. But I need that it could operate as daemon that I could start openssl OCSP by script and OpenSSL could handles clients requests in background mode. Is it possible and how can it be done ? And can OpenSSL for Windows run as Windows service ? I need mini OCSP server (responder) based on OpenSSL at Windows as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Tue Nov 10 22:51:03 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 10 Nov 2015 17:51:03 -0500 Subject: [openssl-users] Solaris 8, OpenSSL 1.0.1e, not connecting fro our client, but can connect via openssl in client mode Message-ID: I have an interesting case where I am using Solaris 8 (the patchset for which which has /dev/urandom and /dev/random) with OpenSSL 1.0.1e. I can see from my truss logs that we are attempting to connect to a secure web server, but we see nothing in the Apache log files indicating we connect. If I run ./openssl s_client -ssl3 -host XXX.YYY.com -port 443 we do indeed connect. So I suspect it is something in the client code we are using. We are using the Qt 4.8.5 SSL client. What should I be on the look out for, so I can file a reasonable support request with Digia? This code works fine on Linux and Windows, so I don't really know at this point if the problem is with Solaris support in Qt, or something lower level in OpenSSL (thought I doubt the latter as openssl in client mode is able to connect). Thanks. If this should go to the OpenSSL developers list, let me know. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mofassir_haque at yahoo.com Wed Nov 11 10:51:11 2015 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Wed, 11 Nov 2015 10:51:11 +0000 (UTC) Subject: [openssl-users] Encryption and Decryption using aes-xxx-cfb1 References: <484538754.3152394.1447239071566.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <484538754.3152394.1447239071566.JavaMail.yahoo@mail.yahoo.com> I am running FIPS test vectors against AES-CFB. I am getting correct results for aes-cfb128 and aes-cfb8 tests but not getting correct values for aes-cfb1. The details are given below. Am I missing something ? =========================== Correct Results for CFB128 =========================== KEY = 10a58869d74be5a374cf867cfb473859 IV = 00000000000000000000000000000000 PLAINTEXT = 00000000000000000000000000000000 CIPHERTEXT = 6d251e6944b051e04eaa6fb4dbf78465 [root at Con]# echo 00000000000000000000000000000000 | xxd -r -p > plaintext [root at Con]# [root at Con]# openssl enc -aes-128-cfb -p -nopad -nosalt -K 10a58869d74be5a374cf867cfb473859 -iv 00000000000000000000000000000000 -in plaintext -out ciphertext key=10A58869D74BE5A374CF867CFB473859 iv =00000000000000000000000000000000 [root at Con]# xxd -p ciphertext > ciphertextssd [root at Con]# cat ciphertextssd 6d251e6944b051e04eaa6fb4dbf78465 <================== Correct Result [root at Controller]# ============================ In-Correct Results for CFB1 ============================ KEY = a2e2fa9baf7d20822ca9f0542f764a41 IV = 00000000000000000000000000000000 PLAINTEXT = 0 CIPHERTEXT = 1 [root at Con]# echo 0 | xxd -r -p > plaintext [root at Con]# [root at Con]# openssl enc -aes-128-cfb1 -p -nopad -nosalt -K a2e2fa9baf7d20822ca9f0542f764a41 -iv 00000000000000000000000000000000 -in pla intext -out ciphertext key=A2E2FA9BAF7D20822CA9F0542F764A41 iv =00000000000000000000000000000000 [root at Con]# xxd -p ciphertext > ciphertextssd [root at Cont]# [root at Con]# cat ciphertextssd [root at Con]# <================== No Result whereas it should be 1 Thanks,Haq -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauljosephhebert at gmail.com Wed Nov 11 15:32:34 2015 From: pauljosephhebert at gmail.com (Paul Hebert) Date: Wed, 11 Nov 2015 10:32:34 -0500 Subject: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d? In-Reply-To: References: Message-ID: Hello, After long delays with the client vendor (rhymes with 'Big Red'), I finally have a packet capture detailing the failing two-way authentication TLS 1.2 protocol exchanges - our handshake begins at packet 199 and proceeds with packet 214 being sent from the Apache 2.2.29/OpenSSL 1.0.2d server at 136.223.23.16 sending a bad ChangeCipherSpec record (I've attached packet excerpts from a failing two-way client and server auth session). It looks like our server is sending a {ChangeCipherSpec, Finished} record - but the ChangeCipherSpec shows a length of 25 (19 hex) which causes the client to respond with an Alert (97). Any suggestions you can provide would be appreciated? Thanks, Paul Hebert/State University of New York 199 3.953050 136.223.23.16 151.103.16.212 TLSv1.2 99 Hello Request TLSv1.2 Record Layer: Handshake Protocol: Hello Request 200 3.953237 151.103.16.212 136.223.23.16 TLSv1.2 217 Client Hello TLSv1.2 Record Layer: Handshake Protocol: Client Hello 202 3.983310 136.223.23.16 151.103.16.212 TLSv1.2 1434 Server Hello TLSv1.2 Record Layer: Handshake Protocol: Server Hello 206 3.983489 136.223.23.16 151.103.16.212 TLSv1.2 1183 Certificate Request, Server Hello Done TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages 209 3.984815 151.103.16.212 136.223.23.16 TLSv1.2 1197 Certificate TLSv1.2 Record Layer: Handshake Protocol: Certificate 210 3.987192 151.103.16.212 136.223.23.16 TLSv1.2 725 Client Key Exchange, Certificate Verify, Change Cipher Spec, Finished TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange TLSv1.2 Record Layer: Handshake Protocol: Certificate Verify TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec TLSv1.2 Record Layer: Handshake Protocol: Finished 214 4.017836 136.223.23.16 151.103.16.212 TLSv1.2 141 Change Cipher Spec, Finished TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec TLSv1.2 Record Layer: Handshake Protocol: Finished 215 4.017917 151.103.16.212 136.223.23.16 TLSv1.2 97 Alert (Level: Fatal, Description: Illegal Parameter) TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Illegal Parameter) TLSv1.2 Record Layer: Application Data Protocol: http TLSv1.2 Record Layer: Application Data Protocol: http TLSv1.2 Record Layer: Application Data Protocol: http TLSv1.2 Record Layer: Application Data Protocol: http TLSv1.2 Record Layer: Application Data Protocol: http 253 4.770105 136.223.23.16 151.103.16.212 TLSv1.2 97 Alert (Level: Warning, Description: Close Notify) TLSv1.2 Record Layer: Alert (Level: Warning, Description: Close Notify) ~ On Thu, Aug 6, 2015 at 8:48 AM, Paul Hebert wrote: > We are using a wildcard certificate requiring SNI and are also requiring > client certificate authentication. > > Our TLS 1.2 client is seeing a ChangeCipherspec record with length 30 > bytes (x19) instead of the expected 0x01. The broken ChangeCipherspec > record looks like this (hex) *14 03 03 00 01 19*. Is this a problem with > the TLS 1.2 client, or a problem with the OpenSSL 1.0.2d patch? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tls12_fail_packets.zip Type: application/zip Size: 3408 bytes Desc: not available URL: From jonetsu at teksavvy.com Wed Nov 11 16:27:02 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 11 Nov 2015 11:27:02 -0500 Subject: [openssl-users] (2013) : PKCS12 keystore creation failing in fips mode (RT3515) Message-ID: Hello, There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL 1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to handle a certificate using a non-FIPS component. ?I think I found the commit that fixes this, although it is part of a quite huge commit of 33,065 lines (7e1b7485706c2b11091b5fa897fe496a2faa56cc) done earlier this year. ? There is perhaps a simpler commit that fixes only this issue (92830dc1ca0bb2d12bf05a12ebb798709595fa5a) although I can't see the commit in the git tree I have fetched last week, even by branching to?remotes/origin/OpenSSL_1_0_1-stable. We are using 1.0.1.e. ?My question is, was bug RT3515 included in a later 1.0.1 release ? ?If so, which one ? (If you can also clear up why the patch is not seen... :) Much appreciated, thanks. From director at openca.org Wed Nov 11 16:27:15 2015 From: director at openca.org (Massimiliano Pala) Date: Wed, 11 Nov 2015 11:27:15 -0500 Subject: [openssl-users] Fwd: [saag] Standard Crypto API + Symmetric Crypto At Rest In-Reply-To: <563DFCFB.8090405@openca.org> References: <563DFCFB.8090405@openca.org> Message-ID: <56436C63.6080302@openca.org> Hi OpenSSL Community, I originally posted this message on the security area ML at IETF and I am trying to reach out to a broad audience of experts, implementers, and vendors. I would love to have contributions and implementations (once we have some initial specs) around this initiative. I am still trying to find the right host for the mailing list where to discuss all aspects of this initiative, but I hope that this message will spark some interest and (especially from one of the most vibrant crypto library community out there) possibly inspire the community to join the envisioned effort. Any comments and feedback are welcome (positive and negative alike). Cheers, Max -------- Forwarded Message -------- Subject: [saag] Standard Crypto API + Symmetric Crypto At Rest Date: Sat, 7 Nov 2015 22:30:35 +0900 From: Massimiliano Pala Organization: OpenCA Labs To: saag at ietf.org Hi all, I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail. The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities). Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at: http://cryptoapi.openca.org/ Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest". Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address. Happy Security Everybody! Cheers, Max P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS). -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 11 17:25:19 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Nov 2015 17:25:19 +0000 Subject: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d? In-Reply-To: References: Message-ID: <564379FF.7040500@openssl.org> On 11/11/15 15:32, Paul Hebert wrote: > Hello, > > After long delays with the client vendor (rhymes with 'Big Red'), I > finally have a packet capture detailing the failing two-way > authentication TLS 1.2 protocol exchanges - our handshake begins at > packet 199 and proceeds with packet 214 being sent from the Apache > 2.2.29/OpenSSL 1.0.2d server at 136.223.23.16 sending a bad > ChangeCipherSpec record (I've attached packet excerpts from a failing > two-way client and server auth session). It looks like our server is > sending a {ChangeCipherSpec, Finished} record - but the ChangeCipherSpec > shows a length of 25 (19 hex) which causes the client to respond with an > Alert (97). > > Any suggestions you can provide would be appreciated? The key point here is that this is a *renegotiation* handshake. You can see this from the "Hello Request" coming from the server at the start of your handshake. TLS record headers are always sent in the clear, but the payload will be encrypted for all records after the CCS in the first handshake. Whilst in an initial handshake you would expect a CCS length of 1 the encrypted length in a renegotiation will be dependant on the ciphersuite selected (e.g. MAC sizes, IVs, padding etc). In fact I just had a look at a default s_server->s_client connection (which negotiated ECDHE-RSA-AES256-GCM-SHA384), and the CCS length was indeed 25 (correctly). You can see this in some of the other records in your trace. For example the alert coming from the client has a length of 26 instead of 2 for an unencrypted alert. The client is failing with an alert of "Illegal Parameter". You need to find out what parameter it is choking on, although my guess is, given where it is in the handshake, that the client doesn't like the verify data provided in the Finished message. That's quite tricky to pin down because it essentially means that the handshake hashes differ for some reason. Does this happen for all handshakes or only some? Does it only ever happen with a reneg handshakes (an initial handshake will be easier to diagnose)? Are you only ever talking to one type of client or are there others (and do the others work)? What ciphersuite is being negotiated? Does it work with other ciphersuites? Matt From alex_chen at filemaker.com Wed Nov 11 20:02:01 2015 From: alex_chen at filemaker.com (Alex Chen) Date: Wed, 11 Nov 2015 12:02:01 -0800 Subject: [openssl-users] Elliptic curves approved or recommended by government Message-ID: <56439EB9.9070305@filemaker.com> I see there is a list of recommended list by NIST in http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, but it is very old (1999) Is there a up to date list of elliptic curves approved or recommended for government use in OpenSSL? Is NID_X9_62_prime256v1 the strongest? Thanks Alex From jb-openssl at wisemo.com Wed Nov 11 21:08:23 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 11 Nov 2015 22:08:23 +0100 Subject: [openssl-users] Elliptic curves approved or recommended by government In-Reply-To: <56439EB9.9070305@filemaker.com> References: <56439EB9.9070305@filemaker.com> Message-ID: <5643AE47.4060207@wisemo.com> On 11/11/2015 21:02, Alex Chen wrote: > I see there is a list of recommended list by NIST in > http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, > but it is very old (1999) > Is there a up to date list of elliptic curves approved or recommended > for government use in OpenSSL? > Is NID_X9_62_prime256v1 the strongest? First of all, it depends on *which government*, NIST is for the USA Government only, though some allied countries may have copied their decisions. Secondly, since ca. 1999, the official list has been mostly unchanged, namely those that are listed in the official NIST standard FIPS 186-2 for use with ECDSA and in NIST Special publication SP 800-56A for ECDH. So far, the public adjustments have been: 2005: The official Suite B list of ciphers was published and included the P-256 and P-384 bit curves as minimum. Around the same time they made a secret Suite A list of ciphers for stuff more secret than "top secret". 2015: NSA announced that they will soon start work on a new list, and that government departments should not waste taxpayers money doing the upgrade to Suite B just a few years before it becomes obsolete. However for use at this time they recommend P-384 or 3072 bit RSA/DH as a good minimum while accepting the next step down (P-256 or 2048 bit RSA/DH) in already built systems. They also recommend the use of pure symmetric key solutions with strong (256 random bits) keys as the best current solution where possible. The (non-classified) current official advice can be read at https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 jonetsu at teksavvy.com Wed Nov 11 20:53:51 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 11 Nov 2015 13:53:51 -0700 (MST) Subject: [openssl-users] Elliptic curves approved or recommended by government In-Reply-To: <5643AE47.4060207@wisemo.com> References: <56439EB9.9070305@filemaker.com> <5643AE47.4060207@wisemo.com> Message-ID: <1447275231244-60946.post@n7.nabble.com> In the NSA page referred above, the p-384 curves are specifically mentioned for DH. These would be the ones covered by the Suite B NSA license sub-licensed to OpenSSL, are they ? Is it possible to build OpenSSL in FIPS in such a way that only these curves will be used ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/Elliptic-curves-approved-or-recommended-by-government-tp60944p60946.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From igor.sverkos at gmail.com Wed Nov 11 21:53:46 2015 From: igor.sverkos at gmail.com (Igor Sverkos) Date: Wed, 11 Nov 2015 22:53:46 +0100 Subject: [openssl-users] No TLS Extended Master Secret Extension (RFC7627) support yet? Message-ID: Hi, today I read [1] that Microsoft finally added support for TLS Extended Master Secret Extension to their SSL implementation (SChannel). The author was so kind to provide a test script [2] to check if your own servers support TLS Extended Master Secret extension yet. Looks like my servers don't support TLS Extended Master Secret extension yet. This lead me to the question when OpenSSL will add support for this extensions or if it is my fault. I am using nginx/1.9.6 build against OpenSSL 1.0.2d 9 Jul 2015 from source. Looks like there was already a contribution [3] which was already reviewed in some ways [4]. Any status update would be nice. [1] http://www.tripwire.com/state-of-security/security-data-protection/security-hardening/tls-extended-master-secret-extension-fixing-a-hole-in-tls/ [2] https://github.com/Tripwire-VERT/TLS_Extended_Master_Checker [3] https://github.com/alfredopironti/openssl/commit/5339db9ec81727456f7edb86aab186e7deefe819 [4] http://openssl.6102.n7.nabble.com/PATCH-Fix-for-Triple-Handshake-attacks-via-extended-master-secret-td50058.html Regards, Igor From wiml at omnigroup.com Wed Nov 11 22:05:08 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 11 Nov 2015 14:05:08 -0800 Subject: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format In-Reply-To: References: Message-ID: <0D59A87E-7449-4370-A3D2-F1DAE9A6C52A@omnigroup.com> On Nov 9, 2015, at 3:46 PM, Peter P. wrote: > I'm writing an application using Openssl 1.0.2d where I am trying to take a DER encoded unsigned CSR and read it into an X509_REQ data structure via the d2i_X509_REQ_bio() function. This function errors out during when I attempt to read in my unsigned CSR and I would like to know if there is any other way to read in an unsigned CSR into an X509_REQ data structure. A CSR (from PKCS#10 / RFC2986) has the structure: SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING } where the actual request is the CertificationRequestInfo, and the signature is composed of the AlgorithmIdentifier + BIT STRING. Are you trying to just read in a bare CertificationRequestInfo structure? I suspect you can do that with a call like ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req) which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ replaced by X509_REQ_INFO. I haven't tried it, though. (Whether it's a *good idea* to pass bare CSR info structs around is another question but I'll leave that up to you.) Wim. From matt at openssl.org Wed Nov 11 22:15:04 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Nov 2015 22:15:04 +0000 Subject: [openssl-users] No TLS Extended Master Secret Extension (RFC7627) support yet? In-Reply-To: References: Message-ID: <5643BDE8.6030209@openssl.org> On 11/11/15 21:53, Igor Sverkos wrote: > Hi, > > today I read [1] that Microsoft finally added support for TLS Extended > Master Secret Extension to their SSL implementation (SChannel). > > The author was so kind to provide a test script [2] to check if your > own servers support TLS Extended Master Secret extension yet. > > Looks like my servers don't support TLS Extended Master Secret > extension yet. This lead me to the question when OpenSSL will add > support for this extensions or if it is my fault. I am using > > nginx/1.9.6 build against OpenSSL 1.0.2d 9 Jul 2015 > > from source. > > Looks like there was already a contribution [3] which was already > reviewed in some ways [4]. > > Any status update would be nice. Extended Master Secret support is already merged into the current git master branch. It will be supported in our forthcoming 1.1.0 release. Our current release schedule puts this as being released on 28th April 2016: https://www.openssl.org/policies/releasestrat.html Matt From matt at openssl.org Wed Nov 11 23:07:28 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 11 Nov 2015 23:07:28 +0000 Subject: [openssl-users] Elliptic curves approved or recommended by government In-Reply-To: <1447275231244-60946.post@n7.nabble.com> References: <56439EB9.9070305@filemaker.com> <5643AE47.4060207@wisemo.com> <1447275231244-60946.post@n7.nabble.com> Message-ID: <5643CA30.7050006@openssl.org> On 11/11/15 20:53, jonetsu wrote: > In the NSA page referred above, the p-384 curves are specifically mentioned > for DH. These would be the ones covered by the Suite B NSA license > sub-licensed to OpenSSL, are they ? Is it possible to build OpenSSL in FIPS > in such a way that only these curves will be used ? OpenSSL 1.0.2 has Suite B support. It can be configured via the cipher list. See SUITEB128, SUITEB128ONLY, SUITEB192 here: https://www.openssl.org/docs/man1.0.2/apps/ciphers.html Matt From alex_chen at filemaker.com Thu Nov 12 00:31:18 2015 From: alex_chen at filemaker.com (Alex Chen) Date: Wed, 11 Nov 2015 16:31:18 -0800 Subject: [openssl-users] Elliptic curves approved or recommended by government In-Reply-To: <5643AE47.4060207@wisemo.com> References: <56439EB9.9070305@filemaker.com> <5643AE47.4060207@wisemo.com> Message-ID: <5643DDD6.5060701@filemaker.com> Thanks for the reply Jakob. Is there a mapping in the government's elliptic curve names to the names in OpenSSL? For instance, the API EC_KEY_new_by_curve_name( int nid ) takes an id of the EC name where the id can be something like NID_X9_62_prime256v1, NID_X9_62_prime239v3, etc. that are defined in ob_jmac.h. What I would like to know is how the names are related to NIST's recommendation list? Is there a convention? Thanks On 11/11/2015 1:08 PM, Jakob Bohm wrote: > On 11/11/2015 21:02, Alex Chen wrote: >> I see there is a list of recommended list by NIST in >> http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, >> but it is very old (1999) >> Is there a up to date list of elliptic curves approved or recommended >> for government use in OpenSSL? >> Is NID_X9_62_prime256v1 the strongest? > First of all, it depends on *which government*, NIST is for > the USA Government only, though some allied countries may have > copied their decisions. > > Secondly, since ca. 1999, the official list has been mostly > unchanged, namely those that are listed in the official NIST > standard FIPS 186-2 for use with ECDSA and in NIST Special > publication SP 800-56A for ECDH. > > So far, the public adjustments have been: > > 2005: The official Suite B list of ciphers was published and > included the P-256 and P-384 bit curves as minimum. > Around the same time they made a secret Suite A list of > ciphers for stuff more secret than "top secret". > 2015: NSA announced that they will soon start work on a new > list, and that government departments should not waste > taxpayers money doing the upgrade to Suite B just a few > years before it becomes obsolete. > However for use at this time they recommend P-384 or > 3072 bit RSA/DH as a good minimum while accepting the > next step down (P-256 or 2048 bit RSA/DH) in already > built systems. > They also recommend the use of pure symmetric key > solutions with strong (256 random bits) keys as the best > current solution where possible. > > The (non-classified) current official advice can be read at > > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From xxiao8 at fosiao.com Thu Nov 12 16:08:27 2015 From: xxiao8 at fosiao.com (xxiao8) Date: Thu, 12 Nov 2015 10:08:27 -0600 Subject: [openssl-users] Openssl FIPS uses /dev/urandom by default? Message-ID: <5644B97B.7040306@fosiao.com> in e_os.h I saw ====== #ifndef DEVRANDOM /* set this to a comma-separated list of 'random' device files to try out. * My default, we will try to read at least one of these files */ #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" # endif ====== this basically sets /dev/urandom as the default which really is not FIPS-friendly, is there a way to override this during compilation to set the default to /dev/random instead? I'm not supposed to modify the source code as it will invalidate openssl-FIPS certificate. Thanks, xxiao From ethan.rahn at gmail.com Thu Nov 12 16:35:45 2015 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Thu, 12 Nov 2015 08:35:45 -0800 Subject: [openssl-users] Openssl FIPS uses /dev/urandom by default? In-Reply-To: <5644B97B.7040306@fosiao.com> References: <5644B97B.7040306@fosiao.com> Message-ID: xxiao, Are you sure you can't modify that? My understanding of FIPS mode is that you cannot modify the FIPS code canister, which entropy sources are not a part of. Cheers, Ethan On Thu, Nov 12, 2015 at 8:08 AM, xxiao8 wrote: > in e_os.h I saw > ====== > #ifndef DEVRANDOM > > /* set this to a comma-separated list of 'random' device files to try out. > > * My default, we will try to read at least one of these files */ > > #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" > > # endif > ====== > this basically sets /dev/urandom as the default which really is not > FIPS-friendly, is there a way to override this during compilation to set > the default to /dev/random instead? I'm not supposed to modify the source > code as it will invalidate openssl-FIPS certificate. > > Thanks, > xxiao > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Thu Nov 12 16:51:06 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 12 Nov 2015 11:51:06 -0500 Subject: [openssl-users] Openssl FIPS uses /dev/urandom by default? In-Reply-To: References: <5644B97B.7040306@fosiao.com> Message-ID: <5644C37A.4070504@cisco.com> Entropy collection is outside the FIPS boundary. If you don't want to modify the code, you can pass in -DDEVRANDOM using CFLAGS and set it to whatever value you desire. For instance, maybe you have a hardware device mapped to /dev/entropy that provides sufficient random data to seed the DRBG. On 11/12/2015 11:35 AM, Ethan Rahn wrote: > xxiao, > > Are you sure you can't modify that? My understanding of FIPS mode is > that you cannot modify the FIPS code canister, which entropy sources > are not a part of. > > Cheers, > > Ethan > > On Thu, Nov 12, 2015 at 8:08 AM, xxiao8 > wrote: > > in e_os.h I saw > ====== > #ifndef DEVRANDOM > > /* set this to a comma-separated list of 'random' device files to > try out. > > * My default, we will try to read at least one of these files */ > > #define DEVRANDOM "/dev/urandom","/dev/random","/dev/srandom" > > # endif > ====== > this basically sets /dev/urandom as the default which really is > not FIPS-friendly, is there a way to override this during > compilation to set the default to /dev/random instead? I'm not > supposed to modify the source code as it will invalidate > openssl-FIPS certificate. > > Thanks, > xxiao > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergiomagra at gmail.com Thu Nov 12 18:56:30 2015 From: sergiomagra at gmail.com (Sergio Magra) Date: Thu, 12 Nov 2015 15:56:30 -0300 Subject: [openssl-users] Protecting RSA keys Message-ID: <008701d11d7b$d9079230$8b16b690$@com> Hi everybody, I'm new with OpenSSL and I have some questions. The thing is that several RSA key pairs (each one for a different user) will be stored in a shared secured location. As the key pairs will be stored in the same place, we are looking for a way to ensure that one user is able to use only its own key pair, and not the key pair of another user. In this way, I'm thinking on a passphrase to protect the private key, so when the user needs to use its key pair for signing or encrypting, he must provide the passphrase. As he knows its passphrase and not the passphrase of the other key pairs, he is able to use only its own key pair. Until now, the theory. I don't know if I'm right. If yes, I tried to generate protected key pairs, but when using them, I'm never prompted for the passphrase. So, I'm able to use any of the keys created. Can you help me with this issue? Thanks in advance Best regards Sergio Magra -------------- next part -------------- An HTML attachment was scrubbed... URL: From pratyush.parimal at gmail.com Fri Nov 13 02:56:33 2015 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Thu, 12 Nov 2015 21:56:33 -0500 Subject: [openssl-users] How to get list of TLS protocols supported by OpenSSL? Message-ID: Hi, I'm writing a client-server program that uses TLS for communication. I'm wondering if there's any way to programmatically find out which TLS protocol versions are supported by the OpenSSL library installed on my system. I'm currently aware of three ways which "sort of" provide this information: (1) After setting up the TLS communication, call: SSL_get_version(ssl); which returns "TLSV1.2", etc. (2) Try to connect to a server using TLS by specifying all possible TLS versions in the client program, and see which connections pass/fail. (3) Call: SSL_get_ciphers(), print their names, and try to correlate them with the protocol they're associated with. Unfortunately, none of the above answer my question completely. So is it possible to ascertain which TLS protocol versions are actually supported by my server-program, without trying the above methods? My purpose is not to simply make a list for my own reference, but rather finding it out on-the-fly in the server-side program, since I may run it on different versions of OpenSSL. Thanks in advance! Pratyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Nov 13 04:44:36 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 13 Nov 2015 05:44:36 +0100 Subject: [openssl-users] How to get list of TLS protocols supported by OpenSSL? In-Reply-To: References: Message-ID: <56456AB4.7030104@wisemo.com> On 13/11/2015 03:56, pratyush parimal wrote: > Hi, > > I'm writing a client-server program that uses TLS for communication. > I'm wondering if there's any way to programmatically find out which > TLS protocol versions are supported by the OpenSSL library installed > on my system. > > I'm currently aware of three ways which "sort of" provide this > information: > (1) After setting up the TLS communication, call: > SSL_get_version(ssl); which returns "TLSV1.2", etc. > (2) Try to connect to a server using TLS by specifying all possible > TLS versions in the client program, and see which connections pass/fail. > (3) Call: SSL_get_ciphers(), print their names, and try to correlate > them with the protocol they're associated with. > > Unfortunately, none of the above answer my question completely. > > So is it possible to ascertain which TLS protocol versions are > actually supported by my server-program, without trying the above > methods? My purpose is not to simply make a list for my own reference, > but rather finding it out on-the-fly in the server-side program, since > I may run it on different versions of OpenSSL. > If there is no suitable direct API, the following might still be helpful: (4) Get the OpenSSL library version directly and compare to the known version ranges supporting different SSL/TLS versions. (5) Looking for ways to determine the configure options used when the SSL library was built (in particular if it was compiled without some SSL/TLS versions supported in the source code of that version). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 ignacio.casal at nice-software.com Fri Nov 13 08:37:54 2015 From: ignacio.casal at nice-software.com (Ignacio Casal) Date: Fri, 13 Nov 2015 09:37:54 +0100 Subject: [openssl-users] Rehandshake problem Message-ID: Hey guys, I am having a specific problem that I do not seem to find a solution for. - I have a server and a client that handshake properly - the server will read from the client and the client from the server a few bytes - the client will try to read again - the server will try to handshake again by calling SSL_renegotiate and SSL_do_handshake. I get no errors in these calls. - then I would expect the client to exit from the read call with an error saying that needs to handshake again, instead it stays blocked on the read until the server sends some data. But then I get an error server side that there was no proper handshaking. Do you know how to get a notification client side that the client needs to handshake again when blocked on a read or write? Cheers. -- Ignacio Casal Quinteiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 13 09:34:47 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 13 Nov 2015 09:34:47 +0000 Subject: [openssl-users] How to get list of TLS protocols supported by OpenSSL? In-Reply-To: References: Message-ID: <5645AEB7.6040608@openssl.org> On 13/11/15 02:56, pratyush parimal wrote: > Hi, > > I'm writing a client-server program that uses TLS for communication. > I'm wondering if there's any way to programmatically find out which TLS > protocol versions are supported by the OpenSSL library installed on my > system. > > I'm currently aware of three ways which "sort of" provide this information: > (1) After setting up the TLS communication, call: SSL_get_version(ssl); > which returns "TLSV1.2", etc. > (2) Try to connect to a server using TLS by specifying all possible TLS > versions in the client program, and see which connections pass/fail. > (3) Call: SSL_get_ciphers(), print their names, and try to correlate > them with the protocol they're associated with. > > Unfortunately, none of the above answer my question completely. > > So is it possible to ascertain which TLS protocol versions are actually > supported by my server-program, without trying the above methods? My > purpose is not to simply make a list for my own reference, but rather > finding it out on-the-fly in the server-side program, since I may run it > on different versions of OpenSSL. You can use the define TLS_MAX_VERSION to determine the highest protocol version supported by the library. If you also want to know the lowest version then that's a bit more tricky. All current released versions will define OPENSSL_NO_SSL3 if SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2 support has been compiled out (its not currently possible to compile out other protocol versions). In the forthcoming 1.1.0 release SSLv2 support has been completely removed so you don't get OPENSSL_NO_SSL2 even though there is no SSLv2 support available (hmmmm...I wonder if we should add that?). There are other SSLv2 defines in ssl2.h that are removed in 1.1.0 which you could use to detect whether you are on a version with ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like (completely untested): #ifdef OPENSSL_NO_SSL3 #define TLS_MIN_VERSION TLS1_VERSION #elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR) #define TLS_MIN_VERSION SSL3_VERSION #else #define TLS_MIN_VERSION SSL2_VERSION #endif How future proof that is if we ever remove SSLv3 support I'm not sure. Matt From matt at openssl.org Fri Nov 13 10:08:16 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 13 Nov 2015 10:08:16 +0000 Subject: [openssl-users] Rehandshake problem In-Reply-To: References: Message-ID: <5645B690.30709@openssl.org> On 13/11/15 08:37, Ignacio Casal wrote: > Hey guys, > > I am having a specific problem that I do not seem to find a solution for. > > - I have a server and a client that handshake properly > - the server will read from the client and the client from the server a > few bytes > - the client will try to read again > - the server will try to handshake again by calling SSL_renegotiate and > SSL_do_handshake. I get no errors in these calls. > - then I would expect the client to exit from the read call with an > error saying that needs to handshake again, instead it stays blocked on > the read until the server sends some data. But then I get an error > server side that there was no proper handshaking. > > Do you know how to get a notification client side that the client needs > to handshake again when blocked on a read or write? Which OpenSSL version/platform are you using? Can you get a pcap packet trace and post the specific errors that you are receiving? You would normally expect to get an SSL_ERROR_WANT_READ on the client side when the server sends the HelloRequest. Matt From ignacio.casal at nice-software.com Fri Nov 13 10:18:48 2015 From: ignacio.casal at nice-software.com (Ignacio Casal) Date: Fri, 13 Nov 2015 11:18:48 +0100 Subject: [openssl-users] Rehandshake problem In-Reply-To: <5645B690.30709@openssl.org> References: <5645B690.30709@openssl.org> Message-ID: Hey, this is on fedora 23, though I built openssl 1.0.1k (since it is the version supported on rhel 6) These are the specific test cases that are failing with openssl for us: https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1948 https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n1950 And here is where the second handshake happens: https://git.gnome.org/browse/glib-networking/tree/tls/tests/connection.c?h=wip/openssl#n389 FWIW we are using our own bio: https://git.gnome.org/browse/glib-networking/tree/tls/openssl/gtlsbio.c?h=wip/openssl I can try to get you the pcap packet trace. About " You would normally expect to get an SSL_ERROR_WANT_READ on the client side when the server sends the HelloRequest." Yes this is what I would have expected as well. Cheers. On Fri, Nov 13, 2015 at 11:08 AM, Matt Caswell wrote: > > > On 13/11/15 08:37, Ignacio Casal wrote: > > Hey guys, > > > > I am having a specific problem that I do not seem to find a solution for. > > > > - I have a server and a client that handshake properly > > - the server will read from the client and the client from the server a > > few bytes > > - the client will try to read again > > - the server will try to handshake again by calling SSL_renegotiate and > > SSL_do_handshake. I get no errors in these calls. > > - then I would expect the client to exit from the read call with an > > error saying that needs to handshake again, instead it stays blocked on > > the read until the server sends some data. But then I get an error > > server side that there was no proper handshaking. > > > > Do you know how to get a notification client side that the client needs > > to handshake again when blocked on a read or write? > > Which OpenSSL version/platform are you using? Can you get a pcap packet > trace and post the specific errors that you are receiving? > > You would normally expect to get an SSL_ERROR_WANT_READ on the client > side when the server sends the HelloRequest. > > Matt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Ignacio Casal Quinteiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Nov 13 12:38:36 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 13 Nov 2015 13:38:36 +0100 Subject: [openssl-users] How to get list of TLS protocols supported by OpenSSL? In-Reply-To: <5645AEB7.6040608@openssl.org> References: <5645AEB7.6040608@openssl.org> Message-ID: <5645D9CC.2030608@wisemo.com> On 13/11/2015 10:34, Matt Caswell wrote: > On 13/11/15 02:56, pratyush parimal wrote: >> Hi, >> >> I'm writing a client-server program that uses TLS for communication. >> I'm wondering if there's any way to programmatically find out which TLS >> protocol versions are supported by the OpenSSL library installed on my >> system. >> >> I'm currently aware of three ways which "sort of" provide this information: >> (1) After setting up the TLS communication, call: SSL_get_version(ssl); >> which returns "TLSV1.2", etc. >> (2) Try to connect to a server using TLS by specifying all possible TLS >> versions in the client program, and see which connections pass/fail. >> (3) Call: SSL_get_ciphers(), print their names, and try to correlate >> them with the protocol they're associated with. >> >> Unfortunately, none of the above answer my question completely. >> >> So is it possible to ascertain which TLS protocol versions are actually >> supported by my server-program, without trying the above methods? My >> purpose is not to simply make a list for my own reference, but rather >> finding it out on-the-fly in the server-side program, since I may run it >> on different versions of OpenSSL. > You can use the define TLS_MAX_VERSION to determine the highest protocol > version supported by the library. > > If you also want to know the lowest version then that's a bit more > tricky. All current released versions will define OPENSSL_NO_SSL3 if > SSLv3 support has been compiled out, and OPENSSL_NO_SSL2 if SSLv2 > support has been compiled out (its not currently possible to compile out > other protocol versions). In the forthcoming 1.1.0 release SSLv2 support > has been completely removed so you don't get OPENSSL_NO_SSL2 even though > there is no SSLv2 support available (hmmmm...I wonder if we should add > that?). There are other SSLv2 defines in ssl2.h that are removed in > 1.1.0 which you could use to detect whether you are on a version with > ssl2.h completely removed such as SSL2_MT_ERROR, i.e. something like > (completely untested): > > #ifdef OPENSSL_NO_SSL3 > #define TLS_MIN_VERSION TLS1_VERSION > #elif defined(OPENSSL_NO_SSL2) || !defined(SSL2_MT_ERROR) > #define TLS_MIN_VERSION SSL3_VERSION > #else > #define TLS_MIN_VERSION SSL2_VERSION > #endif > > How future proof that is if we ever remove SSLv3 support I'm not sure. > > Matt Unfortunately that presumes that the client is compiled against configure headers from the library build. This is absolutely useless if you try to share an OpenSSL shared library compiled by a 3rd party (such as an OS distribution or an end user). What lots of people need is an ability to interrogate a compiled shared library about what is enabled in that copy, similar to how the SSL_get_ciphers() or similar can be used to determine if the current copy has been compiled without IDEA, ECC or other optional cipher suites. This is what happens in the real world when end users run your compiled program on various Linux distributions, such as Red Hat vs. OpenSUSE vs. Ubuntu... Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 pauljosephhebert at gmail.com Fri Nov 13 12:13:39 2015 From: pauljosephhebert at gmail.com (hebertpj) Date: Fri, 13 Nov 2015 05:13:39 -0700 (MST) Subject: [openssl-users] Fwd: Broken ChangeCipherspec record in TLS 1.2 with OpenSSL 1.0.2d? In-Reply-To: <564379FF.7040500@openssl.org> References: <564379FF.7040500@openssl.org> Message-ID: <1447416819442-60972.post@n7.nabble.com> Thank you kindly Matt, for the pointers - these connections always end with that renegotiation and subsequent failure - I suspect there is a ciphersuite problem and am following up to see what the client *will* support.Paul H. -- View this message in context: http://openssl.6102.n7.nabble.com/Broken-ChangeCipherspec-record-in-TLS-1-2-with-OpenSSL-1-0-2d-tp59592p60972.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Fri Nov 13 13:40:33 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 13 Nov 2015 14:40:33 +0100 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Message-ID: Hi all, We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL first to ensure we won't be breaking any major applications. These algorithms are currently candidates for removal: CAST IDEA MDC2 MD2 [ already disabled by default ] RC5 [ already disabled by default ] RIPEMD SEED WHIRLPOOL ALL BINARY ELLIPTIC CURVES My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is effectively dead and can be removed. *Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between new and old peers, or major pain to distro end-users. These algorithms are obsolete but removing them doesn't look feasible: BLOWFISH - probably still in use though I don't know where exactly? MD4 - used in NTLM RC2 - used in PKCS#12 *Did I miss anything from the list?* Cheers, Emilia -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.pan48711 at gmail.com Fri Nov 13 14:33:35 2015 From: p.pan48711 at gmail.com (Peter P.) Date: Fri, 13 Nov 2015 09:33:35 -0500 Subject: [openssl-users] Converting DER encoded unsigned CSR to internal OpenSSL format In-Reply-To: <0D59A87E-7449-4370-A3D2-F1DAE9A6C52A@omnigroup.com> References: <0D59A87E-7449-4370-A3D2-F1DAE9A6C52A@omnigroup.com> Message-ID: Hi Wim, I'll give this a shot, thank you for the suggestion! -Peter On Wed, Nov 11, 2015 at 5:05 PM, Wim Lewis wrote: > > On Nov 9, 2015, at 3:46 PM, Peter P. wrote: > > I'm writing an application using Openssl 1.0.2d where I am trying to > take a DER encoded unsigned CSR and read it into an X509_REQ data structure > via the d2i_X509_REQ_bio() function. This function errors out during when I > attempt to read in my unsigned CSR and I would like to know if there is any > other way to read in an unsigned CSR into an X509_REQ data structure. > > A CSR (from PKCS#10 / RFC2986) has the structure: > > SEQUENCE { CertificationRequestInfo, AlgorithmIdentifier, BIT STRING } > > where the actual request is the CertificationRequestInfo, and the > signature is composed of the AlgorithmIdentifier + BIT STRING. > > Are you trying to just read in a bare CertificationRequestInfo structure? > I suspect you can do that with a call like > > ASN1_item_d2i_bio(ASN1_ITEM_rptr(X509_REQ_INFO), bp, req) > > which is the same as the body of d2i_X509_REQ_bio(), but with X509_REQ > replaced by X509_REQ_INFO. I haven't tried it, though. > > (Whether it's a *good idea* to pass bare CSR info structs around is > another question but I'll leave that up to you.) > > > Wim. > > _______________________________________________ > 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 Nov 13 15:31:51 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 13 Nov 2015 16:31:51 +0100 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <56460267.1080802@wisemo.com> On 13/11/2015 14:40, Emilia K?sper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated > cryptographic primitives. As you may know the forks have already done > this but I'd like to seek careful feedback for OpenSSL first to ensure > we won't be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, > delete the code). Disabled-by-default code will either be re-enabled > by distros (if there's widespread need for it - in which case we might > as well leave it in) or will be poorly tested and is likely to just > silently rot and break. This code is bloat and maintentance burden for > us - my hope is that much of this code is effectively dead and can be > removed. > > *Are you aware of any mainstream need to continue supporting these > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > binary, or a standalone implementation or another crypto toolkit can > always be used to continue supporting a legacy standalone application, > or to decrypt ciphertext from the distant past. I am looking for use > cases that could cause e.g. interop breakage between new and old > peers, or major pain to distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > *Did I miss anything from the list?* > BlowFish is still hardcoded into some file formats that are still in use, such as the PasswordSafe password database format, I don't know if any related implementations get the Blowfish code from OpenSSL though. IDEA was famously used in the original PGP encryption format and as such remains useful when implementing OpenPGP decryption on top of OpenSSL's libcrypto (as opposed to implementing an OpenSSL emulation on top an OpenPGP library like GNU did). I don't know if any of the 'OpenPGP in a high level language such as perl/python/php' implementations use OpenSSL's IDEA implementation as the backend though, but someone will need to trawl through CPAN (for perl), the Linux dists etc. to be sure. MD2 is still present in the self-signature on some major root certificates that are still trusted in signatures on old/historic data and documents. Note that the default OpenSSL code currently skips checking the self-signature on self-signed root certificates, but that was done based as a workaround for the disabling of MD2, and is based on the (unreliable) assumption that checking their internal consistency had no value in determining the trust. Accepting MD2 only for this limited role (and thus keeping the code around for that case only) would be more secure. The use of MD4 in NTLM is closely related to its use in the password database format of computers that interoperate with NTLM, SMB, CIFS, Microsoft Kerberos extensions etc. Those password databases and related protocols will probably outlive NTLM itself by many years. WHIRLPOOL has been frequently recommended as the premier non-NIST alternative to SHA-512, I have heard of no reason to deprecate it. The binary elliptic curve code in OpenSSL seems to have a unique patent license heritage (via Sun I think) and thus provides a unique source of such code for other FOSS code as the Certicom and Sun patents change hands in unpredictable ways. I don't know if any major CA issued ECDSA certificates using those curves, in which case they remain important to the CMS and certificate code in OpenSSL. Again I have heard of no reason to deprecate them. I do not recall any common uses for the CAST cipher, the MDC hash construct family or the RIPEMD hash function family (at this time). RC5 may be a patent problem and would probably be disabled in most OpenSSL builds anyway. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 jonetsu at teksavvy.com Fri Nov 13 16:14:56 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 13 Nov 2015 11:14:56 -0500 Subject: [openssl-users] How to access a bug fix ? Message-ID: Hello, ?I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with no-rc2' although the opnssl tree I got recently does not show it: % git status On branch master Your branch is up-to-date with 'origin/master'. % git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a I tried with checking out a few branches: ? remotes/origin/OpenSSL-fips-2_0-stable ? remotes/origin/OpenSSL_1_0_1-stable ? remotes/origin/OpenSSL_1_0_2-stable And still not shown. ?Did that bug fix ever made it to the OpenSSL tree as such, or was it bundled in the 33,000+ lines commit?7e1b7485706c2b11091b5fa897fe496a2faa56cc ? Alternatively, in which 1.0.1 version was this bug fix included ? ?I grepped the CHANGES file of some versions after 1.0.1e although these do not list the bug numbers. Thanks. From rsalz at akamai.com Fri Nov 13 16:24:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 16:24:46 +0000 Subject: [openssl-users] Elliptic curves approved or recommended by government In-Reply-To: <56439EB9.9070305@filemaker.com> References: <56439EB9.9070305@filemaker.com> Message-ID: <1447431886253.68038@akamai.com> > Is there a up to date list of elliptic curves approved or recommended for government use in OpenSSL? You'll have to look outside OpenSSL for advice like that. I would suggest looking at the CFRG, part of the IETF basically. Do web search for curve recommendations. Good luck. It's a contentious area. From bkaduk at akamai.com Fri Nov 13 16:48:19 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 13 Nov 2015 10:48:19 -0600 Subject: [openssl-users] How to access a bug fix ? In-Reply-To: References: Message-ID: <56461453.8060101@akamai.com> On 11/13/2015 10:14 AM, jonetsu wrote: > Hello, > > > I would like to see the bug fix for RT3515 'Use 3DES in pkcs12 if built with no-rc2' although the opnssl tree I got recently does not show it: The bug fix is just the patch contained in the initial submission. > > % git status > On branch master > Your branch is up-to-date with 'origin/master'. > > > % git show 92830dc1ca0bb2d12bf05a12ebb798709595fa5a > fatal: bad object 92830dc1ca0bb2d12bf05a12ebb798709595fa5a > > > I tried with checking out a few branches: > > > remotes/origin/OpenSSL-fips-2_0-stable > remotes/origin/OpenSSL_1_0_1-stable > remotes/origin/OpenSSL_1_0_2-stable Checking out a different branch will not make any difference; "git show" checks for all objects in a given repository, whether accessible from the current HEAD or otherwise. > > And still not shown. Did that bug fix ever made it to the OpenSSL tree as such, or was it bundled in the 33,000+ lines commit 7e1b7485706c2b11091b5fa897fe496a2faa56cc ? It seems to be only in that mega-commit, which is not a real git merge commit despite having 'merge' in the commit message. > > Alternatively, in which 1.0.1 version was this bug fix included ? I grepped the CHANGES file of some versions after 1.0.1e although these do not list the bug numbers. > Looking at the pkcs12.c version in the OpenSSL_1_0_2-stable branch and OpenSSL_1_0_1-stable branch, the bugfix is not present. You would need to apply it manually or convince a committer to push the change to the stable branches. -Ben Kaduk From bkaduk at akamai.com Fri Nov 13 17:00:54 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 13 Nov 2015 11:00:54 -0600 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56460267.1080802@wisemo.com> References: <56460267.1080802@wisemo.com> Message-ID: <56461746.7040808@akamai.com> On 11/13/2015 09:31 AM, Jakob Bohm wrote: > On 13/11/2015 14:40, Emilia K?sper wrote: >> Hi all, >> >> We are considering removing from OpenSSL 1.1 known broken or outdated >> cryptographic primitives. As you may know the forks have already done >> this but I'd like to seek careful feedback for OpenSSL first to >> ensure we won't be breaking any major applications. >> >> These algorithms are currently candidates for removal: >> >> CAST >> IDEA >> MDC2 >> MD2 [ already disabled by default ] >> RC5 [ already disabled by default ] >> RIPEMD >> SEED >> WHIRLPOOL >> ALL BINARY ELLIPTIC CURVES >> I wonder why single-DES is not in the above list. (Maybe because no one has spoken up as being interested in disentangling triple-DES from single-DES?) >> My preference would be to remove these algorithms completely (as in, >> delete the code). Disabled-by-default code will either be re-enabled >> by distros (if there's widespread need for it - in which case we >> might as well leave it in) or will be poorly tested and is likely to >> just silently rot and break. This code is bloat and maintentance >> burden for us - my hope is that much of this code is effectively dead >> and can be removed. >> My hope as well :) >> These algorithms are obsolete but removing them doesn't look feasible: >> >> BLOWFISH - probably still in use though I don't know where exactly? >> MD4 - used in NTLM >> RC2 - used in PKCS#12 >> As another thread calls to mind, PKCS#12 could potentially just use triple-DES. (BTW, the CMS tests fail when openssl is configured with no-rc2, due to this; I have a WIP patch sitting around.) > MD2 is still present in the self-signature on some major > root certificates that are still trusted in signatures > on old/historic data and documents. Note that the > default OpenSSL code currently skips checking the > self-signature on self-signed root certificates, but > that was done based as a workaround for the disabling > of MD2, and is based on the (unreliable) assumption > that checking their internal consistency had no value > in determining the trust. Accepting MD2 only for this > limited role (and thus keeping the code around for that > case only) would be more secure. > I am not sure that I agree with the claim that this assumption is unreliable. There have been some (heated) discussions on the IETF tls WG list recently regarding the self-signatures on trust anchors, and I have not seen any compelling arguments there for checking the self-signature. The trust anchor is just a key and an identifier; its presence in the trust store seems necessary and sufficient to me. > The use of MD4 in NTLM is closely related to its use in > the password database format of computers that > interoperate with NTLM, SMB, CIFS, Microsoft Kerberos > extensions etc. Those password databases and related > protocols will probably outlive NTLM itself by many > years. > The MD4 in the NTLM password hash is unsalted, for extra insecurity. The only real reason to still be using MD4 (by way of the RC4 enctype) in Kerberos is if you need to interoperate with WinXP or Server 2003 machines, but those are not really supported anymore. We are working to get RC4 explicitly deprecated for Kerberos at the IETF. -Ben Kaduk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Nov 13 17:47:05 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 13 Nov 2015 18:47:05 +0100 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56461746.7040808@akamai.com> References: <56460267.1080802@wisemo.com> <56461746.7040808@akamai.com> Message-ID: <56462219.9000501@wisemo.com> On 13/11/2015 18:00, Benjamin Kaduk wrote: > On 11/13/2015 09:31 AM, Jakob Bohm wrote: >> On 13/11/2015 14:40, Emilia K?sper wrote: >>> Hi all, >>> >>> We are considering removing from OpenSSL 1.1 known broken or >>> outdated cryptographic primitives. As you may know the forks have >>> already done this but I'd like to seek careful feedback for OpenSSL >>> first to ensure we won't be breaking any major applications. >>> >>> These algorithms are currently candidates for removal: >>> >>> CAST >>> IDEA >>> MDC2 >>> MD2 [ already disabled by default ] >>> RC5 [ already disabled by default ] >>> RIPEMD >>> SEED >>> WHIRLPOOL >>> ALL BINARY ELLIPTIC CURVES >>> > > I wonder why single-DES is not in the above list. (Maybe because no > one has spoken up as being interested in disentangling triple-DES from > single-DES?) > >>> My preference would be to remove these algorithms completely (as in, >>> delete the code). Disabled-by-default code will either be re-enabled >>> by distros (if there's widespread need for it - in which case we >>> might as well leave it in) or will be poorly tested and is likely to >>> just silently rot and break. This code is bloat and maintentance >>> burden for us - my hope is that much of this code is effectively >>> dead and can be removed. >>> > > My hope as well :) >>> These algorithms are obsolete but removing them doesn't look feasible: >>> >>> BLOWFISH - probably still in use though I don't know where exactly? >>> MD4 - used in NTLM >>> RC2 - used in PKCS#12 >>> > > As another thread calls to mind, PKCS#12 could potentially just use > triple-DES. (BTW, the CMS tests fail when openssl is configured with > no-rc2, due to this; I have a WIP patch sitting around.) > >> MD2 is still present in the self-signature on some major >> root certificates that are still trusted in signatures >> on old/historic data and documents. Note that the >> default OpenSSL code currently skips checking the >> self-signature on self-signed root certificates, but >> that was done based as a workaround for the disabling >> of MD2, and is based on the (unreliable) assumption >> that checking their internal consistency had no value >> in determining the trust. Accepting MD2 only for this >> limited role (and thus keeping the code around for that >> case only) would be more secure. >> > > I am not sure that I agree with the claim that this assumption is > unreliable. There have been some (heated) discussions on the IETF tls > WG list recently regarding the self-signatures on trust anchors, and I > have not seen any compelling arguments there for checking the > self-signature. The trust anchor is just a key and an identifier; its > presence in the trust store seems necessary and sufficient to me. > It is essentially a "proof-of-possession", just like the signature on a CSR. Another way to look at is that it is a consistency check rather than a trust check. One use would be to refuse import of an invalid root CA before even getting to the point of asking the user if she wants to add this certificate to the trusted roots store. Another use would be to detect accidental corruption of the trusted roots store (e.g. from disk I/O errors or partial disk writes during a system crash). >> The use of MD4 in NTLM is closely related to its use in >> the password database format of computers that >> interoperate with NTLM, SMB, CIFS, Microsoft Kerberos >> extensions etc. Those password databases and related >> protocols will probably outlive NTLM itself by many >> years. >> > > The MD4 in the NTLM password hash is unsalted, for extra insecurity. > The only real reason to still be using MD4 (by way of the RC4 enctype) > in Kerberos is if you need to interoperate with WinXP or Server 2003 > machines, but those are not really supported anymore. We are working > to get RC4 explicitly deprecated for Kerberos at the IETF. I have not checked the details, but the fundamental issue is this: Windows domain controller databases store only the unsalted MD4 password hash and/or the historic LM password hash, with most current systems configured to store only the MD4 hash. Thus any protocol that validates user identity via their knowledge of their domain password would need to either transmit the actual password to the domain controller or use some kind of cryptographic calculation where the computer closer to the user proves knowledge of the MD4 hash to the domain controller server. Historically, Microsoft has implemented multiple such cryptographic protocols: NTLMv1 was the oldest such protocol, based on a using DES in a silly way vastly similar to the LM protocol. NTLMv2 was the next version, based mostly on HMAC-MD5, introduced in the late 1990s and still the strongest supported when the client computer is not (yet) joined to the domain. Microsoft-specific variants/profiles of Kerberos V are used between modern (post 2000) domain joined computers and the trusted domain controllers of the users login domain. I have not yet studied which formulas they are currently using/ recommending/planning for this case, but they will all be constrained by the fact that the server knows nothing about the password except its MD4 hash or some value derived therefrom. Any upgrade of the password database to a new format would either involve requesting a different form of the password (encrypted) after a successful MD4 based login or choosing a new form mathematically derived from the MD4 hash, such as foo(HMAC(SHA3-512, salt, MD4(UTF16LE(password)))). New client protocols could challenge with salt and engage in some zero knowledge proof of knowledge of HMAC(SHA3-512, salt, MD4(UTF16LE(password))) . Also note that the inherently low entropy of human-memorable passwords means that there is little security difference between starting from MD4(UTF16LE(password)) and starting from SHA3-1024(UTF8(password)), what matters most is the calculations done on top of that. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 steve at openssl.org Fri Nov 13 18:15:20 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 13 Nov 2015 18:15:20 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56461746.7040808@akamai.com> References: <56460267.1080802@wisemo.com> <56461746.7040808@akamai.com> Message-ID: <20151113181520.GA14277@openssl.org> On Fri, Nov 13, 2015, Benjamin Kaduk wrote: > > As another thread calls to mind, PKCS#12 could potentially just use > triple-DES. (BTW, the CMS tests fail when openssl is configured with > no-rc2, due to this; I have a WIP patch sitting around.) > The issue is that some cuurent software (including major web browsers) still produce PKCS#12 files which include 40 bit RC2 for certificate "encryption" and OpenSSL would fail to decrypt those if it removed RC2. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Fri Nov 13 18:23:35 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 13 Nov 2015 18:23:35 +0000 Subject: [openssl-users] (2013) : PKCS12 keystore creation failing in fips mode (RT3515) In-Reply-To: References: Message-ID: <20151113182335.GA14705@openssl.org> On Wed, Nov 11, 2015, jonetsu wrote: > Hello, > > > There is a thread in 2013 (30 May 03:15) in which Steve writes that OpenSSL 1.0.1 has a bug regarding the use of PKCS12 in FIPS mode since it tries to handle a certificate using a non-FIPS component. ?I think I found the commit that fixes this, although it is part of a quite huge commit of 33,065 lines (7e1b7485706c2b11091b5fa897fe496a2faa56cc) done earlier this year. ? > > > There is perhaps a simpler commit that fixes only this issue (92830dc1ca0bb2d12bf05a12ebb798709595fa5a) although I can't see the commit in the git tree I have fetched last week, even by branching to?remotes/origin/OpenSSL_1_0_1-stable. > > > We are using 1.0.1.e. ?My question is, was bug RT3515 included in a later 1.0.1 release ? ?If so, which one ? > Try commit cdb6c48445ded3daafab32e5f266943d07bb512b Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From noloader at gmail.com Fri Nov 13 18:24:26 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 13 Nov 2015 13:24:26 -0500 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: > ALL BINARY ELLIPTIC CURVES This one may be premature. I understand the TLS WG is moving against it. However, I am aware of implementations of Shoup's ECIES, and they, in turn, depend on OpenSSL. I don't know if the ECIES implementations rely solely on prime fields or not, however. > BLOWFISH - probably still in use though I don't know where exactly? Linux password files and associated tools, like John the Ripper (JtR). OpenSSL is a good toolkit for research purposes. But if research is not a goal, then that's understandable. There are other crypto libraries that include research as a goal. Jeff On Fri, Nov 13, 2015 at 8:40 AM, Emilia K?sper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated > cryptographic primitives. As you may know the forks have already done this > but I'd like to seek careful feedback for OpenSSL first to ensure we won't > be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, delete > the code). Disabled-by-default code will either be re-enabled by distros (if > there's widespread need for it - in which case we might as well leave it in) > or will be poorly tested and is likely to just silently rot and break. This > code is bloat and maintentance burden for us - my hope is that much of this > code is effectively dead and can be removed. > > Are you aware of any mainstream need to continue supporting these algorithms > in OpenSSL 1.1? Note that an older OpenSSL library or binary, or a > standalone implementation or another crypto toolkit can always be used to > continue supporting a legacy standalone application, or to decrypt > ciphertext from the distant past. I am looking for use cases that could > cause e.g. interop breakage between new and old peers, or major pain to > distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > Did I miss anything from the list? From sergiomagra at gmail.com Fri Nov 13 18:50:05 2015 From: sergiomagra at gmail.com (Sergio Magra) Date: Fri, 13 Nov 2015 15:50:05 -0300 Subject: [openssl-users] Protecting RSA keys Message-ID: <00d701d11e44$1e1c8510$5a558f30$@com> Hi everybody, I'm new with OpenSSL and I have some questions. The thing is that several RSA key pairs (each one for a different user) will be stored in a shared secured location (Safenet HSM). As the key pairs will be stored in the same place, we are looking for a way to ensure that one user is able to use only its own key pair, and not the key pair of another user. In this way, I'm thinking on a passphrase to protect the private key, so when the user needs to use its key pair for signing or encrypting, he must provide the passphrase. As he knows its passphrase and not the passphrase of the other key pairs, he is able to use only its own key pair. Until now, the theory. I don't know if I'm right. Supposing that I'm right, I tried to generate protected key pairs, but when using them, I'm never prompted for the passphrase. So, I'm able to use any of the keys created, instead of using only my own key. Can you help me with this issue? Thanks in advance Best regards Sergio Magra -------------- next part -------------- An HTML attachment was scrubbed... URL: From benn.bollay at gmail.com Fri Nov 13 19:21:22 2015 From: benn.bollay at gmail.com (Benn Bollay) Date: Fri, 13 Nov 2015 11:21:22 -0800 Subject: [openssl-users] ECDHE Negotiation for Client but not Server Message-ID: Hi folks - Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications). I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch) that works fine for negotiating ECDHE-* ciphers as a client when talking to an s_server, but fails as a server both when accepting connections from itself or from s_client with a no shared cipher error. You can download a full package to reproduce the issue at http://www.magitech.org/gambit/ecdhetest.tar.gz You can run the test by using make: $ make all $ make s_server & # Run?s OpenSSL s_server in the background $ make t_client # Runs the client - should be able to see the handshake complete on the server?s log window. $ make t_server & # After killing the s_server, start up the test server $ make s_client # Fails to negotiate. Any suggestions? Cheers, --B -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Nov 13 20:31:12 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 13 Nov 2015 20:31:12 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <1cac27a642934febbab78327ba1c9322@usma1ex-dag1mb1.msg.corp.akamai.com> > Rfc5246 basically says that the server will choose the highest version but I wanted to confirm that that's what openssl does (just to be certain). That is what openssl does. From benn.bollay at gmail.com Fri Nov 13 21:41:57 2015 From: benn.bollay at gmail.com (Benn Bollay) Date: Fri, 13 Nov 2015 13:41:57 -0800 Subject: [openssl-users] ECDHE Negotiation for Client but not Server In-Reply-To: References: Message-ID: Sorted; needed to call SSL_CTX_set_tmp_ecdh with my private EC_KEY. Can someone express an opinion if using my private key is acceptable there, or if I should generate a new one from a named curve each time I create a context? Cheers, --B On Fri, Nov 13, 2015 at 11:21 AM, Benn Bollay wrote: > Hi folks - > > Tested against OpenSSL 1.0.1f and 1.0.1p (but with modifications). > > I've got some code that creates an SSL_CTX (http://pastebin.com/XveDvvch) > that works fine for negotiating ECDHE-* ciphers as a client when talking to > an s_server, but fails as a server both when accepting connections from > itself or from s_client with a no shared cipher error. > > You can download a full package to reproduce the issue at > http://www.magitech.org/gambit/ecdhetest.tar.gz > > You can run the test by using make: > > $ make all > > $ make s_server & # Run?s OpenSSL s_server in the background > > $ make t_client # Runs the client - should be able to see the handshake > complete on the server?s log window. > > $ make t_server & # After killing the s_server, start up the test server > > $ make s_client # Fails to negotiate. > > Any suggestions? > Cheers, > --B > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Nov 13 22:21:54 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 13 Nov 2015 17:21:54 -0500 Subject: [openssl-users] FIPS 140-2, a game of chance Message-ID: <56466282.4080103@openssl.com> If you don't know or care what FIPS 140-2 is, trash this message quickly before it harshes your mellow. The "RE" validation, an "Alternative Scenario 1A" clone of the #1747 validation, was approved today (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2473). It was submitted along with its identical twin "RE" validation on April 17. The two sets of paperwork differed in only one trivial aspect, "RE" in the module name for one versus "SE" for the other. Same module, same test lab, same paperwork, submitted together at the same time. We could not have devised a more perfect controlled study if we'd tried. The "SE" validation was approved on June 25 (#2398), after a little more than two months (69 calendar days, 48 working days). The "RE" validation was not approved for almost seven months (210 calendar days, 145 working days). That's three times as long for the exact same submission. I've had the experience for years now of doing very similar validation submissions and noting very different outcomes, but this is the most striking example yet of CMVP capriciousness. Why the wild disparity? Well, probably because the two identical submissions were farmed out to two different reviewers. The review process is notoriously subjective, and in fact we received "comments" (requirements for changes) for the "RE" validation whereas the "SE" one was approved as-is. As a result the two Security Policy documents are no longer identical. That doesn't explain the time discrepancy, though, as those "comments" weren't received until long after "SE" had been approved. The moral here is that FIPS 140-2 validations are a crapshoot; it's impossible to make any reliable predictions on how long any validation action will take or how it will be received. If you have really deep pockets you can submit the same validation multiple times to hedge your bets (we've actually done that[1]), but for most of us it's an open ended gamble: submit, hope, wait, ... -Steve M. [1] See http://veridicalsystems.com/blog/the-fickleness-of-fips/; note that dual submission did pay off for that client. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From hoomanfazaeli at gmail.com Sun Nov 15 10:29:34 2015 From: hoomanfazaeli at gmail.com (Hooman Fazaeli) Date: Sun, 15 Nov 2015 13:59:34 +0330 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <56485E8E.7050702@gmail.com> On 11/13/2015 5:10 PM, Emilia K?sper wrote: > Hi all, > > We are considering removing from OpenSSL 1.1 known broken or outdated cryptographic primitives. As you may know the forks have already done this but I'd like to seek careful feedback for OpenSSL > first to ensure we won't be breaking any major applications. > > These algorithms are currently candidates for removal: > > CAST > IDEA > MDC2 > MD2 [ already disabled by default ] > RC5 [ already disabled by default ] > RIPEMD > SEED > WHIRLPOOL > ALL BINARY ELLIPTIC CURVES > > My preference would be to remove these algorithms completely (as in, delete the code). Disabled-by-default code will either be re-enabled by distros (if there's widespread need for it - in which > case we might as well leave it in) or will be poorly tested and is likely to just silently rot and break. This code is bloat and maintentance burden for us - my hope is that much of this code is > effectively dead and can be removed. > > *Are you aware of any mainstream need to continue supporting these algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary, or a standalone implementation or another crypto toolkit > can always be used to continue supporting a legacy standalone application, or to decrypt ciphertext from the distant past. I am looking for use cases that could cause e.g. interop breakage between > new and old peers, or major pain to distro end-users. > > These algorithms are obsolete but removing them doesn't look feasible: > > BLOWFISH - probably still in use though I don't know where exactly? > MD4 - used in NTLM > RC2 - used in PKCS#12 > > *Did I miss anything from the list?* > > Cheers, > Emilia > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Regarding that hardware accelerationand aes-ni is not yet common among today desktops and mobile devices, rc5 is a very good choice in situations where you need a reasonably secure and yet fast cipher(as 'openssl speed' shows, rc5 is 2.5 times fasterthan aes-128 w/o aes-ni. We developa tunneling appthat uses rc5 for LAN to gateway encryption). So, pls. do no remove rc5. -- Best regards Hooman Fazaeli -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Sun Nov 15 13:30:06 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sun, 15 Nov 2015 19:00:06 +0530 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates Message-ID: Hi All, In earlier version of OpenSSL (i.e OpenSSL 1.0.1c) X509_verify_cert had a check * if (params->trust >0)* before invoking check_trust function. This has been removed in OpenSSL 1.0.2d. Does it mean applications are expected to set the X509_VERIFY_PARAM properly? Our application works fine in OpenSSL 1.0.1c. In OpenSSL 1.0.2d app fails with X509_TRUST_UNTRUSTED error. I added the check *if (params->trust >0) *before invoking the check_trust API and functionality worked fine. Any help on this well appreciated. Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Nov 15 19:56:10 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 15 Nov 2015 19:56:10 +0000 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: References: Message-ID: <20151115195610.GC18315@mournblade.imrryr.org> On Sun, Nov 15, 2015 at 07:00:06PM +0530, Jayalakshmi bhat wrote: > In earlier version of OpenSSL (i.e OpenSSL 1.0.1c) X509_verify_cert had a > check * if (params->trust >0)* before invoking check_trust function. The OpenSSL source code is available via git: https://github.com/openssl/openssl.git The branch containing 1.0.2c and 1.0.2d is "OpenSSL_1_0_2-stable". Can you point to the commit that makes the change in question? > This has been removed in OpenSSL 1.0.2d. Does it mean applications are > expected to set the X509_VERIFY_PARAM properly? I don't see any changes that match your description. -- Viktor. From bhat.jayalakshmi at gmail.com Mon Nov 16 05:14:05 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 16 Nov 2015 10:44:05 +0530 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <20151115195610.GC18315@mournblade.imrryr.org> References: <20151115195610.GC18315@mournblade.imrryr.org> Message-ID: Hi Viktor, Thank you for the response. This is the code snippet from OpenSSL 1.0.2d. int X509_verify_cert(X509_STORE_CTX *ctx) { .................... .................... .................... /* we now have our chain, lets check it... */ i = check_trust(ctx); /* If explicitly rejected error */ if (i == X509_TRUST_REJECTED) goto end; } This is code snippet from OpenSSL 1.0.1c int X509_verify_cert(X509_STORE_CTX *ctx) { .................... .................... .................... /* The chain extensions are OK: check trust */ *if (param->trust > 0)* ok = check_trust(ctx); } I am talking about "*if (param->trust > 0)" *that seems to removed in OpenSSL 1.0.2d. Regards Jayalakshmi On Mon, Nov 16, 2015 at 1:26 AM, Viktor Dukhovni wrote: > On Sun, Nov 15, 2015 at 07:00:06PM +0530, Jayalakshmi bhat wrote: > > > In earlier version of OpenSSL (i.e OpenSSL 1.0.1c) X509_verify_cert > had a > > check * if (params->trust >0)* before invoking check_trust function. > > The OpenSSL source code is available via git: > > https://github.com/openssl/openssl.git > > The branch containing 1.0.2c and 1.0.2d is "OpenSSL_1_0_2-stable". > > Can you point to the commit that makes the change in question? > > > This has been removed in OpenSSL 1.0.2d. Does it mean applications are > > expected to set the X509_VERIFY_PARAM properly? > > I don't see any changes that match your description. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 16 06:10:19 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Nov 2015 01:10:19 -0500 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: References: <20151115195610.GC18315@mournblade.imrryr.org> Message-ID: <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> > On Nov 16, 2015, at 12:14 AM, Jayalakshmi bhat wrote: > > This is code snippet from OpenSSL 1.0.1c > > int X509_verify_cert(X509_STORE_CTX *ctx) { > > .................... > .................... > .................... > /* The chain extensions are OK: check trust */ > > if (param->trust > 0) ok = check_trust(ctx); > } > > I am talking about "if (param->trust > 0)" that seems to removed in OpenSSL 1.0.2d. Well this code was removed in 1.0.2d, rather the code in question was removed via commit d65b8b2162f33ac0d53dace588a0847ed827626c Author: Ben Laurie Date: Fri Dec 14 12:53:53 2012 +0000 Backport OCSP fixes. More than 2 years before the first OpenSSL 1.0.2 release: commit 4ac0329582829f5378d8078c8d314ad37db87736 Author: Matt Caswell Date: Thu Jan 22 16:12:26 2015 +0000 Prepare for 1.0.2 release Reviewed-by: Stephen Henson http://openssl.org/news/newslog.html Date Item 09-Jul-2015 Security Advisory: one security fix 09-Jul-2015 OpenSSL 1.0.2d is now available, including bug and security fixes 09-Jul-2015 OpenSSL 1.0.1p is now available, including bug and security fixes 06-Jul-2015 OpenSSL 1.0.2d and 1.0.1p security releases due 9th July 2015 12-Jun-2015 New releases to resolve ABI compatibility problems: 12-Jun-2015 OpenSSL 1.0.2c is now available, including bug fixes 12-Jun-2015 OpenSSL 1.0.1o is now available, including bug fixes 11-Jun-2015 Security Advisory: five security fixes 11-Jun-2015 OpenSSL 1.0.2b is now available, including bug and security fixes 11-Jun-2015 OpenSSL 1.0.1n is now available, including bug and security fixes 11-Jun-2015 OpenSSL 1.0.0s is now available, including bug and security fixes 11-Jun-2015 OpenSSL 0.9.8zg is now available, including bug and security fixes 19-Mar-2015 Security Advisory: twelve security fixes 19-Mar-2015 OpenSSL 1.0.2a is now available, including bug and security fixes 19-Mar-2015 OpenSSL 1.0.1m is now available, including bug and security fixes 19-Mar-2015 OpenSSL 1.0.0r is now available, including bug and security fixes 19-Mar-2015 OpenSSL 0.9.8zf is now available, including bug and security fixes 22-Jan-2015 OpenSSL 1.0.2 is now available, a major release You should probably explain what you're doing, and in what way OpenSSL 1.0.2 (all upstream versions) is not working the way you expect. -- Viktor. From bhat.jayalakshmi at gmail.com Mon Nov 16 06:52:48 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 16 Nov 2015 12:22:48 +0530 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> Message-ID: Hi Victor, Thanks a lot for details explanation. Our device acts as TLS/SSL client. The device receives chain of certificates as part of SSL handshake, when it is trying to get connected to TLS/SSL server like sharepoint 365. While validating the certificate chain from server, "*check_trust" *fails with X509_V_ERR_CERT_UNTRUSTED. This had been working fine with OpenSSL 1.0.1c. When I checked the code execution, check_trust was not being called in OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. That is why I wanted to know is it mandatory for the applications to set X509_VERIFY_PARAM in X509_STORE_CTX Regards Jayalakshmi On Mon, Nov 16, 2015 at 11:40 AM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > > > On Nov 16, 2015, at 12:14 AM, Jayalakshmi bhat < > bhat.jayalakshmi at gmail.com> wrote: > > > > This is code snippet from OpenSSL 1.0.1c > > > > int X509_verify_cert(X509_STORE_CTX *ctx) { > > > > .................... > > .................... > > .................... > > /* The chain extensions are OK: check trust */ > > > > if (param->trust > 0) ok = check_trust(ctx); > > } > > > > I am talking about "if (param->trust > 0)" that seems to removed in > OpenSSL 1.0.2d. > > Well this code was removed in 1.0.2d, rather the code in question was > removed via > > commit d65b8b2162f33ac0d53dace588a0847ed827626c > Author: Ben Laurie > Date: Fri Dec 14 12:53:53 2012 +0000 > > Backport OCSP fixes. > > More than 2 years before the first OpenSSL 1.0.2 release: > > commit 4ac0329582829f5378d8078c8d314ad37db87736 > Author: Matt Caswell > Date: Thu Jan 22 16:12:26 2015 +0000 > > Prepare for 1.0.2 release > > Reviewed-by: Stephen Henson > > http://openssl.org/news/newslog.html > > Date Item > 09-Jul-2015 Security Advisory: one security fix > 09-Jul-2015 OpenSSL 1.0.2d is now available, including bug and > security fixes > 09-Jul-2015 OpenSSL 1.0.1p is now available, including bug and > security fixes > 06-Jul-2015 OpenSSL 1.0.2d and 1.0.1p security releases due 9th July > 2015 > 12-Jun-2015 New releases to resolve ABI compatibility problems: > 12-Jun-2015 OpenSSL 1.0.2c is now available, including bug fixes > 12-Jun-2015 OpenSSL 1.0.1o is now available, including bug fixes > 11-Jun-2015 Security Advisory: five security fixes > 11-Jun-2015 OpenSSL 1.0.2b is now available, including bug and > security fixes > 11-Jun-2015 OpenSSL 1.0.1n is now available, including bug and > security fixes > 11-Jun-2015 OpenSSL 1.0.0s is now available, including bug and > security fixes > 11-Jun-2015 OpenSSL 0.9.8zg is now available, including bug and > security fixes > 19-Mar-2015 Security Advisory: twelve security fixes > 19-Mar-2015 OpenSSL 1.0.2a is now available, including bug and > security fixes > 19-Mar-2015 OpenSSL 1.0.1m is now available, including bug and > security fixes > 19-Mar-2015 OpenSSL 1.0.0r is now available, including bug and > security fixes > 19-Mar-2015 OpenSSL 0.9.8zf is now available, including bug and > security fixes > 22-Jan-2015 OpenSSL 1.0.2 is now available, a major release > > You should probably explain what you're doing, and in what way OpenSSL > 1.0.2 > (all upstream versions) is not working the way you expect. > > -- > Viktor. > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 16 07:05:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Nov 2015 07:05:45 +0000 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> Message-ID: <20151116070545.GG18315@mournblade.imrryr.org> On Mon, Nov 16, 2015 at 01:10:19AM -0500, Viktor Dukhovni wrote: > > You should probably explain what you're doing, and in what way OpenSSL 1.0.2 > > (all upstream versions) is not working the way you expect. On Mon, Nov 16, 2015 at 12:22:48PM +0530, Jayalakshmi bhat wrote: > Our device acts as TLS/SSL client. The device receives chain of > certificates as part of SSL handshake, when it is trying to get connected > to TLS/SSL server like sharepoint 365. This is not a plausibly detailed explanation of how you're using OpenSSL in your device. > While validating the certificate chain from server, "*check_trust" *fails > with X509_V_ERR_CERT_UNTRUSTED. OpenSSL 1.0.2 is broadly used, with no similar problem reports. You're probably doing something atypical, and need to explain in technical detail how you're configuring certificate verification. > This had been working fine with OpenSSL 1.0.1c. You can download http://openssl.org/source/old/1.0.2/openssl-1.0.2c.tar.gz for yourself and check that the code you claim to make the difference is simply not there. If 1.0.2c is working and 1.0.2d is not, either you're using a modified 1.0.2c (seek support from whoever made the changes) or the problem lies elsewhere. > When I checked the code execution, check_trust was not being called in > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. This is simply irrelevant, the change in question predates the 1.0.2 base version. > That is why I wanted to know is it mandatory for the applications to > set X509_VERIFY_PARAM in X509_STORE_CTX The question has a false premise and so makes no sense. Rather you need to forget about (param->trust) and focus on why your application is failing to verify the peer certificate. -- Viktor. From bhat.jayalakshmi at gmail.com Mon Nov 16 07:23:08 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 16 Nov 2015 12:53:08 +0530 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <20151116070545.GG18315@mournblade.imrryr.org> References: <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> <20151116070545.GG18315@mournblade.imrryr.org> Message-ID: Hi Victor, First thing kindly note that I am talking about *OpenSSL-1.0.1c* not about OpenSSL 1.0.2c. So far we were using *OpenSSL-1.0.1c* and server validation was working fine. Recently we upgraded the OpenSSL library to *OpenSSL-1.0.2d. * Also we have not done any modification to the SSL client application that is using the OpenSSL library. We started seeing server certificate validation failures only for chain of certificate i.e. roota->intermediate ca->id certificate. We are not seeing any issues when only rootca->cerificate is used. Regards Jayalakshmi Regards Jayalakshmi On Mon, Nov 16, 2015 at 12:35 PM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > On Mon, Nov 16, 2015 at 01:10:19AM -0500, Viktor Dukhovni wrote: > > > > You should probably explain what you're doing, and in what way OpenSSL > 1.0.2 > > > (all upstream versions) is not working the way you expect. > > On Mon, Nov 16, 2015 at 12:22:48PM +0530, Jayalakshmi bhat wrote: > > > Our device acts as TLS/SSL client. The device receives chain of > > certificates as part of SSL handshake, when it is trying to get connected > > to TLS/SSL server like sharepoint 365. > > This is not a plausibly detailed explanation of how you're using > OpenSSL in your device. > > > While validating the certificate chain from server, "*check_trust" *fails > > with X509_V_ERR_CERT_UNTRUSTED. > > OpenSSL 1.0.2 is broadly used, with no similar problem reports. > You're probably doing something atypical, and need to explain in > technical detail how you're configuring certificate verification. > > > This had been working fine with OpenSSL 1.0.1c. > > You can download http://openssl.org/source/old/1.0.2/openssl-1.0.2c.tar.gz > for yourself and check that the code you claim to make the difference > is simply not there. If 1.0.2c is working and 1.0.2d is not, either > you're using a modified 1.0.2c (seek support from whoever made the > changes) or the problem lies elsewhere. > > > When I checked the code execution, check_trust was not being called in > > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > This is simply irrelevant, the change in question predates the > 1.0.2 base version. > > > That is why I wanted to know is it mandatory for the applications to > > set X509_VERIFY_PARAM in X509_STORE_CTX > > The question has a false premise and so makes no sense. Rather > you need to forget about (param->trust) and focus on why your > application is failing to verify the peer certificate. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 16 09:22:38 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Nov 2015 09:22:38 +0000 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> Message-ID: <5649A05E.1030101@openssl.org> On 16/11/15 06:52, Jayalakshmi bhat wrote: > Hi Victor, > > Thanks a lot for details explanation. > > Our device acts as TLS/SSL client. The device receives chain of > certificates as part of SSL handshake, when it is trying to get > connected to TLS/SSL server like sharepoint 365. > > While validating the certificate chain from server, "*check_trust" > *fails with X509_V_ERR_CERT_UNTRUSTED. > > This had been working fine with OpenSSL 1.0.1c. > > When I checked the code execution, check_trust was not being called in > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > That is why I wanted to know is it mandatory for the applications to > set X509_VERIFY_PARAM in X509_STORE_CTX Are you able to share the certificates that the server provides you with? Also the root certificate you are using. It is not mandatory to set X509_VERIFY_PARAMs (but typically you at least want to verify the hostname through a call to "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this? Matt From noadsplease at web.de Mon Nov 16 10:51:13 2015 From: noadsplease at web.de (Dirk Menstermann) Date: Mon, 16 Nov 2015 11:51:13 +0100 Subject: [openssl-users] Available ciphers In-Reply-To: <564216A7.1010206@web.de> References: <564216A7.1010206@web.de> Message-ID: <5649B521.2020300@web.de> Anybody able to help? Thanks Dirk On 10.11.2015 17:09, Dirk Menstermann wrote: > Hi, > > I'm using openssl 1.0.2 (as web server application) and utilize the APLN > callback to react on protocols offered by the client. In this callback I need a > way to get the list of ciphers that the client sends within the client_hello. > > Background is that http2 should only be negotiated if client supports > "ECDHE-RSA-AES128-GCM-SHA256" (like Firefox). Any idea how I can get this > information? > > Thanks a lot > Dirk > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From sebastian.stolzenberg at secusmart.de Wed Nov 4 11:34:22 2015 From: sebastian.stolzenberg at secusmart.de (Sebastian Stolzenberg) Date: Wed, 4 Nov 2015 11:34:22 +0000 (UTC) Subject: [openssl-users] Incompatibility between OpenSSL 1.0.2 and FIPS 2.0.10 Message-ID: Hi, I am seeing crashes in OpenSSL 1.0.2d when using it with the FIPS 2.0.10 object module. Apparently the size of struct ec_group_st (in crypto/ec/ec_lcl.h) differs between 1.0.1 and 1.0.2, since BN_MONT_CTX *mont_data; /* data for ECDSA inverse */ has been added to it. The FIPS module still uses the 1.0.1 version of struct ec_group. That leads to crashes when ownership is transferred between the FIPS module and OpenSSL. I.e. when an ec_group object is allocated by the FIPS version of EC_GROUP_new and then destroyed by the OpenSSL variant of OPENSSL_free. Am I using the FIPS object module wrongly or is not compatible to OpenSSL 1.0.2 when it comes to EC crytpography? If 1.0.2 is not supported by FIPS 2.0.10, are there any plans to get another, compatible version of the FIPS object module validated? Thanks! Sebastian From emilia at openssl.org Mon Nov 16 15:51:10 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 16 Nov 2015 16:51:10 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: Thanks all for your feedback! I asked for mainstream use-cases for algorithms whose removal could cause widespread pain. Some individual users, undoubtedly, will be hit by this, and I acknowledge that they may not be reading this list. But I wanted to know if I'd missed something endemic. I also asked elsewhere: Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 must stay. There is a tradeoff: by attempting to accommodate every single use-case, we will weaken the library for a substantial amount of our user base, by offering them bad defaults, or simply by virtue of the fact that our developer resources are not infinite. (Near)-dead code is a liability. So far, excluding suspicions that something may be used somewhere, I've received one clear argument, for RC5. And, while I'm sympathetic to the cause, I believe this is the case where we have to balance one user's needs against everyone else's. As for specific deprecation strategies: - Don't forget that all applications will have to recompile against 1.1. - Disabling algorithms doesn't work well for us as it's just pushing the decision on the distros. It also wouldn't win us any resources as we'd still be responsible for keeping the code bug-free. The only win would be in default compiled code size. - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python, PHP etc) who correctly account for the fact that an implementation may be missing (which they have to, anyway) will continue to work. - Removing assembly support is a GREAT suggestion to simplify the complexity, and I think we should do this for anything we end up leaving in, and perhaps even for some things not yet on the hit list (RC4?). - I appreciate OpenSSL's role as a "Swiss army knife" research tool but research needs shouldn't prevail over those of real applications. We are generally not on the frontline of deprecating things - RC4 isn't yet on the list. SSLv3 isn't yet on the list, etc. But we can't become the Internet Archive of All Old Crypto either, and there's some cleanup to do that's long overdue. - I believe that the OpenSSL community generally tends to overlook the positive impact of change when trying to round up the negative impact of breakage. Applications are generally able to move along and fix things when presented with the right incentives. Applications that aren't generally able to move along are rather unlikely to jump onto OpenSSL 1.1, and all these algorithms will be supported as part of OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these algorithms from OpenSSL doesn't render your encrypted storage inaccessible. You can always use another implementation to decrypt/re-encrypt your data, and I fully believe in the power of the community in providing such tools where necessary. - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty widespread MySQL breakage. That made MySQL backport a change increasing the DH key length from 512 to 2048 bits. For end user security, it's a win. I would prefer that we start cashing in these improvements before the next Logjam happens. (This is my view; as you can see views differ even within the team.) - On binary elliptic curves: with recent cryptographic advances, I believe these are now firmly planted in the "internet archive" category, even if not practically broken yet. The other reason for removing these is that our implementations are crappy. They're not constant-time, and they've been shown to contain bugs. Improving upon these implementations is not a good use of dev time imo, given their decreasing credibility. Here's the list of algorithms gone from BoringSSL: IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves This isn't of course entirely representative of widespread usage. However Google's multi-billion line codebase now builds against BoringSSL and therefore largely does not depend on these algorithms. Those billions of lines aren't all new and shiny code written in 2015, and some of it does have to interoperate with the outside world. And here's the list gone from LibreSSL, from what I can tell: MD2, MDC2, RC5, SEED Neither have removed CAST, and there is presumably a good reason for that. (PGP?) It seems to me that these can pretty safely go: MD2 - (The argument that someone somewhere may want to keep verifying old MD2 signatures on self-signed certs doesn't seem like a compelling enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) MDC2 SEED RC5 These could probably stay (C only): CAST IDEA RIPEMD (used in Bitcoin?) WHIRLPOOL as well as BLOWFISH MD4 RC2 I am on the fence about the binary curves: I am not aware of any usage, really, and it's not about to pick up now. Cheers, Emilia On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario wrote: > On Friday 13 November 2015 14:40:33 Emilia K?sper wrote: > > Hi all, > > > > We are considering removing from OpenSSL 1.1 known broken or outdated > > cryptographic primitives. As you may know the forks have already done > > this but I'd like to seek careful feedback for OpenSSL first to > > ensure we won't be breaking any major applications. > > > > These algorithms are currently candidates for removal: > > > > CAST > > IDEA > > MDC2 > > MD2 [ already disabled by default ] > > RC5 [ already disabled by default ] > > RIPEMD > > SEED > > WHIRLPOOL > > ALL BINARY ELLIPTIC CURVES > > > > My preference would be to remove these algorithms completely (as in, > > delete the code). Disabled-by-default code will either be re-enabled > > by distros (if there's widespread need for it - in which case we > > might as well leave it in) or will be poorly tested and is likely to > > just silently rot and break. This code is bloat and maintentance > > burden for us - my hope is that much of this code is effectively dead > > and can be removed. > > > > *Are you aware of any mainstream need to continue supporting these > > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > > binary, or a standalone implementation or another crypto toolkit can > > always be used to continue supporting a legacy standalone > > application, or to decrypt ciphertext from the distant past. I am > > looking for use cases that could cause e.g. interop breakage between > > new and old peers, or major pain to distro end-users. > > > > These algorithms are obsolete but removing them doesn't look feasible: > > > > BLOWFISH - probably still in use though I don't know where exactly? > > MD4 - used in NTLM > > RC2 - used in PKCS#12 > > > > *Did I miss anything from the list?* > > I'd say that this is the wrong approach. > > If you have old stuff signed with MD2, and then timestamped with MD5, > SHA-1, SHA-256 over the years, with new timestamp added every year this > makes the MD2 signature _valid_ and _secure_. > > If you have stuff that is encrypted, but in deep storage with any of > those algorithms, then yes, it's less than optimal. Removing support for > those algorithm will make this data inaccessible. Not to mention that > stuff like IDEA or SEED may never get broken before the data in them > needs to remain secret - and after that creating a new archive with > unencrypted data after it can become public would simply cost money. > > And as some pointed out, few OpenSSL users actually read mailing lists, > fewer still know what actual primitives are necessary for their stuff to > work (e.g. PKCS#8 files specify inside them the cipher and key > derivation necessary for decryption). > > > What I think is the correct course of action, is to have in the > configuration file settings which specify the set of algorithms that are > set as available and trusted. So that we can disable them by default and > require the users to make a concious decision to enable support for > them. (Make openssl print to stderr info about them being > administratively disabled when application tries using them for bonus > points). > > This allows to place the information about this depreciation in a place > where users will actually see it and will make them concious of using > weak and badly tested algorithms. At the same time it will protect most > of the users that don't require such obsolete algorithms. > > But this concious decision MUST NOT require recompilation of the > package. Few if any distributions support recompiled packages. For many > end-users this is also a hurdle they simply can't cross. > > And this also allows openssl to change the cryptographic policy in > stable branches without breaking the API/ABI promise. (POODLE, FREAK, > Logjam) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Nov 16 16:09:28 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 16 Nov 2015 16:09:28 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <20151116160928.GK18315@mournblade.imrryr.org> On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia K?sper wrote: > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1. The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces remain, so nothing changes at compile-time. Most code does not use EVP_() directly. This means that: * Most errors are not caught at compile time. * Porting is not the difficult part, the much more difficult problem is dealing with runtime access to any algorithms needed to handle data at rest. > - Disabling algorithms doesn't work well for us as it's just pushing the > decision on the distros. It also wouldn't win us any resources as we'd > still be responsible for keeping the code bug-free. The only win would be > in default compiled code size. Removing assembly support would substantially lower support cost. For many of the algorithms we can likely find a reference implementation in an RFC or similar standards document, if our own code is substantially more refined (and requires greater support effort). > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python, > PHP etc) who correctly account for the fact that an implementation may be > missing (which they have to, anyway) will continue to work. These don't help with EVP "by name" indirection. > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up leaving > in, and perhaps even for some things not yet on the hit list (RC4?). Yes, and probably. > - I appreciate OpenSSL's role as a "Swiss army knife" research tool but > research needs shouldn't prevail over those of real applications. We are > generally not on the frontline of deprecating things - RC4 isn't yet on the > list. SSLv3 isn't yet on the list, etc. But we can't become the Internet > Archive of All Old Crypto either, and there's some cleanup to do that's > long overdue. Researchers can indeed use older toolkits, my concern is real users, with non-SSL applications (data at rest). > - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty > widespread MySQL breakage. That made MySQL backport a change increasing the > DH key length from 512 to 2048 bits. For end user security, it's a win. I > would prefer that we start cashing in these improvements before the next > Logjam happens. (This is my view; as you can see views differ even within > the team.) This is SSL/TLS where we have algorithm agility. I support the Logjam changes. It is likely time for us to take the next (not final) step from 768 to 1024 as the min prime size. > - On binary elliptic curves: with recent cryptographic advances, I believe > these are now firmly planted in the "internet archive" category, even if > not practically broken yet. The other reason for removing these is that our > implementations are crappy. They're not constant-time, and they've been > shown to contain bugs. Improving upon these implementations is not a good > use of dev time imo, given their decreasing credibility. I agree they need to go from SSL/TLS. What about S/MIME and CMS? > Here's the list of algorithms gone from BoringSSL: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves Boring SSL has a very narrow user base. By all means drop as much as you can get away with. > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED Likewise, not a wide user base. We can make incremental steps, drop assembly support and SSL/TLS codepoints in this release, and assess things from there. My hope is that the support cost of a stable reference implementation in C (yes, likely not constant time) is not that onerous. -- Viktor. From jb-openssl at wisemo.com Mon Nov 16 16:34:41 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 16 Nov 2015 17:34:41 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <564A05A1.30008@wisemo.com> On 16/11/2015 16:51, Emilia K?sper wrote: > Thanks all for your feedback! > > I asked for mainstream use-cases for algorithms whose removal could > cause widespread pain. Some individual users, undoubtedly, will be hit > by this, and I acknowledge that they may not be reading this list. But > I wanted to know if I'd missed something endemic. I also asked > elsewhere: Adam Langley pointed me to the MD4 use-case and Steve > confirmed that RC2 must stay. > > There is a tradeoff: by attempting to accommodate every single > use-case, we will weaken the library for a substantial amount of our > user base, by offering them bad defaults, or simply by virtue of the > fact that our developer resources are not infinite. (Near)-dead code > is a liability. > > So far, excluding suspicions that something may be used somewhere, > I've received one clear argument, for RC5. And, while I'm sympathetic > to the cause, I believe this is the case where we have to balance one > user's needs against everyone else's. > > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1. > > - Disabling algorithms doesn't work well for us as it's just pushing > the decision on the distros. It also wouldn't win us any resources as > we'd still be responsible for keeping the code bug-free. The only win > would be in default compiled code size. > > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries > (Python, PHP etc) who correctly account for the fact that an > implementation may be missing (which they have to, anyway) will > continue to work. > > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up > leaving in, and perhaps even for some things not yet on the hit list > (RC4?). > > - I appreciate OpenSSL's role as a "Swiss army knife" research tool > but research needs shouldn't prevail over those of real applications. > We are generally not on the frontline of deprecating things - RC4 > isn't yet on the list. SSLv3 isn't yet on the list, etc. But we can't > become the Internet Archive of All Old Crypto either, and there's some > cleanup to do that's long overdue. There is also the point that OpenSSL is the worlds most well known "Swiss army knife" crypto package for non-research uses. The more you overfocus on the single SSL/TLS use case, the less attractive OpenSSL becomes to all other uses. If OpenSSL makes itself useless, others will have to reinvent it. > > - I believe that the OpenSSL community generally tends to overlook the > positive impact of change when trying to round up the negative impact > of breakage. Applications are generally able to move along and fix > things when presented with the right incentives. Applications that > aren't generally able to move along are rather unlikely to jump onto > OpenSSL 1.1, and all these algorithms will be supported as part of > OpenSSL 1.0.2 until 2020 for them. Finally, removing support for these > algorithms from OpenSSL doesn't render your encrypted storage > inaccessible. You can always use another implementation to > decrypt/re-encrypt your data, and I fully believe in the power of the > community in providing such tools where necessary. > > - Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty > widespread MySQL breakage. That made MySQL backport a change > increasing the DH key length from 512 to 2048 bits. For end user > security, it's a win. I would prefer that we start cashing in these > improvements before the next Logjam happens. (This is my view; as you > can see views differ even within the team.) The Logjam protection was an SSL-only change. It has NO relevance to the deleterious effects of crippling the non-SSL functionality in the OpenSSL libraries. > > - On binary elliptic curves: with recent cryptographic advances, I > believe these are now firmly planted in the "internet archive" > category, even if not practically broken yet. The other reason for > removing these is that our implementations are crappy. They're not > constant-time, and they've been shown to contain bugs. Improving upon > these implementations is not a good use of dev time imo, given their > decreasing credibility. > > Here's the list of algorithms gone from BoringSSL: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > This isn't of course entirely representative of widespread usage. > However Google's multi-billion line codebase now builds against > BoringSSL and therefore largely does not depend on these algorithms. > Those billions of lines aren't all new and shiny code written in 2015, > and some of it does have to interoperate with the outside world. > > And here's the list gone from LibreSSL, from what I can tell: > > MD2, MDC2, RC5, SEED > > Neither have removed CAST, and there is presumably a good reason for > that. (PGP?) > > It seems to me that these can pretty safely go: > > MD2 - (The argument that someone somewhere may want to keep verifying > old MD2 signatures on self-signed certs doesn't seem like a compelling > enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) Please read my description again. I was arguing that the disabling of signature checking done in OpenSSL 1.0.0 was a mistake and is really a security-weakening bug. As that bug is fixed (by reinstating, in general, the checking of the self-signature on root certificates), the problem with MD2 being disabled completely (rather than being marked as untrusted) will resurface, at least for data at rest (prime *example* is CMS signed e-mail and files signed with certificates that trace back to the original Verisign root). > MDC2 > SEED > RC5 > > These could probably stay (C only): > > CAST > IDEA > RIPEMD (used in Bitcoin?) > WHIRLPOOL > > as well as > > BLOWFISH > MD4 > RC2 > > I am on the fence about the binary curves: I am not aware of any > usage, really, and it's not about to pick up now. > > Cheers, > Emilia > > On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario > wrote: > > On Friday 13 November 2015 14:40:33 Emilia K?sper wrote: > > Hi all, > > > > We are considering removing from OpenSSL 1.1 known broken or > outdated > > cryptographic primitives. As you may know the forks have already > done > > this but I'd like to seek careful feedback for OpenSSL first to > > ensure we won't be breaking any major applications. > > > > These algorithms are currently candidates for removal: > > > > CAST > > IDEA > > MDC2 > > MD2 [ already disabled by default ] > > RC5 [ already disabled by default ] > > RIPEMD > > SEED > > WHIRLPOOL > > ALL BINARY ELLIPTIC CURVES > > > > My preference would be to remove these algorithms completely (as in, > > delete the code). Disabled-by-default code will either be re-enabled > > by distros (if there's widespread need for it - in which case we > > might as well leave it in) or will be poorly tested and is likely to > > just silently rot and break. This code is bloat and maintentance > > burden for us - my hope is that much of this code is effectively > dead > > and can be removed. > > > > *Are you aware of any mainstream need to continue supporting these > > algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or > > binary, or a standalone implementation or another crypto toolkit can > > always be used to continue supporting a legacy standalone > > application, or to decrypt ciphertext from the distant past. I am > > looking for use cases that could cause e.g. interop breakage between > > new and old peers, or major pain to distro end-users. > > > > These algorithms are obsolete but removing them doesn't look > feasible: > > > > BLOWFISH - probably still in use though I don't know where exactly? > > MD4 - used in NTLM > > RC2 - used in PKCS#12 > > > > *Did I miss anything from the list?* > > I'd say that this is the wrong approach. > > If you have old stuff signed with MD2, and then timestamped with MD5, > SHA-1, SHA-256 over the years, with new timestamp added every year > this > makes the MD2 signature _valid_ and _secure_. > > If you have stuff that is encrypted, but in deep storage with any of > those algorithms, then yes, it's less than optimal. Removing > support for > those algorithm will make this data inaccessible. Not to mention that > stuff like IDEA or SEED may never get broken before the data in them > needs to remain secret - and after that creating a new archive with > unencrypted data after it can become public would simply cost money. > > And as some pointed out, few OpenSSL users actually read mailing > lists, > fewer still know what actual primitives are necessary for their > stuff to > work (e.g. PKCS#8 files specify inside them the cipher and key > derivation necessary for decryption). > > > What I think is the correct course of action, is to have in the > configuration file settings which specify the set of algorithms > that are > set as available and trusted. So that we can disable them by > default and > require the users to make a concious decision to enable support for > them. (Make openssl print to stderr info about them being > administratively disabled when application tries using them for bonus > points). > > This allows to place the information about this depreciation in a > place > where users will actually see it and will make them concious of using > weak and badly tested algorithms. At the same time it will protect > most > of the users that don't require such obsolete algorithms. > > But this concious decision MUST NOT require recompilation of the > package. Few if any distributions support recompiled packages. For > many > end-users this is also a hurdle they simply can't cross. > > And this also allows openssl to change the cryptographic policy in > stable branches without breaking the API/ABI promise. (POODLE, FREAK, > Logjam) > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 bhat.jayalakshmi at gmail.com Mon Nov 16 16:48:01 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 16 Nov 2015 22:18:01 +0530 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <5649A05E.1030101@openssl.org> References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> <5649A05E.1030101@openssl.org> Message-ID: Hi Matt, Thank you for the response. I have attached the certificates details. My apology I am not supposed to share the certificates. We are not using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with the device. 1. Root CA- Baltimore CyberTrust Root 2. Intermediate CA-1 - Microsoft Internet Authority 3. Intermediate CA-2 - Microsoft IT SSL SHA2 4. ID certificate - *.sharepoint.com Intermediate CAs are issued by the above Root CA. Issue is seen when all 4 certificates are installed. Error happens with the intermediate CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not install intermediate CA-2 things works fine. Any help is well appreciated. Regards Jayalakshmi On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell wrote: > > > On 16/11/15 06:52, Jayalakshmi bhat wrote: > > Hi Victor, > > > > Thanks a lot for details explanation. > > > > Our device acts as TLS/SSL client. The device receives chain of > > certificates as part of SSL handshake, when it is trying to get > > connected to TLS/SSL server like sharepoint 365. > > > > While validating the certificate chain from server, "*check_trust" > > *fails with X509_V_ERR_CERT_UNTRUSTED. > > > > This had been working fine with OpenSSL 1.0.1c. > > > > When I checked the code execution, check_trust was not being called in > > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > > > That is why I wanted to know is it mandatory for the applications to > > set X509_VERIFY_PARAM in X509_STORE_CTX > > > Are you able to share the certificates that the server provides you > with? Also the root certificate you are using. > > It is not mandatory to set X509_VERIFY_PARAMs (but typically you at > least want to verify the hostname through a call to > "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this? > > Matt > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ID CERTIFICATE Version 3 Serial Number 4F 5D 8E A9 00 01 00 00 D8 6F Signature Algorithm sha1RSA Issuer DC=com DC=microsoft DC=corp DC=redmond CN=MSIT Machine Auth CA 2 Valid From 4/14/2014 10:01:07 PM UTC Valid To 4/13/2016 10:01:07 PM UTC Subject C=US S=WA L=Redmond O=Microsoft CN=*.sharepoint.com Public Key Public Key Algorithm RSA Public Key Length 2048 bits Exponent 65537 (10001) Extensions Authority Key Identifier KeyID=EB DB 11 5E F8 09 9E D8 D6 62 9C FD 62 9D E3 84 4A 28 E1 27 Subject Key Identifier F5 D0 5C 03 01 C3 D9 31 56 24 3F BF 26 4F 04 A7 D8 3C B3 CE Basic Constraints Key Usage Data Encipherment (b0), Digital Signature, Key Encipherment (a0) Extended Key Usage Client Authentication, Server Authentication Additional Extensions Subject Alternative Name, CRL Distribution Points Subject Alternative Name *.sharepoint.com *.sharepoint.apac.microsoftonline.com *.sharepoint.emea.microsoftonline.com *.sharepoint.microsoftonline.com Thumbprint 3D A0 FF 58 AF 96 A0 BE 01 BB 7E 05 65 7C D7 89 27 F9 52 98 INTERMEDIATE CA-1 Version 3 Serial Number 07 27 6F AE Signature Algorithm sha1RSA Issuer C=IE O=Baltimore OU=CyberTrust CN=Baltimore CyberTrust Root Valid From 4/25/2012 5:41:36 PM UTC Valid To 4/25/2020 5:40:55 PM UTC Subject CN=Microsoft Internet Authority Public Key Public Key Algorithm RSA Public Key Length 4096 bits Exponent 65537 (10001) Extensions Authority Key Identifier KeyID=E5 9D 59 30 82 47 58 CC AC FA 08 54 36 86 7B 3A B5 04 4D F0 Subject Key Identifier 2A 4D 97 95 5D 34 7E 9D B6 E6 33 BE 9C 27 C1 70 7E 67 DB C1 Basic Constraints critical CA: True Key Usage Certificate Signing, CRL Signing (86), Digital Signature, Off-line CRL Signing Extended Key Usage Additional Extensions Certificate Policies, CRL Distribution Points Subject Alternative Name Thumbprint 99 2A D4 4D 7D CE 29 8D E1 7E 6F 2F 56 A7 B9 CA A4 1D B9 3F INTERMEDIATE CA-2 Version 3 Serial Number 07 27 9A A9 Signature Algorithm sha256RSA Issuer C=IE O=Baltimore OU=CyberTrust CN=Baltimore CyberTrust Root Valid From 12/19/2013 8:07:32 PM UTC Valid To 12/19/2017 8:06:55 PM UTC Subject C=US S=Washington L=Redmond O=Microsoft Corporation OU=Microsoft IT CN=Microsoft IT SSL SHA2 Public Key Public Key Algorithm RSA Public Key Length 4096 bits Exponent 65537 (10001) Extensions Authority Key Identifier KeyID=E5 9D 59 30 82 47 58 CC AC FA 08 54 36 86 7B 3A B5 04 4D F0 Subject Key Identifier 51 AF 24 26 9C F4 68 22 57 80 26 2B 3B 46 62 15 7B 1E CC A5 Basic Constraints critical CA: True Key Usage Certificate Signing, CRL Signing (86), Digital Signature, Off-line CRL Signing Extended Key Usage Client Authentication, Server Authentication Additional Extensions Certificate Policies, CRL Distribution Points Subject Alternative Name Thumbprint 94 8E 16 52 58 62 40 D4 53 28 7A B6 9C AE B8 F2 F4 F0 21 17 ROOT CA Version 3 Serial Number 02 00 00 B9 Signature Algorithm sha1RSA Issuer C=IE O=Baltimore OU=CyberTrust CN=Baltimore CyberTrust Root Valid From 5/12/2000 6:46:00 PM UTC Valid To 5/12/2025 11:59:00 PM UTC Subject C=IE O=Baltimore OU=CyberTrust CN=Baltimore CyberTrust Root Public Key Public Key Algorithm RSA Public Key Length 2048 bits Exponent 65537 (10001) Extensions Authority Key Identifier Subject Key Identifier E5 9D 59 30 82 47 58 CC AC FA 08 54 36 86 7B 3A B5 04 4D F0 Basic Constraints critical CA: True Key Usage Certificate Signing, Off-line CRL Signing Extended Key Usage Additional Extensions Subject Alternative Name Thumbprint D4 DE 20 D0 5E 66 FC 53 FE 1A 50 88 2C 78 DB 28 52 CA E4 74 From emilia at openssl.org Mon Nov 16 18:51:08 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 16 Nov 2015 19:51:08 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> Message-ID: One more time, I know that someone, somewhere is probably using any given feature of OpenSSL. I am looking to gather information about concrete, actively maintained applications that may be using one of those algorithms, to build a more complete picture. If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know! Thanks, Emilia On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario wrote: > On Monday 16 November 2015 16:51:10 Emilia K?sper wrote: > > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves > > > > This isn't of course entirely representative of widespread usage. > > However Google's multi-billion line codebase now builds against > > BoringSSL and therefore largely does not depend on these algorithms. > > Those billions of lines aren't all new and shiny code written in > > 2015, and some of it does have to interoperate with the outside > > world. > > > > And here's the list gone from LibreSSL, from what I can tell: > > > > MD2, MDC2, RC5, SEED > > > > Neither have removed CAST, and there is presumably a good reason for > > that. (PGP?) > > > > It seems to me that these can pretty safely go: > > > > MD2 - (The argument that someone somewhere may want to keep verifying > > old MD2 signatures on self-signed certs doesn't seem like a > > compelling enough reason to me. It's been disabled by default since > > OpenSSL 1.0.0.) MDC2 > > SEED > > RC5 > > > > These could probably stay (C only): > > > > CAST > > IDEA > > RIPEMD (used in Bitcoin?) > > WHIRLPOOL > > > > as well as > > > > BLOWFISH > > MD4 > > RC2 > > > > I am on the fence about the binary curves: I am not aware of any > > usage, really, and it's not about to pick up now. > > I'm afraid you're too focused on TLS/SSL use case. And while it is > important it's not the only use case the OpenSSL does serve. > > And for what it's worth, I'm very much *for* removing as much (and as > fast as possible) support for the old junk (or unused stuff - like > curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT > cipher set" for an example. > > But stuff like this: > > > The argument that someone somewhere may want to keep verifying > > old MD2 signatures on self-signed certs > > is not true. I was talking about document signatures, time stamps, CRL > signatures and certificate signatures in general. Not the trust anchors > or their self-signatures. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Mon Nov 16 20:28:01 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 16 Nov 2015 20:28:01 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> References: <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> <2923076.EjhxOnJbK2@pintsize.usersys.redhat.com> Message-ID: On 16 November 2015 at 19:05, Hubert Kario wrote: > Example: CAdES V1.2.2 was published in late 2000, the first serious > attacks on MD2 were not published until 2004. I think it is not > unreasonable for CAdES-A documents to exist today which were originally > signed with MD2 while it was still considered secure and that are still > relevant today, just 15 years later. > > ?This doesn't explain why the code needs to exist in future versions of openssl. The previous ones aren't going to vanish and can be compiled and used to rescue data in theoretical edge cases like this. You're making it sound like this is making the data totally inaccessible which is not the case. Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From etksubs at gmail.com Mon Nov 16 21:37:02 2015 From: etksubs at gmail.com (E T) Date: Mon, 16 Nov 2015 16:37:02 -0500 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> <5649A05E.1030101@openssl.org> Message-ID: <00EEC723-F129-4B6D-BB07-5EB350440A5C@gmail.com> Could it be because your CA-2 has the following: Extended Key Usage - Client Authentication, Server Authentication? Some fields that in general only apply to end certificates, e.g. name constraints, when used in a CA certificate, are interpreted as constraints on the certificates that can be issued by that CA. Erik Tkal On Nov 16, 2015, at 11:48 AM, Jayalakshmi bhat wrote: Hi Matt, Thank you for the response. I have attached the certificates details. My apology I am not supposed to share the certificates. We are not using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with the device. 1. Root CA- Baltimore CyberTrust Root 2. Intermediate CA-1 - Microsoft Internet Authority 3. Intermediate CA-2 - Microsoft IT SSL SHA2 4. ID certificate - *.sharepoint.com Intermediate CAs are issued by the above Root CA. Issue is seen when all 4 certificates are installed. Error happens with the intermediate CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not install intermediate CA-2 things works fine. Any help is well appreciated. Regards Jayalakshmi On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell > wrote: On 16/11/15 06:52, Jayalakshmi bhat wrote: > Hi Victor, > > Thanks a lot for details explanation. > > Our device acts as TLS/SSL client. The device receives chain of > certificates as part of SSL handshake, when it is trying to get > connected to TLS/SSL server like sharepoint 365. > > While validating the certificate chain from server, "*check_trust" > *fails with X509_V_ERR_CERT_UNTRUSTED. > > This had been working fine with OpenSSL 1.0.1c. > > When I checked the code execution, check_trust was not being called in > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > That is why I wanted to know is it mandatory for the applications to > set X509_VERIFY_PARAM in X509_STORE_CTX Are you able to share the certificates that the server provides you with? Also the root certificate you are using. It is not mandatory to set X509_VERIFY_PARAMs (but typically you at least want to verify the hostname through a call to "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like this? Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 16 23:05:55 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 17 Nov 2015 00:05:55 +0100 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: <00EEC723-F129-4B6D-BB07-5EB350440A5C@gmail.com> References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> <5649A05E.1030101@openssl.org> <00EEC723-F129-4B6D-BB07-5EB350440A5C@gmail.com> Message-ID: <564A6153.9040501@wisemo.com> Probably not, that constraint is satisfied since this is SSL/TLS and the end cert has that same EKU. On 16/11/2015 22:37, E T wrote: > Could it be because your CA-2 has the following: Extended Key Usage > - Client Authentication, Server Authentication? > > Some fields that in general only apply to end certificates, e.g. name > constraints, when used in a CA certificate, are interpreted as > constraints on the certificates that can be issued by that CA. > > > On Nov 16, 2015, at 11:48 AM, Jayalakshmi bhat > > wrote: > > Hi Matt, > > Thank you for the response. I have attached the certificates details. > My apology I am not supposed to share the certificates. We are not > using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with > the device. > > 1. Root CA- Baltimore CyberTrust Root > 2. Intermediate CA-1 - Microsoft Internet Authority > 3. Intermediate CA-2 - Microsoft IT SSL SHA2 > 4. ID certificate - *.sharepoint.com > > Intermediate CAs are issued by the above Root CA. Issue is seen when > all 4 certificates are installed. Error happens with the intermediate > CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not > install intermediate CA-2 things works fine. > > Any help is well appreciated. > > Regards > Jayalakshmi > > On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell > wrote: > > > > On 16/11/15 06:52, Jayalakshmi bhat wrote: > > Hi Victor, > > > > Thanks a lot for details explanation. > > > > Our device acts as TLS/SSL client. The device receives chain of > > certificates as part of SSL handshake, when it is trying to get > > connected to TLS/SSL server like sharepoint 365. > > > > While validating the certificate chain from server, "*check_trust" > > *fails with X509_V_ERR_CERT_UNTRUSTED. > > > > This had been working fine with OpenSSL 1.0.1c. > > > > When I checked the code execution, check_trust was not being > called in > > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > > > That is why I wanted to know is it mandatory for the applications to > > set X509_VERIFY_PARAM in X509_STORE_CTX > > > Are you able to share the certificates that the server provides you > with? Also the root certificate you are using. > > It is not mandatory to set X509_VERIFY_PARAMs (but typically you at > least want to verify the hostname through a call to > "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like > this? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Nov 16 23:22:38 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Nov 2015 23:22:38 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <564A653E.8000000@openssl.org> On 16/11/15 15:51, Emilia K?sper wrote: > Thanks all for your feedback! > > I asked for mainstream use-cases for algorithms whose removal could > cause widespread pain. Some individual users, undoubtedly, will be hit > by this, and I acknowledge that they may not be reading this list. But I > wanted to know if I'd missed something endemic. I also asked elsewhere: > Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 > must stay. > > There is a tradeoff: by attempting to accommodate every single use-case, > we will weaken the library for a substantial amount of our user base, by > offering them bad defaults, or simply by virtue of the fact that our > developer resources are not infinite. (Near)-dead code is a liability. We can significantly reduce that liability by removing any assembler optimisations. Also just because something is available doesn't mean it has to be "default". We can have good defaults whilst keeping old crypto. > > So far, excluding suspicions that something may be used somewhere, I've > received one clear argument, for RC5. And, while I'm sympathetic to the > cause, I believe this is the case where we have to balance one user's > needs against everyone else's. > > As for specific deprecation strategies: > - Don't forget that all applications will have to recompile against 1.1. > > - Disabling algorithms doesn't work well for us as it's just pushing the > decision on the distros. It also wouldn't win us any resources as we'd > still be responsible for keeping the code bug-free. The only win would > be in default compiled code size. Disabling algorithms isn't the right answer IMO. I do like the idea of a "liblegacycrypto". That way people that only have need of current up-to-date crypto can stick with the main library. Others who need the older crypto can still get at it. Yes, that means we still have to maintain this code - but I don't see it as that big a burden. > > - We can leave OPENSSL_NO_XXX defines around so wrapper libraries > (Python, PHP etc) who correctly account for the fact that an > implementation may be missing (which they have to, anyway) will continue > to work. > > - Removing assembly support is a GREAT suggestion to simplify the > complexity, and I think we should do this for anything we end up leaving > in, and perhaps even for some things not yet on the hit list (RC4?). > > - I appreciate OpenSSL's role as a "Swiss army knife" research tool but > research needs shouldn't prevail over those of real applications. We are > generally not on the frontline of deprecating things - RC4 isn't yet on > the list. SSLv3 isn't yet on the list, etc. But we can't become the > Internet Archive of All Old Crypto either, and there's some cleanup to > do that's long overdue. Being the "swiss army knife" is no bad thing (even where that includes old crypto). We just have to find a way to separate the two concerns: current crypto (and only current crypto) for most (and probably most importantly for libssl users); broader crypto support for those that want it (which is why I like the liblegacycrypto idea because it enables us to do that). > It seems to me that these can pretty safely go: > > MD2 - (The argument that someone somewhere may want to keep verifying > old MD2 signatures on self-signed certs doesn't seem like a compelling > enough reason to me. It's been disabled by default since OpenSSL 1.0.0.) > MDC2 > SEED > RC5 All candidates for liblegacycrypto IMO rather than deletion. Whether this is the right thing to do in the 1.1.0 timeframe is another consideration though. Viktor's arguments are quite convincing. Matt From jb-openssl at wisemo.com Tue Nov 17 00:36:08 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 17 Nov 2015 01:36:08 +0100 Subject: [openssl-users] OpenSSL 1.0.2d X509_verify_cert function does not work as used to with chain of certificates In-Reply-To: References: <20151115195610.GC18315@mournblade.imrryr.org> <3763B010-ED85-49BF-8253-FB70F7AAF093@dukhovni.org> <5649A05E.1030101@openssl.org> Message-ID: <564A7678.40403@wisemo.com> At most one of CA-1 and CA-2 would be part of the chain from Baltimore to the end cert. However your end cert (apparently for hosted Sharepoint services) was issued by a 3rd MSIT CA that was not provided. If it wasn't provided to the code either, the chain would not validate for that reason alone. I also note that none of the certs in the chain contain any Authority Information Access (AIA) extension (issuer certificate download URL and OCSP URL) only a CRL URL extension, which wouldn't be normal MS practice (Certificate revocation cannot be detected by some browsers that use only OCSP and the automatic certificate download done by some Microsoft Windows Security Support Providers (such as CredSSP) won't work). Oh and you are not posting from an official Microsoft e-mail address either. Something seems very odd here. On 16/11/2015 17:48, Jayalakshmi bhat wrote: > Hi Matt, > > Thank you for the response. I have attached the certificates details. > My apology I am not supposed to share the certificates. We are not > using X509_VERIFY_PARAM_xxx API's. We are using 4 certificates with > the device. > > 1. Root CA- Baltimore CyberTrust Root > 2. Intermediate CA-1 - Microsoft Internet Authority > 3. Intermediate CA-2 - Microsoft IT SSL SHA2 > 4. ID certificate - *.sharepoint.com > > Intermediate CAs are issued by the above Root CA. Issue is seen when > all 4 certificates are installed. Error happens with the intermediate > CA-2. check_trust returns X509_TRUST_UNTRUSTED. However if I do not > install intermediate CA-2 things works fine. > > Any help is well appreciated. > > Regards > Jayalakshmi > > On Mon, Nov 16, 2015 at 2:52 PM, Matt Caswell > wrote: > > > > On 16/11/15 06:52, Jayalakshmi bhat wrote: > > Hi Victor, > > > > Thanks a lot for details explanation. > > > > Our device acts as TLS/SSL client. The device receives chain of > > certificates as part of SSL handshake, when it is trying to get > > connected to TLS/SSL server like sharepoint 365. > > > > While validating the certificate chain from server, "*check_trust" > > *fails with X509_V_ERR_CERT_UNTRUSTED. > > > > This had been working fine with OpenSSL 1.0.1c. > > > > When I checked the code execution, check_trust was not being > called in > > OpenSSL 1.0.1c as "if (param->trust > 0)" was not satisfied. > > > > That is why I wanted to know is it mandatory for the applications to > > set X509_VERIFY_PARAM in X509_STORE_CTX > > > Are you able to share the certificates that the server provides you > with? Also the root certificate you are using. > > It is not mandatory to set X509_VERIFY_PARAMs (but typically you at > least want to verify the hostname through a call to > "X509_VERIFY_PARAM_set1_host"). Are you currently do anything like > this? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Nov 17 02:13:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 17 Nov 2015 02:13:54 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <16838026.jLb3FpZjMu@pintsize.usersys.redhat.com> Message-ID: <9851643599e344659ac6319399d73c7f@usma1ex-dag1mb1.msg.corp.akamai.com> ? If you are aware of a concrete use of MD2 or any of the other algorithms, please let us know! Also, note that we have an extended alpha and-beta test period, so we can add things back if mistakes are made. /r$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonb at parsec.co.za Tue Nov 17 07:48:29 2015 From: leonb at parsec.co.za (Leon Brits) Date: Tue, 17 Nov 2015 07:48:29 +0000 Subject: [openssl-users] FIPS certification for AES GCM mode algorithm Message-ID: <15b650a8b7204459bf9440a6e75d2318@EXCHANGESRV.PARSEC.local> Hi all, We are using the OpenSSL FIPS module v2.0 and are in the process of certifying the algorithms for our implementation. As part of this process there are different types of questionnaires about the algorithms. The questionnaire for AES GCM mode asks: : : Input Data Lengths (0 to 65536 bits, multiples of 8): * If any category of Plaintext or AAD value is not supported, enter "0" in both fields. * If only one value is supported for a given category, enter that value in both fields. Plaintext: Supports 0 Length Plaintext (GMAC) * Enter 2 Plaintext values that are multiples of 128: (1) 0 (2) 1024 * Enter 2 Plaintext values that are not multiples of 128: (1) 0 (2) 1024 AAD: Supports 0 Length AAD (Additional Authenticated Data) * Enter 2 AAD values that are multiples of 128: (1) 0 (2) 1024 * Enter 2 AAD values that are not multiples of 128: (1) 0 (2) 1024 : Any advice on what two values to enter for "multiple of 128" and "not multiple of 128" for plaintext and AAD. Why do I need to select these values? Are there exclusions in that range (0-1024)? Thanks for your time Regards, LJB -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Nov 17 10:12:11 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 05:12:11 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: > MD2 - (The argument that someone somewhere may want to keep verifying old > MD2 signatures on self-signed certs doesn't seem like a compelling enough > reason to me. It's been disabled by default since OpenSSL 1.0.0.) > ... Apple still provides two Verisign certificates using md2WithRSAEncryption. Confer, https://support.apple.com/en-us/HT203065. Jeff From noloader at gmail.com Tue Nov 17 10:19:27 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 05:19:27 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564A653E.8000000@openssl.org> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <564A653E.8000000@openssl.org> Message-ID: >> I asked for mainstream use-cases for algorithms whose removal could >> cause widespread pain. Some individual users, undoubtedly, will be hit >> by this, and I acknowledge that they may not be reading this list. But I >> wanted to know if I'd missed something endemic. I also asked elsewhere: >> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2 >> must stay. >> >> There is a tradeoff: by attempting to accommodate every single use-case, >> we will weaken the library for a substantial amount of our user base, by >> offering them bad defaults, or simply by virtue of the fact that our >> developer resources are not infinite. (Near)-dead code is a liability. > > We can significantly reduce that liability by removing any assembler > optimisations. Also just because something is available doesn't mean it > has to be "default". We can have good defaults whilst keeping old crypto. Zooko Wilcox O'Hearn recently gave a talk at a software assurance conference on the downsides of assembly language routines in software. I'm trying to locate it now. All in all, this is probably a move in the right direction, especially for non-contemporary algorithms, to help sunset them and maintain them with minimal effort. Its probably a good idea for mainstream algorithms, too. But the guys I know who provide the highest-performance implementations probably won't want to leave it to a compiler. Jeff From emilia at openssl.org Tue Nov 17 12:21:03 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 17 Nov 2015 13:21:03 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: > > MD2 - (The argument that someone somewhere may want to keep verifying old > > MD2 signatures on self-signed certs doesn't seem like a compelling enough > > reason to me. It's been disabled by default since OpenSSL 1.0.0.) > > ... > Apple still provides two Verisign certificates using > md2WithRSAEncryption. Confer, > https://support.apple.com/en-us/HT203065. > Setting aside the debate of whether verifying trust store signatures is useful, whether verifying MD2 signatures has any practical security value, or whether OpenSSL + iOS is a meaningful combination: This is iOS7. The current release is iOS9 (trust store here: https://support.apple.com/en-us/HT205205, MD2 certs are gone). Arguments like this illustrate a fundamental misunderstanding in this thread. We are not pulling the carpet from any users TODAY. We are asking whether there are applications that will need this code 2..3..5 years down the line. When I referred to the fact that users of 1.1 will have to recompile, I didn't mean that errors would be revealed by recompilation. I meant that you would have to be an actively maintained application or library, and be doing a new release, and be stuck using an old algorithm, to even be impacted by this change. > Jeff > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwood at IUPUI.Edu Tue Nov 17 14:02:10 2015 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 17 Nov 2015 09:02:10 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564A653E.8000000@openssl.org> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <564A653E.8000000@openssl.org> Message-ID: <20151117140210.GA28040@IUPUI.Edu> With regard to the idea that one can simply make older algorithms Somebody Else's Problem: is it *known* that another viable, well-maintained product sees this as one of its roles? That would be more reassuring, I think, than just hoping that some unknown group will step into the gap. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: Digital signature URL: From noloader at gmail.com Tue Nov 17 17:56:16 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 12:56:16 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <564A653E.8000000@openssl.org> Message-ID: >> We can significantly reduce that liability by removing any assembler >> optimisations. Also just because something is available doesn't mean it >> has to be "default". We can have good defaults whilst keeping old crypto. > > Zooko Wilcox O'Hearn recently gave a talk at a software assurance > conference on the downsides of assembly language routines in software. > I'm trying to locate it now. All in all, this is probably a move in > the right direction, especially for non-contemporary algorithms, to > help sunset them and maintain them with minimal effort. My bad... I just talked to Zooko about the presentation. He was not able to attend the conference, so there is no presentation to link to. However, here is the write-up in the Tahoe-LAFS Bug Reporter: https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes the case for No-ASM. (And was the corpus of knowledge for the presentation). Jeff From noloader at gmail.com Tue Nov 17 18:00:44 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 17 Nov 2015 13:00:44 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: On Tue, Nov 17, 2015 at 7:21 AM, Emilia K?sper wrote: > > > On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton wrote: >> >> > MD2 - (The argument that someone somewhere may want to keep verifying >> > old >> > MD2 signatures on self-signed certs doesn't seem like a compelling >> > enough >> > reason to me. It's been disabled by default since OpenSSL 1.0.0.) >> > ... >> Apple still provides two Verisign certificates using >> md2WithRSAEncryption. Confer, >> https://support.apple.com/en-us/HT203065. > > > Setting aside the debate of whether verifying trust store signatures is > useful, whether verifying MD2 signatures has any practical security value, > or whether OpenSSL + iOS is a meaningful combination: > > This is iOS7. The current release is iOS9 (trust store here: > https://support.apple.com/en-us/HT205205, MD2 certs are gone). > > Arguments like this illustrate a fundamental misunderstanding in this > thread. We are not pulling the carpet from any users TODAY. We are asking > whether there are applications that will need this code 2..3..5 years down > the line. My bad... I was not arguing either way. I was just presenting facts. Also, if OpenSSL requires iOS 9 or above, then its setting policy for users. I still have iOS 6, 7 and 8 devices because (1) some of my hardware is old and abandoned by Apple (they are trying to set policy, too, in an effort to boost sales). (2) I dislike the "cartoony" interface of iOS 7 and above. (3) I have down level OS X operating systems (due to operational requirements and personal taste), and they can't talk to iOS 8 or 9 devices. Jeff From bkaduk at akamai.com Tue Nov 17 19:18:54 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 17 Nov 2015 13:18:54 -0600 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> Message-ID: <564B7D9E.2030009@akamai.com> On 11/17/2015 12:00 PM, Jeffrey Walton wrote: > > > Also, if OpenSSL requires iOS 9 or above, then its setting policy for users. In some sense, yes. But it has always done so -- OpenSSL only supports certain platforms, and certain versions of certain platforms. There are prerequisites to being able to build any piece of software, and those prerequisites can and must change as new versions of that software are released. In particular... > I still have iOS 6, 7 and 8 devices because (1) some of my hardware is > old and abandoned by Apple (they are trying to set policy, too, in an > effort to boost sales). (2) I dislike the "cartoony" interface of iOS > 7 and above. (3) I have down level OS X operating systems (due to > operational requirements and personal taste), and they can't talk to > iOS 8 or 9 devices. > Will Apple still be supporting even iOS 8 in two years? I find it hard to make a case that OpenSSL should make an active push to support platforms no longer receiving security updates, given that we are supposed to be security software. In your personal case, you seem happy to use older versions of OS X and iOS; what is different about those compared to OpenSSL that you could not continue using an older version of OpenSSL if you found some functionality of the old version to be preferable? -Ben From jayf0ster at roadrunner.com Tue Nov 17 19:24:17 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Tue, 17 Nov 2015 11:24:17 -0800 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <564A653E.8000000@openssl.org> Message-ID: <564B7EE1.6000108@roadrunner.com> On 11/17/2015 9:56 AM, Jeffrey Walton wrote: >>> We can significantly reduce that liability by removing any assembler >>> optimisations. Also just because something is available doesn't mean it >>> has to be "default". We can have good defaults whilst keeping old crypto. >> Zooko Wilcox O'Hearn recently gave a talk at a software assurance >> conference on the downsides of assembly language routines in software. >> I'm trying to locate it now. All in all, this is probably a move in >> the right direction, especially for non-contemporary algorithms, to >> help sunset them and maintain them with minimal effort. > My bad... I just talked to Zooko about the presentation. He was not > able to attend the conference, so there is no presentation to link to. > > However, here is the write-up in the Tahoe-LAFS Bug Reporter: > https://tahoe-lafs.org/trac/pycryptopp/ticket/85#comment:20. It makes > the case for No-ASM. (And was the corpus of knowledge for the > presentation). > > Jeff > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > I can understand the desire to remove the assembly code options, but I think there are legitimate reasons to leave them in. From the write-up referenced (above), "because the added speed really makes no difference to our uses, as far as I know" was a reason given for removing assembly. I think this is based on some assumptions that are not universally true, such as OpenSSL is running on multi-GHz multi-core 64-bit processors. This is not always the case. I recently updated a product I support (50MHz single core) to OpenSSL 1.0.2d, and found that the assembly optimizations gave me a 40% increase in performance over the C version (AES decryption). 40% was very significant in my case. Seems like the low power IoT devices might be similarly CPU challenged in the future. Jay From openssl-users at dukhovni.org Tue Nov 17 19:35:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 17 Nov 2015 19:35:53 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564B7EE1.6000108@roadrunner.com> References: <1542773.NjbpUrSLMg@pintsize.usersys.redhat.com> <564A653E.8000000@openssl.org> <564B7EE1.6000108@roadrunner.com> Message-ID: <20151117193553.GN18315@mournblade.imrryr.org> On Tue, Nov 17, 2015 at 11:24:17AM -0800, Jay Foster wrote: > I can understand the desire to remove the assembly code options, *ONLY* for deprecated legacy algorithms, as an alternative to the proposal to remove the algorithm entirely. > I recently updated a product I support (50MHz single core) to OpenSSL > 1.0.2d, and found that the assembly optimizations gave me a 40% increase in > performance over the C version (AES decryption). 40% was very significant > in my case. Seems like the low power IoT devices might be similarly CPU > challenged in the future. The AES assembly packs are staying either way. Enjoy. -- Viktor. From rsalz at akamai.com Tue Nov 17 23:25:11 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 17 Nov 2015 23:25:11 +0000 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <5640A405.8050501@wisemo.com> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> <20151107025417.GE18315@mournblade.imrryr.org> <563E8391.9020807@openssl.org> <5640A405.8050501@wisemo.com> Message-ID: <0d06fc2e79024e3d9d6e0a0955af7578@usma1ex-dag1mb1.msg.corp.akamai.com> ? I have seen rumors (nothing reliable) that the TLS WG is proposing to disable a whole lot of good cipher suites in TLS 1.3. Well, it's pretty easy to verify. Look at the IETF TLS-WG web page, and get a pointer to the current draft doc. Yes, TLS removes non-AEAD ciphers, and has only PFS key exchange. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Nov 18 14:50:27 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 18 Nov 2015 15:50:27 +0100 Subject: [openssl-users] Does openssl server always choose highest TLS version offered? In-Reply-To: <0d06fc2e79024e3d9d6e0a0955af7578@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8149AB08BCB1F54F92680ED6104891A0DEFA61@mbx027-w1-ca-4.exch027.domain.local> <20151106213227.GB18315@mournblade.imrryr.org> <563D3EB4.6020905@openssl.org> <20151107025417.GE18315@mournblade.imrryr.org> <563E8391.9020807@openssl.org> <5640A405.8050501@wisemo.com> <0d06fc2e79024e3d9d6e0a0955af7578@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <564C9033.30104@wisemo.com> On 18/11/2015 00:25, Salz, Rich wrote: > > ?I have seen rumors (nothing reliable) that the TLS WG is proposing > to disable a whole lot of good cipher suites in TLS 1.3. > > Well, it?s pretty easy to verify. Look at the IETF TLS-WG web page, > and get a pointer to the current draft doc. > > Yes, TLS removes non-AEAD ciphers, and has only PFS key exchange. > > What I have seen of AEAD ciphers, they tend to be designed right "at the margin" in terms of security, compared to traditional combinations of one MAC algorithm with a different encryption algorithm, where the different algorithms tend to protect each other against many attacks. The recent NSA notes on post-suite B and quantum-resistant algorithms reminds us that all of the PFS key exchanges (DH and ECDH) available are vulnerable to decryption of wiretapped (recorded) transmissions once a real quantum computer is built by anyone. So are the other public key exchange algorithms in TLS, but not the PSK algorithms without PFS. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 bkaduk at akamai.com Wed Nov 18 17:12:59 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 18 Nov 2015 11:12:59 -0600 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> Message-ID: <564CB19B.6050605@akamai.com> On 11/18/2015 07:05 AM, Hubert Kario wrote: > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support > both relatively modern TLS with user certificates, preferably the newest > cryptosystems and hashes as well as the oldest ones that were > standardised and used. > > That means that old algorithms MUST remain in OpenSSL as supported > functionality. It may require linking to a specific library to make the > EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed > from it completely, definitely not before at least 50 years _after_ they > became obsolete and broken. > There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. -Ben From richmoore44 at gmail.com Wed Nov 18 20:05:22 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 18 Nov 2015 20:05:22 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <4855989.nphBNJ5Ttk@pintsize.usersys.redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <4855989.nphBNJ5Ttk@pintsize.usersys.redhat.com> Message-ID: On 18 November 2015 at 17:57, Hubert Kario wrote: > On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote: > > On 11/18/2015 07:05 AM, Hubert Kario wrote: > > > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to > > > support both relatively modern TLS with user certificates, > > > preferably the newest cryptosystems and hashes as well as the > > > oldest ones that were standardised and used. > > > > > > That means that old algorithms MUST remain in OpenSSL as supported > > > functionality. It may require linking to a specific library to make > > > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be > > > removed from it completely, definitely not before at least 50 years > > > _after_ they became obsolete and broken. > > > There seems to be a logical leap between these two paragraphs. Why is > > it necessary that OpenSSL be the only cryptographic library used by > > CAdES-A/etc. implementations? Is it in fact even necessary that only > > a single version of a single cryptographic library be used for such > > software? > > > > While OpenSSL may try to be a general-purpose crypto > > library, when a software has stringent or unusual crypto > > requirements, it seems reasonable that such a software may need to > > involve unusual implementations. > > > > I do not believe that OpenSSL has promised anywhere that it will > > support this sort of use case. > > From the main web page of project: > > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, *full-featured*, and Open Source toolkit > implementing the Transport Layer Security (TLS) and Secure Sockets > Layer (SSL) protocols as well as a full-strength *general purpose* > *cryptography library* . > > (emphasis mine) > > ?I think now is the time for those who are going to provide the 50 year support to step up to the plate then. Saying "oh but we can get it for free for the next 50 years" doesn't work. I think your emphasis here is exactly right though, the aim is *general purpose*? you are most definitely describing an extremely specialised purpose that has unusual requirements. ?Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Wed Nov 18 20:34:41 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 18 Nov 2015 14:34:41 -0600 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <564CE0E1.2000203@akamai.com> On 11/18/2015 12:52 PM, Blumenthal, Uri - 0553 - MITLL wrote: > On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" > wrote: > >> On 11/18/2015 07:05 AM, Hubert Kario wrote: >>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>> support >>> both relatively modern TLS with user certificates, preferably the >>> newest >>> cryptosystems and hashes as well as the oldest ones that were >>> standardised and used. >>> >>> That means that old algorithms MUST remain in OpenSSL as supported >>> functionality. It may require linking to a specific library to make the >>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed >>> from it completely, definitely not before at least 50 years _after_ >>> they >>> became obsolete and broken. >> There seems to be a logical leap between these two paragraphs. Why is >> it necessary that OpenSSL be the only cryptographic library used by >> CAdES-A/etc. implementations? > Because it used to be the only real game in town, and *people learned to > rely upon it*. > >> Is it in fact even necessary that only a >> single version of a single cryptographic library be used for such >> software? > No, of course not. But after letting people depend on this ?single > cryptographic library? for many years, telling them ?too bad? isn?t very > nice. I guess I'm just having a hard time wrapping my head around why, upon hearing that the volunteer-run project is giving years' advance notice that certain features will be removed, the response is insistence that everything must remain supported forever, instead of using the advance notice to investigate alternatives. Volunteers should be allowed to ease up when they need to, after all. >> While OpenSSL may try to be a general-purpose crypto library, >> when a software has stringent or unusual crypto requirements, it seems >> reasonable that such a software may need to involve unusual >> implementations. > The requirements did not change. What changed was the maintainers > expressing their desire to stop supporting some of them. Surely the requirements for a general-purpose crypto library must change over time! In 1995, such a library did not (could not!) include AES support, whereas even by 2005 it would have been pretty essential to have. As the state of the art advances, the library must adapt to match, and removing components that are no longer widespread or essential seems a natural part of that adaptation. The requirements are not an append-only list. >> I do not believe that OpenSSL has promised anywhere that it will support >> this sort of use case. > Implicitly, by providing that kind of service for so long. And explicitly, > as pointed out by Hubert: Well, I see this thread as notice that the implicit support should no longer be taken for granted, with plenty of advance notice. > From the main web page of project: > > The OpenSSL Project is a collaborative effort to develop a robust, > commercial-grade, *full-featured*, and Open Source toolkit > implementing the Transport Layer Security (TLS) and Secure Sockets > Layer (SSL) protocols as well as a full-strength *general purpose* > *cryptography library* . > > That text reads as if it was originally drafted 10+ years ago, when "full-featured" meant "we support both encryption and decryption" as well as "we provide both export-grade and strong crypto". I'm sure we could put some updated text in if that would help clarify what exactly the goals of the project are. And, as Richard notes, general-purpose does not mean "usable for every possible specific use case under the sun", it means "usable for most common things", which to me does not include CAdES-A and the like. -Ben From openssl-users at dukhovni.org Thu Nov 19 02:12:44 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 Nov 2015 02:12:44 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <564CE0E1.2000203@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> Message-ID: <20151119021244.GG18315@mournblade.imrryr.org> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: > > No, of course not. But after letting people depend on this ?single > > cryptographic library? for many years, telling them ?too bad? isn?t very > > nice. > > I guess I'm just having a hard time wrapping my head around why, upon > hearing that the volunteer-run project is giving years' advance notice > that certain features will be removed, the response is insistence that > everything must remain supported forever, instead of using the advance > notice to investigate alternatives. Volunteers should be allowed to > ease up when they need to, after all. Culture-clash. Security culture says everything remotely weak must go, but release-engineering culture emphasizes compatibilty. The crypto library is more of a systems component, not a security component. The SSL library is more of a security component than a systems component, and has algorithm negotiation. For example, Linux never breaks user-land, you can do all kinds of things inside the kernel, but user-land software (for a fixed libc) that worked before is going to continue working on new kernels. Doing that since 1991 or so. SunOS libc implemented multiple ABIs to ensure application compatibility. Many other operating systems do likewise. For better or worse, libcrypto is part of that world. It is a building block library for whatever applications the users want to use it for. It is not a security technology in its own right. > Surely the requirements for a general-purpose crypto library must change > over time! Yes, by accretion. And "general-purpose" does not mean "the expected use-cases", it really means "general". > have. As the state of the art advances, the library must adapt to > match, and removing components that are no longer widespread or > essential seems a natural part of that adaptation. The requirements are > not an append-only list. Except that they are, just as Linux and libc provide an append-only set of interfaces. > > The OpenSSL Project is a collaborative effort to develop a robust, > > commercial-grade, *full-featured*, and Open Source toolkit > > implementing the Transport Layer Security (TLS) and Secure Sockets > > Layer (SSL) protocols as well as a full-strength *general purpose* > > *cryptography library* . > > > That text reads as if it was originally drafted 10+ years ago, when > "full-featured" meant "we support both encryption and decryption" as > well as "we provide both export-grade and strong crypto". I'm sure we > could put some updated text in if that would help clarify what exactly > the goals of the project are. And, as Richard notes, general-purpose > does not mean "usable for every possible specific use case under the > sun", it means "usable for most common things", which to me does not > include CAdES-A and the like. No, general purpose really means whatever purpose the user has in mind. The "most common things" is not "general purpose". -- Viktor. From openssl-users at dukhovni.org Thu Nov 19 19:13:22 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 19 Nov 2015 19:13:22 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <1447927286.13671.9.camel@redhat.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <564CE0E1.2000203@akamai.com> <20151119021244.GG18315@mournblade.imrryr.org> <1447927286.13671.9.camel@redhat.com> Message-ID: <20151119191322.GN18315@mournblade.imrryr.org> On Thu, Nov 19, 2015 at 11:01:26AM +0100, Tomas Mraz wrote: > 3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the > OpenSSL_add* functions so the users have to explicitly add these to use > them automatically. This does not work. Often the code that calls OpenSSL_add_all_algorithms() is not the code that knows which algorithms will be used (think scripting languages). Having a single call that adds all the algorithms or just the non-legacy algorithms can work, hance Matt's suggestion of a #define that selects between two implementations, and requires linking with the legacy library. -- Viktor. From tshort at akamai.com Fri Nov 20 22:26:47 2015 From: tshort at akamai.com (Short, Todd) Date: Fri, 20 Nov 2015 22:26:47 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> Message-ID: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> While I am all for simplicity, I also think that removing functionality is a ?bad idea?. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the library. Those ?who don?t care? (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL > wrote: On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" on behalf of bkaduk at akamai.com> wrote: On 11/18/2015 07:05 AM, Hubert Kario wrote: So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support both relatively modern TLS with user certificates, preferably the newest cryptosystems and hashes as well as the oldest ones that were standardised and used. That means that old algorithms MUST remain in OpenSSL as supported functionality. It may require linking to a specific library to make the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed from it completely, definitely not before at least 50 years _after_ they became obsolete and broken. There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Because it used to be the only real game in town, and *people learned to rely upon it*. Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? No, of course not. But after letting people depend on this ?single cryptographic library? for many years, telling them ?too bad? isn?t very nice. While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. The requirements did not change. What changed was the maintainers expressing their desire to stop supporting some of them. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. Implicitly, by providing that kind of service for so long. And explicitly, as pointed out by Hubert: From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 23 04:17:33 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 23 Nov 2015 05:17:33 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> References: <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> Message-ID: <5652935D.1030002@wisemo.com> On 20/11/2015 23:26, Short, Todd wrote: > While I am all for simplicity, I also think that removing > functionality is a ?bad idea?. > > To reduce the support burden, deprecate the ciphers: > 1. Under support, indicate that these ciphers will no longer receive > fixes. > 2. Remove any assembly implementations > 3. Disable them by default. > > I suggest following the 80/20 rule (sometimes the 95/5 rule): > > Those ?who care? (the minority) about the ciphers can re-enable them > and rebuild the library. > Those ?who don?t care? (the majority) about the ciphers, should get > the functionality that most people care about, basically SSL/TLS > connectivity. > You all seem to misunderstand the fundamental release engineering issues involved. 1. Very shortly after you release OpenSSL 1.1.0, many distributions and pointy haired managers will blindly switch to the new version as the only version available. This will not at all await the "end of support" for OpenSSL 1.0.x . So breaking changes will cause harm much sooner than you claim. 2. Because of the need to easily keep up with routine security updates to OpenSSL, it is highly impractical to maintain locally reconfigured build scripts and patches, though some of us have no choice (and are still struggling with the massively huge and disorganized code reformatting in the middle of the 1.0.1 security update series). 3. When distributions upgrade OpenSSL, many applications that have not been actively and deliberately ported to the new OpenSSL version will be blindly recompiled with the new versions, and if they break, random developers with no understanding of either the application, OpenSSL or even security will do ill-informed rushed patches to try to undo the breakage you caused. 4. OpenSSL is THE primary crypto library for the FOSS universe. You may be volunteers, but you are working on a massively important piece of software, not some random optional library. 5. In these times of panic and marshal law, it is essential that the key resources for open source crypto remain unrestrained by the politics of any single country, such that the sudden outlawing of crypto in the current home of the maintainers does not prevent the project from being continued by a different team in a different country. This makes it essential not to tie any legal or technical aspect to a single place, country, political alliance, company or person. It is also critical to avoid any and all legal ties to the historically most problematic jurisdictions, such as the US. So don't pay people through any US bank accounts, foundations or legal entities. Don't keep any technical assets (such as repositories or mail archives) in one country. Don't create legal documents that tie any license permissions to any specific country or organization. These same considerations exclude any of the US based libraries and forks from being relevant outside that country. 6. All of this requires a lot more caution and a lot less arrogance from the people making decisions about changes in the OpenSSL library and project. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 tshort at akamai.com Mon Nov 23 16:05:12 2015 From: tshort at akamai.com (Short, Todd) Date: Mon, 23 Nov 2015 16:05:12 +0000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> Message-ID: I suspect that most ?users? of OpenSSL are doing it indirectly through other applications that use TLS (or crypto) functionality. Example: the Cisco AnyConnect client is reportedly one of the most installed pieces of software regardless of platform; it uses OpenSSL for TLS. Taking those indirect users into account, they don?t care about the research or advanced uses of OpenSSL; they just want to connect securely to their corporate network. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 20, 2015, at 9:09 PM, Peter Waltenberg > wrote: Quite reasonable except. I'm not sure you have majority and minority the right way around. My guess would be that the majority of OpenSSL users are libcrypto. consumers rather than SSL/TLS consumers. A point several of us have been trying to get through for some time. Peter -----"openssl-dev" > wrote: ----- To: "openssl-dev at openssl.org" > From: "Short, Todd" Sent by: "openssl-dev" Date: 11/21/2015 08:28AM Cc: "openssl-users at openssl.org" > Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback While I am all for simplicity, I also think that removing functionality is a ?bad idea?. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest following the 80/20 rule (sometimes the 95/5 rule): Those ?who care? (the minority) about the ciphers can re-enable them and rebuild the library. Those ?who don?t care? (the majority) about the ciphers, should get the functionality that most people care about, basically SSL/TLS connectivity. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL > wrote: On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" on behalf of bkaduk at akamai.com> wrote: On 11/18/2015 07:05 AM, Hubert Kario wrote: So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support both relatively modern TLS with user certificates, preferably the newest cryptosystems and hashes as well as the oldest ones that were standardised and used. That means that old algorithms MUST remain in OpenSSL as supported functionality. It may require linking to a specific library to make the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed from it completely, definitely not before at least 50 years _after_ they became obsolete and broken. There seems to be a logical leap between these two paragraphs. Why is it necessary that OpenSSL be the only cryptographic library used by CAdES-A/etc. implementations? Because it used to be the only real game in town, and *people learned to rely upon it*. Is it in fact even necessary that only a single version of a single cryptographic library be used for such software? No, of course not. But after letting people depend on this ?single cryptographic library? for many years, telling them ?too bad? isn?t very nice. While OpenSSL may try to be a general-purpose crypto library, when a software has stringent or unusual crypto requirements, it seems reasonable that such a software may need to involve unusual implementations. The requirements did not change. What changed was the maintainers expressing their desire to stop supporting some of them. I do not believe that OpenSSL has promised anywhere that it will support this sort of use case. Implicitly, by providing that kind of service for so long. And explicitly, as pointed out by Hubert: From the main web page of project: The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, *full-featured*, and Open Source toolkit implementing the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols as well as a full-strength *general purpose* *cryptography library* . _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Nov 23 18:09:08 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 23 Nov 2015 19:09:08 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> Message-ID: <56535644.3010002@wisemo.com> But they care very much if Cisco AnyConnect (or any other OpenSSL using program they may need) stops working or becomes insecure because the OpenSSL team is breaking stuff just because it is not needed in their own handful of example uses. And while ordinary people may not know or care, they will be deeply affected by the increase in undiscovered vulnerabilities if the white hat research community stops supporting OpenSSL by researching its code more deeply than any other crypto library. It is already bad enough that no code review made before the giant reformat provides much insight into the current code, because it is virtually impossible to independently review the mega- patch that mixed reformatting and actual code changes. Fundamentally, appealing to what "ordinary users" care about in the way you just did is an appeal to stupidity. Ordinary users don't know how the innards of OpenSSL affect their lives, as was so clearly seen when the first a lot of them heard about OpenSSL was Heartbleed and the resulting "gut reactions" was to say that OpenSSL must be a fundamentally bad thing (spurred along by mass media describing Heartbleed as a "virus"). Or think about all the people confusing the Android stagefreight multimedia library with the recently discovered vulnerabilities in that same library. Note that I am not saying ordinary users are stupid, they just don't know a lot of things about our profession, as they don't know much about each others professions either. This is the fundamental principle of specialization ever since the concept of professions was invented millennia ago. On 23/11/2015 17:05, Short, Todd wrote: > I suspect that most ?users? of OpenSSL are doing it indirectly through > other applications that use TLS (or crypto) functionality. Example: > the Cisco AnyConnect client is reportedly one of the most installed > pieces of software regardless of platform; it uses OpenSSL for TLS. > > Taking those indirect users into account, they don?t care about the > research or advanced uses of OpenSSL; they just want to connect > securely to their corporate network. > >> On Nov 20, 2015, at 9:09 PM, Peter Waltenberg > > wrote: >> >> Quite reasonable except. >> >> I'm not sure you have majority and minority the right way around. My >> guess would be that the majority of OpenSSL users are libcrypto. >> consumers rather than SSL/TLS consumers. >> >> A point several of us have been trying to get through for some time. >> >> -----"openssl-dev" > > wrote: ----- >> To: "openssl-dev at openssl.org " >> > >> From: "Short, Todd" >> Sent by: "openssl-dev" >> Date: 11/21/2015 08:28AM >> Cc: "openssl-users at openssl.org " >> > >> Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto >> from OpenSSL 1.1 - seeking feedback >> >> While I am all for simplicity, I also think that removing >> functionality is a ?bad idea?. >> >> To reduce the support burden, deprecate the ciphers: >> 1. Under support, indicate that these ciphers will no longer receive >> fixes. >> 2. Remove any assembly implementations >> 3. Disable them by default. >> >> I suggest following the 80/20 rule (sometimes the 95/5 rule): >> >> Those ?who care? (the minority) about the ciphers can re-enable them >> and rebuild the library. >> Those ?who don?t care? (the majority) about the ciphers, should get >> the functionality that most people care about, basically SSL/TLS >> connectivity. >> >>> On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL >>> > wrote: >>> >>> On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk" >>> >> on behalf of >>> bkaduk at akamai.com > wrote: >>> >>>> On 11/18/2015 07:05 AM, Hubert Kario wrote: >>>>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to >>>>> support >>>>> both relatively modern TLS with user certificates, preferably the >>>>> newest >>>>> cryptosystems and hashes as well as the oldest ones that were >>>>> standardised and used. >>>>> >>>>> That means that old algorithms MUST remain in OpenSSL as supported >>>>> functionality. It may require linking to a specific library to >>>>> make the >>>>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed >>>>> from it completely, definitely not before at least 50 years _after_ >>>>> they >>>>> became obsolete and broken. >>>> >>>> There seems to be a logical leap between these two paragraphs. Why is >>>> it necessary that OpenSSL be the only cryptographic library used by >>>> CAdES-A/etc. implementations? >>> >>> Because it used to be the only real game in town, and *people learned to >>> rely upon it*. >>> >>>> Is it in fact even necessary that only a >>>> single version of a single cryptographic library be used for such >>>> software? >>> >>> No, of course not. But after letting people depend on this ?single >>> cryptographic library? for many years, telling them ?too bad? isn?t very >>> nice. >>> >>>> While OpenSSL may try to be a general-purpose crypto library, >>>> when a software has stringent or unusual crypto requirements, it seems >>>> reasonable that such a software may need to involve unusual >>>> implementations. >>> >>> The requirements did not change. What changed was the maintainers >>> expressing their desire to stop supporting some of them. >>> >>>> I do not believe that OpenSSL has promised anywhere that it will >>>> support >>>> this sort of use case. >>> >>> Implicitly, by providing that kind of service for so long. And >>> explicitly, >>> as pointed out by Hubert: >>> >>> From the main web page of project: >>> >>> The OpenSSL Project is a collaborative effort to develop a robust, >>> commercial-grade, *full-featured*, and Open Source toolkit >>> implementing the Transport Layer Security (TLS) and Secure Sockets >>> Layer (SSL) protocols as well as a full-strength *general purpose* >>> *cryptography library* . >>> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 vogelke at pobox.com Mon Nov 23 20:36:37 2015 From: vogelke at pobox.com (Karl Vogel) Date: Mon, 23 Nov 2015 15:36:37 -0500 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback Message-ID: <20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil> >> On Mon, 23 Nov 2015 05:17:33 +0100, >> Jakob Bohm said: J> You all seem to misunderstand the fundamental release engineering issues J> involved. Actually, we don't. J> 1. Very shortly after you release OpenSSL 1.1.0, many distributions J> and pointy haired managers will blindly switch to the new version as J> the only version available. I've installed new OS releases and distributions for over 20 years, and I don't ever remember having that particular problem with OpenSSL. On the contrary, our vendors are very conservative and I frequently end up replacing their version. J> This will not at all await the "end of support" for OpenSSL 1.0.x. J> So breaking changes will cause harm much sooner than you claim. If we'd waited for the lowest common denominators (aka PHBs) to start doing their jobs right, we'd still be using DOS 5 and looking forward to that new-fangled windows thing. J> 2. Because of the need to easily keep up with routine security updates to J> OpenSSL, it is highly impractical to maintain locally reconfigured build J> scripts and patches, though some of us have no choice (and are still J> struggling with the massively huge and disorganized code reformatting J> in the middle of the 1.0.1 security update series). Do you mean reformatting or refactoring? Would the API itself undergo significant changes just because some obsolete crypto was removed? Not being snarky, honestly curious. I understand that people do more complex things than simply install the openssl binary and associated libraries, but I keep CentOS-6, Solaris-10, and Solaris-11 boxes patched with the same set of scripts. Aside from the (rare) portability tweak, I don't touch them. J> 3. When distributions upgrade OpenSSL, many applications that have not J> been actively and deliberately ported to the new OpenSSL version will J> be blindly recompiled with the new versions, and if they break, random J> developers with no understanding of either the application, OpenSSL or J> even security will do ill-informed rushed patches to try to undo the J> breakage you caused. If you blindly recompile *anything* just because a version number changed, any resulting breakage is YOUR problem. People who understand release engineering issues know better; they also know how to read a changelog and tell their customers when (and why) to expect something different. When OpenSSL-1.1.whatever comes out, I'll do the same thing I've always done -- wait a bit for the initial reactions, install it on my workstation first to make sure it doesn't barf, and then move it out to the production boxes. J> 4. OpenSSL is THE primary crypto library for the FOSS universe. J> You may be volunteers, but you are working on a massively important J> piece of software, not some random optional library. Most of them *are* volunteers, and they seem to be taking their work more seriously than the people disparaging them, not to mention the folks who are supposed to get this right (i.e., U.S. Office of Personnel Management). J> 5. In these times of panic and marshal law, it is essential that the J> key resources for open source crypto remain unrestrained by the politics J> of any single country... What does this have to do with removing obsolete crypto from a library? J> 6. All of this requires a lot more caution and a lot less arrogance J> from the people making decisions about changes in the OpenSSL library J> and project. "Arrogance" would be slamming the changes in without discussion or notification and saying "like it or lump it". Haven't seen that. -- Karl Vogel I don't speak for the USAF or my company eBay scammer steals identity of Special Agent investigating him --"Register" headline, 18 Nov 2015 From jb-openssl at wisemo.com Mon Nov 23 23:10:45 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 24 Nov 2015 00:10:45 +0100 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil> References: <20151123203637.GA12739@bsd118.area52.afnoapps.usaf.mil> Message-ID: <56539CF5.4060809@wisemo.com> On 23/11/2015 21:36, Karl Vogel wrote: >>> On Mon, 23 Nov 2015 05:17:33 +0100, >>> Jakob Bohm said: > J> You all seem to misunderstand the fundamental release engineering issues > J> involved. > > Actually, we don't. > > J> 1. Very shortly after you release OpenSSL 1.1.0, many distributions > J> and pointy haired managers will blindly switch to the new version as > J> the only version available. > > I've installed new OS releases and distributions for over 20 years, > and I don't ever remember having that particular problem with OpenSSL. > On the contrary, our vendors are very conservative and I frequently end > up replacing their version. I am saying that some distributions will switch to the branch currently planned to be named 1.1.0 long before support for 1.0.2 ends. And those distributions will then run try to routinely recompile all openSSL- referencing software packages against the new OpenSSL (along with the new libc, the new kernel, the new zlib etc. etc.) and dispatch bug fixers to fix the resulting compile errors with no special considerations for crypto expertise. (More on this later in this e-mail). By the time such an 1.1.0-based OS release is shipped, that 1.1.0 code will probably be a few letter-patches behind the latest upstream, at least in name (some distributions backport the changes but don't change the letter in the version number, naming it instead something like 1.1.0d+ourpatch7). > J> This will not at all await the "end of support" for OpenSSL 1.0.x. > J> So breaking changes will cause harm much sooner than you claim. > > If we'd waited for the lowest common denominators (aka PHBs) to start > doing their jobs right, we'd still be using DOS 5 and looking forward > to that new-fangled windows thing. I am talking about the breakage caused by PHBs that insist on using the highest OpenSSL version listed as "fixed" in the most recent CVE entry, even when a letter patch to an earlier branch is equally safe. This combined with code that has not (for any reason) been ported from 1.0.2 to 1.1.0 by its primary authors, perhaps because they need some featureremoved in 1.1.0. > > J> 2. Because of the need to easily keep up with routine security updates to > J> OpenSSL, it is highly impractical to maintain locally reconfigured build > J> scripts and patches, though some of us have no choice (and are still > J> struggling with the massively huge and disorganized code reformatting > J> in the middle of the 1.0.1 security update series). > > Do you mean reformatting or refactoring? Would the API itself undergo > significant changes just because some obsolete crypto was removed? > Not being snarky, honestly curious. > > I understand that people do more complex things than simply install > the openssl binary and associated libraries, but I keep CentOS-6, > Solaris-10, and Solaris-11 boxes patched with the same set of scripts. > Aside from the (rare) portability tweak, I don't touch them. I am talking about applying usage/application specific patches to the OpenSSL source tree and the fact that the reformatting requires all such patches to be reimplemented one by one to apply to the reformatted code. > > J> 3. When distributions upgrade OpenSSL, many applications that have not > J> been actively and deliberately ported to the new OpenSSL version will > J> be blindly recompiled with the new versions, and if they break, random > J> developers with no understanding of either the application, OpenSSL or > J> even security will do ill-informed rushed patches to try to undo the > J> breakage you caused. > > If you blindly recompile *anything* just because a version number > changed, any resulting breakage is YOUR problem. People who understand > release engineering issues know better; they also know how to read a > changelog and tell their customers when (and why) to expect something > different. > > When OpenSSL-1.1.whatever comes out, I'll do the same thing I've > always done -- wait a bit for the initial reactions, install it on my > workstation first to make sure it doesn't barf, and then move it out > to the production boxes. You are talking about internal corporate careful roll-out procedures, I am talking about OS distributions such as *BSD and *Linux doing their usual preparations for a new OS release by importing new versions of upstream sources, recompiling and fixing obvious bugs until it "looks OK", while failing to detect subtle breakage or new security issues. A classic example is how Debian (a few years back) did a patch to the OpenSSL RNG, creating an RNG that worked but had way too little entropy. It is that kind of crypto- unskilled mistakes that I fear will proliferate in the fall-out from the breaking changes in OpenSSL 1.1.0. > > J> 4. OpenSSL is THE primary crypto library for the FOSS universe. > J> You may be volunteers, but you are working on a massively important > J> piece of software, not some random optional library. > > Most of them *are* volunteers, and they seem to be taking their > work more seriously than the people disparaging them, not to mention > the folks who are supposed to get this right (i.e., U.S. Office of > Personnel Management). It would be more interesting to compare to teams such as the volunteers on the Linux kernel teams and how they deal with user mode API compatibility. > > J> 5. In these times of panic and marshal law, it is essential that the > J> key resources for open source crypto remain unrestrained by the politics > J> of any single country... > > What does this have to do with removing obsolete crypto from a library? It is just another (unrelated) set of mistakes happening in the new OpenSSL team after the large infusion of money. > > J> 6. All of this requires a lot more caution and a lot less arrogance > J> from the people making decisions about changes in the OpenSSL library > J> and project. > > "Arrogance" would be slamming the changes in without discussion or > notification and saying "like it or lump it". Haven't seen that. Saying "we here you" and then high-handedly deciding to do the deed anyway would also count as arrogance in my book. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 leenanand at yahoo.com Tue Nov 24 05:17:10 2015 From: leenanand at yahoo.com (Leena Soman) Date: Tue, 24 Nov 2015 05:17:10 +0000 (UTC) Subject: [openssl-users] Verifying Authenticode timestamp using openssl apis References: <1041392301.4119037.1448342230046.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1041392301.4119037.1448342230046.JavaMail.yahoo@mail.yahoo.com> Hello, I am trying to verify the timestamp in a file signed using Authenticode. I have found that this timestamp is in the RFC3161 format. Using openssl apis, I have parsed the Authenticode signature and reached the oid 1.3.6.1.4.1.311.3.3.1. I have subsequently used the following apis :------------------------------------------------------------------------ ASN1_OBJECT *obj;??????? obj = OBJ_txt2obj("1.3.6.1.4.1.311.3.3.1", 1); ??????? int cmp = -1; ??????? ??????? attr = sk_X509_ATTRIBUTE_value(pSkUnauthAttr, 0); ??????? if (0 == (cmp = OBJ_cmp(attr->object, obj))) ??????? { ??????????? ASN1_TYPE *asn1_type = NULL; ??????????? asn1_type = sk_ASN1_TYPE_value(attr->value.set, 0); ??????????? ??????????? if (V_ASN1_SEQUENCE == asn1_type->type) ??????????? {?????????? ??????????????? ptr = asn1_type->value.octet_string->data;??????????????? ts_pkcs7 = d2i_PKCS7(NULL, &ptr, (int)asn1_type->value.octet_string->length); ------------------------------------------------------------------------Since the sequence following the oid is of type PKCS7_signed_data, I expected d2i_PKCS7 to convert it after which I would be able to reach id-smime-ct-TSTInfo. But d2i_PKCS7 fails returning NULL. I would appreciate if someone who has done something similar and faced this problem can help me. I am unable to move forward so any help would be greatly appreciated.Thanks, Leena. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Nov 24 09:30:41 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 24 Nov 2015 09:30:41 +0000 Subject: [openssl-users] Verifying Authenticode timestamp using openssl apis In-Reply-To: <1041392301.4119037.1448342230046.JavaMail.yahoo@mail.yahoo.com> References: <1041392301.4119037.1448342230046.JavaMail.yahoo.ref@mail.yahoo.com> <1041392301.4119037.1448342230046.JavaMail.yahoo@mail.yahoo.com> Message-ID: <56542E41.7040106@openssl.org> On 24/11/15 05:17, Leena Soman wrote: > Hello, > I am trying to verify the timestamp in a file signed using Authenticode. > I have found that this timestamp is in the RFC3161 format. > Using openssl apis, I have parsed the Authenticode signature and reached > the oid 1.3.6.1.4.1.311.3.3.1. I have subsequently used the following apis : Am I right in understanding that you are attempting to use the OpenSSL ASN.1 APIs to parse an RFC3161 response? Did you realise that OpenSSL has APIs that support RFC3161 directly? See opensssl/ts.h as well as the "openssl ts" command line app. Matt From leenanand at yahoo.com Tue Nov 24 10:44:41 2015 From: leenanand at yahoo.com (Leena Soman) Date: Tue, 24 Nov 2015 10:44:41 +0000 (UTC) Subject: [openssl-users] Verifying Authenticode timestamp using openssl apis In-Reply-To: <56542E41.7040106@openssl.org> References: <56542E41.7040106@openssl.org> Message-ID: <1753346158.5386979.1448361881191.JavaMail.yahoo@mail.yahoo.com> Hi?Matt,Yes I have seen them and?am planning on using them. But the timestamp is embedded in the Authenticode signature as?a PKCS7 signedData under OID 1.3.6.1.4.1.311.3.3.1.?I have reached this oid but need to convert the PKCS7 signedData into?a structure?after which I will be able to use the ts apis.After some debugging, I found that the?version in the PKCS7 structure is 3. So I am now wondering if I need to use d2i_CMS_SignedData instead of d2i_PKCS7. Thanks,Leena. ? From: Matt Caswell To: openssl-users at openssl.org Sent: Tuesday, November 24, 2015 3:00 PM Subject: Re: [openssl-users] Verifying Authenticode timestamp using openssl apis On 24/11/15 05:17, Leena Soman wrote: > Hello, > I am trying to verify the timestamp in a file signed using Authenticode. > I have found that this timestamp is in the RFC3161 format. > Using openssl apis, I have parsed the Authenticode signature and reached > the oid 1.3.6.1.4.1.311.3.3.1. I have subsequently used the following apis : Am I right in understanding that you are attempting to use the OpenSSL ASN.1 APIs to parse an RFC3161 response? Did you realise that OpenSSL has APIs that support RFC3161 directly? See opensssl/ts.h as well as the "openssl ts" command line app. Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From leenanand at yahoo.com Tue Nov 24 10:46:36 2015 From: leenanand at yahoo.com (Leena Soman) Date: Tue, 24 Nov 2015 10:46:36 +0000 (UTC) Subject: [openssl-users] Verifying Authenticode timestamp using openssl apis In-Reply-To: <56542E41.7040106@openssl.org> References: <56542E41.7040106@openssl.org> Message-ID: <185179316.7990685.1448361996747.JavaMail.yahoo@mail.yahoo.com> Hi Matt,Here is an excerpt of openssl asn1parse ------------------------------------------------------------------------------------------------3588:d=5? hl=4 l=4940 cons: cont [ 1 ] ?3592:d=6? hl=4 l=4936 cons: SEQUENCE ?3596:d=7? hl=2 l=? 10 prim: OBJECT??????????? :1.3.6.1.4.1.311.3.3.1 ?3608:d=7? hl=4 l=4920 cons: SET ?3612:d=8? hl=4 l=4916 cons: SEQUENCE ?3616:d=9? hl=2 l=?? 9 prim: OBJECT??????????? :pkcs7-signedData ?3627:d=9? hl=4 l=4901 cons: cont [ 0 ] ?3631:d=10 hl=4 l=4897 cons: SEQUENCE ?3635:d=11 hl=2 l=?? 1 prim: INTEGER?????????? :03 ?3638:d=11 hl=2 l=? 15 cons: SET ?3640:d=12 hl=2 l=? 13 cons: SEQUENCE ?3642:d=13 hl=2 l=?? 9 prim: OBJECT??????????? :sha256 ?3653:d=13 hl=2 l=?? 0 prim: NULL ?3655:d=11 hl=4 l= 316 cons: SEQUENCE ?3659:d=12 hl=2 l=? 11 prim: OBJECT??????????? :id-smime-ct-TSTInfo ?3672:d=12 hl=4 l= 299 cons: cont [ 0 ] ?3676:d=13 hl=4 l= 295 prim: OCTET STRING????? [HEX DUMP]:30820123020101060A2B0601040184590A03013031300D060960864801650304020105000420817580D34E29FAD72349E478B6EA0B6354F926FD5CB8719E230D0672BFC5E9C102065593CB94E2BC181232303135303731303035303331352E37315A3007020101800201F4A081B9A481B63081B3310B3009060355040613025553311330110603550408130A57617368696E67746F6E3110300E060355040713075265646D6F6E64311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E310D300B060355040B13044D4F505231273025060355040B131E6E436970686572204453452045534E3A433046342D333038362D44454638312530230603550403131C4D6963726F736F66742054696D652D5374616D702053657276696365 ?3975:d=11 hl=4 l=3792 cons: cont [ 0 ] ?3979:d=12 hl=4 l=1649 cons: SEQUENCE ?3983:d=13 hl=4 l=1113 cons: SEQUENCE ?3987:d=14 hl=2 l=?? 3 cons: cont [ 0 ] ?3989:d=15 hl=2 l=?? 1 prim: INTEGER?????????? :02 ?3992:d=14 hl=2 l=? 10 prim: INTEGER?????????? :6109812A000000000002 ?4004:d=14 hl=2 l=? 13 cons: SEQUENCE ?4006:d=15 hl=2 l=?? 9 prim: OBJECT??????????? :sha256WithRSAEncryption ?4017:d=15 hl=2 l=?? 0 prim: NULL ?4019:d=14 hl=3 l= 136 cons: SEQUENCE ?4022:d=15 hl=2 l=? 11 cons: SET ?4024:d=16 hl=2 l=?? 9 cons: SEQUENCE ?4026:d=17 hl=2 l=?? 3 prim: OBJECT??????????? :countryName ?4031:d=17 hl=2 l=?? 2 prim: PRINTABLESTRING?? :US------------------------------------------------------------------------------------------------- Thanks,Leena. ? From: Matt Caswell To: openssl-users at openssl.org Sent: Tuesday, November 24, 2015 3:00 PM Subject: Re: [openssl-users] Verifying Authenticode timestamp using openssl apis On 24/11/15 05:17, Leena Soman wrote: > Hello, > I am trying to verify the timestamp in a file signed using Authenticode. > I have found that this timestamp is in the RFC3161 format. > Using openssl apis, I have parsed the Authenticode signature and reached > the oid 1.3.6.1.4.1.311.3.3.1. I have subsequently used the following apis : Am I right in understanding that you are attempting to use the OpenSSL ASN.1 APIs to parse an RFC3161 response? Did you realise that OpenSSL has APIs that support RFC3161 directly? See opensssl/ts.h as well as the "openssl ts" command line app. Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From garcia.narbona at gmail.com Tue Nov 24 11:56:29 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Tue, 24 Nov 2015 12:56:29 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one Message-ID: Hi, I am trying to use openssl command line tool for des-ede3-cbc encryption, but it does not mach with the one I have in Java (and that I know that works ok). I try to generate a des-ede3-cbc encryption with an IV = 0,0,0,0,0,0,0,0. Then I launch following command: echo 'text_to_cypher' | openssl enc -e -des-ede3-cbc -k 'b2aec78eb50e04f2a60b9efa20b82c903e3cad4f3bd2027g' -iv 00000000 -nosalt | openssl enc -base64 But I don't get the same result as the one I get in Java using Cipher: private final byte [] IV = {0, 0, 0, 0, 0, 0, 0, 0}; ..... DESedeKeySpec desKeySpec = new DESedeKeySpec(toByteArray(hexKey)); SecretKey desKey = new SecretKeySpec(desKeySpec.getKey(), "DESede"); Cipher desCipher = Cipher.getInstance("DESede/CBC/NoPadding"); desCipher.init(Cipher.ENCRYPT_MODE, desKey, new IvParameterSpec(IV)); //text 0 padding to get it multilpe of 8 byte[] ciphertext = desCipher.doFinal(cleartext); new String(Base64.encodeBase64(ciphertext), "UTF-8"); Could anyone point me to what I am doing worng in this command line call? Thanks in advance. -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue Nov 24 15:28:51 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 24 Nov 2015 15:28:51 +0000 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: Message-ID: > echo 'text_to_cypher' | openssl enc -e -des-ede3-cbc -k 'b2aec78eb50e04f2a60b9efa20b82c903e3cad4f3bd2027g' -iv 00000000 -nosalt | openssl enc -base64 That echo command will append a LF (x'0a') byte (if this is a conventional UNIX or Linux system, or Cygwin, etc, and you're running under one of the standard shells). Do you have that byte in the value of your "cleartext" variable in the Java code? You failed to supply that. (Also, the single-quote characters are unnecessary, unless you're running a very odd shell.) The value of the -k argument you're passing to "openssl enc" ends with "g", which is not a hexadecimal digit; the rest of the value appears to be hexadecimal. But it's not clear why you're using -k anyway. Perhaps you mean to use -K (uppercase K, with an actual hexadecimal argument)? -- Michael Wojcik Technology Specialist, Micro Focus From garcia.narbona at gmail.com Tue Nov 24 16:55:42 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Tue, 24 Nov 2015 17:55:42 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: Message-ID: I am sorry, I pasted an invalid key I was playing with to check some other things. Next, the real key and now reading the value from a file instead from echo (BTW I am using a linux terminal): openssl enc -e -des-ede3-cbc -in myfile.txt -k 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | openssl enc -base64 myfile.txt (edited with vim) contains the string: 005863330 The value I get is: SYqzNH5u8ExzyakWO3Cj/A== meanwhile the one I am getting from Java and PHP examples is: H6cr2yN8oWUVY3a6/Vaaow== Regards. 2015-11-24 16:28 GMT+01:00 Michael Wojcik : > > > echo 'text_to_cypher' | openssl enc -e -des-ede3-cbc -k > 'b2aec78eb50e04f2a60b9efa20b82c903e3cad4f3bd2027g' -iv 00000000 -nosalt | > openssl enc -base64 > > That echo command will append a LF (x'0a') byte (if this is a conventional > UNIX or Linux system, or Cygwin, etc, and you're running under one of the > standard shells). Do you have that byte in the value of your "cleartext" > variable in the Java code? You failed to supply that. (Also, the > single-quote characters are unnecessary, unless you're running a very odd > shell.) > > The value of the -k argument you're passing to "openssl enc" ends with > "g", which is not a hexadecimal digit; the rest of the value appears to be > hexadecimal. But it's not clear why you're using -k anyway. Perhaps you > mean to use -K (uppercase K, with an actual hexadecimal argument)? > > > -- > Michael Wojcik > Technology Specialist, Micro Focus > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 24 17:00:37 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 Nov 2015 17:00:37 +0000 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: Message-ID: <20151124170037.GF18315@mournblade.imrryr.org> On Tue, Nov 24, 2015 at 05:55:42PM +0100, David Garc?a wrote: > openssl enc -e -des-ede3-cbc -in myfile.txt -k > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | > openssl enc -base64 Please read Michael's message carefully. Note the comment about "-k" vs. "-K" (upper-case). -- Viktor. From garcia.narbona at gmail.com Tue Nov 24 17:07:19 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Tue, 24 Nov 2015 18:07:19 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: <20151124170037.GF18315@mournblade.imrryr.org> References: <20151124170037.GF18315@mournblade.imrryr.org> Message-ID: You are right Viktor, that was my problem. Thank you very much for your help Viktor and Michael. 2015-11-24 18:00 GMT+01:00 Viktor Dukhovni : > On Tue, Nov 24, 2015 at 05:55:42PM +0100, David Garc?a wrote: > > > openssl enc -e -des-ede3-cbc -in myfile.txt -k > > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | > > openssl enc -base64 > > Please read Michael's message carefully. Note the comment about > "-k" vs. "-K" (upper-case). > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From garcia.narbona at gmail.com Tue Nov 24 17:12:59 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Tue, 24 Nov 2015 18:12:59 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: <20151124170037.GF18315@mournblade.imrryr.org> Message-ID: Sorry, still not getting the same result, now with the command: echo 005863330 | openssl enc -e -des-ede3-cbc -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | openssl enc -base64 I get: H6cr2yN8oWXn2RxiDqnXLg== but I should get: H6cr2yN8oWUVY3a6/Vaaow== BTW I get the same result if the text in the echo is between '' or is read from a text file. 2015-11-24 18:07 GMT+01:00 David Garc?a : > You are right Viktor, that was my problem. > > Thank you very much for your help Viktor and Michael. > > 2015-11-24 18:00 GMT+01:00 Viktor Dukhovni : > >> On Tue, Nov 24, 2015 at 05:55:42PM +0100, David Garc?a wrote: >> >> > openssl enc -e -des-ede3-cbc -in myfile.txt -k >> > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt >> | >> > openssl enc -base64 >> >> Please read Michael's message carefully. Note the comment about >> "-k" vs. "-K" (upper-case). >> >> -- >> Viktor. >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > > -- > David > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From karthik.raman at siemens.com Tue Nov 24 16:45:40 2015 From: karthik.raman at siemens.com (Raman, Karthik IN BLR STS) Date: Tue, 24 Nov 2015 22:15:40 +0530 Subject: [openssl-users] OpenSSL compilation with no_des option. Message-ID: <8D15F77F211D7D4786182E1C8E679FAD4177A94E54@INBLRK77M1MSX.in002.siemens.net> Hi, I faced a problem to compile OpenSSL 1.0.2a with no_des option. I faced the same problem until OpenSSL 1.0.2d. Fortunately I found a patch in the URL below. I can do the code changes suggested in this URL and able to compile. https://www.mail-archive.com/openssl-dev at openssl.org/msg39295.html I was wondering, how this code change can be incorporated formally in the OpenSSL source code. This will help to benefit everybody who ever uses OpenSSL with this option. With best regards, Karthik R -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 24 17:17:59 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 24 Nov 2015 17:17:59 +0000 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: <20151124170037.GF18315@mournblade.imrryr.org> Message-ID: <20151124171759.GG18315@mournblade.imrryr.org> On Tue, Nov 24, 2015 at 06:12:59PM +0100, David Garc?a wrote: > Sorry, still not getting the same result, now with the command: > > echo 005863330 | openssl enc -e -des-ede3-cbc -K > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | > openssl enc -base64 Please also read his comment about newlines (aka LF characters) appended by "echo", or read from a file containing a line of text. (Hint: instead of "echo 005863330" try "printf 005863330"). -- Viktor. From jayf0ster at roadrunner.com Tue Nov 24 17:19:59 2015 From: jayf0ster at roadrunner.com (Jay Foster) Date: Tue, 24 Nov 2015 09:19:59 -0800 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: <20151124170037.GF18315@mournblade.imrryr.org> Message-ID: <56549C3F.9080307@roadrunner.com> It is very likely that your text file also contains a newline at the end, so getting the same result as with the echo command would be expected. If it is indeed the newline that is making the difference, you could try using the echo command with the '-n' option to suppress it. Jay On 11/24/2015 9:12 AM, David Garc?a wrote: > Sorry, still not getting the same result, now with the command: > > echo 005863330 | openssl enc -e -des-ede3-cbc -K > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 > -nosalt | openssl enc -base64 > > I get: > > H6cr2yN8oWXn2RxiDqnXLg== > > but I should get: > > H6cr2yN8oWUVY3a6/Vaaow== > > > BTW I get the same result if the text in the echo is between '' or is > read from a text file. > > 2015-11-24 18:07 GMT+01:00 David Garc?a >: > > You are right Viktor, that was my problem. > > Thank you very much for your help Viktor and Michael. > > 2015-11-24 18:00 GMT+01:00 Viktor Dukhovni > >: > > On Tue, Nov 24, 2015 at 05:55:42PM +0100, David Garc?a wrote: > > > openssl enc -e -des-ede3-cbc -in myfile.txt -k > > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv > 00000000 -nosalt | > > openssl enc -base64 > > Please read Michael's message carefully. Note the comment about > "-k" vs. "-K" (upper-case). > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > -- > David > > > > > -- > David > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.loah at gmail.com Tue Nov 24 18:46:12 2015 From: matt.loah at gmail.com (Matt Loah) Date: Tue, 24 Nov 2015 19:46:12 +0100 Subject: [openssl-users] Help on basic EC programming Message-ID: Hello all guys, I'm a newbie... and going to understand the OpenSSL and the APIs involved in, and even if I searched in the Net, there are two main question/subject fields that I'd like to ask for. 1. Firstly, I wrote a little code that I don't know if it's really good enough. So, comments, suggestions... will be greatly appreciated. ---- #include #include #include #include #define ECCTYPE "brainpoolP512t1" int generate_keys (EC_KEY * ecc, EVP_PKEY * pkey) { if (EC_KEY_generate_key (ecc) <= 0) return 1; else { if (EVP_PKEY_assign_EC_KEY (pkey, ecc) <= 0) return 2; else { BIO * bp_public = BIO_new_file ("./key.pub.pem", "w+"); BIO * bp_private = BIO_new_file ("./key.prv.pem", "w+"); if (bp_public) { if (PEM_write_bio_PUBKEY (bp_public, pkey) <= 0) return 3; else BIO_free_all (bp_public); } else return 4; if (bp_private) { if (PEM_write_bio_PrivateKey (bp_private, pkey, nullptr, nullptr, 0, 0, nullptr) <= 0) return 5; else BIO_free_all (bp_private); } else return 6; } } return 0; } int main() { int retVal = 0; OpenSSL_add_all_algorithms(); ERR_load_BIO_strings(); ERR_load_crypto_strings(); EVP_PKEY * pkey = EVP_PKEY_new(); EC_KEY * ecc = EC_KEY_new_by_curve_name (OBJ_txt2nid (ECCTYPE)); retVal = generate_keys (ecc, pkey); EVP_PKEY_free (pkey); EC_KEY_free (ecc); return retVal; } ---- 2. Secondly, I'd like to be able to work with these two generated keys... I mean, encrypt, decrypt... but don't reach to understand how to use them and which functions should be invoked ? And also, I'd like to get the public/private keys... Should use EC_KEY_get0_private_key() & EC_KEY_get0_public_key() functions ? Any help will be also highly appreciated. Matt L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From garcia.narbona at gmail.com Wed Nov 25 08:18:15 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Wed, 25 Nov 2015 09:18:15 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: <56549C3F.9080307@roadrunner.com> References: <20151124170037.GF18315@mournblade.imrryr.org> <56549C3F.9080307@roadrunner.com> Message-ID: Thanks, you are rigth. I did a test with echo -n 005863330 and echo 005863330 and the last one adds the new line character. I also checked that openssl is not adding this new line character. Now with this command: echo -n 005863330 | openssl enc -e -des-ede3-cbc -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | openssl enc -base64 I get: H6cr2yN8oWV6AUY/JlknQw== but is not exactly the same result I get for the same input in my Java and PHP examples. In those ones I get: H6cr2yN8oWUVY3a6/Vaaow== In the Java and PHP examples the input data is hardcoded in text: text "005863330" key "b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b" Regards. 2015-11-24 18:19 GMT+01:00 Jay Foster : > It is very likely that your text file also contains a newline at the end, > so getting the same result as with the echo command would be expected. If > it is indeed the newline that is making the difference, you could try using > the echo command with the '-n' option to suppress it. > > Jay > > > On 11/24/2015 9:12 AM, David Garc?a wrote: > > Sorry, still not getting the same result, now with the command: > > echo 005863330 | openssl enc -e -des-ede3-cbc -K > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nosalt | > openssl enc -base64 > > I get: > > H6cr2yN8oWXn2RxiDqnXLg== > > but I should get: > > H6cr2yN8oWUVY3a6/Vaaow== > > > BTW I get the same result if the text in the echo is between '' or is read > from a text file. > > 2015-11-24 18:07 GMT+01:00 David Garc?a : > >> You are right Viktor, that was my problem. >> >> Thank you very much for your help Viktor and Michael. >> >> 2015-11-24 18:00 GMT+01:00 Viktor Dukhovni < >> openssl-users at dukhovni.org>: >> >>> On Tue, Nov 24, 2015 at 05:55:42PM +0100, David Garc?a wrote: >>> >>> > openssl enc -e -des-ede3-cbc -in myfile.txt -k >>> > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 >>> -nosalt | >>> > openssl enc -base64 >>> >>> Please read Michael's message carefully. Note the comment about >>> "-k" vs. "-K" (upper-case). >>> >>> -- >>> Viktor. >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> >> >> -- >> David >> > > > > -- > David > > > _______________________________________________ > 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 > > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 25 09:39:23 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Nov 2015 09:39:23 +0000 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: <20151124170037.GF18315@mournblade.imrryr.org> <56549C3F.9080307@roadrunner.com> Message-ID: <20151125093923.GQ18315@mournblade.imrryr.org> On Wed, Nov 25, 2015 at 09:18:15AM +0100, David Garc?a wrote: > H6cr2yN8oWV6AUY/JlknQw== Decrypting in ECB mode you get: $ echo H6cr2yN8oWV6AUY/JlknQw== | openssl base64 -d | openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad | hexdump -ve '/1 "%02x"'; echo 30303538363333332fa02cdc247ba662 > but is not exactly the same result I get for the same input in my Java and > PHP examples. In those ones I get: > > H6cr2yN8oWUVY3a6/Vaaow== Decrypting in ECB mode you get: $ echo H6cr2yN8oWUVY3a6/Vaaow== | openssl base64 -d | openssl enc -d -des-ede3 -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad | hexdump -ve '/1 "%02x"'; echo 30303538363333332fa72bdb237ca165 The initial 8-byte blocks are identical, but the trailing blocks differ subtly. The hexdump of the OpenSSL ciphertext is: $ echo H6cr2yN8oWV6AUY/JlknQw== | openssl base64 -d | hexdump -ve '/1 "%02x"'; echo 1fa72bdb237ca1657a01463f26592743 If you XOR the common first block of ciphertext into each of the second decrypted blocks you get: $ perl -le ' for ( (0x2fa02cdc247ba662, 0x2fa72bdb237ca165) ) { printf "%016x\n", ($_ ^ 0x1fa72bdb237ca165) }' 3007070707070707 3000000000000000 What you see is the effect of PKCS#5 padding in the case of OpenSSL, and zero-padding (which is not reversible and not suitable for encrypting ciphertext that is a not a multiple of 8 bytes in length) in Java. You've failed to configure the correct padding mode. -- Viktor. From garcia.narbona at gmail.com Wed Nov 25 10:14:48 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Wed, 25 Nov 2015 11:14:48 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: <20151125093923.GQ18315@mournblade.imrryr.org> References: <20151124170037.GF18315@mournblade.imrryr.org> <56549C3F.9080307@roadrunner.com> <20151125093923.GQ18315@mournblade.imrryr.org> Message-ID: Viktor, you pointed me to the right way. I was missing the -nopad flag in the openssl command. I don't need to do the padding through the cipher algorithm because I do the 0 padding manually before executing the ciphering. Now it matches. This is the command I am using (for this manual example I am providing an already multiple of 8 string, so I have removed the first char of the input string for testing): echo -n 05863330 | openssl enc -e -des-ede3-cbc -K 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -iv 00000000 -nopad | openssl enc -base64 Thanks Viktor. 2015-11-25 10:39 GMT+01:00 Viktor Dukhovni : > On Wed, Nov 25, 2015 at 09:18:15AM +0100, David Garc?a wrote: > > > H6cr2yN8oWV6AUY/JlknQw== > > Decrypting in ECB mode you get: > > $ echo H6cr2yN8oWV6AUY/JlknQw== | > openssl base64 -d | > openssl enc -d -des-ede3 -K > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad | > hexdump -ve '/1 "%02x"'; echo > 30303538363333332fa02cdc247ba662 > > > but is not exactly the same result I get for the same input in my Java > and > > PHP examples. In those ones I get: > > > > H6cr2yN8oWUVY3a6/Vaaow== > > Decrypting in ECB mode you get: > > $ echo H6cr2yN8oWUVY3a6/Vaaow== | > openssl base64 -d | > openssl enc -d -des-ede3 -K > 'b2aec78eb50e05f2a60b9efa20b82c903e6cad4f3bd2027b' -nopad | > hexdump -ve '/1 "%02x"'; echo > 30303538363333332fa72bdb237ca165 > > The initial 8-byte blocks are identical, but the trailing blocks > differ subtly. The hexdump of the OpenSSL ciphertext is: > > $ echo H6cr2yN8oWV6AUY/JlknQw== | > openssl base64 -d | > hexdump -ve '/1 "%02x"'; echo > 1fa72bdb237ca1657a01463f26592743 > > If you XOR the common first block of ciphertext into each of the > second decrypted blocks you get: > > $ perl -le ' > for ( (0x2fa02cdc247ba662, 0x2fa72bdb237ca165) ) { > printf "%016x\n", ($_ ^ 0x1fa72bdb237ca165) > }' > 3007070707070707 > 3000000000000000 > > What you see is the effect of PKCS#5 padding in the case of OpenSSL, > and zero-padding (which is not reversible and not suitable for > encrypting ciphertext that is a not a multiple of 8 bytes in length) > in Java. You've failed to configure the correct padding mode. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 25 10:23:33 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Nov 2015 10:23:33 +0000 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: References: <20151124170037.GF18315@mournblade.imrryr.org> <56549C3F.9080307@roadrunner.com> <20151125093923.GQ18315@mournblade.imrryr.org> Message-ID: <20151125102333.GR18315@mournblade.imrryr.org> On Wed, Nov 25, 2015 at 11:14:48AM +0100, David Garc?a wrote: > Viktor, you pointed me to the right way. I was missing the -nopad flag in > the openssl command. Not using padding is fragile and can lead to subtle data corruption. Perhaps not padding is safe and correct in your case, but I am skeptical and you should be too. If you're constrained to interoperate with existing code that is not padding, that code is questionable, but you may have no choice but to follow suite. If you're free to choose formats, you should probably pad. -- Viktor. From garcia.narbona at gmail.com Wed Nov 25 10:26:23 2015 From: garcia.narbona at gmail.com (=?UTF-8?Q?David_Garc=C3=ADa?=) Date: Wed, 25 Nov 2015 11:26:23 +0100 Subject: [openssl-users] openssl des-ede3-cbc does not match with Java one In-Reply-To: <20151125102333.GR18315@mournblade.imrryr.org> References: <20151124170037.GF18315@mournblade.imrryr.org> <56549C3F.9080307@roadrunner.com> <20151125093923.GQ18315@mournblade.imrryr.org> <20151125102333.GR18315@mournblade.imrryr.org> Message-ID: Exactly, that's my point, I have to integrate with a third party API, so I can't do anything else but to send the ciphered text as expected. Anyway, thanks for your explanation on this issue, I'll take it into account and try to contact third party support team. Thanks. 2015-11-25 11:23 GMT+01:00 Viktor Dukhovni : > On Wed, Nov 25, 2015 at 11:14:48AM +0100, David Garc?a wrote: > > > Viktor, you pointed me to the right way. I was missing the -nopad flag in > > the openssl command. > > Not using padding is fragile and can lead to subtle data corruption. > Perhaps not padding is safe and correct in your case, but I am > skeptical and you should be too. If you're constrained to interoperate > with existing code that is not padding, that code is questionable, > but you may have no choice but to follow suite. If you're free to > choose formats, you should probably pad. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.loah at gmail.com Wed Nov 25 17:18:26 2015 From: matt.loah at gmail.com (Matt Loah) Date: Wed, 25 Nov 2015 18:18:26 +0100 Subject: [openssl-users] Ask for a tutorial on EC... Message-ID: Hi all, Has anyone a little tutorial on how to use OpenSSL APIs to implement an encryption / decryption code using Elliptic Curves ? Thanks, Matt L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pl at artisanlogiciel.net Wed Nov 25 17:50:17 2015 From: pl at artisanlogiciel.net (pl) Date: Wed, 25 Nov 2015 18:50:17 +0100 Subject: [openssl-users] Ask for a tutorial on EC... In-Reply-To: References: Message-ID: <5655F4D9.4040803@artisanlogiciel.net> On 25/11/2015 18:18, Matt Loah wrote: > Hi all, > > Has anyone a little tutorial on how to use OpenSSL APIs to implement > an encryption / decryption code using Elliptic Curves ? > > Thanks, > > Matt L. > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users You can kickstart here : https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography Regards, Philippe L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Wed Nov 25 20:57:55 2015 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Wed, 25 Nov 2015 20:57:55 +0000 Subject: [openssl-users] Ask for a tutorial on EC... In-Reply-To: <5655F4D9.4040803@artisanlogiciel.net> References: <5655F4D9.4040803@artisanlogiciel.net> Message-ID: <8149AB08BCB1F54F92680ED6104891A0DFB716@mbx027-w1-ca-4.exch027.domain.local> I also like this page for the best conceptual explanation for how EC crypto works that I've seen: https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of pl Sent: Wednesday, November 25, 2015 9:50 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Ask for a tutorial on EC... On 25/11/2015 18:18, Matt Loah wrote: Hi all, Has anyone a little tutorial on how to use OpenSSL APIs to implement an encryption / decryption code using Elliptic Curves ? Thanks, Matt L. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users You can kickstart here : https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography Regards, Philippe L. From cvkalyani1 at gmail.com Wed Nov 25 23:34:17 2015 From: cvkalyani1 at gmail.com (kalyani cv) Date: Wed, 25 Nov 2015 15:34:17 -0800 Subject: [openssl-users] af_alg plugin for openssl source codes Message-ID: Hi, I am unable to find the source codes for af_alg plugin i.e source codes for libaf_alg.so shared library. The link http://src.carnivore.it/users/common/af alg/tree/ is referenced in most of the places. But link does not work. Can somebody point me to its source codes? Thanks, Kalyani -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 25 23:41:56 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 25 Nov 2015 23:41:56 +0000 Subject: [openssl-users] af_alg plugin for openssl source codes In-Reply-To: References: Message-ID: <56564744.1080807@openssl.org> On 25/11/15 23:34, kalyani cv wrote: > Hi, > I am unable to find the source codes for af_alg plugin i.e source codes > for libaf_alg.so shared library. > The link http://src.carnivore.it/users/common/af alg/tree/ is referenced > in most of the places. But link does not work. > Can somebody point me to its source codes? I found this mirror on google, but it doesn't seem to have been touched in a while so I don't know if its up to date: https://github.com/xoware/af_ag Matt From mofassir_haque at yahoo.com Thu Nov 26 10:25:53 2015 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Thu, 26 Nov 2015 10:25:53 +0000 (UTC) Subject: [openssl-users] Generation of the primes p, q and g for DSA using an Hash Function in OpenSSL References: <1634057561.11650838.1448533553897.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1634057561.11650838.1448533553897.JavaMail.yahoo@mail.yahoo.com> We can generate primes p,q and g for DSA in OpenSSL by using command: openssl dsaparam -text -out dsaparam.pem 1024 Is it possible to generate primes p , q and g using an Hash Function in OpenSSL if value of L , N and hash function is known ? Any help will be greatly appreciated ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at rustichelli.net Thu Nov 26 15:10:20 2015 From: lists at rustichelli.net (lists) Date: Thu, 26 Nov 2015 16:10:20 +0100 Subject: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: References: Message-ID: <565720DC.6070705@rustichelli.net> On 11/13/2015 02:40 PM, Emilia K?sper wrote: > > BLOWFISH - probably still in use though I don't know where exactly? Isn't Blowfish a building block of bcrypt and/or some similar stuff? I think that implementations don't rely on OpenSSL but I wouldn't give it for granted. As for the rest of the algorithms, a lot has been already said but I would like to share my personal opinion (that of someone who codes using the OpenSSL API since some time): I think of OpenSSL as an incredibly rich tool for the professionals and the students as well, if it were possible I would like to see all of the algorithms to be there forever, including the odd situation of people who must decrypt some content they produced a long time ago, for instance. I understand that this is not feasable in the long-term, but we cannot forget that IT time is different from people time: the fact that an algorithm is born and becomes insecure in a few years doesn't mean that it won't be needed for some time, unless we accept the idea that OpenSSL is something to be used "for the moment being" (which is reasonable for SSL/TLS and communications in general, much less for file encryption and signature features). So, if it were possible to keep the algorithms for a long time, providing a simple way to put them out of the compilation (and the default compilation options may just do that), that would be great. At least as long as they are API-compliant (of course, you cannot ask to be kept consistent with the rest of the code for decades). My gratefulness to all developers, whatever it will be! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.loah at gmail.com Thu Nov 26 19:18:19 2015 From: matt.loah at gmail.com (Matt Loah) Date: Thu, 26 Nov 2015 20:18:19 +0100 Subject: [openssl-users] Better understanding of EC encryption API Message-ID: Hi all, While the public key in the context of OpenSSL Elliptic Curves algorithm is stored as a EC_POINT pointer... and the private key as a BIGNUM pointer... which functions (or which kind of them) should be called to encrypt & to decrypt a message in C/C++ ? Matt L. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 26 19:59:22 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 26 Nov 2015 19:59:22 +0000 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: References: Message-ID: <5657649A.4050900@openssl.org> On 26/11/15 19:18, Matt Loah wrote: > While the public key in the context of OpenSSL Elliptic Curves algorithm > is stored as a EC_POINT pointer... and the private key as a BIGNUM > pointer... which functions (or which kind of them) should be called to > encrypt & to decrypt a message in C/C++ ? OpenSSL only supports ECDH and ECDSA, neither of which can be used to perform encryption. Matt From jan.m.danielsson at gmail.com Thu Nov 26 22:26:08 2015 From: jan.m.danielsson at gmail.com (Jan Danielsson) Date: Thu, 26 Nov 2015 23:26:08 +0100 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: References: Message-ID: <56578700.10903@gmail.com> On 26/11/15 20:18, Matt Loah wrote: > While the public key in the context of OpenSSL Elliptic Curves algorithm is > stored as a EC_POINT pointer... and the private key as a BIGNUM pointer... > which functions (or which kind of them) should be called to encrypt & to > decrypt a message in C/C++ ? OpenSSL doesn't support it out of the box. What you're looking for is something akin to https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme. Ladar Levison has written an implementation which uses OpenSSL as a backend. I tried finding it for you, but my connection (mobile, on train) is so bad that I couldn't be bothered to keep trying. If you google for it I'm sure you'll find it pretty easily. If you can't find it -- it's not difficult to do it from scratch using that wikipedia page and the OpenSSL reference manuals. /Jan From openssl-users at dukhovni.org Fri Nov 27 04:07:12 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Nov 2015 04:07:12 +0000 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: <5657649A.4050900@openssl.org> References: <5657649A.4050900@openssl.org> Message-ID: <20151127040712.GC18315@mournblade.imrryr.org> On Thu, Nov 26, 2015 at 07:59:22PM +0000, Matt Caswell wrote: > On 26/11/15 19:18, Matt Loah wrote: > > While the public key in the context of OpenSSL Elliptic Curves algorithm > > is stored as a EC_POINT pointer... and the private key as a BIGNUM > > pointer... which functions (or which kind of them) should be called to > > encrypt & to decrypt a message in C/C++ ? > > OpenSSL only supports ECDH and ECDSA, neither of which can be used to > perform encryption. This is not entirely true, in sufficiently recent versions of OpenSSL, ECDSA keys can be used with CMS to encrypt keys. Just create an ECDSA private key and email cerficate (example attached), and then encrypt and decrypt some data: $ printf "%s\n" sesame | openssl cms -binary -outform DER -aes-128-cbc -encrypt -recip cert.pem | openssl cms -binary -inform DER -decrypt -recip cert.pem -inkey key.pem sesame Examining the structure we see ECDSA enveloped keys ( https://tools.ietf.org/html/rfc3278.html#section-3.1 ): $ printf "%s\n" sesame | openssl cms -binary -outform DER -aes-128-cbc -encrypt -recip cert.pem | openssl asn1parse -inform DER 0:d=0 hl=4 l= 263 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData 15:d=1 hl=3 l= 249 cons: cont [ 0 ] 18:d=2 hl=3 l= 246 cons: SEQUENCE 21:d=3 hl=2 l= 1 prim: INTEGER :02 24:d=3 hl=3 l= 178 cons: SET 27:d=4 hl=3 l= 175 cons: cont [ 1 ] 30:d=5 hl=2 l= 1 prim: INTEGER :03 33:d=5 hl=2 l= 81 cons: cont [ 0 ] 35:d=6 hl=2 l= 79 cons: cont [ 1 ] 37:d=7 hl=2 l= 9 cons: SEQUENCE 39:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 48:d=7 hl=2 l= 66 prim: BIT STRING 116:d=5 hl=2 l= 24 cons: SEQUENCE 118:d=6 hl=2 l= 9 prim: OBJECT :dhSinglePass-stdDH-sha1kdf-scheme 129:d=6 hl=2 l= 11 cons: SEQUENCE 131:d=7 hl=2 l= 9 prim: OBJECT :id-aes128-wrap 142:d=5 hl=2 l= 61 cons: SEQUENCE 144:d=6 hl=2 l= 59 cons: SEQUENCE 146:d=7 hl=2 l= 31 cons: SEQUENCE 148:d=8 hl=2 l= 26 cons: SEQUENCE 150:d=9 hl=2 l= 24 cons: SET 152:d=10 hl=2 l= 22 cons: SEQUENCE 154:d=11 hl=2 l= 3 prim: OBJECT :commonName 159:d=11 hl=2 l= 15 prim: UTF8STRING :Viktor Dukhovni 176:d=8 hl=2 l= 1 prim: INTEGER :01 179:d=7 hl=2 l= 24 prim: OCTET STRING [HEX DUMP]:54480EC3C3C51599E1A058B4B8C467643E49067C9ED810C3 205:d=3 hl=2 l= 60 cons: SEQUENCE 207:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 218:d=4 hl=2 l= 29 cons: SEQUENCE 220:d=5 hl=2 l= 9 prim: OBJECT :aes-128-cbc 231:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:D7A3A11E3A6ADE4A36050CCF7E123377 249:d=4 hl=2 l= 16 prim: cont [ 0 ] -- Viktor. -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIBuzCCAWGgAwIBAgIBATAKBggqhkjOPQQDAjAaMRgwFgYDVQQDDA9WaWt0b3Ig RHVraG92bmkwHhcNMTUxMTI3MDM1MzQ3WhcNMTUxMjI3MDM1MzQ3WjAaMRgwFgYD VQQDDA9WaWt0b3IgRHVraG92bmkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATE 5mgTFdY8CrqgDR8JBGTPhHNYhcd38+BagQdm7Zo1Z2zVJMdgjfp+bMxHmnVq06UR yIAEGgonSvVY0tIjaOgOo4GXMIGUMB0GA1UdDgQWBBTRXWsWcTdQFJxxhUsMliJu o2D3QzAfBgNVHSMEGDAWgBTRXWsWcTdQFJxxhUsMliJuo2D3QzAJBgNVHRMEAjAA MAsGA1UdDwQEAwIEsDATBgNVHSUEDDAKBggrBgEFBQcDBDAlBgNVHREEHjAcgRpv cGVuc3NsLXVzZXJzQGR1a2hvdm5pLm9yZzAKBggqhkjOPQQDAgNIADBFAiEAnG5X wlBEQScZLGRmxsV/vAapbJhTBpCbaE1Nms6JghsCIGsCIY/2VezMoLtahSHi+KZf zSePdYIGC49VZF1f2m0f -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN PRIVATE KEY----- MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQglgUxDgdcr1IRtjix Sy39lOQOwpriCjByKX+Lh8k+SnmhRANCAATE5mgTFdY8CrqgDR8JBGTPhHNYhcd3 8+BagQdm7Zo1Z2zVJMdgjfp+bMxHmnVq06URyIAEGgonSvVY0tIjaOgO -----END PRIVATE KEY----- From tjh at cryptsoft.com Fri Nov 27 09:19:17 2015 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 27 Nov 2015 19:19:17 +1000 Subject: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback In-Reply-To: <56535644.3010002@wisemo.com> References: <3CB9005A-76B1-4F42-BA72-DE46AB82C27D@akamai.com> <1770293.ATZhSyddb0@pintsize.usersys.redhat.com> <564CB19B.6050605@akamai.com> <201511210210.tAL2AvJi030500@d23av02.au.ibm.com> <56535644.3010002@wisemo.com> Message-ID: <56582015.7010109@cryptsoft.com> On 24/11/2015 4:09 AM, Jakob Bohm wrote: > But they care very much if Cisco AnyConnect (or any other > OpenSSL using program they may need) stops working or > becomes insecure because the OpenSSL team is breaking > stuff just because it is not needed in their own handful > of example uses. The OpenSSL team (like most open source projects) is made up of individuals that have widely varying backgrounds and experiences - and those experiences lead to different view points on a lot of fairly fundamental topics. This is a good thing - as frankly a project that doesn't have a mix of view points tends to not last. Between the OpenSSL team members our experiences cover a very wide range of uses and many of us have been working on the code base for 17+ years and have worked in areas that are certainly well outside the average or common uses. However despite that experience we certainly don't think that we know what all the users of the code base are doing. Increasingly we are making sure any debate on project direction where there are mixed view points within the team brings in the openssl-users and/or openssl-dev lists so we get to have input from a wider set of people - who may or may not represent uses that we don't already know about. All the view points being expressed are valid and there are good reasons why we could as a team head in either direction (dropping out code or keeping everything or anything along that spectrum) and what is important is to listen to the input and see the varying points of view and add that into the decision making process. So if you have a use of OpenSSL that you think the team might not know about then please express that clearly on the list. View points on what has been proposed are also welcome - but I think you'll find increasing the awareness of the team about what our users are doing is the more important of the two objectives in seeking feedback. Tim. From tjh at cryptsoft.com Fri Nov 27 09:28:36 2015 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 27 Nov 2015 19:28:36 +1000 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: <56578700.10903@gmail.com> References: <56578700.10903@gmail.com> Message-ID: <56582244.3050602@cryptsoft.com> On 27/11/2015 8:26 AM, Jan Danielsson wrote: > On 26/11/15 20:18, Matt Loah wrote: >> While the public key in the context of OpenSSL Elliptic Curves algorithm is >> stored as a EC_POINT pointer... and the private key as a BIGNUM pointer... >> which functions (or which kind of them) should be called to encrypt & to >> decrypt a message in C/C++ ? > OpenSSL doesn't support it out of the box. What you're looking for > is something akin to > https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme. > > Ladar Levison has written an implementation which uses OpenSSL as a > backend. I tried finding it for you, but my connection (mobile, on > train) is so bad that I couldn't be bothered to keep trying. http://www.mail-archive.com/openssl-dev at openssl.org/msg28042.html Tim. From matt at openssl.org Fri Nov 27 09:36:41 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 27 Nov 2015 09:36:41 +0000 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: <20151127040712.GC18315@mournblade.imrryr.org> References: <5657649A.4050900@openssl.org> <20151127040712.GC18315@mournblade.imrryr.org> Message-ID: <56582429.5020703@openssl.org> On 27/11/15 04:07, Viktor Dukhovni wrote: > On Thu, Nov 26, 2015 at 07:59:22PM +0000, Matt Caswell wrote: > >> On 26/11/15 19:18, Matt Loah wrote: >>> While the public key in the context of OpenSSL Elliptic Curves algorithm >>> is stored as a EC_POINT pointer... and the private key as a BIGNUM >>> pointer... which functions (or which kind of them) should be called to >>> encrypt & to decrypt a message in C/C++ ? >> >> OpenSSL only supports ECDH and ECDSA, neither of which can be used to >> perform encryption. > > This is not entirely true, in sufficiently recent versions of > OpenSSL, ECDSA keys can be used with CMS to encrypt keys. Well, perhaps I should modify the statement to say "OpenSSL only supports ECDH and ECDSA, neither of which can be used *by themselves* to perform encryption." Clearly you can use them in combination with other algorithms to achieve encryption - but they don't do encryption themselves. I'm not particularly familiar with CMS but from my very quick reading of what is going on in your example is that the EC key is being used by ECDH to agree a shared secret (in combination with a KDF). Then AES128 key wrapping is used to encrypt the CEK, followed by AES to actually encrypt the data. So ECDH is not encrypting anything directly (it can't - its not an encryption algorithm - it a key agreement algorithm). Matt From mcepl at cepl.eu Fri Nov 27 10:25:36 2015 From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl) Date: Fri, 27 Nov 2015 11:25:36 +0100 Subject: [openssl-users] Better understanding of EC encryption API References: <56578700.10903@gmail.com> <56582244.3050602@cryptsoft.com> Message-ID: On 2015-11-27, 09:28 GMT, Tim Hudson wrote: > http://www.mail-archive.com/openssl-dev at openssl.org/msg28042.html That?s http://article.gmane.org/gmane.comp.encryption.openssl.devel/17997/ for those afflicted with gmane?s mangling of anything looking like an email address. Mat?j -- https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC See, when the GOVERNMENT spends money, it creates jobs; whereas when the money is left in the hands of TAXPAYERS, God only knows what they do with it. Bake it into pies, probably. Anything to avoid creating jobs. -- Dave Barry From noloader at gmail.com Fri Nov 27 13:40:26 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 27 Nov 2015 08:40:26 -0500 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: <56578700.10903@gmail.com> References: <56578700.10903@gmail.com> Message-ID: > OpenSSL doesn't support it out of the box. What you're looking for > is something akin to > https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme. +1 on ECIES. If OpenSSL provided one additional, non core feature, ECIES would be at the top of my list. Its hard to use incorrectly, and easy to use correctly. Its also IND_CCA2, which provides a number of desirable security properties. In my day job, I recommend it whenever I come across a home grown scheme rolled by the developers. > Ladar Levison has written an implementation which uses OpenSSL as a > backend. I tried finding it for you, but my connection (mobile, on > train) is so bad that I couldn't be bothered to keep trying. > Speaking from experience, be careful of interop issues. I know of two libraries that support ECIES out of the box. They are BouncyCastle and Crypto++. In the past BouncyCastle and Crypto++ could not interop even though they both claim to follow P1363. IEEE did not publish test vectors, so each library had a misinterpretation that ensured they did not interop. Here were the issues for each library: * BouncyCastle - Label should be 8 octets * Crypto++ - Length of the label specified in bits BouncyCastle fixed their issue in version 1.53 (about 2 months ago). Crypto++ is fixing their issue at 5.7 (in about 2 months). If you need a "gold" standard, then use BouncyCastle's implementation, version 5.7 or above. Jeff From leonb at parsec.co.za Fri Nov 27 14:02:50 2015 From: leonb at parsec.co.za (Leon Brits) Date: Fri, 27 Nov 2015 14:02:50 +0000 Subject: [openssl-users] FIPS certification for AES GCM mode algorithm In-Reply-To: <15b650a8b7204459bf9440a6e75d2318@EXCHANGESRV.PARSEC.local> References: <15b650a8b7204459bf9440a6e75d2318@EXCHANGESRV.PARSEC.local> Message-ID: <9bec7b20fb8e4639b0cd8fc4575bb0e3@EXCHANGESRV.PARSEC.local> To answer my own question: Use 512, 1024 and 504, 1016 in both cases -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Nov 27 16:59:59 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 27 Nov 2015 16:59:59 +0000 Subject: [openssl-users] Better understanding of EC encryption API In-Reply-To: <56582429.5020703@openssl.org> References: <5657649A.4050900@openssl.org> <20151127040712.GC18315@mournblade.imrryr.org> <56582429.5020703@openssl.org> Message-ID: <20151127165959.GD18315@mournblade.imrryr.org> On Fri, Nov 27, 2015 at 09:36:41AM +0000, Matt Caswell wrote: > >> OpenSSL only supports ECDH and ECDSA, neither of which can be used to > >> perform encryption. > > > > This is not entirely true, in sufficiently recent versions of > > OpenSSL, ECDSA keys can be used with CMS to encrypt keys. > > Well, perhaps I should modify the statement to say > "OpenSSL only supports ECDH and ECDSA, neither of which can be used *by > themselves* to perform encryption." Of course, but I generally interpret requests for "encryption" with EC to mean the ability to exchange encrypted messages with the holder of an EC public key. In which case, CMS provides a broadly interoperable mechanism to do so. > I'm not particularly familiar with CMS but from my very quick reading of > what is going on in your example is that the EC key is being used by > ECDH to agree a shared secret (in combination with a KDF). Correct. > Then AES128 > key wrapping is used to encrypt the CEK, followed by AES to actually > encrypt the data. So ECDH is not encrypting anything directly (it can't > - its not an encryption algorithm - it a key agreement algorithm). Correct, as described in RFC 3278 the KEK from the key agreement encrypts the CEK. This supports multi-recipient messages with a single CEK and (unavoidably) a separate KEK for each recipient derived from the ephemeral-fixed key agreement. The CMS API takes care of the internal details, but can be difficult to learn because of its flexibility (signed or unsigned, encrypted or unencrypted, detached signatures, ...). -- Viktor. From matt at openssl.org Mon Nov 30 15:38:12 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 30 Nov 2015 15:38:12 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: <565C6D64.8010003@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh. These releases will be made available on 3rd December between approx. 1pm and 5pm (UTC). They will fix a number of security defects, the highest of which is classified as "moderate" severity. Please note that the OpenSSL project has recently revised its severity definitions by introducing a new "critical" level, i.e. the severity levels are now: critical, high, moderate and low. Please see the following page for further details: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, the 1.0.0 and 0.9.8 releases will no longer be receiving security updates after the end of this year. This means that, barring any unexpected significant security issues between now and 31st December 2015, it is likely that these releases will be the last ones for 1.0.0 and 0.9.8. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWXG1kAAoJENnE0m0OYESR3vgH/0R7GCsN4moof7ezQIbZbxxN qeiwH2SGj0a5KXM/J9Ee4jcQWA2n0SfUeFbgLSvqBO8BQdz3oTJMF45Z+gXjWFqZ OiEQ+ZFayNm/Tb46OFhglbRBhfb7Je4sy4i8cSW6wGQ2EdWz3JN/xWC0q9KMqQpi k8IwitBK3WxZ/Je+rHZvsDzABWd3Jf2+QlDjwHXxSfrW9UBc5Wr7e+d5XMQk2KML FGJtkucAFs+AiOWvfsJ2WzFYy373M7pYQT38ODOuvT9HxMHzDY89kj2BsFjr8pZY yIk9fAE1BTKRoNoUPETVuYi0Wq+xFHgV5urFQztxglWymcxAILHOZ+PZDyT/m5Q= =QGvN -----END PGP SIGNATURE----- From paliopipis at gmail.com Mon Nov 30 20:02:49 2015 From: paliopipis at gmail.com (findor) Date: Mon, 30 Nov 2015 13:02:49 -0700 (MST) Subject: [openssl-users] OpenSSL - asn1parse how to use offset-hlentgth-length Message-ID: <1448913769989-61324.post@n7.nabble.com> Hi there, I have this project on MD5 collision that I'm working on and I have a problem understanding something. I have a certificate in DER encoding. I need to "export" from it the header, the prefix, the public modulus etc., using xxd. I can't understand how exactly I have to read the data an1parse (or dumpasn1) gives me, so I can put the right values for -s and -l to xxd. For example, for the public modulus, I put in -s the byte where the BIT STRING starts? or where the actual public modulus starts? And that means that the prefix will contain everything until the point where the public modulus starts? The professor has given us an example of how to do it, but in the part of the xxd commands he has given us only the commands without the structure of the file he used. Next question: In the second image, why is he creating a .pfx2 with 6 bytes more, which are from the public modulus "block"? (Someone would think he has explained all this, but no he hasn't.) And last question, if I understand correctly what we want to do here is that the first thing we want to apply the MD5 collision on is the public modulus, but instead he uses .pfx2 on fastcoll. I've attached the whole file with the commands for better understanding.X.rtf Can anyone help? Thanks in advance -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-asn1parse-how-to-use-offset-hlentgth-length-tp61324.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Michael.Wojcik at microfocus.com Mon Nov 30 22:46:45 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 30 Nov 2015 22:46:45 +0000 Subject: [openssl-users] long (~2.5 minute) delay in TLS handshake Message-ID: I'm curious if anyone has seen anything like this before. We have a situation at one customer site. They see it happen every few days. No one else has reported it, and we can't reproduce it. There's a Linux server, listening on multiple ports, handling lots of conversations (multiplexed with poll). Various protocols, some TLS, others not. Clients from many remote systems connect to this server. Some conversations are short-lived, others long-lived. Four of the ports are handling Telnet (TN3270) traffic, over TLS. Sometimes one of the ports stops responding to new conversations, from the client's point of view. Other clients continue to connect to other ports owned by the same server process; established conversations continue to work. After a while (maybe 15 minutes or so), the problem goes away. Note, again, that this only applies to new conversations on this one port. Everything else in the same process is happy. A wire trace taken while the problem is occuring shows: 1. Client sends ClientHello; server stack ACKs it immediately. 2. A minute passes with no activity on the conversation. 3. Client gives up - we get a FIN from it. Server stack ACKs the FIN immediately. 4. Almost a minute and a half later (89 seconds in the case I'm looking at), the server happily sends the ServerHello. Well, that's a bit too late, and there's the usual crying and recriminations (RSTs from the client stack). So nearly 2.5 minutes between ClientHello being received by the server machine's stack, and the ServerHello appearing on the wire. We know there's nothing generally wrong with the network or machines, and the processes in question are otherwise behaving normally. ServerHello shows the server chose TLS_RSA_WITH_AES_256_CBC_SHA (TLS/1.0), so there's nothing screwy like computing DH parameters happening behind the covers. It's too early in the process for certificate validation callbacks to be invoked. Or for nearly anything else to be happening. All the server has is the ClientHello. One thing I don't have at this point is any tracepoints I can have the customer enable to see if, say, we're getting a lot of SSL_WANT_READ or SSL_WANT_WRITE from SSL_accept. The socket should be in blocking mode, though it's possible there's some bug there. The logic here is not exotic. It's along the lines of: desc = accept(master, ...); ssl = SSL_new(ctx); SSL_set_fd(ssl, desc); SSL_accept(ssl); There's some setting of socket options like SO_KEEPALIVE and ex_data so we can recover our info in the callbacks, but really it's all pretty standard. Any ideas? -- Michael Wojcik Technology Specialist, Micro Focus Please consider the environment before printing this e-mail. From kurt at roeckx.be Mon Nov 30 23:38:04 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 1 Dec 2015 00:38:04 +0100 Subject: [openssl-users] long (~2.5 minute) delay in TLS handshake In-Reply-To: References: Message-ID: <20151130233803.GA10359@roeckx.be> On Mon, Nov 30, 2015 at 10:46:45PM +0000, Michael Wojcik wrote: > I'm curious if anyone has seen anything like this before. > > We have a situation at one customer site. They see it happen every few days. No one else has reported it, and we can't reproduce it. Have you considered that this might be a path MTU discovery issue and that the TCP layer is just resending the (too large) packet without it reaching the other side? Kurt