From de.techno at gmail.com Sun Mar 1 12:11:03 2015 From: de.techno at gmail.com (dE) Date: Sun, 01 Mar 2015 17:41:03 +0530 Subject: [openssl-dev] s_server does not work over localhost. Message-ID: <54F301D7.8010409@gmail.com> Hi! There appears to be a bug in the openssl program which has persisted for years (as it appears from the Google search results). I'm using s_server as follows openssl s_server -accept 8888 -cert issuer.pem -key issuer.key If the incoming connection is from localhost -- Using default temp DH parameters Using default temp ECDH parameters ACCEPT gethostbyname failure 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 0 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 0 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) I dont understand why it runs gethostbyname on the incoming address in the 1st place. From kurt at roeckx.be Sun Mar 1 14:37:48 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Mar 2015 15:37:48 +0100 Subject: [openssl-dev] s_server does not work over localhost. In-Reply-To: <54F301D7.8010409@gmail.com> References: <54F301D7.8010409@gmail.com> Message-ID: <20150301143748.GA24216@roeckx.be> On Sun, Mar 01, 2015 at 05:41:03PM +0530, dE wrote: > Hi! > > gethostbyname failure This probably means that you don't have localhost in /etc/hosts Kurt From de.techno at gmail.com Sun Mar 1 14:42:25 2015 From: de.techno at gmail.com (dE) Date: Sun, 01 Mar 2015 20:12:25 +0530 Subject: [openssl-dev] s_server does not work over localhost. In-Reply-To: <20150301143748.GA24216@roeckx.be> References: <54F301D7.8010409@gmail.com> <20150301143748.GA24216@roeckx.be> Message-ID: <54F32551.5000403@gmail.com> On 03/01/15 20:07, Kurt Roeckx wrote: > On Sun, Mar 01, 2015 at 05:41:03PM +0530, dE wrote: >> Hi! >> >> gethostbyname failure > This probably means that you don't have localhost in /etc/hosts > > > Kurt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 127.0.0.1 DESKTOP_MINER localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 ::1 localhost From kurt at roeckx.be Sun Mar 1 15:01:07 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Mar 2015 16:01:07 +0100 Subject: [openssl-dev] s_server does not work over localhost. In-Reply-To: <54F32551.5000403@gmail.com> References: <54F301D7.8010409@gmail.com> <20150301143748.GA24216@roeckx.be> <54F32551.5000403@gmail.com> Message-ID: <20150301150107.GA24737@roeckx.be> On Sun, Mar 01, 2015 at 08:12:25PM +0530, dE wrote: > On 03/01/15 20:07, Kurt Roeckx wrote: > >On Sun, Mar 01, 2015 at 05:41:03PM +0530, dE wrote: > >>Hi! > >> > >>gethostbyname failure > >This probably means that you don't have localhost in /etc/hosts > > 127.0.0.1 DESKTOP_MINER localhost.localdomain localhost > ::1 localhost6.localdomain6 localhost6 > ::1 localhost Then I'm not sure why it breaks for you, it works for me. But then there is no reason for it to first to gethostbyaddr and then gethostbyname. Kurt From matt at openssl.org Sun Mar 1 17:23:16 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 01 Mar 2015 17:23:16 +0000 Subject: [openssl-dev] Suspicious crash in 1.0.2 In-Reply-To: References: Message-ID: <54F34B04.5010701@openssl.org> On 28/02/15 06:53, Erik Forsberg wrote: > Hi. > I seem to have run into a really hard to pin down issue in > OpenSSL 1.0.2. Normally, it simply causes an EFAULT during > a write syscall, which makes me close the connection, but > to investigate, I added a core dump at that time. This is what I see > Hi Erik Thanks for the really useful analysis of this issue. Please could you try out the attached patch and see if that solves things for you? Let me know how you get on. Many thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: multiblock.patch Type: text/x-patch Size: 489 bytes Desc: not available URL: From rsalz at akamai.com Sun Mar 1 17:48:33 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 1 Mar 2015 17:48:33 +0000 Subject: [openssl-dev] s_server does not work over localhost. In-Reply-To: <54F301D7.8010409@gmail.com> References: <54F301D7.8010409@gmail.com> Message-ID: > I dont understand why it runs gethostbyname on the incoming address in the > 1st place. To see if it's an AF_INET incoming address. It does seem kinda silly. From erik at efca.com Mon Mar 2 01:54:01 2015 From: erik at efca.com (Erik Forsberg) Date: Sun, 1 Mar 2015 17:54:01 -0800 Subject: [openssl-dev] Suspicious crash in 1.0.2 Message-ID: This patch fixes the issue. I had a similar fix, but yours is more complete. Thanks. Another thought. As I looked at this multiblock code I realize it will have some impact on memory usage. Thinking it might be good to have an option to disable the function at runtime so one can chose between memory savings and performance. Particularly in the main branch where these OPENSS_NO_XXX compile time options are going away ? >-- Original Message -- > > > > >On 28/02/15 06:53, Erik Forsberg wrote: >> Hi. >> I seem to have run into a really hard to pin down issue in >> OpenSSL 1.0.2. Normally, it simply causes an EFAULT during >> a write syscall, which makes me close the connection, but >> to investigate, I added a core dump at that time. This is what I see >> > > >Hi Erik > >Thanks for the really useful analysis of this issue. > >Please could you try out the attached patch and see if that solves >things for you? Let me know how you get on. > >Many thanks > >Matt > > >Attachment: multiblock.patch (0.5 KB) > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From ikonta at yandex.ru Mon Mar 2 05:58:21 2015 From: ikonta at yandex.ru (Ikonta) Date: Mon, 02 Mar 2015 08:58:21 +0300 Subject: [openssl-dev] openssl x509 -text incorrectly displays non-latin (non-ansi) symbols (missed '-utf8 option?) In-Reply-To: <2347421424844375@web1m.yandex.ru> Message-ID: <14354401425275901@web1o.yandex.ru> AFAIR in 2004 openssl switched to UTF8 as default bitmask in certificate. But ANSI extension's of utf8 support is still incomplete: $ openssl x509 -text -in localhost-server.crt Certificate: ????Data: ????????Version: 3 (0x2) ????????Serial Number: 1 (0x1) ????Signature Algorithm: sha256WithRSAEncryption ????????Issuer: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, L=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache, CN=\xD1\x82\xD0\xB5\xD1\x81\xD1\x82\xD0\xBE\xD0\xB2\xD1\x8B\xD0\xB9 \xD0\xA6\xD0\x90/emailAddress=root at localhost ????????Validity ????????????Not Before: Feb ?6 08:28:23 2015 GMT ????????????Not After : Sep 15 08:28:23 2020 GMT ????????Subject: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache web server, CN=localhost/emailAddress=apache at localhost ? (not attaching exanple certificate file because mail list seems to reject such letters) displays utf8 symbol codes instead of expected human-readably letters (in this case ? ?cyrillic), shown after import this certificate into browser's profile. Probably adding -utf8 option for x509 command should fix this particular issue. P.S. I use =dev-libs/openssl-1.0.1k amd64 build on Gentoo GNU/Linux. From erwann.abalea at opentrust.com Mon Mar 2 09:14:40 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Mon, 02 Mar 2015 10:14:40 +0100 Subject: [openssl-dev] openssl x509 -text incorrectly displays non-latin (non-ansi) symbols (missed '-utf8 option?) In-Reply-To: <14354401425275901@web1o.yandex.ru> References: <14354401425275901@web1o.yandex.ru> Message-ID: <54F42A00.9010505@opentrust.com> Bonjour, Probably an openssl-users question. Use "openssl x509 -text -in localhost-server.crt -nameopt oneline,utf8,-esc_msb" Your terminal must be able to display UTF8 sequences. I sometimes add the "show_type" nameopt option, to check things. -- Erwann ABALEA Le 02/03/2015 06:58, Ikonta a ?crit : > AFAIR in 2004 openssl switched to UTF8 as default bitmask in certificate. > But ANSI extension's of utf8 support is still incomplete: > > $ openssl x509 -text -in localhost-server.crt > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha256WithRSAEncryption > Issuer: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, L=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache, CN=\xD1\x82\xD0\xB5\xD1\x81\xD1\x82\xD0\xBE\xD0\xB2\xD1\x8B\xD0\xB9 \xD0\xA6\xD0\x90/emailAddress=root at localhost > Validity > Not Before: Feb 6 08:28:23 2015 GMT > Not After : Sep 15 08:28:23 2020 GMT > Subject: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache web server, CN=localhost/emailAddress=apache at localhost > ? > (not attaching exanple certificate file because mail list seems to reject such letters) > displays utf8 symbol codes instead of expected human-readably letters (in this case ? cyrillic), shown after import this certificate into browser's profile. > > Probably adding -utf8 option for x509 command should fix this particular issue. > > P.S. I use =dev-libs/openssl-1.0.1k amd64 build on Gentoo GNU/Linux. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Mon Mar 2 13:46:16 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 02 Mar 2015 13:46:16 +0000 Subject: [openssl-dev] Suspicious crash in 1.0.2 In-Reply-To: References: Message-ID: <54F469A8.6080607@openssl.org> On 02/03/15 01:54, Erik Forsberg wrote: > This patch fixes the issue. > I had a similar fix, but yours is more complete. > Thanks. > > Another thought. As I looked at this multiblock code I realize it > will have some impact on memory usage. Thinking it might be good > to have an option to disable the function at runtime so one can chose > between memory savings and performance. Particularly in the main > branch where these OPENSS_NO_XXX compile time options are going away ? You can already use OPENSSL_SMALL_FOOTPRINT for this purpose. Matt From rt at openssl.org Mon Mar 2 15:28:13 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 2 Mar 2015 16:28:13 +0100 Subject: [openssl-dev] [openssl.org #3708] segfault while generating a certificate signing request based on a malformed certificate In-Reply-To: References: Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Mar 2 17:06:06 2015 From: rt at openssl.org (Alex Sklyar via RT) Date: Mon, 2 Mar 2015 18:06:06 +0100 Subject: [openssl-dev] [openssl.org #3726] Cocoapods install BUG In-Reply-To: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> References: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> Message-ID: Hello guys. There is a issue with openssl pod installing with cocoapods tool. The URL ?https://www.openssl.org/source/openssl-1.0.2.tar.gz? is dead. Downloading dependencies -> Installing OpenSSL (1.0.200) > Http download $ /usr/bin/curl -f -L -o /Users/Quizer/Development/iOS/testOpenSsl/Pods/OpenSSL/file.tgz "https://www.openssl.org/source/openssl-1.0.2.tar.gz" --create-dirs % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 404 Not Found [!] Error installing OpenSSL [!] /usr/bin/curl -f -L -o /Users/Quizer/Development/iOS/testOpenSsl/Pods/OpenSSL/file.tgz "https://www.openssl.org/source/openssl-1.0.2.tar.gz" --create-dirs % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (22) The requested URL returned error: 404 Not Found From erwann.abalea at opentrust.com Mon Mar 2 17:27:25 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Mon, 02 Mar 2015 18:27:25 +0100 Subject: [openssl-dev] [openssl.org #3726] Cocoapods install BUG In-Reply-To: References: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> Message-ID: <54F49D7D.8000204@opentrust.com> It seems all the tarballs have disappeared. -- Erwann ABALEA Le 02/03/2015 18:06, Alex Sklyar via RT a ?crit : > Hello guys. There is a issue with openssl pod installing with cocoapods tool. The URL ?https://www.openssl.org/source/openssl-1.0.2.tar.gz? is dead. > From tshort at akamai.com Mon Mar 2 18:05:36 2015 From: tshort at akamai.com (Short, Todd) Date: Mon, 2 Mar 2015 12:05:36 -0600 Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking of self-signed certificates In-Reply-To: References: <761813D4-0DE6-4726-A987-FF943C152041@akamai.com> Message-ID: <29E29F99-5259-42F2-A52B-83F8DD9014B5@akamai.com> This code is currently being used by Akamai to check for the validity of certificates. I find it highly unusual for multiple certificates to have the same SubjectDN to be valid simultaneously. All those certificates would need to have a unique serial number; but the Issuer?s serial number is is not included in the certificate, so there?s no easy way to determine the issuing certificate. To validate those chains, the signature would have to be validated using the public key of each certificate that matches the Issuer. That can be an expensive proposition, and there are clients that will give up after the first failure. Have you seen any chains like this IRL? Do you know of any CA that have their chains set up like this? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Feb 27, 2015, at 5:31 PM, Brian Smith > wrote: Short, Todd via RT > wrote: Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer. Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that. Github link: https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b Could you explain this more? In your patch, there is a comment that says "Input certificate (subject) is self signed." But, the test is that the issuer name equals the subject name. That means the certificate is self-*issued*, not self-*signed*. Consider this chain: { Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key2 } { Subject=Foo, Issuer=Foo, Key=Key2, Signed by Key3 } { Subject=Foo, Issuer=Foo, Key=Key3, Signed by Key3, Trust Anchor } All three certificates are self-issued. The issuer of the first certificate is not self-signed but it is self-issued. But, it being self-issued doesn't matter because it isn't a trust anchor. Consider this chain: { Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key1 } { Subject=Foo, Issuer=Bar, Key=Key1, Signed by Key2 } { Subject=Bar, Issuer=Bar, Key=Key2, Signed by Key2, Trust Anchor } The first certificate is self-signed and self-issued. It's issuer is not self-signed or self-issued, so your patch would reject this chain. But, this is a valid chain. Cheers, Brian _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Mar 2 18:06:05 2015 From: rt at openssl.org (Short, Todd via RT) Date: Mon, 2 Mar 2015 19:06:05 +0100 Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking of self-signed certificates In-Reply-To: <29E29F99-5259-42F2-A52B-83F8DD9014B5@akamai.com> References: <761813D4-0DE6-4726-A987-FF943C152041@akamai.com> <29E29F99-5259-42F2-A52B-83F8DD9014B5@akamai.com> Message-ID: This code is currently being used by Akamai to check for the validity of certificates. I find it highly unusual for multiple certificates to have the same SubjectDN to be valid simultaneously. All those certificates would need to have a unique serial number; but the Issuer?s serial number is is not included in the certificate, so there?s no easy way to determine the issuing certificate. To validate those chains, the signature would have to be validated using the public key of each certificate that matches the Issuer. That can be an expensive proposition, and there are clients that will give up after the first failure. Have you seen any chains like this IRL? Do you know of any CA that have their chains set up like this? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Feb 27, 2015, at 5:31 PM, Brian Smith > wrote: Short, Todd via RT > wrote: Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer. Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that. Github link: https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b Could you explain this more? In your patch, there is a comment that says "Input certificate (subject) is self signed." But, the test is that the issuer name equals the subject name. That means the certificate is self-*issued*, not self-*signed*. Consider this chain: { Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key2 } { Subject=Foo, Issuer=Foo, Key=Key2, Signed by Key3 } { Subject=Foo, Issuer=Foo, Key=Key3, Signed by Key3, Trust Anchor } All three certificates are self-issued. The issuer of the first certificate is not self-signed but it is self-issued. But, it being self-issued doesn't matter because it isn't a trust anchor. Consider this chain: { Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key1 } { Subject=Foo, Issuer=Bar, Key=Key1, Signed by Key2 } { Subject=Bar, Issuer=Bar, Key=Key2, Signed by Key2, Trust Anchor } The first certificate is self-signed and self-issued. It's issuer is not self-signed or self-issued, so your patch would reject this chain. But, this is a valid chain. Cheers, Brian _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Mon Mar 2 18:31:46 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 2 Mar 2015 18:31:46 +0000 Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking of self-signed certificates In-Reply-To: References: <761813D4-0DE6-4726-A987-FF943C152041@akamai.com> Message-ID: <20150302183145.GC1260@mournblade.imrryr.org> On Fri, Feb 27, 2015 at 09:14:08PM +0100, Short, Todd via RT wrote: > Hello OpenSSL Org: > > This is a change that Akamai has made to its implementation of OpenSSL. > > Version: master branch > Description: Additional checking of self-signed certificates. > > Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer. > Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that. > > Github link: > https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b What motivates this proposed change? What issues did you run into without it? -- Viktor. From jeremy.farrell at oracle.com Mon Mar 2 17:50:58 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 02 Mar 2015 17:50:58 +0000 Subject: [openssl-dev] [openssl.org #3726] Cocoapods install BUG In-Reply-To: <54F49D7D.8000204@opentrust.com> References: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> <54F49D7D.8000204@opentrust.com> Message-ID: <54F4A302.40100@oracle.com> And the table linking to the latest releases on https://www.openssl.org/source/ is empty. On 02/03/2015 17:27, Erwann Abalea wrote: > It seems all the tarballs have disappeared. > Le 02/03/2015 18:06, Alex Sklyar via RT a ?crit : > Hello guys. There is a issue with openssl pod installing with > cocoapods tool. The URL > ?https://www.openssl.org/source/openssl-1.0.2.tar.gz? is dead. -- J. J. Farrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Mar 2 19:42:05 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 02 Mar 2015 19:42:05 +0000 Subject: [openssl-dev] [openssl.org #3726] Cocoapods install BUG In-Reply-To: <54F4A302.40100@oracle.com> References: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> <54F49D7D.8000204@opentrust.com> <54F4A302.40100@oracle.com> Message-ID: <54F4BD0D.1040006@openssl.org> On 02/03/15 17:50, Jeremy Farrell wrote: > And the table linking to the latest releases on > https://www.openssl.org/source/ is empty. > > On 02/03/2015 17:27, Erwann Abalea wrote: >> It seems all the tarballs have disappeared. > >> Le 02/03/2015 18:06, Alex Sklyar via RT a ?crit : >> Hello guys. There is a issue with openssl pod installing with >> cocoapods tool. The URL >> ?https://www.openssl.org/source/openssl-1.0.2.tar.gz? is dead. > It should all be fixed now. Sorry for the inconvenience. Matt From dwmw2 at infradead.org Tue Mar 3 08:18:17 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Mar 2015 08:18:17 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1424702049.5437.222.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> Message-ID: <1425370697.3359.47.camel@infradead.org> On Mon, 2015-02-23 at 14:34 +0000, David Woodhouse wrote: > I have created pull requests on Github for HEAD and 1.0.2: > https://github.com/openssl/openssl/pull/228 (master) > https://github.com/openssl/openssl/pull/229 (OpenSSL_1_0_2-stable) > > These contain the fixes I have already filed in RT#3703, RT#3704 and > RT#3711. > > For master, it also introduces DTLSv0_9_client_method() as discussed? in > RT#3711. I didn't do that for 1.0.2 but perhaps we could. RT#3704 is now fixed in HEAD and 1.0.2 (thanks), and I've updated the above tree to carry just the pending fixes for RT#3703 and RT#3711... -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From matt at openssl.org Tue Mar 3 08:58:38 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 08:58:38 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425370697.3359.47.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> Message-ID: <54F577BE.3070402@openssl.org> On 03/03/15 08:18, David Woodhouse wrote: > On Mon, 2015-02-23 at 14:34 +0000, David Woodhouse wrote: >> I have created pull requests on Github for HEAD and 1.0.2: >> https://github.com/openssl/openssl/pull/228 (master) >> https://github.com/openssl/openssl/pull/229 (OpenSSL_1_0_2-stable) >> >> These contain the fixes I have already filed in RT#3703, RT#3704 and >> RT#3711. >> >> For master, it also introduces DTLSv0_9_client_method() as discussed? in >> RT#3711. I didn't do that for 1.0.2 but perhaps we could. > > RT#3704 is now fixed in HEAD and 1.0.2 (thanks), and I've updated the > above tree to carry just the pending fixes for RT#3703 and RT#3711... Hi David Fixes for #3703 and #3711 are currently going through the review process so should be in soon hopefully. I've not looked at the DTLSv0_9_client_method() stuff for master as yet. Matt From dwmw2 at infradead.org Tue Mar 3 11:36:15 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Mar 2015 11:36:15 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F577BE.3070402@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> Message-ID: <1425382575.3359.57.camel@infradead.org> On Tue, 2015-03-03 at 08:58 +0000, Matt Caswell wrote: > Fixes for #3703 and #3711 are currently going through the review > process so should be in soon hopefully. Thanks. Should I have known that? I've been monitoring RT (when it's up) and the mailing list, but is there somewhere else I should have been looking? > I've not looked at the DTLSv0_9_client_method() stuff for master as > yet. That's less of a priority, of course, since it isn't a regression. I'll look at adding test cases to exercise the DTLS_BAD_VER support, to try to avoid this kind of thing happening in future. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From matt at openssl.org Tue Mar 3 12:00:37 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 12:00:37 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425382575.3359.57.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> Message-ID: <54F5A265.4070902@openssl.org> On 03/03/15 11:36, David Woodhouse wrote: > On Tue, 2015-03-03 at 08:58 +0000, Matt Caswell wrote: >> Fixes for #3703 and #3711 are currently going through the review >> process so should be in soon hopefully. > > Thanks. Should I have known that? I've been monitoring RT (when it's up) > and the mailing list, but is there somewhere else I should have been > looking? No - I haven't updated RT - sorry. When Richard gets RT back from wherever its gone to I'll update the tickets. > >> I've not looked at the DTLSv0_9_client_method() stuff for master as >> yet. > > That's less of a priority, of course, since it isn't a regression. > > I'll look at adding test cases to exercise the DTLS_BAD_VER support, to > try to avoid this kind of thing happening in future. > That would be fantastic to have. Matt From dwmw2 at infradead.org Tue Mar 3 14:28:09 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Mar 2015 14:28:09 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F5A265.4070902@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> Message-ID: <1425392889.3033.34.camel@infradead.org> On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: > > > I'll look at adding test cases to exercise the DTLS_BAD_VER support, > to > > try to avoid this kind of thing happening in future. > > > > That would be fantastic to have. I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to ssl/ssltest.c isn't particularly hard, but we don't actually *have* server support for DTLS1_BAD_VER. I suppose I could fix it up, but it doesn't seem to make a lot of sense. It's the wrong thing to test against *anyway* since there are plenty of failure modes in which a regression could be introduced in generic code and OpenSSL would remain compatible with *itself* anyway. So I'm torn between doing a minimal reimplementation of the server side and making OpenSSL talk to that, or a dirty replay attack such as the one I had when I was first working it out: http://david.woodhou.se/dtls-test.c -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From matt at openssl.org Tue Mar 3 14:43:17 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 14:43:17 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425392889.3033.34.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> Message-ID: <54F5C885.1050302@openssl.org> On 03/03/15 14:28, David Woodhouse wrote: > On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: >> >>> I'll look at adding test cases to exercise the DTLS_BAD_VER support, >> to >>> try to avoid this kind of thing happening in future. >>> >> >> That would be fantastic to have. > > I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to > ssl/ssltest.c isn't particularly hard, If you fancy taking on that task, that would be really useful just in itself. > but we don't actually *have* > server support for DTLS1_BAD_VER. > > I suppose I could fix it up, but it doesn't seem to make a lot of sense. Agreed. > It's the wrong thing to test against *anyway* since there are plenty of > failure modes in which a regression could be introduced in generic code > and OpenSSL would remain compatible with *itself* anyway. > > So I'm torn between doing a minimal reimplementation of the server side > and making OpenSSL talk to that, or a dirty replay attack such as the > one I had when I was first working it out: > http://david.woodhou.se/dtls-test.c > The minimal reimplementation sounds like it might be the more flexible base to work from (and could even be the basis for future DTLSv1/1.2 tests). But it also sounds like quite a bit more work to me. Either way, having *some* tests has got to be a lot better than *no* tests like we have now! Matt From nmav at redhat.com Tue Mar 3 15:03:13 2015 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Tue, 03 Mar 2015 16:03:13 +0100 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F5C885.1050302@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> Message-ID: <1425394993.27126.11.camel@redhat.com> On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote: > > It's the wrong thing to test against *anyway* since there are plenty of > > failure modes in which a regression could be introduced in generic code > > and OpenSSL would remain compatible with *itself* anyway. > > So I'm torn between doing a minimal reimplementation of the server side > > and making OpenSSL talk to that, or a dirty replay attack such as the > > one I had when I was first working it out: > > http://david.woodhou.se/dtls-test.c > The minimal reimplementation sounds like it might be the more flexible > base to work from (and could even be the basis for future DTLSv1/1.2 > tests). But it also sounds like quite a bit more work to me. Either way, > having *some* tests has got to be a lot better than *no* tests like we > have now! I don't know whether you'd like to depend on gnutls for testing, but I have a test of most ciphersuites [0] in common under various protocols between openssl and gnutls. That currently doesn't cope with DTLS0.9 (gnutls' name of DTLS_BAD_VER), but could easily extend to handle it. regards, Nikos [0]. https://gitorious.org/gnutls/gnutls/source/3754af1c694c829c89ea7865ac1718a763c682c4:tests/suite/testcompat-main-openssl From dwmw2 at infradead.org Tue Mar 3 15:14:16 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Mar 2015 15:14:16 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F5C885.1050302@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> Message-ID: <1425395656.3359.68.camel@infradead.org> On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote: > > On 03/03/15 14:28, David Woodhouse wrote: > > On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: > >> > >>> I'll look at adding test cases to exercise the DTLS_BAD_VER support, > >> to > >>> try to avoid this kind of thing happening in future. > >>> > >> > >> That would be fantastic to have. > > > > I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to > > ssl/ssltest.c isn't particularly hard, > > If you fancy taking on that task, that would be really useful just in > itself. This works for 'ssltest -dtls1' but not with -bio_pair for some reason. I got this far before concluding it wasn't going to be a helpful approach... diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c index c535a42..e550704 100644 --- a/ssl/ssl_lib.c +++ b/ssl/ssl_lib.c @@ -2749,6 +2749,12 @@ const char *SSL_get_version(const SSL *s) return ("TLSv1"); else if (s->version == SSL3_VERSION) return ("SSLv3"); + else if (s->version == DTLS1_BAD_VER) + return ("DTLSv0.9"); + else if (s->version == DTLS1_VERSION) + return ("DTLSv1"); + else if (s->version == DTLS1_2_VERSION) + return ("DTLSv1.2"); else return ("unknown"); } diff --git a/ssl/ssltest.c b/ssl/ssltest.c index 89fb44a..511f674 100644 --- a/ssl/ssltest.c +++ b/ssl/ssltest.c @@ -787,6 +787,10 @@ static void sv_usage(void) #ifndef OPENSSL_NO_SSL3_METHOD fprintf(stderr, " -ssl3 - use SSLv3\n"); #endif +#ifndef OPENSSL_NO_DTLS + fprintf(stderr, " -dtls1 - use DTLSv1\n"); + fprintf(stderr, " -dtls12 - use DTLSv1.2\n"); +#endif fprintf(stderr, " -tls1 - use TLSv1\n"); fprintf(stderr, " -CApath arg - PEM format directory of CA's\n"); fprintf(stderr, " -CAfile arg - PEM format file of CA's\n"); @@ -958,7 +962,7 @@ int main(int argc, char *argv[]) int badop = 0; int bio_pair = 0; int force = 0; - int tls1 = 0, ssl3 = 0, ret = 1; + int dtls1 = 0, dtls12 = 0, tls1 = 0, ssl3 = 0, ret = 1; int client_auth = 0; int server_auth = 0, i; struct app_verify_arg app_verify_arg = @@ -1136,6 +1140,16 @@ int main(int argc, char *argv[]) no_protocol = 1; #endif ssl3 = 1; + } else if (strcmp(*argv, "-dtls1") == 0) { +#ifdef OPENSSL_NO_DTLS + no_protocol = 1; +#endif + dtls1 = 1; + } else if (strcmp(*argv, "-dtls12") == 0) { +#ifdef OPENSSL_NO_DTLS + no_protocol = 1; +#endif + dtls12 = 1; } else if (strncmp(*argv, "-num", 4) == 0) { if (--argc < 1) goto bad; @@ -1309,8 +1323,8 @@ int main(int argc, char *argv[]) goto end; } - if (ssl3 + tls1 > 1) { - fprintf(stderr, "At most one of -ssl3, or -tls1 should " + if (ssl3 + tls1 + dtls1 + dtls12 > 1) { + fprintf(stderr, "At most one of -ssl3, -tls1, -dtls1 or -dtls12should " "be requested.\n"); EXIT(1); } @@ -1327,10 +1341,10 @@ int main(int argc, char *argv[]) goto end; } - if (!ssl3 && !tls1 && number > 1 && !reuse && !force) { + if (!ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse && !force) { fprintf(stderr, "This case cannot work. Use -f to perform " "the test anyway (and\n-d to see what happens), " - "or add one of -ssl3, -tls1, -reuse\n" + "or add one of -ssl3, -tls1, -dtls1, dtls12, -reuse\n" "to avoid protocol mismatch.\n"); EXIT(1); } @@ -1403,6 +1417,13 @@ int main(int argc, char *argv[]) meth = SSLv3_method(); else #endif +#ifndef OPENSSL_NO_DTLS + if (dtls1) + meth = DTLSv1_method(); + else if (dtls12) + meth = DTLSv1_2_method(); + else +#endif if (tls1) meth = TLSv1_method(); else > > So I'm torn between doing a minimal reimplementation of the server side > > and making OpenSSL talk to that, or a dirty replay attack such as the > > one I had when I was first working it out: > > http://david.woodhou.se/dtls-test.c > > > The minimal reimplementation sounds like it might be the more flexible > base to work from (and could even be the basis for future DTLSv1/1.2 > tests). But it also sounds like quite a bit more work to me. Either way, > having *some* tests has got to be a lot better than *no* tests like we > have now! Well, the evil "override RAND_bytes() and replay" trick isn't actually working any more. I think I need to disable all extensions so the ClientHello precisely matches the one in my capture, or redo a capture with the options that we currently send.... which all in all is probably a fairly strong hint that I ought not to be doing the replay thing :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Mar 3 15:20:50 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 03 Mar 2015 15:20:50 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425394993.27126.11.camel@redhat.com> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425394993.27126.11.camel@redhat.com> Message-ID: <1425396050.3359.72.camel@infradead.org> On Tue, 2015-03-03 at 16:03 +0100, Nikos Mavrogiannopoulos wrote: > > I don't know whether you'd like to depend on gnutls for testing, but I > have a test of most ciphersuites [0] in common under various protocols > between openssl and gnutls. That currently doesn't cope with DTLS0.9 > (gnutls' name of DTLS_BAD_VER), but could easily extend to handle it. I did think of it, but wasn't going to suggest that I use GnuTLS purely for testing OpenSSL's DTLS1_BAD_VER support. But the script that you have to do systematic interop between OpenSSL and GnuTLS looks like it could be useful for *both* projects. If that's something that the OpenSSL team think could be added to pre-release testing, then adding the Cisco DTLS there would certainly be helpful. I'd then be less worried about *purely* fixing up DTLSv0_9_server_method() and testing that in the OpenSSL internal tests. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From matt at openssl.org Tue Mar 3 15:33:14 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 15:33:14 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425394993.27126.11.camel@redhat.com> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425394993.27126.11.camel@redhat.com> Message-ID: <54F5D43A.5030004@openssl.org> On 03/03/15 15:03, Nikos Mavrogiannopoulos wrote: > On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote: > >>> It's the wrong thing to test against *anyway* since there are plenty of >>> failure modes in which a regression could be introduced in generic code >>> and OpenSSL would remain compatible with *itself* anyway. >>> So I'm torn between doing a minimal reimplementation of the server side >>> and making OpenSSL talk to that, or a dirty replay attack such as the >>> one I had when I was first working it out: >>> http://david.woodhou.se/dtls-test.c >> The minimal reimplementation sounds like it might be the more flexible >> base to work from (and could even be the basis for future DTLSv1/1.2 >> tests). But it also sounds like quite a bit more work to me. Either way, >> having *some* tests has got to be a lot better than *no* tests like we >> have now! > > I don't know whether you'd like to depend on gnutls for testing, but I > have a test of most ciphersuites [0] in common under various protocols > between openssl and gnutls. That currently doesn't cope with DTLS0.9 > (gnutls' name of DTLS_BAD_VER), but could easily extend to handle it. > > regards, > Nikos > > [0]. > https://gitorious.org/gnutls/gnutls/source/3754af1c694c829c89ea7865ac1718a763c682c4:tests/suite/testcompat-main-openssl That's an awesome idea. I love the idea of a cross-implementation test. I see two problems: 1) Probably we can't introduce a gnutls dependency except for those that explicitly request it (e.g. perhaps some developer config flag to enable it) 2) The killer: the gnutls licence is incompatible with the OpenSSL licence ... I don't think (?) that causes a problem if we're just executing the binary (we wouldn't be *linking* to it), but the test script you point to couldn't be incorporated with that licence :-( Matt From matt at openssl.org Tue Mar 3 16:17:44 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 16:17:44 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425395656.3359.68.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425395656.3359.68.camel@infradead.org> Message-ID: <54F5DEA8.7000404@openssl.org> On 03/03/15 15:14, David Woodhouse wrote: > On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote: >> >> On 03/03/15 14:28, David Woodhouse wrote: >>> On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: >>>> >>>>> I'll look at adding test cases to exercise the DTLS_BAD_VER support, >>>> to >>>>> try to avoid this kind of thing happening in future. >>>>> >>>> >>>> That would be fantastic to have. >>> >>> I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to >>> ssl/ssltest.c isn't particularly hard, >> >> If you fancy taking on that task, that would be really useful just in >> itself. > > This works for 'ssltest -dtls1' but not with -bio_pair for some reason. Great. Thanks. I just submitted that patch for review. Matt From nmav at redhat.com Tue Mar 3 16:37:34 2015 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Tue, 03 Mar 2015 17:37:34 +0100 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F5D43A.5030004@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425394993.27126.11.camel@redhat.com> <54F5D43A.5030004@openssl.org> Message-ID: <1425400654.27126.20.camel@redhat.com> On Tue, 2015-03-03 at 15:33 +0000, Matt Caswell wrote: > 2) The killer: the gnutls licence is incompatible with the OpenSSL > licence ... I don't think (?) that causes a problem if we're just > executing the binary (we wouldn't be *linking* to it), but the test > script you point to couldn't be incorporated with that licence :-( If you want to re-use the script I can simply switch the license to BSD-3 clause. regards, Nikos From matt at openssl.org Tue Mar 3 16:42:18 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 03 Mar 2015 16:42:18 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425400654.27126.20.camel@redhat.com> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425394993.27126.11.camel@redhat.com> <54F5D43A.5030004@openssl.org> <1425400654.27126.20.camel@redhat.com> Message-ID: <54F5E46A.2020601@openssl.org> On 03/03/15 16:37, Nikos Mavrogiannopoulos wrote: > On Tue, 2015-03-03 at 15:33 +0000, Matt Caswell wrote: > >> 2) The killer: the gnutls licence is incompatible with the OpenSSL >> licence ... I don't think (?) that causes a problem if we're just >> executing the binary (we wouldn't be *linking* to it), but the test >> script you point to couldn't be incorporated with that licence :-( > > If you want to re-use the script I can simply switch the license to > BSD-3 clause. That's a very generous offer Nikos. Thanks. I'll check with the rest of the team whether that is considered compatible. Matt From tshort at akamai.com Tue Mar 3 21:15:23 2015 From: tshort at akamai.com (Short, Todd) Date: Tue, 3 Mar 2015 15:15:23 -0600 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: References: Message-ID: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> The previous patch file had two bugs due to a swapped argument and the formatting changes (missing braces). The attached is an updated patch. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Provides-IPv6-support-in-s_client-s_server-Patch-ipv.patch Type: application/octet-stream Size: 18167 bytes Desc: 0001-Provides-IPv6-support-in-s_client-s_server-Patch-ipv.patch URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Mar 4 10:54:23 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 4 Mar 2015 11:54:23 +0100 Subject: [openssl-dev] [openssl.org #3726] Cocoapods install BUG In-Reply-To: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> References: <6AD89B1B-8C41-4A1F-BAA2-7030E7AD2531@gmail.com> Message-ID: This was due to a temporary issue on the openssl website. Should all be fixed so closing this ticket. Matt From rt at openssl.org Thu Mar 5 04:22:06 2015 From: rt at openssl.org (=?UTF-8?B?7KCE7KeA7ZiE?= via RT) Date: Thu, 5 Mar 2015 05:22:06 +0100 Subject: [openssl-dev] [openssl.org #3727] Question about ECC Patent In-Reply-To: <1ef514a147a9a7afafed451b2ec7eb@cweb09.nm.nhnsystem.com> References: <372a454157db5589d315fdd3185e4d3@cweb26.nm.nhnsystem.com> <7DE5DB67BDFC5641AF67737FC9E91E1469C8AF58@XMB116CNC.rim.net> <1ef514a147a9a7afafed451b2ec7eb@cweb09.nm.nhnsystem.com> Message-ID: Hi! I am developing a software. I want to use the OpenSSL ECDSA library to my software. So, I would like to know if there is a legal problem using ECDSA in Openssl. For example, patent issues, license etc. Can I use ECDSA library without legal problem? Please answer.. From dragon at dancingdragon.be Thu Mar 5 21:19:44 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Thu, 05 Mar 2015 13:19:44 -0800 Subject: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7 Message-ID: <54F8C870.1020005@dancingdragon.be> Hello, I'm trying to build openssl-1.0.2 for windows. I successfully built win32 binaries, but I can't seem to build win64a. I get reasonably far into the build, but then it fails doing AES nasm calls. Previous nasm calls succeed. perl Configure VC-WIN64A --prefix=Output\Win64\Release ms\do_win64a nmake -f ms\nt.mak ... nasm -f win64 -DNEAR -Ox -g -o tmp32\aesni-sha256-x86_64.obj tmp32\aesni-sha256-x86_64.asm tmp32\aesni-sha256-x86_64.asm:113: error: symbol `__imp_RtlVirtualUnwind' undefined tmp32\aesni-sha256-x86_64.asm:130: error: symbol `L$SEH_begin_aesni_cbc_sha256_enc_xop' undefined tmp32\aesni-sha256-x86_64.asm:131: error: symbol `L$SEH_end_aesni_cbc_sha256_enc_xop' undefined tmp32\aesni-sha256-x86_64.asm:132: error: symbol `L$SEH_info_aesni_cbc_sha256_enc_xop' undefined tmp32\aesni-sha256-x86_64.asm:134: error: symbol `L$SEH_begin_aesni_cbc_sha256_enc_avx' undefined tmp32\aesni-sha256-x86_64.asm:135: error: symbol `L$SEH_end_aesni_cbc_sha256_enc_avx' undefined tmp32\aesni-sha256-x86_64.asm:136: error: symbol `L$SEH_info_aesni_cbc_sha256_enc_avx' undefined NMAKE : fatal error U1077: '"C:\Program Files (x86)\NASM\nasm.EXE"' : return code '0x1' Any ideas? thanks, Joey From de.techno at gmail.com Thu Mar 5 06:33:55 2015 From: de.techno at gmail.com (dE) Date: Thu, 05 Mar 2015 12:03:55 +0530 Subject: [openssl-dev] s_server does not work over localhost. In-Reply-To: <20150301150107.GA24737@roeckx.be> References: <54F301D7.8010409@gmail.com> <20150301143748.GA24216@roeckx.be> <54F32551.5000403@gmail.com> <20150301150107.GA24737@roeckx.be> Message-ID: <54F7F8D3.2040009@gmail.com> On 03/01/15 20:31, Kurt Roeckx wrote: > On Sun, Mar 01, 2015 at 08:12:25PM +0530, dE wrote: >> On 03/01/15 20:07, Kurt Roeckx wrote: >>> On Sun, Mar 01, 2015 at 05:41:03PM +0530, dE wrote: >>>> Hi! >>>> >>>> gethostbyname failure >>> This probably means that you don't have localhost in /etc/hosts >> 127.0.0.1 DESKTOP_MINER localhost.localdomain localhost >> ::1 localhost6.localdomain6 localhost6 >> ::1 localhost > Then I'm not sure why it breaks for you, it works for me. But > then there is no reason for it to first to gethostbyaddr and then > gethostbyname. > > > Kurt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev There's a problem with OpenSSL lib. It's skin deep. I'll start another thread about this. From de.techno at gmail.com Thu Mar 5 06:48:34 2015 From: de.techno at gmail.com (dE) Date: Thu, 05 Mar 2015 12:18:34 +0530 Subject: [openssl-dev] openssl (lib and application) localhost problems. Message-ID: <54F7FC42.9070202@gmail.com> First I encountered problems here -- https://mta.openssl.org/pipermail/openssl-dev/2015-March/000806.html Guessing if this's a openssl command related problem, but now I've problems in code. SSL_library_init(); SSL_load_error_strings(); const SSL_METHOD* meth; meth = TLSv1_2_method(); SSL_CTX* ctx = SSL_CTX_new(meth); if ( ctx == NULL ) { printf ("ERROR: TLS internal error!\n"); } SSL* sslconnection = SSL_new (ctx); BIO* bioconnection = BIO_new(BIO_s_socket()); int hSocket = 0; struct sockaddr_in server; server.sin_family = AF_INET; server.sin_port = htons(80); server.sin_addr.s_addr = inet_addr ("104.68.173.123"); hSocket = socket(AF_INET, SOCK_STREAM, 0); if (connect(hSocket, (struct sockaddr*) &server, sizeof(server)) < 0) printf ("connection failed\n"); BIO_set_fd(bioconnection, hSocket, BIO_NOCLOSE); SSL_set_bio(sslconnection, bioconnection, bioconnection); int result = SSL_connect(sslconnection); printf ("error no. is %ld\n", ERR_peek_last_error()); This code does work and prints 'error no. is 336130315', but when it connects over localhost, the error is always 0. From dragon at dancingdragon.be Thu Mar 5 23:56:12 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Thu, 05 Mar 2015 15:56:12 -0800 Subject: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7 In-Reply-To: <54F8C870.1020005@dancingdragon.be> References: <54F8C870.1020005@dancingdragon.be> Message-ID: <54F8ED1C.5000100@dancingdragon.be> > I'm trying to build openssl-1.0.2 for windows. I successfully built > win32 binaries, but I can't seem to build win64a. I get reasonably far > into the build, but then it fails doing AES nasm calls. Previous nasm > calls succeed. > FWIW, I was able to work around this by disabling asm entirely: perl Configure VC-WIN64A no-asm --prefix=Output\Win64\Release From rt at openssl.org Thu Mar 5 09:34:10 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 5 Mar 2015 10:34:10 +0100 Subject: [openssl-dev] [openssl.org #3725] [PATCH] Use warning/fatal constants instead of numbers with comments In-Reply-To: References: Message-ID: Patch applied. Many thanks. Matt From rsalz at akamai.com Thu Mar 5 13:47:11 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 5 Mar 2015 13:47:11 +0000 Subject: [openssl-dev] openssl (lib and application) localhost problems. In-Reply-To: <54F7FC42.9070202@gmail.com> References: <54F7FC42.9070202@gmail.com> Message-ID: <209428abb09c4867abe1affb25ac4c8a@ustx2ex-dag1mb2.msg.corp.akamai.com> > int result = SSL_connect(sslconnection); > printf ("error no. is %ld\n", ERR_peek_last_error()); > > This code does work and prints 'error no. is 336130315', but when it connects > over localhost, the error is always 0. What's result? From ikonta at yandex.ru Thu Mar 5 14:53:13 2015 From: ikonta at yandex.ru (Ikonta) Date: Thu, 05 Mar 2015 17:53:13 +0300 Subject: [openssl-dev] openssl x509 -text incorrectly displays non-latin (non-ansi) symbols (missed '-utf8 option?) In-Reply-To: <54F42A00.9010505@opentrust.com> References: <14354401425275901@web1o.yandex.ru> <54F42A00.9010505@opentrust.com> Message-ID: <36271425567193@web16j.yandex.ru> Good day! Thank you! I've referenced to^ $ openssl x509 --help and find no keys to answer. Maybe it will be good to extend -nameopt arg - various certificate name options to something like -nameopt arg - various certificate name options (including output codepage, i.e. utf8 etc) man openssl-x509 is well enough. What is the reason of keeping non-utf8 default output codepage 11 years after switching default string_mask to utf8? P.S. I have one more similiar question (to my mind for openssl-dev list). Is it appropriate to ask it directly here, or it will be better to try openssl-users first? 02.03.2015, 13:04, "Erwann Abalea" : > Probably an openssl-users question. > > Use "openssl x509 -text -in localhost-server.crt -nameopt > oneline,utf8,-esc_msb" > Your terminal must be able to display UTF8 sequences. > > I sometimes add the "show_type" nameopt option, to check things. > > -- > Erwann ABALEA > > Le 02/03/2015 06:58, Ikonta a ?crit : >> AFAIR in 2004 openssl switched to UTF8 as default bitmask in certificate. >> But ANSI extension's of utf8 support is still incomplete: >> >> $ openssl x509 -text -in localhost-server.crt >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 1 (0x1) >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, L=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache, CN=\xD1\x82\xD0\xB5\xD1\x81\xD1\x82\xD0\xBE\xD0\xB2\xD1\x8B\xD0\xB9 \xD0\xA6\xD0\x90/emailAddress=root at localhost >> Validity >> Not Before: Feb 6 08:28:23 2015 GMT >> Not After : Sep 15 08:28:23 2020 GMT >> Subject: C=RU, ST=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, O=\xD0\xA2\xD0\xB5\xD1\x81\xD1\x82, OU=Apache web server, CN=localhost/emailAddress=apache at localhost >> ? >> (not attaching exanple certificate file because mail list seems to reject such letters) >> displays utf8 symbol codes instead of expected human-readably letters (in this case ? cyrillic), shown after import this certificate into browser's profile. >> >> Probably adding -utf8 option for x509 command should fix this particular issue. >> >> P.S. I use =dev-libs/openssl-1.0.1k amd64 build on Gentoo GNU/Linux. >> _______________________________________________ >> 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 From foleyj at cisco.com Thu Mar 5 16:29:17 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 05 Mar 2015 11:29:17 -0500 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <54F8845D.6090503@cisco.com> Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: OPENSSL_NO_EC OPENSSL_NO_ECDH OPENSSL_NO_EDDSA Is there a valid case where all three of these wouldn't be used together? Would the code even compile if only one (or two) of these were defined? On 01/23/2015 02:11 PM, Salz, Rich wrote: > > Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef > options and we are considering removing nearly a third of them. > Please reply soon if the following plan would cause problems. This > will happen only in master, for post-1.0.2. > > We will remove the following options. You could argue that the > OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not > compile without SHA and SHA1 defined, and we have no interest in > spending the time to fix it. So for consistency, we will remove all of > them. > > GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) > > OPENSSL_NO_BIO > > OPENSSL_NO_BUFFER > > OPENSSL_NO_BUF_FREELISTS > > OPENSSL_NO_CHAIN_VERIFY > > OPENSSL_NO_DESCBCM (also removing the code; no EVP support) > > OPENSSL_NO_EVP > > OPENSSL_NO_FIPS_ERR > > OPENSSL_NO_HASH_COMP > > OPENSSL_NO_LHASH > > OPENSSL_NO_LOCKING > > OPENSSL_NO_MULTIBYTE (also removing the code) > > OPENSSL_NO_OBJECT > > OPENSSL_NO_RFC3779 > > OPENSSL_NO_SHA > > OPENSSL_NO_SHA0 (also removing the code for SHA0) > > OPENSSL_NO_SHA1 > > OPENSSL_NO_SHA224 > > OPENSSL_NO_SHA256 > > OPENSSL_NO_SHA384 > > OPENSSL_NO_SHA512 > > OPENSSL_NO_SPEED > > OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) > > OPENSSL_NO_STACK > > OPENSSL_NO_STORE > > OPENSSL_NO_TLS > > OPENSSL_NO_TLS1 > > OPENSSL_NO_TLS1_2_CLIENT > > OPENSSL_NO_TLSEXT > > OPENSSL_NO_X509 > > OPENSSL_NO_X509_VERIFY > > > > > > -- > > Principal Security Engineer, Akamai Technologies > > IM: rsalz at jabber.me Twitter: RichSalz > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Mar 5 16:42:49 2015 From: rt at openssl.org (Richard C Paterson via RT) Date: Thu, 5 Mar 2015 17:42:49 +0100 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> Message-ID: Apologies if this is the incorrect forum for this question. We?re seeing error messages like SSL3_READ_BYTES and SSL3_GET_SERVER_CERTIFICATE for some reason; - SSL3_GET_SERVER_CERTIFICATE:certificate verify failed - SSL?_GET_BYTES:sslv3 alert handshake failure However, we believe that we have disabled the use of SSLv3. Does the presence of ?SSL3_? in the logs indicate that we are still using SSLv3 and not TLS like we think? Richard C Paterson Development Testing Manager SAS R&D Scotland Tel: +44 141 223 9100 ? Mobile: +447977 477296 ? richard.c.paterson at sas.com www.sas.com SAS?... THE POWER TO KNOW P Please consider the environment before printing this e-mail The information in this e-mail and any attached files is confidential. It is intended solely for the use of the addressee. Any unauthorised disclosure or use is prohibited. If you are not the intended recipient of the message, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. The views of the author may not necessarily reflect those of the company. From rt at openssl.org Thu Mar 5 16:58:10 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 5 Mar 2015 17:58:10 +0100 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> Message-ID: On Thu Mar 05 17:42:49 2015, richard.c.paterson at sas.com wrote: > Apologies if this is the incorrect forum for this question. > > We?re > seeing error messages like SSL3_READ_BYTES and > SSL3_GET_SERVER_CERTIFICATE for some reason; > > - > SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > - > SSL?_GET_BYTES:sslv3 alert handshake failure > > However, we believe > that we have disabled the use of SSLv3. Does the presence of > ?SSL3_? in the logs indicate that we are still using SSLv3 and not > TLS like we think? No. These are just the names of internal functions. Originally written when it was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but the names have remained the same. Matt From rsalz at akamai.com Thu Mar 5 17:27:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 5 Mar 2015 17:27:25 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <54F8845D.6090503@cisco.com> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <54F8845D.6090503@cisco.com> Message-ID: > Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: > OPENSSL_NO_EC > OPENSSL_NO_ECDH > OPENSSL_NO_EDDSA > Is there a valid case where all three of these wouldn't be used together?? Would the code even compile if only one (or two) of these were defined? I would be happy to unify these, and you are probably right that the various mix and match options do not work. Does anyone here have issues or concerns if we do that? From appro at openssl.org Thu Mar 5 20:26:56 2015 From: appro at openssl.org (Andy Polyakov) Date: Thu, 05 Mar 2015 21:26:56 +0100 Subject: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7 In-Reply-To: <54F8C870.1020005@dancingdragon.be> References: <54F8C870.1020005@dancingdragon.be> Message-ID: <54F8BC10.5000105@openssl.org> Hi, > nasm -f win64 -DNEAR -Ox -g -o tmp32\aesni-sha256-x86_64.obj > tmp32\aesni-sha256-x86_64.asm > tmp32\aesni-sha256-x86_64.asm:113: error: symbol > `__imp_RtlVirtualUnwind' undefined > NMAKE : fatal error U1077: '"C:\Program Files (x86)\NASM\nasm.EXE"' : > return code '0x1' > > Any ideas? Can you confirm that attached patch addresses the problem? On side note the error is indication that your nasm is out-of-date and you are missing out some optimizations. But before you update it, please, test the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: aesni-sha256-x86_64.diff Type: text/x-patch Size: 1019 bytes Desc: not available URL: From de.techno at gmail.com Fri Mar 6 06:25:25 2015 From: de.techno at gmail.com (dE) Date: Fri, 06 Mar 2015 11:55:25 +0530 Subject: [openssl-dev] Set fragment size. Message-ID: <54F94855.2010606@gmail.com> I'm trying to set the fragment size for the TLS connection under the hopes that it improves compression. Is there anyway I can do so? From de.techno at gmail.com Fri Mar 6 10:37:06 2015 From: de.techno at gmail.com (dE) Date: Fri, 06 Mar 2015 16:07:06 +0530 Subject: [openssl-dev] openssl (lib and application) localhost problems. In-Reply-To: <209428abb09c4867abe1affb25ac4c8a@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <54F7FC42.9070202@gmail.com> <209428abb09c4867abe1affb25ac4c8a@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <54F98352.2050605@gmail.com> On 03/05/15 19:17, Salz, Rich wrote: >> int result = SSL_connect(sslconnection); >> printf ("error no. is %ld\n", ERR_peek_last_error()); >> >> This code does work and prints 'error no. is 336130315', but when it connects >> over localhost, the error is always 0. > What's result? > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 0 From tmraz at redhat.com Fri Mar 6 12:06:15 2015 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 06 Mar 2015 13:06:15 +0100 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <54F8845D.6090503@cisco.com> Message-ID: <54F99837.4060008@redhat.com> On 5.3.2015 18:27, Salz, Rich wrote: >> Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: >> OPENSSL_NO_EC >> OPENSSL_NO_ECDH >> OPENSSL_NO_EDDSA >> Is there a valid case where all three of these wouldn't be used together? Would the code even compile if only one (or two) of these were defined? > > I would be happy to unify these, and you are probably right that the various mix and match options do not work. > > Does anyone here have issues or concerns if we do that? If you still keep the OPENSSL_NO_EC2M separate, then I do not have any problem with this. However I would expect these three ifdefs to work - of course with OPENSSL_NO_EC implying the NO_ECDH amd NO_ECDSA. Although I did not try it myself. Tomas Mraz From steve at scheftech.com Fri Mar 6 13:35:20 2015 From: steve at scheftech.com (Steve Schefter) Date: Fri, 06 Mar 2015 08:35:20 -0500 Subject: [openssl-dev] Intent of the private_ wrappers Message-ID: <54F9AD18.1080106@scheftech.com> Hi. I am compiling OpenSSL with the FIPS options and seeing a build error. My question is more about the intent than the problem. One example: When apps/speed.c is compiled with FIPS enabled, OPENSSL_FIPS is defined and DES_set_key_unchecked gets defined to be private_DES_set_key_unchecked. The use of the private_ function means that fips_cipher_abort is not called. Am I correct that the intent is to allow the OpenSSl-provided apps to use the low level APIs (like DES) while user applications linking with libcrypto.so can not? The problem is that the OpenSSL-provided apps also link with that library and the private_ functions are not global (they are not in openssl.ld). So the OpenSSL-provided apps fail to link. In the above example, apps/speed.c can't find private_DES_set_key_unchecked(). Or am I not understanding the intent? Regards, Steve From rsalz at akamai.com Fri Mar 6 14:34:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 6 Mar 2015 14:34:47 +0000 Subject: [openssl-dev] openssl (lib and application) localhost problems. In-Reply-To: <54F98352.2050605@gmail.com> References: <54F7FC42.9070202@gmail.com> <209428abb09c4867abe1affb25ac4c8a@ustx2ex-dag1mb2.msg.corp.akamai.com> <54F98352.2050605@gmail.com> Message-ID: So if you don't get back an error, looking at the error stack isn't guaranteed to be useful. Just like errno and syscalls. You have to explicit clear the error stack if you want that behavior. -- Senior Architect, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From rt at openssl.org Fri Mar 6 15:02:37 2015 From: rt at openssl.org (Duane Bronson via RT) Date: Fri, 6 Mar 2015 16:02:37 +0100 Subject: [openssl-dev] [openssl.org #3730] openssl 1.0.2 compile failure with OPENSSL_FIPS In-Reply-To: <23ED77F0-48FA-4FC9-B933-A3FB77A94092@riverbed.com> References: <23ED77F0-48FA-4FC9-B933-A3FB77A94092@riverbed.com> Message-ID: Openssl guys, It looks like an accidental * slipped into *pcurveslen in ssl/t1_lib.c. This patch fixes it and also a warning, but I still get an installed but unpackaged error that could be my fault. Still investigating. bash-4.1# cat openssl-1.0.2-pcurveslen.patch diff -up openssl-1.0.2/ssl/t1_lib.c.fips openssl-1.0.2/ssl/t1_lib.c --- openssl-1.0.2/ssl/t1_lib.c.fips 2015-03-05 16:26:48.786265443 -0500 +++ openssl-1.0.2/ssl/t1_lib.c 2015-03-05 16:29:35.419166733 -0500 @@ -119,6 +119,9 @@ #include #include #include "ssl_locl.h" +#ifndef OPENSSL_NO_KRB5 +# include +#endif const char tls1_version_str[] = "TLSv1" OPENSSL_VERSION_PTEXT; @@ -470,7 +473,7 @@ static int tls1_get_curvelist(SSL *s, in # ifdef OPENSSL_FIPS if (FIPS_mode()) { *pcurves = fips_curves_default; - *pcurveslen = sizeof(fips_curves_default); + pcurveslen = sizeof(fips_curves_default); } else # endif { Duane Duane Bronson Member of Technical Staff Cascade Business Unit Riverbed Technology 125 CambridgePark Drive Cambridge, MA 02140 Mobile: 617.515.2909 From rt at openssl.org Fri Mar 6 15:02:51 2015 From: rt at openssl.org (Paul Nelson via RT) Date: Fri, 6 Mar 2015 16:02:51 +0100 Subject: [openssl-dev] [openssl.org #3731] BUG darwin FIPS openssl-1.0.2 ssl/t1_lib.c line 472 In-Reply-To: <1CF6ABD3-6C3C-4F7E-B51C-7796CC15FCCC@thursby.com> References: <1CF6ABD3-6C3C-4F7E-B51C-7796CC15FCCC@thursby.com> Message-ID: OS is darwin openssl version is 1.0.2 Bug only happens when building the FIPS version of SSL. In t1_lib.c at line 472 the assignment to *pcurveslen should be to pcurveslen instead. Here is the diff for the fix: diff -ur openssl-1.0.2/ssl/t1_lib.c openssl-1.0.2_patched/ssl/t1_lib.c --- openssl-1.0.2/ssl/t1_lib.c 2015-01-22 08:58:32.000000000 -0600 +++ openssl-1.0.2_patched/ssl/t1_lib.c 2015-03-05 16:40:35.000000000 -0600 @@ -470,7 +470,7 @@ # ifdef OPENSSL_FIPS if (FIPS_mode()) { *pcurves = fips_curves_default; - *pcurveslen = sizeof(fips_curves_default); + pcurveslen = sizeof(fips_curves_default); } else # endif { From rt at openssl.org Fri Mar 6 15:03:43 2015 From: rt at openssl.org (Richard C Paterson via RT) Date: Fri, 6 Mar 2015 16:03:43 +0100 Subject: [openssl-dev] [openssl.org #3732] Does OpenSSL construe expired certs as reason to downgrade? In-Reply-To: <4605a5d6e9804977af9d1ebfcd3c31dc@mercmbx60d.na.SAS.com> References: <4605a5d6e9804977af9d1ebfcd3c31dc@mercmbx60d.na.SAS.com> Message-ID: Hi, Our certificates expired recently, and our application log contained the following error: ?SSL3_GET_BYTES:sslv3 alert handshake failure? >From what I can see, this message is a valid error message indicating that SSLv3 is not supported by the server. My question is, why are we seeing this message in this situation? Does OpenSSL construe certificate expiry as a reason to downgrade to SSLv3? Richard C Paterson Development Testing Manager SAS R&D Scotland Tel: +44 141 223 9100 ? Mobile: +447977 477296 ? richard.c.paterson at sas.com www.sas.com SAS?... THE POWER TO KNOW P Please consider the environment before printing this e-mail The information in this e-mail and any attached files is confidential. It is intended solely for the use of the addressee. Any unauthorised disclosure or use is prohibited. If you are not the intended recipient of the message, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. The views of the author may not necessarily reflect those of the company. From rt at openssl.org Fri Mar 6 15:21:17 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 6 Mar 2015 16:21:17 +0100 Subject: [openssl-dev] [openssl.org #3730] openssl 1.0.2 compile failure with OPENSSL_FIPS In-Reply-To: <23ED77F0-48FA-4FC9-B933-A3FB77A94092@riverbed.com> References: <23ED77F0-48FA-4FC9-B933-A3FB77A94092@riverbed.com> Message-ID: On Fri Mar 06 16:02:37 2015, Duane.Bronson at riverbed.com wrote: > Openssl guys, > > It looks like an accidental * slipped into *pcurveslen in > ssl/t1_lib.c. This patch fixes it and also a warning, but I still get > an installed but unpackaged error that could be my fault. Still > investigating. Hi Duane This issue has been previously reported, and has been fixed in commit 6fa805f516f. This will be incorporated into the next 1.0.2 release. Matt From rt at openssl.org Fri Mar 6 15:02:03 2015 From: rt at openssl.org (Short, Todd via RT) Date: Fri, 6 Mar 2015 16:02:03 +0100 Subject: [openssl-dev] [openssl.org #3729] Patch to add support for iovec-based IO in OpenSSL In-Reply-To: References: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add ?struct iovec? variants to ssl IO (configurable, disabled by default) This adds support of iovec-based IO into openSSL. iovec can be faster than normal IO mechanism as there are fewer calls into the kernel. Regular APIs are modified to use ?ssl_bucket? (similar to iovec structures) at the lower level, so the IO path is still the same regardless of whether iovec-based APIs are used or not. Github link: https://github.com/akamai/openssl/commit/91f65728bbd7d52ae6b75050d31e197591769d78 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-struct-iovec-variants-to-ssl-IO-configurable-dis.patch Type: application/octet-stream Size: 39231 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From de.techno at gmail.com Sat Mar 7 14:36:27 2015 From: de.techno at gmail.com (dE) Date: Sat, 07 Mar 2015 20:06:27 +0530 Subject: [openssl-dev] openssl (lib and application) localhost problems. In-Reply-To: References: <54F7FC42.9070202@gmail.com> <209428abb09c4867abe1affb25ac4c8a@ustx2ex-dag1mb2.msg.corp.akamai.com> <54F98352.2050605@gmail.com> Message-ID: <54FB0CEB.1040202@gmail.com> On 03/06/15 20:04, Salz, Rich wrote: > So if you don't get back an error, looking at the error stack isn't guaranteed to be useful. Just like errno and syscalls. > > You have to explicit clear the error stack if you want that behavior. > > -- > Senior Architect, Akamai Technologies > IM: rsalz at jabber.me Twitter: RichSalz Error stack cleared with the same affect. But surprising fact is that it works over any IP except localhost. Also if the handshake fails (over localhost), then it does generate the correct error codes, but not when it's trying to connect to a plain TCP server. From rt at openssl.org Sat Mar 7 17:14:17 2015 From: rt at openssl.org (Allauddin Ahmad via RT) Date: Sat, 7 Mar 2015 18:14:17 +0100 Subject: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch In-Reply-To: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> References: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> Message-ID: Dear Concerned: Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by: * DTLS segmentation fault in dtls1_get_record (CVE-2014-3571 (CVE-2015-0206 * DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) * no-ssl3 configuration sets method to NULL (CVE-2014-3569) * ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) * RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) * DH client certificates accepted without verification [Server] (CVE-2015-0205) * Certificate fingerprints can be modified (CVE-2014-8275) * Bignum squaring may produce incorrect results (CVE-2014-3570) Since we do not find any mention of 0.9.7 branch in advisory links. Please note that OpenSSL 0.9.7 is shipped with Solaris10. Thanks and Regards Allauddin Ahmad Sr. System Analyst-I | THPS TELUS Health and Payment Solutions 505 March Rd., Suite 450, Kanata, ON, K2K 3A4 T : (613) 576 2091 allauddin.ahmad at telus.com telushealth.com [cid:image001.jpg at 01D0580F.9A788DD0] The information contained herein, including any attachments, is proprietary and confidential and is intended for the exclusive use of the addressee. It also may contain privileged information and/or personal information subject to privacy legislation. The authorized addressee of this information, by its retention and use, agrees to protect the information contained herein from loss, disclosure, theft or compromise with at least the same care it employs to protect its own confidential information. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. If you have received this e-mail in error, please notify us immediately by reply e-mail and destroy all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 5370 bytes Desc: not available URL: From rt at openssl.org Sat Mar 7 17:14:17 2015 From: rt at openssl.org (Randall Geyer via RT) Date: Sat, 7 Mar 2015 18:14:17 +0100 Subject: [openssl-dev] [openssl.org #3733] ZOS 1.0.1k bug report with fix. In-Reply-To: <40093139-6706-4699-8bbb-a915c523c5dd@default> References: <40093139-6706-4699-8bbb-a915c523c5dd@default> Message-ID: util/mkbuildinf.pl builds an invalid char array, if the associated *OS390* Configure entry contain backslashes(\). Our configure entry: "OS390-Unix","c89:-O2 -Wc,langlvl\\\(extended\\\),longname,enum\\\(int\\\),float\\\(ieee\\\),exportall,xplink\\\(callback\\\),target\\\(zOSV1R12\\\) -Wl,xplink,compat=ZOSV1R12 -DB_ENDIAN -DCHARSET_EBCDIC -DNO_SYS_PARAM_H -DOS390 -D_XOPEN_SOURCE_EXTENDED -D_ALL_SOURCE::-Wc,rent:::THIRTY_TWO_BIT DES_PTR DES_UNROLL MD2_CHAR RC4_INDEX RC4_CHAR BF_PTR::::::::::::::::::os390-shared:-Wc,dll:-Wl,dll:.so:", Solution - new util/mkbuildinf.pl: #!/usr/local/bin/perl my ($cflags, $platform) = @ARGV; $cflags = "compiler: $cflags"; $date = localtime(); print <<"END_OUTPUT"; #ifndef MK1MF_BUILD /* auto-generated by util/mkbuildinf.pl for crypto/cversion.c */ #define CFLAGS cflags /* * Generate CFLAGS as an array of individual characters. This is a * workaround for the situation where CFLAGS gets too long for a C90 string * literal */ static const char cflags[] = { END_OUTPUT my $ctr = 0; foreach my $c (split //, $cflags) { # Max 18 characters per line if (($ctr++ % 18) == 0) { if ($ctr != 1) { print "\n"; } print " "; } $c =~ s|\\|\\\\|g; print "'$c',"; } print <<"END_OUTPUT"; '\\0' }; #define PLATFORM "platform: $platform" #define DATE "built on: $date" #endif END_OUTPUT From rt at openssl.org Sat Mar 7 17:14:44 2015 From: rt at openssl.org (Randall S. Becker via RT) Date: Sat, 7 Mar 2015 18:14:44 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: Please forgive the potential red-herring nature of this minor report, however.. Openssl distribution depends on tardy, which in turn, depends on libexplain. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, the libexplain maintainer has retired and the package is orphaned. This is potentially represents an issue as libexplain is highly embedded in tardy. Sincerely, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000) -- In my real life, I talk too much. From openssl-users at dukhovni.org Sat Mar 7 17:42:45 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 7 Mar 2015 17:42:45 +0000 Subject: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch In-Reply-To: References: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> Message-ID: <20150307174245.GZ1260@mournblade.imrryr.org> On Sat, Mar 07, 2015 at 06:14:17PM +0100, Allauddin Ahmad via RT wrote: OpenSSL 0.9.7 has been unsupported for quite some time. Therefore, as far as I know the OpenSSL team is not checking 0.9.7 to verify whether it is or is not affected by any recent vulnerability disclosures. It is almost certainly vulnerable to a number of unpatched issues older than the ones you list. That said: > * DTLS segmentation fault in dtls1_get_record (CVE-2014-3571 (CVE-2015-0206 > * DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) 0.9.7 has no DTLS support, so these can't be a problem. > * no-ssl3 configuration sets method to NULL (CVE-2014-3569) The Solaris 0.9.7 is not compiled without SSLv3 support. > * ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) 0.9.7 has no support elliptic curve cryptography. -- Viktor. From richmoore44 at gmail.com Sat Mar 7 17:58:57 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 7 Mar 2015 17:58:57 +0000 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: On 7 March 2015 at 17:14, Randall S. Becker via RT wrote: > Please forgive the potential red-herring nature of this minor report, > however.. > > Openssl distribution depends on tardy, which in turn, depends on > libexplain. > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, the > libexplain maintainer has retired and the package is orphaned. This is > potentially represents an issue as libexplain is highly embedded in tardy. > This sounds purely a packaging issue with debian and nothing to do with openssl itself. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Mar 7 18:01:42 2015 From: rt at openssl.org (Richard Moore via RT) Date: Sat, 7 Mar 2015 19:01:42 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: On 7 March 2015 at 17:14, Randall S. Becker via RT wrote: > Please forgive the potential red-herring nature of this minor report, > however.. > > Openssl distribution depends on tardy, which in turn, depends on > libexplain. > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, the > libexplain maintainer has retired and the package is orphaned. This is > potentially represents an issue as libexplain is highly embedded in tardy. > This sounds purely a packaging issue with debian and nothing to do with openssl itself. Rich. From rt at openssl.org Sat Mar 7 18:11:16 2015 From: rt at openssl.org (Randall S. Becker via RT) Date: Sat, 7 Mar 2015 19:11:16 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> Message-ID: > On March 7, 2015 1:02 PM Richard Moore via RT [mailto:rt at openssl.org] wrote: >> On 7 March 2015 at 17:14, Randall S. Becker via RT wrote: >> > > Please forgive the potential red-herring nature of this minor report, > > however.. > > > > Openssl distribution depends on tardy, which in turn, depends on > > libexplain. > > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > the libexplain maintainer has retired and the package is orphaned. > > This is potentially represents an issue as libexplain is highly embedded in > tardy. > > > > This sounds purely a packaging issue with debian and nothing to do with > openssl itself. Tardy is referenced in the openssl Makefile tar rule, which is there the dependency manifests. $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ tardy --user_number=0 --user_name=openssl \ --group_number=0 --group_name=openssl \ --prefix=openssl-$(VERSION) - |\ gzip --best >../$(TARFILE).gz; \ From rsbecker at nexbridge.com Sat Mar 7 18:09:18 2015 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Sat, 7 Mar 2015 13:09:18 -0500 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> > On March 7, 2015 1:02 PM Richard Moore via RT [mailto:rt at openssl.org] wrote: >> On 7 March 2015 at 17:14, Randall S. Becker via RT wrote: >> > > Please forgive the potential red-herring nature of this minor report, > > however.. > > > > Openssl distribution depends on tardy, which in turn, depends on > > libexplain. > > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > the libexplain maintainer has retired and the package is orphaned. > > This is potentially represents an issue as libexplain is highly embedded in > tardy. > > > > This sounds purely a packaging issue with debian and nothing to do with > openssl itself. Tardy is referenced in the openssl Makefile tar rule, which is there the dependency manifests. $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ tardy --user_number=0 --user_name=openssl \ --group_number=0 --group_name=openssl \ --prefix=openssl-$(VERSION) - |\ gzip --best >../$(TARFILE).gz; \ From richmoore44 at gmail.com Sat Mar 7 18:31:55 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Sat, 7 Mar 2015 18:31:55 +0000 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> Message-ID: On 7 March 2015 at 18:11, Randall S. Becker via RT wrote: > > On March 7, 2015 1:02 PM Richard Moore via RT [mailto:rt at openssl.org] > wrote: > >> On 7 March 2015 at 17:14, Randall S. Becker via RT > wrote: > >> > > > Please forgive the potential red-herring nature of this minor report, > > > however.. > > > > > > Openssl distribution depends on tardy, which in turn, depends on > > > libexplain. > > > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > > the libexplain maintainer has retired and the package is orphaned. > > > This is potentially represents an issue as libexplain is highly > embedded in > > tardy. > > > > > > > This sounds purely a packaging issue with debian and nothing to do with > > openssl itself. > > Tardy is referenced in the openssl Makefile tar rule, which is there the > dependency manifests. > > $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ > tardy --user_number=0 --user_name=openssl \ > --group_number=0 --group_name=openssl \ > --prefix=openssl-$(VERSION) - |\ > gzip --best >../$(TARFILE).gz; \ > > Surely you build your packages from the release tar balls? That means that this rule is never used. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Mar 7 18:33:40 2015 From: rt at openssl.org (Richard Moore via RT) Date: Sat, 7 Mar 2015 19:33:40 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> Message-ID: On 7 March 2015 at 18:11, Randall S. Becker via RT wrote: > > On March 7, 2015 1:02 PM Richard Moore via RT [mailto:rt at openssl.org] > wrote: > >> On 7 March 2015 at 17:14, Randall S. Becker via RT > wrote: > >> > > > Please forgive the potential red-herring nature of this minor report, > > > however.. > > > > > > Openssl distribution depends on tardy, which in turn, depends on > > > libexplain. > > > According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > > the libexplain maintainer has retired and the package is orphaned. > > > This is potentially represents an issue as libexplain is highly > embedded in > > tardy. > > > > > > > This sounds purely a packaging issue with debian and nothing to do with > > openssl itself. > > Tardy is referenced in the openssl Makefile tar rule, which is there the > dependency manifests. > > $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ > tardy --user_number=0 --user_name=openssl \ > --group_number=0 --group_name=openssl \ > --prefix=openssl-$(VERSION) - |\ > gzip --best >../$(TARFILE).gz; \ > > Surely you build your packages from the release tar balls? That means that this rule is never used. Rich. From steve at openssl.org Sat Mar 7 18:44:06 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 7 Mar 2015 18:44:06 +0000 Subject: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch In-Reply-To: References: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> Message-ID: <20150307184406.GA7669@openssl.org> On Sat, Mar 07, 2015, Allauddin Ahmad via RT wrote: > Dear Concerned: > > Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by: > As Viktor mentioned 0.9.7 is no longer being maintained. However the following two issues will be present in 0.9.7: > > * RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) > > * Certificate fingerprints can be modified (CVE-2014-8275) > And possibly this one too: > * Bignum squaring may produce incorrect results (CVE-2014-3570) > It is quite likely that thare are many more problems with 0.9.7 too. Please don't post questions to the bug tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Mar 7 18:44:20 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 7 Mar 2015 19:44:20 +0100 Subject: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch In-Reply-To: <20150307184406.GA7669@openssl.org> References: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> <20150307184406.GA7669@openssl.org> Message-ID: On Sat, Mar 07, 2015, Allauddin Ahmad via RT wrote: > Dear Concerned: > > Can you please confirm that OpenSSL branch 0.9.7 branch is not affected by: > As Viktor mentioned 0.9.7 is no longer being maintained. However the following two issues will be present in 0.9.7: > > * RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) > > * Certificate fingerprints can be modified (CVE-2014-8275) > And possibly this one too: > * Bignum squaring may produce incorrect results (CVE-2014-3570) > It is quite likely that thare are many more problems with 0.9.7 too. Please don't post questions to the bug tracker. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Sat Mar 7 18:48:33 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 7 Mar 2015 18:48:33 +0000 Subject: [openssl-dev] openssl (lib and application) localhost problems. In-Reply-To: <54F7FC42.9070202@gmail.com> References: <54F7FC42.9070202@gmail.com> Message-ID: <20150307184833.GA1260@mournblade.imrryr.org> On Thu, Mar 05, 2015 at 12:18:34PM +0530, dE wrote: > printf ("error no. is %ld\n", ERR_peek_last_error()); Hex would be more useful than decimal: 0x1408f10b Also the version of OpenSSL you're running (I'll assume for the moment 1.0.1). This encodes the library number, function and line number. >From crypto/err/err.h: # define ERR_LIB_SSL 20 # define ERR_GET_LIB(l) (int)((((unsigned long)l)>>24L)&0xffL) # define ERR_GET_FUNC(l) (int)((((unsigned long)l)>>12L)&0xfffL) # define ERR_GET_REASON(l) (int)((l)&0xfffL) # define ERR_FATAL_ERROR(l) (int)((l)&ERR_R_FATAL) So 0x14 is libssl, the function is 0x08f or 143 and the reason is 0x10b or 267. $ egrep -w '(267|143)' ssl/ssl.h ... # define SSL_F_SSL3_GET_RECORD 143 ... # define SSL_R_WRONG_VERSION_NUMBER 267 ... You'd have figured all this out if you had actually loaded the error strings and used the OpenSSL error decoding interface to print the error details. This of course is not suprising: server.sin_family = AF_INET; server.sin_port = htons(80); server.sin_addr.s_addr = inet_addr ("104.68.173.123"); Why would you expect TLS on port 80??? You'd probably have more luck with port 443, and probably with SSLv23_client_method(), rather than TLSv1_2_method(). As for why the error is 0 with localhost, what is listening on port 80 on localhost? Is it an SSL service? When I run your code against 80 on localhost it fails with the same "wrong version" error. When I change 80 to 443, I get error 0. It sure seems you're barking up the wrong tree... -- Viktor. From rsbecker at nexbridge.com Sat Mar 7 18:51:01 2015 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Sat, 7 Mar 2015 13:51:01 -0500 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> Message-ID: <010c01d05907$a87ad610$f9708230$@nexbridge.com> >> On March 7, 2015 1:34 PM Richard Moore via RT [mailto:rt at openssl.org] wrote: > On 7 March 2015 at 18:11, Randall S. Becker via RT wrote: > > > On March 7, 2015 1:02 PM Richard Moore via RT > > > [mailto:rt at openssl.org] > > wrote: > > >> On 7 March 2015 at 17:14, Randall S. Becker via RT > > wrote: > > >> > > > > Please forgive the potential red-herring nature of this minor > > > > report, however.. > > > > > > > > Openssl distribution depends on tardy, which in turn, depends on > > > > libexplain. > > > > According to > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > > > the libexplain maintainer has retired and the package is orphaned. > > > > This is potentially represents an issue as libexplain is highly > > embedded in > > > tardy. > > > > > > > > > > This sounds purely a packaging issue with debian and nothing to do > > > with openssl itself. > > > > Tardy is referenced in the openssl Makefile tar rule, which is there > > the dependency manifests. > > > > $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ > > tardy --user_number=0 --user_name=openssl \ > > --group_number=0 --group_name=openssl \ > > --prefix=openssl-$(VERSION) - |\ > > gzip --best >../$(TARFILE).gz; \ > > > > > Surely you build your packages from the release tar balls? That means that this > rule is never used. We are building from git, as it is how we apply our platform patches. Support was recently dropped for Tandem/NonStop, so we have little choice here, other than hand-patching, which is not sustainable. Aside, I am just trying to bring an awareness to potential unsupported product dependency. Nothing more. From rt at openssl.org Sat Mar 7 18:52:36 2015 From: rt at openssl.org (Randall S. Becker via RT) Date: Sat, 7 Mar 2015 19:52:36 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <010c01d05907$a87ad610$f9708230$@nexbridge.com> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> <010c01d05907$a87ad610$f9708230$@nexbridge.com> Message-ID: >> On March 7, 2015 1:34 PM Richard Moore via RT [mailto:rt at openssl.org] wrote: > On 7 March 2015 at 18:11, Randall S. Becker via RT wrote: > > > On March 7, 2015 1:02 PM Richard Moore via RT > > > [mailto:rt at openssl.org] > > wrote: > > >> On 7 March 2015 at 17:14, Randall S. Becker via RT > > wrote: > > >> > > > > Please forgive the potential red-herring nature of this minor > > > > report, however.. > > > > > > > > Openssl distribution depends on tardy, which in turn, depends on > > > > libexplain. > > > > According to > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765335, > > > > the libexplain maintainer has retired and the package is orphaned. > > > > This is potentially represents an issue as libexplain is highly > > embedded in > > > tardy. > > > > > > > > > > This sounds purely a packaging issue with debian and nothing to do > > > with openssl itself. > > > > Tardy is referenced in the openssl Makefile tar rule, which is there > > the dependency manifests. > > > > $(TAR) $(TARFLAGS) --files-from ../$(TARFILE).list -cvf - | \ > > tardy --user_number=0 --user_name=openssl \ > > --group_number=0 --group_name=openssl \ > > --prefix=openssl-$(VERSION) - |\ > > gzip --best >../$(TARFILE).gz; \ > > > > > Surely you build your packages from the release tar balls? That means that this > rule is never used. We are building from git, as it is how we apply our platform patches. Support was recently dropped for Tandem/NonStop, so we have little choice here, other than hand-patching, which is not sustainable. Aside, I am just trying to bring an awareness to potential unsupported product dependency. Nothing more. From dragon at dancingdragon.be Sat Mar 7 19:00:26 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Sat, 07 Mar 2015 11:00:26 -0800 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> Message-ID: <54FB4ACA.1080802@dancingdragon.be> > Tardy is referenced in the openssl Makefile tar rule, which is there > the dependency manifests. > > Surely you build your packages from the release tar balls? That means > that this rule is never used. > Many package managers (including debian's, depending on the mode in which it is run) will unpack a tarball, run 'make dist' on it, and then build the resulting tarball. In those cases, tardy is properly a build dependency. From rt at openssl.org Sat Mar 7 19:10:39 2015 From: rt at openssl.org (Joey Yandle via RT) Date: Sat, 7 Mar 2015 20:10:39 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <54FB4ACA.1080802@dancingdragon.be> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <00f801d05901$d4c209b0$7e461d10$@nexbridge.com> <54FB4ACA.1080802@dancingdragon.be> Message-ID: > Tardy is referenced in the openssl Makefile tar rule, which is there > the dependency manifests. > > Surely you build your packages from the release tar balls? That means > that this rule is never used. > Many package managers (including debian's, depending on the mode in which it is run) will unpack a tarball, run 'make dist' on it, and then build the resulting tarball. In those cases, tardy is properly a build dependency. From dwmw2 at infradead.org Sat Mar 7 22:42:47 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 07 Mar 2015 22:42:47 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <54F5A265.4070902@openssl.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> Message-ID: <1425768167.9850.19.camel@infradead.org> On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: > > > On 03/03/15 11:36, David Woodhouse wrote: > > On Tue, 2015-03-03 at 08:58 +0000, Matt Caswell wrote: > >> Fixes for #3703 and #3711 are currently going through the review > >> process so should be in soon hopefully. Any progress on this? > > Thanks. Should I have known that? I've been monitoring RT (when it's up) > > and the mailing list, but is there somewhere else I should have been > > looking? > > No - I haven't updated RT - sorry. When Richard gets RT back from > wherever its gone to I'll update the tickets. Or this? Thanks. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From rt at openssl.org Sat Mar 7 22:46:58 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 7 Mar 2015 23:46:58 +0100 Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco DTLS_BAD_VER In-Reply-To: <1424082497.1804.26.camel@infradead.org> References: <1424082497.1804.26.camel@infradead.org> Message-ID: Patch for this is still going through review at the moment. I'll chase it. Matt From rt at openssl.org Sat Mar 7 22:48:14 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 7 Mar 2015 23:48:14 +0100 Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello In-Reply-To: <1424220216.24248.47.camel@infradead.org> References: <1424220216.24248.47.camel@infradead.org> Message-ID: As with #3703, patch is still in review - I will chase. Matt From rt at openssl.org Sun Mar 8 02:02:34 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 8 Mar 2015 03:02:34 +0100 Subject: [openssl-dev] [openssl.org #3734] question about 0.9.7 branch In-Reply-To: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> References: <07C98B985217BB4BB89D035CE17019462A614994AE@WP41077.corp.ads> Message-ID: Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org lease From rt at openssl.org Sun Mar 8 02:04:15 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 8 Mar 2015 03:04:15 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: Thanks for bringing this up. It's an internal target used only by the openssl team. We'll fix it if/when a system upgrade on our packaging system removes it. :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsbecker at nexbridge.com Sun Mar 8 02:08:23 2015 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Sat, 7 Mar 2015 21:08:23 -0500 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> Message-ID: <013f01d05944$c21bbbb0$46533310$@nexbridge.com> > On March 7, 2015 9:04 PM Rich Salz via RT [mailto:rt at openssl.org] wrote: > To: rsbecker at nexbridge.com > Cc: openssl-dev at openssl.org > Subject: [openssl.org #3735] [bug] Openssl transitive dependency to libexplain > (minor) > > Thanks for bringing this up. It's an internal target used only by the openssl > team. We'll fix it if/when a system upgrade on our packaging system removes > it. > :) That's all I can ask, Rich. Thank you :) From rt at openssl.org Sun Mar 8 02:11:12 2015 From: rt at openssl.org (Randall S. Becker via RT) Date: Sun, 8 Mar 2015 03:11:12 +0100 Subject: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor) In-Reply-To: <013f01d05944$c21bbbb0$46533310$@nexbridge.com> References: <00c301d058f4$6dd75f00$49861d00$@nexbridge.com> <013f01d05944$c21bbbb0$46533310$@nexbridge.com> Message-ID: > On March 7, 2015 9:04 PM Rich Salz via RT [mailto:rt at openssl.org] wrote: > To: rsbecker at nexbridge.com > Cc: openssl-dev at openssl.org > Subject: [openssl.org #3735] [bug] Openssl transitive dependency to libexplain > (minor) > > Thanks for bringing this up. It's an internal target used only by the openssl > team. We'll fix it if/when a system upgrade on our packaging system removes > it. > :) That's all I can ask, Rich. Thank you :) From dkg at fifthhorseman.net Sat Mar 7 17:56:36 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 07 Mar 2015 09:56:36 -0800 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> Message-ID: <87oao4k7xn.fsf@alice.fifthhorseman.net> On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote: > On Thu Mar 05 17:42:49 2015, richard.c.paterson at sas.com wrote: >> Apologies if this is the incorrect forum for this question. >> >> We?re >> seeing error messages like SSL3_READ_BYTES and >> SSL3_GET_SERVER_CERTIFICATE for some reason; >> >> - >> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> >> - >> SSL?_GET_BYTES:sslv3 alert handshake failure >> >> However, we believe >> that we have disabled the use of SSLv3. Does the presence of >> ?SSL3_? in the logs indicate that we are still using SSLv3 and not >> TLS like we think? > > No. These are just the names of internal functions. Originally written when it > was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but > the names have remained the same. Is there a plan to change this in any subsequent release? This kind of misleading debugging information seems likely to confuse people. I understand that knowledgable users and developers might be used to seeing these exact strings, but fixing them to provide correct information is probably better for the entire community in the long-term. --dkg From rt at openssl.org Sun Mar 8 03:58:51 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Sun, 8 Mar 2015 04:58:51 +0100 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: <87oao4k7xn.fsf@alice.fifthhorseman.net> References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> <87oao4k7xn.fsf@alice.fifthhorseman.net> Message-ID: On Thu 2015-03-05 08:58:10 -0800, Matt Caswell via RT wrote: > On Thu Mar 05 17:42:49 2015, richard.c.paterson at sas.com wrote: >> Apologies if this is the incorrect forum for this question. >> >> We?re >> seeing error messages like SSL3_READ_BYTES and >> SSL3_GET_SERVER_CERTIFICATE for some reason; >> >> - >> SSL3_GET_SERVER_CERTIFICATE:certificate verify failed >> >> - >> SSL?_GET_BYTES:sslv3 alert handshake failure >> >> However, we believe >> that we have disabled the use of SSLv3. Does the presence of >> ?SSL3_? in the logs indicate that we are still using SSLv3 and not >> TLS like we think? > > No. These are just the names of internal functions. Originally written when it > was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but > the names have remained the same. Is there a plan to change this in any subsequent release? This kind of misleading debugging information seems likely to confuse people. I understand that knowledgable users and developers might be used to seeing these exact strings, but fixing them to provide correct information is probably better for the entire community in the long-term. --dkg From openssl-users at dukhovni.org Sun Mar 8 04:01:40 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 8 Mar 2015 04:01:40 +0000 Subject: [openssl-dev] [openssl.org #3728] Question: does "sslv3" in log mean we're using SSLv3? In-Reply-To: <87oao4k7xn.fsf@alice.fifthhorseman.net> References: <781cf2c732224d059e15892145113496@mercmbx58d.na.SAS.com> <87oao4k7xn.fsf@alice.fifthhorseman.net> Message-ID: <20150308040140.GF1260@mournblade.imrryr.org> On Sat, Mar 07, 2015 at 09:56:36AM -0800, Daniel Kahn Gillmor wrote: > > No. These are just the names of internal functions. Originally written when it > > was just a choice of ssl2 or ssl3 they were subsequently reused for TLS - but > > the names have remained the same. > > Is there a plan to change this in any subsequent release? This kind of > misleading debugging information seems likely to confuse people. I > understand that knowledgable users and developers might be used to > seeing these exact strings, but fixing them to provide correct > information is probably better for the entire community in the > long-term. I don't see sufficient benefit from such an exercise. It requires retooling any log parsers that already grok the current messages. There are far more important issues to address with the few cycles at hand. Some day, when SSL3 is no longer support at all, and the OpenSSL code base is clean and easy to maintain, we can worry about cosmetic issues of this sort... -- Viktor. From pkannamraju at gmail.com Sun Mar 8 04:04:22 2015 From: pkannamraju at gmail.com (Kannamraju P) Date: Sat, 7 Mar 2015 23:04:22 -0500 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: "Kannamraju P" Date: Mar 6, 2015 12:44 AM Subject: DTLS handshake not getting completed To: Cc: Hi All, I am testing out a DTLS-SRTP webrtc call and running into following issue. Even after DTLS client sends finished message DTLS server (openssl) doesnt do a state transition and send a change cipher spec , it still waits . Attaching PCAP for your reference.Any idea what could be the reason. -- thanks & Regards, Raju -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DTLS handshake failure.pcapng Type: application/octet-stream Size: 24256 bytes Desc: not available URL: From rt at openssl.org Sun Mar 8 06:30:29 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sun, 8 Mar 2015 07:30:29 +0100 Subject: [openssl-dev] [openssl.org #3333] [PATCH] Revert "Make Makefiles OSF-make-friendly." In-Reply-To: <20150308062028.GT12857@vapier> References: <5417D57D.1090209@openssl.org> <2259045.VSgkZ5SNTI@vapier> <20150308062028.GT12857@vapier> Message-ID: this can be closed now since d475b2a3bfde8d4aceefb41b21acc3711893d2a8 fixed it -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Sun Mar 8 06:30:34 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sun, 8 Mar 2015 07:30:34 +0100 Subject: [openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings In-Reply-To: <1425795800-30337-1-git-send-email-vapier@gentoo.org> References: <1425795800-30337-1-git-send-email-vapier@gentoo.org> Message-ID: atm, the windres code in openssl is only usable via the cross-compile prefix option unlike all the other build tools. So add support for the standard $RC / $WINDRES env vars as well. --- Configure | 3 +++ Makefile.org | 2 ++ Makefile.shared | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Configure b/Configure index 5dbfa6c..080cfe2 100755 --- a/Configure +++ b/Configure @@ -744,6 +744,7 @@ my $shared_extension = $fields[$idx_shared_extension]; my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib]; my $ar = $ENV{'AR'} || "ar"; my $arflags = $fields[$idx_arflags]; +my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || "windres"; my $multilib = $fields[$idx_multilib]; # if $prefix/lib$multilib is not an existing directory, then @@ -1210,12 +1211,14 @@ while () s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/; s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/; s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/; + s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/; s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc eq "gcc"; } else { s/^CC=.*$/CC= $cc/; s/^AR=\s*ar/AR= $ar/; s/^RANLIB=.*/RANLIB= $ranlib/; + s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/; s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq "gcc" || ($cc eq 'cc' && $target =~ /darwin/); } s/^CFLAG=.*$/CFLAG= $cflags/; diff --git a/Makefile.org b/Makefile.org index 50f7ae2..83fa45a 100644 --- a/Makefile.org +++ b/Makefile.org @@ -66,6 +66,7 @@ EXE_EXT= ARFLAGS= AR=ar $(ARFLAGS) r RANLIB= ranlib +WINDRES= windres NM= nm PERL= perl #RM= echo -- @@ -216,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' \ CC='$(CC)' CFLAG='$(CFLAG)' \ AS='$(CC)' ASFLAG='$(CFLAG) -c' \ AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)' \ + WINDRES='$(WINDRES)' \ CROSS_COMPILE='$(CROSS_COMPILE)' \ PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \ SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ diff --git a/Makefile.shared b/Makefile.shared index babeb46..e8903ca 100644 --- a/Makefile.shared +++ b/Makefile.shared @@ -282,7 +282,7 @@ link_a.cygwin: fi; \ dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \ $(PERL) util/mkrc.pl $$dll_name | \ - $(CROSS_COMPILE)windres -o rc.o; \ + $(WINDRES) -o rc.o; \ extras="$$extras rc.o"; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ -- 2.3.1 From rt at openssl.org Sun Mar 8 09:26:09 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Sun, 8 Mar 2015 10:26:09 +0100 Subject: [openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings In-Reply-To: <54FC0B6E.2060104@roumenpetrov.info> References: <1425795800-30337-1-git-send-email-vapier@gentoo.org> <54FC0B6E.2060104@roumenpetrov.info> Message-ID: Mike Frysinger via RT wrote: > atm, the windres code in openssl is only usable via the cross-compile prefix > option unlike all the other build tools. So add support for the standard $RC > / $WINDRES env vars as well. > --- > [SNIP] > else { > s/^CC=.*$/CC= $cc/; > s/^AR=\s*ar/AR= $ar/; > s/^RANLIB=.*/RANLIB= $ranlib/; > + s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/; > s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq "gcc" || ($cc eq 'cc' && $target =~ /darwin/); > } Is above line correct ? [SNIP] Regards, Roumen From rt at openssl.org Sun Mar 8 10:54:46 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sun, 8 Mar 2015 11:54:46 +0100 Subject: [openssl-dev] [openssl.org #3736] [PATCH] fix parallel install with dir creation In-Reply-To: <1425796421-30493-1-git-send-email-vapier@gentoo.org> References: <1425796421-30493-1-git-send-email-vapier@gentoo.org> Message-ID: The mkdir-p.pl does not handle parallel creation of directories. This comes up when the install_sw and install_docs rules run and both call mkdir-p.pl on sibling directory trees. Instead, lets create a single install_dirs rule that makes all of the dirs we need, and have these two install steps depend on that. --- Makefile.org | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Makefile.org b/Makefile.org index 83fa45a..5f8e03d 100644 --- a/Makefile.org +++ b/Makefile.org @@ -193,7 +193,11 @@ INSTALLDIRS= \ $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl \ $(INSTALL_PREFIX)$(OPENSSLDIR)/misc \ $(INSTALL_PREFIX)$(OPENSSLDIR)/certs \ - $(INSTALL_PREFIX)$(OPENSSLDIR)/private + $(INSTALL_PREFIX)$(OPENSSLDIR)/private \ + $(INSTALL_PREFIX)$(MANDIR)/man1 \ + $(INSTALL_PREFIX)$(MANDIR)/man3 \ + $(INSTALL_PREFIX)$(MANDIR)/man5 \ + $(INSTALL_PREFIX)$(MANDIR)/man7 all: Makefile build_all openssl.pc libssl.pc libcrypto.pc @@ -548,8 +552,10 @@ install: all install_docs install_sw uninstall: uninstall_sw uninstall_docs -install_sw: +install_dirs: @$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALLDIRS) + +install_sw: install_dirs @set -e; headerlist="$(EXHEADER)"; for i in $$headerlist;\ do \ (cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \ @@ -694,12 +700,7 @@ uninstall_html_docs: done; \ done -install_docs: - @$(PERL) $(TOP)/util/mkdir-p.pl \ - $(INSTALL_PREFIX)$(MANDIR)/man1 \ - $(INSTALL_PREFIX)$(MANDIR)/man3 \ - $(INSTALL_PREFIX)$(MANDIR)/man5 \ - $(INSTALL_PREFIX)$(MANDIR)/man7 +install_docs: install_dirs here="`pwd`"; \ filecase=; \ case "$(PLATFORM)" in DJGPP|Cygwin*|mingw*|darwin*-*-cc) \ -- 2.3.1 From rt at openssl.org Sun Mar 8 10:54:57 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sun, 8 Mar 2015 11:54:57 +0100 Subject: [openssl-dev] [openssl.org #3737] [PATCH] fix parallel generation of obj headers In-Reply-To: <1425796573-30570-1-git-send-email-vapier@gentoo.org> References: <1425796573-30570-1-git-send-email-vapier@gentoo.org> Message-ID: The current code has dummy sleep/touch commands to try and work around the parallel issue, but that is obviously racy. Instead lets force one of the files to depend on the other so we know they'll never run in parallel. --- crypto/objects/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/crypto/objects/Makefile b/crypto/objects/Makefile index a8aedbd..aaa8d29 100644 --- a/crypto/objects/Makefile +++ b/crypto/objects/Makefile @@ -44,11 +44,11 @@ obj_dat.h: obj_dat.pl obj_mac.h # objects.pl both reads and writes obj_mac.num obj_mac.h: objects.pl objects.txt obj_mac.num $(PERL) objects.pl objects.txt obj_mac.num obj_mac.h - @sleep 1; touch obj_mac.h; sleep 1 -obj_xref.h: objxref.pl obj_xref.txt obj_mac.num +# This doesn't really need obj_mac.h, but since that rule reads & writes +# obj_mac.num, we can't run in parallel with it. +obj_xref.h: objxref.pl obj_xref.txt obj_mac.num obj_mac.h $(PERL) objxref.pl obj_mac.num obj_xref.txt > obj_xref.h - @sleep 1; touch obj_xref.h; sleep 1 files: $(PERL) $(TOP)/util/files.pl Makefile >> $(TOP)/MINFO -- 2.3.1 From rt at openssl.org Sun Mar 8 10:55:03 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sun, 8 Mar 2015 11:55:03 +0100 Subject: [openssl-dev] [openssl.org #3738] [PATCH] tell make running subcommands are make based In-Reply-To: <1425797389-3813-1-git-send-email-vapier@gentoo.org> References: <1425797389-3813-1-git-send-email-vapier@gentoo.org> Message-ID: Some of the recursive commands are too complicated for make to detect that the child is actually make. This causes warnings like: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. Lets add + to the rules we know are make based. --- Makefile.org | 30 ++++++++++----------- crypto/Makefile | 8 +++--- engines/Makefile | 14 +++++----- test/Makefile | 80 ++++++++++++++++++++++++++++---------------------------- 4 files changed, 66 insertions(+), 66 deletions(-) diff --git a/Makefile.org b/Makefile.org index 5f8e03d..dcf9f2b 100644 --- a/Makefile.org +++ b/Makefile.org @@ -290,22 +290,22 @@ build_all: build_libs build_apps build_tests build_tools build_libs: build_crypto build_ssl build_engines build_crypto: - @dir=crypto; target=all; $(BUILD_ONE_CMD) + + at dir=crypto; target=all; $(BUILD_ONE_CMD) build_ssl: build_crypto - @dir=ssl; target=all; $(BUILD_ONE_CMD) + + at dir=ssl; target=all; $(BUILD_ONE_CMD) build_engines: build_crypto - @dir=engines; target=all; AS='$(CC) -c'; export AS; $(BUILD_ONE_CMD) + + at dir=engines; target=all; AS='$(CC) -c'; export AS; $(BUILD_ONE_CMD) build_apps: build_libs - @dir=apps; target=all; $(BUILD_ONE_CMD) + + at dir=apps; target=all; $(BUILD_ONE_CMD) build_tests: build_libs - @dir=test; target=all; $(BUILD_ONE_CMD) + + at dir=test; target=all; $(BUILD_ONE_CMD) build_tools: build_libs - @dir=tools; target=all; $(BUILD_ONE_CMD) + + at dir=tools; target=all; $(BUILD_ONE_CMD) all_testapps: build_libs build_testapps build_testapps: - @dir=crypto; target=testapps; $(BUILD_ONE_CMD) + + at dir=crypto; target=testapps; $(BUILD_ONE_CMD) libcrypto$(SHLIB_EXT): libcrypto.a @if [ "$(SHLIB_TARGET)" != "" ]; then \ @@ -415,7 +415,7 @@ libclean: clean: libclean rm -f shlib/*.o *.o core a.out fluff rehash.time testlog make.log cctest cctest.c rm -rf *.bak certs/.0 - @set -e; target=clean; $(RECURSIVE_BUILD_CMD) + + at set -e; target=clean; $(RECURSIVE_BUILD_CMD) rm -f $(LIBS) tags TAGS rm -f openssl.pc libssl.pc libcrypto.pc rm -f speed.* .pure @@ -431,19 +431,19 @@ makefile.one: files files: $(PERL) $(TOP)/util/files.pl Makefile > $(TOP)/MINFO - @set -e; target=files; $(RECURSIVE_BUILD_CMD) + + at set -e; target=files; $(RECURSIVE_BUILD_CMD) links: @$(PERL) $(TOP)/util/mkdir-p.pl include/openssl @$(PERL) $(TOP)/util/mklink.pl include/openssl $(EXHEADER) - @set -e; target=links; $(RECURSIVE_BUILD_CMD) + + at set -e; target=links; $(RECURSIVE_BUILD_CMD) gentests: @(cd test && echo "generating dummy tests (if needed)..." && \ $(CLEARENV) && $(MAKE) -e $(BUILDENV) TESTS='$(TESTS)' OPENSSL_DEBUG_MEMORY=on generate ); dclean: - @set -e; target=dclean; $(RECURSIVE_BUILD_CMD) + + at set -e; target=dclean; $(RECURSIVE_BUILD_CMD) rehash: rehash.time rehash.time: certs apps @@ -467,10 +467,10 @@ report: @$(PERL) util/selftest.pl depend: - @set -e; target=depend; $(RECURSIVE_BUILD_CMD) + + at set -e; target=depend; $(RECURSIVE_BUILD_CMD) lint: - @set -e; target=lint; $(RECURSIVE_BUILD_CMD) + + at set -e; target=lint; $(RECURSIVE_BUILD_CMD) tags TAGS: FORCE rm -f TAGS tags @@ -561,7 +561,7 @@ install_sw: install_dirs (cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \ chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i ); \ done; - @set -e; target=install; $(RECURSIVE_BUILD_CMD) + + at set -e; target=install; $(RECURSIVE_BUILD_CMD) @set -e; liblist="$(LIBS)"; for i in $$liblist ;\ do \ if [ -f "$$i" ]; then \ @@ -655,7 +655,7 @@ uninstall_sw: $(RM) $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/pkgconfig/libcrypto.pc $(RM) $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/pkgconfig/libssl.pc $(RM) $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/pkgconfig/openssl.pc - @target=uninstall; $(RECURSIVE_BUILD_CMD) + + at target=uninstall; $(RECURSIVE_BUILD_CMD) install_html_docs: here="`pwd`"; \ diff --git a/crypto/Makefile b/crypto/Makefile index 6e1c129..b3cb0b9 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -89,11 +89,11 @@ alphacpuid.s: alphacpuid.pl arm64cpuid.S: arm64cpuid.pl; $(PERL) arm64cpuid.pl $(PERLASM_SCHEME) > $@ subdirs: - @target=all; $(RECURSIVE_MAKE) + + at target=all; $(RECURSIVE_MAKE) files: $(PERL) $(TOP)/util/files.pl "CPUID_OBJ=$(CPUID_OBJ)" Makefile >> $(TOP)/MINFO - @target=files; $(RECURSIVE_MAKE) + + at target=files; $(RECURSIVE_MAKE) links: @$(PERL) $(TOP)/util/mklink.pl ../include/openssl $(EXHEADER) @@ -114,7 +114,7 @@ shared: buildinf.h lib subdirs fi libs: - @target=lib; $(RECURSIVE_MAKE) + + at target=lib; $(RECURSIVE_MAKE) install: @[ -n "$(INSTALLTOP)" ] # should be set by top Makefile... @@ -123,7 +123,7 @@ install: (cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \ chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i ); \ done; - @target=install; $(RECURSIVE_MAKE) + + at target=install; $(RECURSIVE_MAKE) uninstall: diff --git a/engines/Makefile b/engines/Makefile index da4ae77..c359c4c 100644 --- a/engines/Makefile +++ b/engines/Makefile @@ -84,14 +84,14 @@ e_padlock-x86_64.s: asm/e_padlock-x86_64.pl $(PERL) asm/e_padlock-x86_64.pl $(PERLASM_SCHEME) > $@ subdirs: - @target=all; $(RECURSIVE_MAKE) + + at target=all; $(RECURSIVE_MAKE) files: $(PERL) $(TOP)/util/files.pl Makefile >> $(TOP)/MINFO - @target=files; $(RECURSIVE_MAKE) + + at target=files; $(RECURSIVE_MAKE) links: - @target=links; $(RECURSIVE_MAKE) + + at target=links; $(RECURSIVE_MAKE) # XXXXX This currently only works on systems that use .so as suffix # for shared libraries as well as for Cygwin which uses the @@ -122,7 +122,7 @@ install: mv -f $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx.new $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR)/engines/$$pfx$$l$$sfx ); \ done; \ fi - @target=install; $(RECURSIVE_MAKE) + + at target=install; $(RECURSIVE_MAKE) tags: ctags $(SRC) @@ -138,7 +138,7 @@ tests: lint: lint -DLINT $(INCLUDES) $(SRC)>fluff - @target=lint; $(RECURSIVE_MAKE) + + at target=lint; $(RECURSIVE_MAKE) depend: @if [ -z "$(THIS)" ]; then \ @@ -150,11 +150,11 @@ depend: dclean: $(PERL) -pe 'if (/^# DO NOT DELETE THIS LINE/) {print; exit(0);}' $(MAKEFILE) >Makefile.new mv -f Makefile.new $(MAKEFILE) - @target=dclean; $(RECURSIVE_MAKE) + + at target=dclean; $(RECURSIVE_MAKE) clean: rm -f *.o *.obj lib tags core .pure .nfs* *.old *.bak fluff - @target=clean; $(RECURSIVE_MAKE) + + at target=clean; $(RECURSIVE_MAKE) # DO NOT DELETE THIS LINE -- make depend depends on it. diff --git a/test/Makefile b/test/Makefile index 6c85b04..25dc359 100644 --- a/test/Makefile +++ b/test/Makefile @@ -397,31 +397,31 @@ BUILD_CMD_STATIC=shlib_target=; \ link_app.$${shlib_target} $(RSATEST)$(EXE_EXT): $(RSATEST).o $(DLIBCRYPTO) - @target=$(RSATEST); $(BUILD_CMD) + + at target=$(RSATEST); $(BUILD_CMD) $(BNTEST)$(EXE_EXT): $(BNTEST).o $(DLIBCRYPTO) - @target=$(BNTEST); $(BUILD_CMD) + + at target=$(BNTEST); $(BUILD_CMD) $(ECTEST)$(EXE_EXT): $(ECTEST).o $(DLIBCRYPTO) - @target=$(ECTEST); $(BUILD_CMD) + + at target=$(ECTEST); $(BUILD_CMD) $(EXPTEST)$(EXE_EXT): $(EXPTEST).o $(DLIBCRYPTO) - @target=$(EXPTEST); $(BUILD_CMD) + + at target=$(EXPTEST); $(BUILD_CMD) $(IDEATEST)$(EXE_EXT): $(IDEATEST).o $(DLIBCRYPTO) - @target=$(IDEATEST); $(BUILD_CMD) + + at target=$(IDEATEST); $(BUILD_CMD) $(MD2TEST)$(EXE_EXT): $(MD2TEST).o $(DLIBCRYPTO) - @target=$(MD2TEST); $(BUILD_CMD) + + at target=$(MD2TEST); $(BUILD_CMD) $(SHA1TEST)$(EXE_EXT): $(SHA1TEST).o $(DLIBCRYPTO) - @target=$(SHA1TEST); $(BUILD_CMD) + + at target=$(SHA1TEST); $(BUILD_CMD) $(SHA256TEST)$(EXE_EXT): $(SHA256TEST).o $(DLIBCRYPTO) - @target=$(SHA256TEST); $(BUILD_CMD) + + at target=$(SHA256TEST); $(BUILD_CMD) $(SHA512TEST)$(EXE_EXT): $(SHA512TEST).o $(DLIBCRYPTO) - @target=$(SHA512TEST); $(BUILD_CMD) + + at target=$(SHA512TEST); $(BUILD_CMD) FIPS_BUILD_CMD=shlib_target=; if [ -n "$(SHARED_LIBS)" ]; then \ shlib_target="$(SHLIB_TARGET)"; \ @@ -453,94 +453,94 @@ FIPS_CRYPTO_BUILD_CMD=shlib_target=; if [ -n "$(SHARED_LIBS)" ]; then \ link_app.$${shlib_target} $(RMDTEST)$(EXE_EXT): $(RMDTEST).o $(DLIBCRYPTO) - @target=$(RMDTEST); $(BUILD_CMD) + + at target=$(RMDTEST); $(BUILD_CMD) $(MDC2TEST)$(EXE_EXT): $(MDC2TEST).o $(DLIBCRYPTO) - @target=$(MDC2TEST); $(BUILD_CMD) + + at target=$(MDC2TEST); $(BUILD_CMD) $(MD4TEST)$(EXE_EXT): $(MD4TEST).o $(DLIBCRYPTO) - @target=$(MD4TEST); $(BUILD_CMD) + + at target=$(MD4TEST); $(BUILD_CMD) $(MD5TEST)$(EXE_EXT): $(MD5TEST).o $(DLIBCRYPTO) - @target=$(MD5TEST); $(BUILD_CMD) + + at target=$(MD5TEST); $(BUILD_CMD) $(HMACTEST)$(EXE_EXT): $(HMACTEST).o $(DLIBCRYPTO) - @target=$(HMACTEST); $(BUILD_CMD) + + at target=$(HMACTEST); $(BUILD_CMD) $(WPTEST)$(EXE_EXT): $(WPTEST).o $(DLIBCRYPTO) - @target=$(WPTEST); $(BUILD_CMD) + + at target=$(WPTEST); $(BUILD_CMD) $(RC2TEST)$(EXE_EXT): $(RC2TEST).o $(DLIBCRYPTO) - @target=$(RC2TEST); $(BUILD_CMD) + + at target=$(RC2TEST); $(BUILD_CMD) $(BFTEST)$(EXE_EXT): $(BFTEST).o $(DLIBCRYPTO) - @target=$(BFTEST); $(BUILD_CMD) + + at target=$(BFTEST); $(BUILD_CMD) $(CASTTEST)$(EXE_EXT): $(CASTTEST).o $(DLIBCRYPTO) - @target=$(CASTTEST); $(BUILD_CMD) + + at target=$(CASTTEST); $(BUILD_CMD) $(RC4TEST)$(EXE_EXT): $(RC4TEST).o $(DLIBCRYPTO) - @target=$(RC4TEST); $(BUILD_CMD) + + at target=$(RC4TEST); $(BUILD_CMD) $(RC5TEST)$(EXE_EXT): $(RC5TEST).o $(DLIBCRYPTO) - @target=$(RC5TEST); $(BUILD_CMD) + + at target=$(RC5TEST); $(BUILD_CMD) $(DESTEST)$(EXE_EXT): $(DESTEST).o $(DLIBCRYPTO) - @target=$(DESTEST); $(BUILD_CMD) + + at target=$(DESTEST); $(BUILD_CMD) $(GOST2814789TEST)$(EXE_EXT): $(GOST2814789TEST).o $(DLIBCRYPTO) - @target=$(GOST2814789TEST); $(BUILD_CMD) + + at target=$(GOST2814789TEST); $(BUILD_CMD) $(RANDTEST)$(EXE_EXT): $(RANDTEST).o $(DLIBCRYPTO) - @target=$(RANDTEST); $(BUILD_CMD) + + at target=$(RANDTEST); $(BUILD_CMD) $(DHTEST)$(EXE_EXT): $(DHTEST).o $(DLIBCRYPTO) - @target=$(DHTEST); $(BUILD_CMD) + + at target=$(DHTEST); $(BUILD_CMD) $(DSATEST)$(EXE_EXT): $(DSATEST).o $(DLIBCRYPTO) - @target=$(DSATEST); $(BUILD_CMD) + + at target=$(DSATEST); $(BUILD_CMD) $(METHTEST)$(EXE_EXT): $(METHTEST).o $(DLIBCRYPTO) - @target=$(METHTEST); $(BUILD_CMD) + + at target=$(METHTEST); $(BUILD_CMD) $(SSLTEST)$(EXE_EXT): $(SSLTEST).o $(DLIBSSL) $(DLIBCRYPTO) - @target=$(SSLTEST); $(BUILD_CMD) + + at target=$(SSLTEST); $(BUILD_CMD) $(ENGINETEST)$(EXE_EXT): $(ENGINETEST).o $(DLIBCRYPTO) - @target=$(ENGINETEST); $(BUILD_CMD) + + at target=$(ENGINETEST); $(BUILD_CMD) $(EVPTEST)$(EXE_EXT): $(EVPTEST).o $(DLIBCRYPTO) - @target=$(EVPTEST); $(BUILD_CMD) + + at target=$(EVPTEST); $(BUILD_CMD) $(EVPEXTRATEST)$(EXE_EXT): $(EVPEXTRATEST).o $(DLIBCRYPTO) - @target=$(EVPEXTRATEST); $(BUILD_CMD) + + at target=$(EVPEXTRATEST); $(BUILD_CMD) $(P5_CRPT2_TEST)$(EXE_EXT): $(P5_CRPT2_TEST).o $(DLIBCRYPTO) - @target=$(P5_CRPT2_TEST); $(BUILD_CMD) + + at target=$(P5_CRPT2_TEST); $(BUILD_CMD) $(ECDSATEST)$(EXE_EXT): $(ECDSATEST).o $(DLIBCRYPTO) - @target=$(ECDSATEST); $(BUILD_CMD) + + at target=$(ECDSATEST); $(BUILD_CMD) $(ECDHTEST)$(EXE_EXT): $(ECDHTEST).o $(DLIBCRYPTO) - @target=$(ECDHTEST); $(BUILD_CMD) + + at target=$(ECDHTEST); $(BUILD_CMD) $(IGETEST)$(EXE_EXT): $(IGETEST).o $(DLIBCRYPTO) - @target=$(IGETEST); $(BUILD_CMD) + + at target=$(IGETEST); $(BUILD_CMD) $(JPAKETEST)$(EXE_EXT): $(JPAKETEST).o $(DLIBCRYPTO) - @target=$(JPAKETEST); $(BUILD_CMD) + + at target=$(JPAKETEST); $(BUILD_CMD) $(SRPTEST)$(EXE_EXT): $(SRPTEST).o $(DLIBCRYPTO) - @target=$(SRPTEST); $(BUILD_CMD) + + at target=$(SRPTEST); $(BUILD_CMD) $(V3NAMETEST)$(EXE_EXT): $(V3NAMETEST).o $(DLIBCRYPTO) - @target=$(V3NAMETEST); $(BUILD_CMD) + + at target=$(V3NAMETEST); $(BUILD_CMD) $(HEARTBEATTEST)$(EXE_EXT): $(HEARTBEATTEST).o $(DLIBCRYPTO) testutil.o - @target=$(HEARTBEATTEST) testutil=testutil.o; $(BUILD_CMD_STATIC) + + at target=$(HEARTBEATTEST) testutil=testutil.o; $(BUILD_CMD_STATIC) $(CONSTTIMETEST)$(EXE_EXT): $(CONSTTIMETEST).o - @target=$(CONSTTIMETEST) $(BUILD_CMD) + + at target=$(CONSTTIMETEST) $(BUILD_CMD) #$(AESTEST).o: $(AESTEST).c # $(CC) -c $(CFLAGS) -DINTERMEDIATE_VALUE_KAT -DTRACE_KAT_MCT $(AESTEST).c @@ -553,7 +553,7 @@ $(CONSTTIMETEST)$(EXE_EXT): $(CONSTTIMETEST).o # fi dummytest$(EXE_EXT): dummytest.o $(DLIBCRYPTO) - @target=dummytest; $(BUILD_CMD) + + at target=dummytest; $(BUILD_CMD) # DO NOT DELETE THIS LINE -- make depend depends on it. -- 2.3.1 From rt at openssl.org Sun Mar 8 19:03:10 2015 From: rt at openssl.org (Kent Fredric via RT) Date: Sun, 8 Mar 2015 20:03:10 +0100 Subject: [openssl-dev] [openssl.org #3739] regression: syswrite payloads >90kb can trigger EFAULT "Bad address" error on 1.0.2 In-Reply-To: References: Message-ID: I had a hard time nailing down this problem, so apologies in advance if this bug is confusing. 1.0.2 seems to have a problem exhibited in various places doing HTTPS uploads over 90k ( ballpark ). 1.0.1l did not suffer this error. The problem is exhibited in both ruby openssl bindings ( https://github.com/excon/excon/issues/467 ) and perl openssl bindings ( https://rt.cpan.org/Ticket/Display.html?id=102640 ) As to where this problem is cropping up and where it needs fixing is uncertain. I am personally replicating this issue on Gentoo X86_64 ( with a few gentoo specified patches ) , but it is apparent that other people are replicating the issue on OSX Homebrew. ( as per the ruby issue ). -- Kent *KENTNL* - https://metacpan.org/author/KENTNL From rsalz at akamai.com Sun Mar 8 20:26:20 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 8 Mar 2015 20:26:20 +0000 Subject: [openssl-dev] [openssl.org #3738] [PATCH] tell make running subcommands are make based In-Reply-To: References: <1425797389-3813-1-git-send-email-vapier@gentoo.org> Message-ID: > Lets add + to the rules we know are make based. Isn't that a gnu-make-only thing? -- Senior Architect, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From rt at openssl.org Sun Mar 8 20:26:51 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 8 Mar 2015 21:26:51 +0100 Subject: [openssl-dev] [openssl.org #3738] [PATCH] tell make running subcommands are make based In-Reply-To: References: <1425797389-3813-1-git-send-email-vapier@gentoo.org> Message-ID: > Lets add + to the rules we know are make based. Isn't that a gnu-make-only thing? -- Senior Architect, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From dougkwan at google.com Mon Mar 9 01:04:04 2015 From: dougkwan at google.com (=?UTF-8?B?RG91ZyBLd2FuICjpl5zmjK/lvrcp?=) Date: Sun, 8 Mar 2015 18:04:04 -0700 Subject: [openssl-dev] [PATCH] Clean up portable implementation of ROTL Message-ID: Clean up portable implementation of ROTL so that there is no undefined behaviour in shift and some commonly used compilers can generate efficient code using rotate instructions. This is tested on x86_64, little-endian POWER and aarch64 with gcc-4.9 and current top of trunk clang. Both compilers generate native rotation instructions for 32-bit inputs. Since the portable implementation is now clean, there is no need for the special code guarded by PEDANTIC. --- crypto/cast/cast_lcl.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/crypto/cast/cast_lcl.h b/crypto/cast/cast_lcl.h index b0f0829..588da44 100644 --- a/crypto/cast/cast_lcl.h +++ b/crypto/cast/cast_lcl.h @@ -152,10 +152,8 @@ #if defined(OPENSSL_SYS_WIN32) && defined(_MSC_VER) # define ROTL(a,n) (_lrotl(a,n)) -#elif defined(PEDANTIC) -# define ROTL(a,n) ((((a)<<(n))&0xffffffffL)|((a)>>((32-(n))&31))) #else -# define ROTL(a,n) ((((a)<<(n))&0xffffffffL)|((a)>>(32-(n)))) +# define ROTL(a,n) ((((a)<<(n))|((a)>>(-(n)&31)))&0xffffffffL) #endif #define C_M 0x3fc -- 2.2.0.rc0.207.ga3a616c -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at efca.com Mon Mar 9 02:52:50 2015 From: erik at efca.com (Erik Forsberg) Date: Sun, 8 Mar 2015 19:52:50 -0700 Subject: [openssl-dev] [openssl.org #3739] regression: syswrite payloads >90kb can trigger EFAULT "Bad address" error on 1.0.2 Message-ID: I found the same issue, seems unique to 1.0.2 MULTIBLOCK The attached patch (developed by Matt Caswell) appears to fix it for me. An alternative, to avoid the issue is compiling with OPENSSL_NO_MULTIBLOCK or only writing small blocks of memory per SSL_write. Flow control was not handled properly in the new multiblock code. >-- Original Message -- > >I had a hard time nailing down this problem, so apologies in advance if >this bug is confusing. > >1.0.2 seems to have a problem exhibited in various places doing HTTPS >uploads over 90k ( ballpark ). > >1.0.1l did not suffer this error. > >The problem is exhibited in both ruby openssl bindings ( >https://github.com/excon/excon/issues/467 ) and perl openssl bindings ( >https://rt.cpan.org/Ticket/Display.html?id=102640 ) > >As to where this problem is cropping up and where it needs fixing is >uncertain. > >I am personally replicating this issue on Gentoo X86_64 ( with a few gentoo >specified patches ) , but it is apparent that other people are replicating >the issue on OSX Homebrew. ( as per the ruby issue ). > > > >-- >Kent > >*KENTNL* - https://metacpan.org/author/KENTNL > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: multiblock.patch Type: application/octet-stream Size: 489 bytes Desc: not available URL: From rt at openssl.org Mon Mar 9 06:15:28 2015 From: rt at openssl.org (Kai Engert via RT) Date: Mon, 9 Mar 2015 07:15:28 +0100 Subject: [openssl-dev] [openssl.org #3740] build error in ssl/kssl.c, deferencing pointer of incomplete type In-Reply-To: <1425853749.20606.25.camel@kuix.de> References: <1425853749.20606.25.camel@kuix.de> Message-ID: I'm trying to build the tip of openssl from github. I ran into a compiler error, trying to dereference a pointer of an incomplete type in this function: void SSL_set0_kssl_ctx(SSL *s, KSSL_CTX *kctx) The patch below fixed it for me: diff --git a/ssl/kssl.c b/ssl/kssl.c index 6ec3742..ce43529 100644 --- a/ssl/kssl.c +++ b/ssl/kssl.c @@ -79,6 +79,7 @@ #include #include #include "kssl_lcl.h" +#include "ssl_locl.h" #ifndef OPENSSL_NO_KRB5 From matt at openssl.org Mon Mar 9 09:58:25 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 09 Mar 2015 09:58:25 +0000 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: References: Message-ID: <54FD6EC1.30402@openssl.org> On 08/03/15 04:04, Kannamraju P wrote: > ---------- Forwarded message ---------- > From: "Kannamraju P" > > Date: Mar 6, 2015 12:44 AM > Subject: DTLS handshake not getting completed > To: > > Cc: > > Hi All, > > I am testing out a DTLS-SRTP webrtc call and running into following issue. > > Even after DTLS client sends finished message DTLS server (openssl) > doesnt do > a state transition and send a change cipher spec , it still waits . > > Attaching PCAP for your reference.Any idea what could be the reason. Could be this: https://rt.openssl.org/Ticket/Display.html?id=3657&user=guest&pass=guest Matt From rt at openssl.org Mon Mar 9 11:00:02 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 9 Mar 2015 12:00:02 +0100 Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco DTLS_BAD_VER In-Reply-To: <1424082497.1804.26.camel@infradead.org> References: <1424082497.1804.26.camel@infradead.org> Message-ID: Fixed in this commit: https://github.com/openssl/openssl/commit/5178a16c4375471d25e1f5ef5de46febb62a5529 Closing ticket. Matt From rt at openssl.org Mon Mar 9 11:11:39 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 9 Mar 2015 12:11:39 +0100 Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello In-Reply-To: <1424220216.24248.47.camel@infradead.org> References: <1424220216.24248.47.camel@infradead.org> Message-ID: Fixed in this commit: https://github.com/openssl/openssl/commit/f7683aaf36341dc65672ac2ccdbfd4a232e3626d Thanks for the patch. I'm leaving this ticket open for now to consider the DTLS 0.9 method stuff (which I would look at from a master only, point of view). Matt From pkannamraju at gmail.com Mon Mar 9 15:17:21 2015 From: pkannamraju at gmail.com (Kannamraju P) Date: Mon, 9 Mar 2015 11:17:21 -0400 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: <54FD6EC1.30402@openssl.org> References: <54FD6EC1.30402@openssl.org> Message-ID: Hi Matt, I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running into the same issue.Any idea what could be the issue. Thanks, Raju. On Mon, Mar 9, 2015 at 5:58 AM, Matt Caswell wrote: > > > On 08/03/15 04:04, Kannamraju P wrote: > > ---------- Forwarded message ---------- > > From: "Kannamraju P" pkannamraju at gmail.com>> > > Date: Mar 6, 2015 12:44 AM > > Subject: DTLS handshake not getting completed > > To: > > > Cc: > > > > Hi All, > > > > I am testing out a DTLS-SRTP webrtc call and running into following > issue. > > > > Even after DTLS client sends finished message DTLS server (openssl) > > doesnt do > > a state transition and send a change cipher spec , it still waits . > > > > Attaching PCAP for your reference.Any idea what could be the reason. > > Could be this: > https://rt.openssl.org/Ticket/Display.html?id=3657&user=guest&pass=guest > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- thanks & Regards, Raju -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Mar 9 16:33:22 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 09 Mar 2015 16:33:22 +0000 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: References: <54FD6EC1.30402@openssl.org> Message-ID: <54FDCB52.8040907@openssl.org> On 09/03/15 15:17, Kannamraju P wrote: > Hi Matt, > > I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running > into the same > issue.Any idea what could be the issue. Hmmmmm....what version of OpenSSL are you using? Do you still get this if you use the git HEAD version? Matt From pkannamraju at gmail.com Mon Mar 9 16:38:08 2015 From: pkannamraju at gmail.com (Kannamraju P) Date: Mon, 9 Mar 2015 12:38:08 -0400 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: <54FDCB52.8040907@openssl.org> References: <54FD6EC1.30402@openssl.org> <54FDCB52.8040907@openssl.org> Message-ID: I am using openssl-1.0.1h . On Mon, Mar 9, 2015 at 12:33 PM, Matt Caswell wrote: > > > On 09/03/15 15:17, Kannamraju P wrote: > > Hi Matt, > > > > I already have SSL_CTX_set_read_ahead(ctx, 1); set , still running > > into the same > > issue.Any idea what could be the issue. > > Hmmmmm....what version of OpenSSL are you using? Do you still get this > if you use the git HEAD version? > > Matt > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- thanks & Regards, Raju -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Mar 9 16:42:39 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 09 Mar 2015 16:42:39 +0000 Subject: [openssl-dev] Fwd: DTLS handshake not getting completed In-Reply-To: References: <54FD6EC1.30402@openssl.org> <54FDCB52.8040907@openssl.org> Message-ID: <54FDCD7F.9040803@openssl.org> On 09/03/15 16:38, Kannamraju P wrote: > I am using openssl-1.0.1h . Please can you try the git HEAD (OpenSSL_1_0_1-stable) and let me know if you still have the same issue. There have been quite a few DTLS fixes that have gone in since 1.0.1h. Thanks Matt From foleyj at cisco.com Tue Mar 10 17:02:25 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 10 Mar 2015 13:02:25 -0400 Subject: [openssl-dev] Intermittent s_server issues with ECDHE cipher suites Message-ID: <54FF23A1.9030007@cisco.com> There appears to be a problem when using s_server with ECDHE cipher suites in OpenSSL_1_0_1-stable. Due to an uninitialized variable, SSL_CTX_set_tmp_ecdh() is not always invoked within s_server. The following patch resolves the issue. This bug appears to have been introduced by 059907771b89549cbd07a81df1a5bdf51e062066. diff --git a/apps/s_server.c b/apps/s_server.c index caba5b3..2a44223 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -998,7 +998,7 @@ int MAIN(int argc, char *argv[]) int off = 0; int no_tmp_rsa = 0, no_dhe = 0, nocert = 0; #ifndef OPENSSL_NO_ECDH - int no_ecdhe; + int no_ecdhe = 0; #endif int state = 0; const SSL_METHOD *meth = NULL; From steve at openssl.org Wed Mar 11 00:03:26 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 11 Mar 2015 00:03:26 +0000 Subject: [openssl-dev] Intent of the private_ wrappers In-Reply-To: <54F9AD18.1080106@scheftech.com> References: <54F9AD18.1080106@scheftech.com> Message-ID: <20150311000326.GA29168@openssl.org> On Fri, Mar 06, 2015, Steve Schefter wrote: > Hi. > > I am compiling OpenSSL with the FIPS options and seeing a build > error. My question is more about the intent than the problem. > > One example: When apps/speed.c is compiled with FIPS enabled, > OPENSSL_FIPS is defined and DES_set_key_unchecked gets defined to be > private_DES_set_key_unchecked. > > The use of the private_ function means that fips_cipher_abort is not called. > > Am I correct that the intent is to allow the OpenSSl-provided apps > to use the low level APIs (like DES) while user applications linking > with libcrypto.so can not? > > The problem is that the OpenSSL-provided apps also link with that > library and the private_ functions are not global (they are not in > openssl.ld). So the OpenSSL-provided apps fail to link. In the > above example, apps/speed.c can't find > private_DES_set_key_unchecked(). > > Or am I not understanding the intent? > Which OS and version of OpenSSL are you using? The intent of the private_ wrappers is to block the accidental use of low level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP: so if an application did use low level APIs it would not be compliant. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at scheftech.com Wed Mar 11 01:21:00 2015 From: steve at scheftech.com (Steve Schefter) Date: Tue, 10 Mar 2015 21:21:00 -0400 Subject: [openssl-dev] Intent of the private_ wrappers In-Reply-To: <20150311000326.GA29168@openssl.org> References: <54F9AD18.1080106@scheftech.com> <20150311000326.GA29168@openssl.org> Message-ID: <54FF987C.6030004@scheftech.com> On 3/10/2015 8:03 PM, Dr. Stephen Henson wrote: > On Fri, Mar 06, 2015, Steve Schefter wrote: > >> Hi. >> >> I am compiling OpenSSL with the FIPS options and seeing a build >> error. My question is more about the intent than the problem. >> >> One example: When apps/speed.c is compiled with FIPS enabled, >> OPENSSL_FIPS is defined and DES_set_key_unchecked gets defined to be >> private_DES_set_key_unchecked. >> >> The use of the private_ function means that fips_cipher_abort is not called. >> >> Am I correct that the intent is to allow the OpenSSl-provided apps >> to use the low level APIs (like DES) while user applications linking >> with libcrypto.so can not? >> >> The problem is that the OpenSSL-provided apps also link with that >> library and the private_ functions are not global (they are not in >> openssl.ld). So the OpenSSL-provided apps fail to link. In the >> above example, apps/speed.c can't find >> private_DES_set_key_unchecked(). >> >> Or am I not understanding the intent? >> > > Which OS and version of OpenSSL are you using? I am using 1.0.1j on Linux. I've not tried to build 1.0.2, but I see the same use of the private_ wrappers in that code too. > The intent of the private_ wrappers is to block the accidental use of low > level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP: > so if an application did use low level APIs it would not be compliant. Okay, so that is mostly what I thought I understood. Except for the "accidental" part. I thought it was to block access altogether. Unfortunately, the use of the private_ wrappers doesn't work on Linux, or at least with my Linux. If I run "nm" on libcrtypto, the private_ functions have a lower case t for the symbol type, meaning that they are within the local text (code) section. They are not global. So when it tries to build the OpenSSL-provided applications, the linker can't find the private_ functions. This results in errors like, "apps/speed.c: undefined reference to private_AES_set_encrypt_key". It would be possible to resolve this by adding the private_ wrappers to openssl.ld which would make them global within the library and not local. But I'm not sure if their use should be more discouraged than that implies. Regards, Steve From steve at openssl.org Wed Mar 11 02:35:07 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 11 Mar 2015 02:35:07 +0000 Subject: [openssl-dev] Intent of the private_ wrappers In-Reply-To: <54FF987C.6030004@scheftech.com> References: <54F9AD18.1080106@scheftech.com> <20150311000326.GA29168@openssl.org> <54FF987C.6030004@scheftech.com> Message-ID: <20150311023507.GA18472@openssl.org> On Tue, Mar 10, 2015, Steve Schefter wrote: > On 3/10/2015 8:03 PM, Dr. Stephen Henson wrote: > >On Fri, Mar 06, 2015, Steve Schefter wrote: > > > > > >Which OS and version of OpenSSL are you using? > > I am using 1.0.1j on Linux. I've not tried to build 1.0.2, but I > see the same use of the private_ wrappers in that code too. > Well in the case of 1.0.1 the private_ functions call the "normal" algorithms in OpenSSL itself: i.e. not the validated ones at all. The low level functions in the fips module being fips_* but as I said an application which calls the low level APIs is not compliant. > >The intent of the private_ wrappers is to block the accidental use of low > >level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP: > >so if an application did use low level APIs it would not be compliant. > > Okay, so that is mostly what I thought I understood. Except for the > "accidental" part. I thought it was to block access altogether. > > Unfortunately, the use of the private_ wrappers doesn't work on > Linux, or at least with my Linux. If I run "nm" on libcrtypto, the > private_ functions have a lower case t for the symbol type, meaning > that they are within the local text (code) section. They are not > global. So when it tries to build the OpenSSL-provided > applications, the linker can't find the private_ functions. This > results in errors like, "apps/speed.c: undefined reference to > private_AES_set_encrypt_key". > > It would be possible to resolve this by adding the private_ wrappers > to openssl.ld which would make them global within the library and > not local. But I'm not sure if their use should be more discouraged > than that implies. > Well if the application is to be compliant it cannot use the low level APIs at all. That's why the block is for accidental usage. If an application decides to ignore than and bypass the blocking and use the private_* wrappers it's free to do so with all the non-compliant consequences. I just built OpenSSL 1.0.1 from source using the normal build procedure on Ubuntu Linux 14.04.2 and it *did* make the private_* symbols global in libcrypto.so for example: 00000000000e2180 T private_AES_set_decrypt_key 00000000000e1eb0 T private_AES_set_encrypt_key So I'm not sure why they're not global in your case. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Mar 11 07:17:37 2015 From: rt at openssl.org (Billy Brumley via RT) Date: Wed, 11 Mar 2015 08:17:37 +0100 Subject: [openssl-dev] [openssl.org #3741] [PATCH] Better side-channel security for ECC table lookups In-Reply-To: References: Message-ID: This patch relates to RT 3667 and the paper here (to appear at COSADE 2015): https://eprint.iacr.org/2015/036 Instead of a direct table lookup for precomputed points in the generic ECC multi-scalar multiplication routine, it computes the point by traversing the entire table. Motivation is better side-channel security. Benchmarking below (evidently code path is not executed for nistp256 anymore). Costs are 6-10% for ECDSA sign, 2-6% for ECDSA verify (defense unnecessary, but AFAICT there is no way to authoritatively distinguish at this depth whether to protect scalars or not), and 1-5% for ECDH. BBB openssl speed ecdsa before: sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0000s 0.0002s 20818.1 5670.3 192 bit ecdsa (nistp192) 0.0001s 0.0002s 17844.1 4570.7 224 bit ecdsa (nistp224) 0.0001s 0.0003s 13452.7 3413.4 256 bit ecdsa (nistp256) 0.0000s 0.0001s 26485.2 10577.4 384 bit ecdsa (nistp384) 0.0002s 0.0007s 5961.0 1438.0 521 bit ecdsa (nistp521) 0.0004s 0.0015s 2837.1 684.5 openssl speed ecdsa after: sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19056.1 5369.1 192 bit ecdsa (nistp192) 0.0001s 0.0002s 16270.0 4490.4 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12150.9 3354.7 256 bit ecdsa (nistp256) 0.0000s 0.0001s 26489.9 10554.9 384 bit ecdsa (nistp384) 0.0002s 0.0007s 5470.9 1355.5 521 bit ecdsa (nistp521) 0.0004s 0.0015s 2673.3 667.4 openssl speed ecdh before: op op/s 160 bit ecdh (secp160r1) 0.0001s 7025.0 192 bit ecdh (nistp192) 0.0002s 5786.0 224 bit ecdh (nistp224) 0.0002s 4158.1 256 bit ecdh (nistp256) 0.0001s 14899.7 384 bit ecdh (nistp384) 0.0006s 1732.1 521 bit ecdh (nistp521) 0.0012s 820.4 openssl speed ecdh after: op op/s 160 bit ecdh (secp160r1) 0.0001s 6750.8 192 bit ecdh (nistp192) 0.0002s 5477.6 224 bit ecdh (nistp224) 0.0002s 4060.2 256 bit ecdh (nistp256) 0.0001s 14886.2 384 bit ecdh (nistp384) 0.0006s 1709.7 521 bit ecdh (nistp521) 0.0012s 802.1 (I do not have root on the benchmarking machine to peg the clock. Sorry.) $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz stepping : 3 microcode : 26 cpu MHz : 800.000 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm bogomips : 6385.38 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: SNIP -------------- next part -------------- diff -rupN openssl-1.0.2_orig/crypto/ec/ec_mult.c openssl-1.0.2/crypto/ec/ec_mult.c --- openssl-1.0.2_orig/crypto/ec/ec_mult.c 2015-01-22 16:58:32.000000000 +0200 +++ openssl-1.0.2/crypto/ec/ec_mult.c 2015-03-10 13:06:50.661644241 +0200 @@ -306,6 +306,66 @@ static signed char *compute_wNAF(const B return r; } +/** + * Traverses t[i] for 0 <= i < 2**(w-1) and places t[digit >> 1] in r + * with bitwise operations as a side-channel defense. + * Assumes r has enough BIGNUM space so tops of BIGNUMs in t do not overflow. + * See https://eprint.iacr.org/2015/036 + */ +void EC_POINT_select(EC_POINT *r, EC_POINT **t, int digit, int w, int top) { + + w = (1 << w); + + int d, j; + BN_ULONG mask; + + for(j=0; jX.d[j] = 0; + r->Y.d[j] = 0; + r->Z.d[j] = 0; + } + r->X.top = 0; + r->X.dmax = 0; + r->X.neg = 0; + r->X.flags = 0; + r->Y.top = 0; + r->Y.dmax = 0; + r->Y.neg = 0; + r->Y.flags = 0; + r->Z.top = 0; + r->Z.dmax = 0; + r->Z.neg = 0; + r->Z.flags = 0; + r->Z_is_one = 0; + + for(d=1; d> 15); + for(j=0; j> 1]->X.top; j++) { + r->X.d[j] |= mask & t[d >> 1]->X.d[j]; + } + for(j=0; j> 1]->Y.top; j++) { + r->Y.d[j] |= mask & t[d >> 1]->Y.d[j]; + } + for(j=0; j> 1]->Z.top; j++) { + r->Z.d[j] |= mask & t[d >> 1]->Z.d[j]; + } + r->X.top |= mask & (t[d >> 1]->X.top ); + r->X.dmax |= mask & (t[d >> 1]->X.dmax ); + r->X.neg |= mask & (t[d >> 1]->X.neg ); + r->X.flags |= mask & (t[d >> 1]->X.flags ); + r->Y.top |= mask & (t[d >> 1]->Y.top ); + r->Y.dmax |= mask & (t[d >> 1]->Y.dmax ); + r->Y.neg |= mask & (t[d >> 1]->Y.neg ); + r->Y.flags |= mask & (t[d >> 1]->Y.flags ); + r->Z.top |= mask & (t[d >> 1]->Z.top ); + r->Z.dmax |= mask & (t[d >> 1]->Z.dmax ); + r->Z.neg |= mask & (t[d >> 1]->Z.neg ); + r->Z.flags |= mask & (t[d >> 1]->Z.flags ); + r->Z_is_one |= mask & (t[d >> 1]->Z_is_one); + } + +} + /* * TODO: table should be optimised for the wNAF-based implementation, * sometimes smaller windows will give better performance (thus the @@ -532,6 +592,7 @@ int ec_wNAF_mul(const EC_GROUP *group, E tmp_points = pre_comp->points; for (i = num; i < totalnum; i++) { + wsize[i] = wsize[num]; if (i < totalnum - 1) { wNAF_len[i] = blocksize; if (tmp_len < blocksize) { @@ -635,6 +696,11 @@ int ec_wNAF_mul(const EC_GROUP *group, E goto err; #endif + /* use tmp for selecting point addition arg */ + bn_wexpand(&tmp->X, group->field.top); + bn_wexpand(&tmp->Y, group->field.top); + bn_wexpand(&tmp->Z, group->field.top); + r_is_at_infinity = 1; for (k = max_len - 1; k >= 0; k--) { @@ -665,12 +731,16 @@ int ec_wNAF_mul(const EC_GROUP *group, E /* digit > 0 */ if (r_is_at_infinity) { - if (!EC_POINT_copy(r, val_sub[i][digit >> 1])) - goto err; + bn_wexpand(&r->X, group->field.top); + bn_wexpand(&r->Y, group->field.top); + bn_wexpand(&r->Z, group->field.top); + EC_POINT_select(r, val_sub[i], digit, wsize[i], group->field.top); r_is_at_infinity = 0; } else { + /* prepare point addition argument */ + EC_POINT_select(tmp, val_sub[i], digit, wsize[i], group->field.top); if (!EC_POINT_add - (group, r, r, val_sub[i][digit >> 1], ctx)) + (group, r, r, tmp, ctx)) goto err; } } From rt at openssl.org Wed Mar 11 07:17:48 2015 From: rt at openssl.org (Kai Engert via RT) Date: Wed, 11 Mar 2015 08:17:48 +0100 Subject: [openssl-dev] [openssl.org #3742] Support s_client -starttls to xmpp server-to-server ports In-Reply-To: <1425990226.8798.7.camel@kuix.de> References: <1425990226.8798.7.camel@kuix.de> Message-ID: I'd like to be able to use openssl s_client to diagnose SSL/TLS connections to XMPP/Jabber servers. There are two types of xmpp server ports: (a) those that are used for connections from clients, usually port 5222 (c2s). (b) those that are used for connections from server to server, usually port 5269 (s2s). As of today, the -starttls xmpp option supports only (a). In order to support (b), the pre-starttls handshake must be slightly different. Attached is a patch that implements -starttls xmpp-server -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-support-xmpp-server-s2s.patch Type: text/x-patch Size: 3214 bytes Desc: not available URL: From rt at openssl.org Wed Mar 11 07:19:08 2015 From: rt at openssl.org (Arun Raghavan via RT) Date: Wed, 11 Mar 2015 08:19:08 +0100 Subject: [openssl-dev] [openssl.org #3743] [PATCH] Make it possible to only install libs In-Reply-To: <1426055704-23676-1-git-send-email-arun@centricular.com> References: <1426055704-23676-1-git-send-email-arun@centricular.com> Message-ID: This is particularly uesful for places where we don't care about the tools, tests, etc. --- Makefile.org | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/Makefile.org b/Makefile.org index 4f5bff9..be844aa 100644 --- a/Makefile.org +++ b/Makefile.org @@ -134,7 +134,9 @@ FIPSCANLIB= BASEADDR= -DIRS= crypto ssl engines apps test tools +LIBDIRS= crypto ssl engines +EXEDIRS= apps test tools +DIRS= $(LIBDIRS) $(EXEDIRS) ENGDIRS= ccgost SHLIBDIRS= crypto ssl @@ -267,7 +269,7 @@ BUILD_CMD= if [ -d "$$dir" ]; then \ $(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target \ ) || exit 1; \ fi -RECURSIVE_BUILD_CMD=for dir in $(DIRS); do $(BUILD_CMD); done +RECURSIVE_BUILD_CMD=for dir in $${DIRS:-$(DIRS)}; do $(BUILD_CMD); done BUILD_ONE_CMD=\ if expr " $(DIRS) " : ".* $$dir " >/dev/null 2>&1; then \ $(BUILD_CMD); \ @@ -545,14 +547,19 @@ install: all install_docs install_sw uninstall: uninstall_sw uninstall_docs -install_sw: +install_sw: install_libs + @set -e; target=install; DIRS="$(EXEDIRS)"; $(RECURSIVE_BUILD_CMD) + +install_libs: install_common + @set -e; target=install; DIRS="$(LIBDIRS)"; $(RECURSIVE_BUILD_CMD) + +install_common: @$(PERL) $(TOP)/util/mkdir-p.pl $(INSTALLDIRS) @set -e; headerlist="$(EXHEADER)"; for i in $$headerlist;\ do \ (cp $$i $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i; \ chmod 644 $(INSTALL_PREFIX)$(INSTALLTOP)/include/openssl/$$i ); \ done; - @set -e; target=install; $(RECURSIVE_BUILD_CMD) @set -e; liblist="$(LIBS)"; for i in $$liblist ;\ do \ if [ -f "$$i" ]; then \ -- 2.1.0 From rt at openssl.org Wed Mar 11 12:28:53 2015 From: rt at openssl.org (Shawn Fernandes via RT) Date: Wed, 11 Mar 2015 13:28:53 +0100 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, At the moment, we have SSL handshake making use of a single certificate, using a single key-pair present in the certificate. In the event the MITM has the same certificate(SSL - offloader) then the data can be encrypted/decrypted. Would like to know if we can have the enhancement of using random key pair, generated form each certificate, so that each SSL handshake would make use of a random key-pair, and thereby give a different key value to each encryption -decryption, and therby be able to determine if the MITM with a same certificate has decrypted & encrypted data. With Regards, Shawn From rt at openssl.org Wed Mar 11 13:24:04 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 11 Mar 2015 14:24:04 +0100 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> Message-ID: We have no plans to do this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From steve at scheftech.com Wed Mar 11 13:31:22 2015 From: steve at scheftech.com (Steve Schefter) Date: Wed, 11 Mar 2015 09:31:22 -0400 Subject: [openssl-dev] Intent of the private_ wrappers In-Reply-To: <20150311023507.GA18472@openssl.org> References: <54F9AD18.1080106@scheftech.com> <20150311000326.GA29168@openssl.org> <54FF987C.6030004@scheftech.com> <20150311023507.GA18472@openssl.org> Message-ID: <550043AA.9090200@scheftech.com> On 3/10/2015 10:35 PM, Dr. Stephen Henson wrote: > I just built OpenSSL 1.0.1 from source using the normal build procedure on > Ubuntu Linux 14.04.2 and it *did* make the private_* symbols global in > libcrypto.so for example: > > 00000000000e2180 T private_AES_set_decrypt_key > 00000000000e1eb0 T private_AES_set_encrypt_key > > So I'm not sure why they're not global in your case. Interesting. Thanks for running that. It looks like a difference in our linkers. Something I just noticed: In openssl.ld for OPENSSL_1.0.0 it has an entry to make all symbols that are not explicitly listed local. global: BIO_F_ssl; BIO_new_buffer_ssl_connect; ... local: *; That isn't the case for OPENSSL_1.0.1 however; only the global list is in place and there's no catch-all local entry. Perhaps that allows for some freedom for the linker with the symbols that are not listed. Regards, Steve From tshort at akamai.com Wed Mar 11 13:32:46 2015 From: tshort at akamai.com (Short, Todd) Date: Wed, 11 Mar 2015 13:32:46 +0000 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> Message-ID: <32B7263E-D960-475F-A105-41772AAF66DA@akamai.com> This is more of a request to change the TLS protocol, than an enhancement to OpenSSL. DHE and ECDHE ciphers provide PFS to protect against compromised public key-pairs. However, if a MITM has the same certificate, signed by a trusted certificate authority, then most bets are off. Client-authentication can provide additional protection against MITM attacks, and allow servers to identify if a MITM is interfering with a valid user. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Mar 11, 2015, at 8:28 AM, Shawn Fernandes via RT > wrote: Hi, At the moment, we have SSL handshake making use of a single certificate, using a single key-pair present in the certificate. In the event the MITM has the same certificate(SSL - offloader) then the data can be encrypted/decrypted. Would like to know if we can have the enhancement of using random key pair, generated form each certificate, so that each SSL handshake would make use of a random key-pair, and thereby give a different key value to each encryption -decryption, and therby be able to determine if the MITM with a same certificate has decrypted & encrypted data. With Regards, Shawn _______________________________________________ openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=ds4i2k1LUtsCfZgPMHS2VdrUvh5w6_xSLfNdm1vpRPo&s=kEns4AYdLMO2_ASqWmVdf9jEzb8yMzvELxKIbzr6Mqc&e= -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Mar 11 13:35:58 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 11 Mar 2015 14:35:58 +0100 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: <32B7263E-D960-475F-A105-41772AAF66DA@akamai.com> References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> <32B7263E-D960-475F-A105-41772AAF66DA@akamai.com> Message-ID: This is more of a request to change the TLS protocol, than an enhancement to OpenSSL. DHE and ECDHE ciphers provide PFS to protect against compromised public key-pairs. However, if a MITM has the same certificate, signed by a trusted certificate authority, then most bets are off. Client-authentication can provide additional protection against MITM attacks, and allow servers to identify if a MITM is interfering with a valid user. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Mar 11, 2015, at 8:28 AM, Shawn Fernandes via RT > wrote: Hi, At the moment, we have SSL handshake making use of a single certificate, using a single key-pair present in the certificate. In the event the MITM has the same certificate(SSL - offloader) then the data can be encrypted/decrypted. Would like to know if we can have the enhancement of using random key pair, generated form each certificate, so that each SSL handshake would make use of a random key-pair, and thereby give a different key value to each encryption -decryption, and therby be able to determine if the MITM with a same certificate has decrypted & encrypted data. With Regards, Shawn _______________________________________________ openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=ds4i2k1LUtsCfZgPMHS2VdrUvh5w6_xSLfNdm1vpRPo&s=kEns4AYdLMO2_ASqWmVdf9jEzb8yMzvELxKIbzr6Mqc&e= From rt at openssl.org Wed Mar 11 14:48:51 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 11 Mar 2015 15:48:51 +0100 Subject: [openssl-dev] [openssl.org #1162] add a "discover-server-ciphers" to s_client References: Message-ID: There are other, more focused, tools on doing this such as nmap, ssllabs, the tool mentioned in this ticket, etc. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From foleyj at cisco.com Wed Mar 11 15:07:51 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 11 Mar 2015 11:07:51 -0400 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> <32B7263E-D960-475F-A105-41772AAF66DA@akamai.com> Message-ID: <55005A47.9000009@cisco.com> In addition to client authentication, another approach would be to use TLS-SRP to protect against MITM. Without the SRP credentials, the attacker would not be able to establish the two TLS connections required for MITM. On 03/11/2015 09:35 AM, Short, Todd via RT wrote: > This is more of a request to change the TLS protocol, than an enhancement to OpenSSL. > > DHE and ECDHE ciphers provide PFS to protect against compromised public key-pairs. > > However, if a MITM has the same certificate, signed by a trusted certificate authority, then most bets are off. > > Client-authentication can provide additional protection against MITM attacks, and allow servers to identify if a MITM is interfering with a valid user. > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet." > > On Mar 11, 2015, at 8:28 AM, Shawn Fernandes via RT > wrote: > > Hi, > At the moment, we have SSL handshake making use of a single certificate, using a single key-pair present in the certificate. > In the event the MITM has the same certificate(SSL - offloader) then the data can be encrypted/decrypted. > Would like to know if we can have the enhancement of using random key pair, generated form each certificate, so that each SSL handshake would make use of a random key-pair, and thereby give a different key value to each encryption -decryption, and therby be able to determine if the MITM with a same certificate has decrypted & encrypted data. > With Regards, > Shawn > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=AwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=ds4i2k1LUtsCfZgPMHS2VdrUvh5w6_xSLfNdm1vpRPo&s=kEns4AYdLMO2_ASqWmVdf9jEzb8yMzvELxKIbzr6Mqc&e= > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Mar 11 21:03:03 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 11 Mar 2015 22:03:03 +0100 Subject: [openssl-dev] [openssl.org #3732] Does OpenSSL construe expired certs as reason to downgrade? In-Reply-To: <4605a5d6e9804977af9d1ebfcd3c31dc@mercmbx60d.na.SAS.com> References: <4605a5d6e9804977af9d1ebfcd3c31dc@mercmbx60d.na.SAS.com> Message-ID: Short answer: no. Is the client a browser? Most probably some network hiccup made it retry. No defect here, closing the ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From Stefan.Neis at t-online.de Thu Mar 12 15:17:38 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Thu, 12 Mar 2015 16:17:38 +0100 Subject: [openssl-dev] Usage of assembler code on ARM architectures Message-ID: <14663360495501ae1268d279.71122473@email.t-online.de> Hi, While looking at the Configure script, I found that there is the armv4_asm variable, which seems to promise a speedup for ARM architectures (and the "4" in ARMv4 sounds like it should work "everywhere"?). However, further looking at that Configure file, I see it's only used for "linux-armv4" and "android-armv7", but not for e.g. iphoneos-cross. Does that imply you know/suspect it doesn't work anyway? Or does it imply there is no measurable speedup? Or does it just imply you never bothered to actually test it? And in the last case, would you expect it's going to work (or "almost") or would you rather expect it's going to be lots of trouble? Similar question for Android: You only use the assembler code for the "android-armv7" configuration. For maximum compatibility, I'm usually compiling with "-march=armv5te", which still sounds like using "armv4" assembler should be safe, but for some reason, you're restricting its use to the "android-armv7" configuration which explicitly sets "-march=armv7-a". Why? Regards, Stefan From foleyj at cisco.com Thu Mar 12 16:09:40 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 12 Mar 2015 12:09:40 -0400 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <14663360495501ae1268d279.71122473@email.t-online.de> References: <14663360495501ae1268d279.71122473@email.t-online.de> Message-ID: <5501BA44.1070803@cisco.com> I can't speak directly to your question on the iphone-cross target, but can warn you that your mileage will vary when using the ARM assembly modules. We observed that some algorithms actually run slower when using the ARM assembly modules. It's been a couple of years and I don't recall the details, but want to say some of the hash algorithms were actually faster when using no-asm. The results are likely to vary depending on the actual chipset used. You'll probably want to test the performance on the target hardware using the "openssl speed" command. You can do this on a jailbroken iOS device via SSH. On 03/12/2015 11:17 AM, Stefan.Neis at t-online.de wrote: > Hi, > > While looking at the Configure script, I found that there is the armv4_asm variable, which seems to promise a speedup for ARM architectures (and the "4" in ARMv4 sounds like it should work "everywhere"?). > However, further looking at that Configure file, I see it's only used for "linux-armv4" and "android-armv7", but not for e.g. iphoneos-cross. > Does that imply you know/suspect it doesn't work anyway? Or does it imply there is no measurable speedup? Or does it just imply you never bothered to actually test it? And in the last case, would you expect it's going to work (or "almost") or would you rather expect it's going to be lots of trouble? > Similar question for Android: You only use the assembler code for the "android-armv7" configuration. For maximum compatibility, I'm usually compiling with "-march=armv5te", which still sounds like using "armv4" assembler should be safe, but for some reason, you're restricting its use to the "android-armv7" configuration which explicitly sets "-march=armv7-a". Why? > > Regards, > Stefan > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From appro at openssl.org Thu Mar 12 16:45:34 2015 From: appro at openssl.org (Andy Polyakov) Date: Thu, 12 Mar 2015 17:45:34 +0100 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <14663360495501ae1268d279.71122473@email.t-online.de> References: <14663360495501ae1268d279.71122473@email.t-online.de> Message-ID: <5501C2AE.2070503@openssl.org> Hi, > While looking at the Configure script, I found that there is the > armv4_asm variable, which seems to promise a speedup for ARM > architectures (and the "4" in ARMv4 sounds like it should work > "everywhere"?). Yes. v4 denotes only *minimal* requirement. There is conditionally compiled code that targets v7 and even v8. > However, further looking at that Configure file, I > see it's only used for "linux-armv4" and "android-armv7", but not for > e.g. iphoneos-cross. Does that imply you know/suspect it doesn't work > anyway? Apple assembler uses a little bit different syntax and you can't assemble current modules as they are. There is perlasm/arm-xlate.pl that enables assembly for 64-bit iOS, and it's being modified to cover even 32-bit iOS. > Or does it imply there is no measurable speedup? You'll observe as much speedup on iOS as on Linux/Android. > Or does it > just imply you never bothered to actually test it? And in the last > case, would you expect it's going to work (or "almost") or would you > rather expect it's going to be lots of trouble? See above. > Similar question for > Android: You only use the assembler code for the "android-armv7" > configuration. For maximum compatibility, I'm usually compiling with > "-march=armv5te", which still sounds like using "armv4" assembler > should be safe, but for some reason, you're restricting its use to > the "android-armv7" configuration which explicitly sets > "-march=armv7-a". Why? Because that target was conceived to solve very specific problem, one can say too specific. In other words, yes, it's appropriate to extend support and introduce additional or unified target in linux-armv4 style. What would be more appropriate? I mean additional or unified? More specifically. Android has two distinct ARM targets, in sense that if you build JNI-enabled application, then you'd have to provide two ARM shared libraries, right? Question is is if both can be build with unified config (see linux-armv4 for example) or does it have to be two config lines? From appro at openssl.org Thu Mar 12 19:37:45 2015 From: appro at openssl.org (Andy Polyakov) Date: Thu, 12 Mar 2015 20:37:45 +0100 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <5501BA44.1070803@cisco.com> References: <14663360495501ae1268d279.71122473@email.t-online.de> <5501BA44.1070803@cisco.com> Message-ID: <5501EB09.7090609@openssl.org> > I can't speak directly to your question on the iphone-cross target, but > can warn you that your mileage will vary when using the ARM assembly > modules. We observed that some algorithms actually run slower when > using the ARM assembly modules. It's been a couple of years and I don't > recall the details, but want to say some of the hash algorithms were > actually faster when using no-asm. Well, I can imagine compiler succeeding to generate code better than sha1-armv4-large, but I can't imagine compiler beating sha256 or sha512. Was it really some of algorithm*s* or just one? Anyway, why sha1-amrv4-large? Two reasons: a) inner loops are not unrolled; b) over-reliance on merged rotate-n-arithmetic. "Over-reliance" means that it uses more such instructions than actually necessary, which can negatively affect performance. I realized this after having hard time getting sha256/512 to work well on Cortex-A53 (see sha512-armv8.pl, it's 64-bit module, but principle of merged rotate-n-arithmetic is same). It should also be noted that now there are additional code paths in sha1-armv4-large, namely NEON and ARMv8. > The results are likely to vary > depending on the actual chipset used. Right, ARM universe is very diverse. Assembly modules, i.e. all, not only ARM, are maintained to provide near-optimal performance across range of platforms, but sometimes optimizations conflict. In either case prerequisite is access to wide range of platforms and feedback. In order words, bring it up. > You'll probably want to test the > performance on the target hardware using the "openssl speed" command. > You can do this on a jailbroken iOS device via SSH. For the record. I do development on non-jailbroken unit, so that it's not hard requirement. From rt at openssl.org Thu Mar 12 21:16:38 2015 From: rt at openssl.org (Rath, Santosh via RT) Date: Thu, 12 Mar 2015 22:16:38 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: Message-ID: Hi I have downloaded the openssl 0.9.8zd source. And I tried below steps to get it install. 1. ./config fipscanisterbuild I did not get any configuration error. 2. make I got the below linker error. make[2]: Entering directory `/home/ratsa02/openssl-0.9.8zd/test' ../fips/fipscanister.o: In function `RSA_padding_check_PKCS1_OAEP': (.text+0x140ab): undefined reference to `CRYPTO_memcmp' collect2: ld returned 1 exit status make[2]: *** [link_app.gnu] Error 1 make[2]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' make[1]: *** [fips_shatest] Error 2 make[1]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' make: *** [build_tests] Error 1 Note: ( if I ran only configure without fipscanisterbuild option in config, the I don't have any issues.'make' is working fine. But I need the libraries should fips compliance). Please help me how I can get rid of this problem, is there something I am doing wrong? Thanks Santosh From rt at openssl.org Thu Mar 12 21:16:57 2015 From: rt at openssl.org (Peter Sylvester via RT) Date: Thu, 12 Mar 2015 22:16:57 +0100 Subject: [openssl-dev] [openssl.org #3746] -nameopt utf8 alone does not work , problem is tht crypto/asn1/a_strex.c returns -1 In-Reply-To: <55016CF2.80508@edelweb.fr> References: <55016CF2.80508@edelweb.fr> Message-ID: In crypto/asn1/a_strex.c routine do_name_ex does not handle case 0 for separators, this can occur if one specifies a -nameopt utf8. Suggested fix: Treat 0 in the same way as XN_FLAG_SEP_CPLUS_SP From rt at openssl.org Thu Mar 12 22:04:20 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 12 Mar 2015 23:04:20 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: Message-ID: On Thu Mar 12 22:16:37 2015, Santosh.Rath at ca.com wrote: > Hi > > I have downloaded the openssl 0.9.8zd source. > And I tried below steps to get it install. > > 1. ./config fipscanisterbuild > > I did not get any configuration error. > > 2. make > > I got the below linker error. > > > > make[2]: Entering directory `/home/ratsa02/openssl-0.9.8zd/test' > > ../fips/fipscanister.o: In function `RSA_padding_check_PKCS1_OAEP': > > (.text+0x140ab): undefined reference to `CRYPTO_memcmp' > > collect2: ld returned 1 exit status > > make[2]: *** [link_app.gnu] Error 1 > > make[2]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' > > make[1]: *** [fips_shatest] Error 2 > > make[1]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' > > make: *** [build_tests] Error 1 > > > > Note: ( if I ran only configure without fipscanisterbuild option in > config, the I don't have any issues.'make' is working fine. > > But I need the libraries should fips compliance). > You don't use that build procedure if you want OpenSSL to be FIPS compliant. You need to build the FIPS module from source first (obeying the security policy) and link the FIPS capable OpenSSL to that. See the user guide for more details. Note that OpenSSL 0.9.8 uses the much older 1.2 module. You should be using the 2.0 module instead and OpenSSL 1.0.1 or later. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From lists at rustichelli.net Fri Mar 13 11:35:47 2015 From: lists at rustichelli.net (lists) Date: Fri, 13 Mar 2015 12:35:47 +0100 Subject: [openssl-dev] [openssl.org #3744] Enhancement Request In-Reply-To: References: <88608035.3590440.1426071995103.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5502CB93.7040303@rustichelli.net> On 03/11/2015 01:28 PM, Shawn Fernandes via RT wrote: > Hi, > At the moment, we have SSL handshake making use of a single certificate, using a single key-pair present in the certificate. > In the event the MITM has the same certificate(SSL - offloader) then the data can be encrypted/decrypted. > Would like to know if we can have the enhancement of using random key pair, generated form each certificate, so that each SSL handshake would make use of a random key-pair, and thereby give a different key value to each encryption -decryption, and therby be able to determine if the MITM with a same certificate has decrypted & encrypted data. > With Regards, > Shawn I'm not an expert here, but I must share a couple of considerations that the master of cryptography may want to reject or amend: - if we're talking of non-mutual X509 authentication, that is just the server has a certificate, the solution would be ineffective against a determined attacker who possesses the server certificate because it would be possible, for the MITM, to fully impersonate the server. The MITM would talk with both parts using random keys - as a general security perspective, it is always bad when a private key is compromised. Mutual authentication would help, yes, but you're navigating dangerous waters anyway - the TLS-SRP, in my understanding, involves a pre-shared secret which is not, most often, a viable solution From rt at openssl.org Fri Mar 13 12:39:34 2015 From: rt at openssl.org (ijing06@gmail.com via RT) Date: Fri, 13 Mar 2015 13:39:34 +0100 Subject: [openssl-dev] [openssl.org #3747] Bug Report - Segmentation fault thrown from engine_unlocked_finish() In-Reply-To: References: Message-ID: Hi, I ran into an issue when testing openssl 1.0.1h with SQL ODBC Driver 11 on Linux Redhat 5. GDB shows the segmentation fault occurs at - Program terminated with signal 11, Segmentation fault. #0 0x00002ae14175e367 in engine_unlocked_finish (e=0x2ae14177f5ca, unlock_for_handlers=1) at eng_init.c:101 101 e->funct_ref--; (gdb) p e->funct_ref $1 = -2092374647 When testing with SQL ODBC Driver w/o openssl lib, it works fine. I also tried the same test with latest version of openssl (1.0.2 & 1.0.1l) and both gave the same result (seg fault). The source code - crypto/engine/eng_init.c shows it unconditionally reduces the reference count at line 101: e->funct_ref--; Is this intentional? Can you provide a feedback? Thanks. From peter.sylvester at edelweb.fr Fri Mar 13 13:54:58 2015 From: peter.sylvester at edelweb.fr (Peter Sylvester) Date: Fri, 13 Mar 2015 14:54:58 +0100 Subject: [openssl-dev] do_name_ex in crypto/asn1/a_strex.c does not treat case 0 in XN_FLAG_SEP_MASK Message-ID: <5502EC32.1000500@edelweb.fr> Hi, when a single -nameopt utf8 or others is used in openss x509 or others, the separator mask is 0. This preempts the command as soon as the Issuer is formatted. It seems that the case 0 should be treated lin the same ways as XN_FLAG_SEP_CPLUS_SPC Best Peter Sylvester From rt at openssl.org Fri Mar 13 14:27:09 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 13 Mar 2015 15:27:09 +0100 Subject: [openssl-dev] [openssl.org #3675] Fix key wrapping mode with padding to conform to RFC 5649 In-Reply-To: <54C646B0.5050001@redhat.com> References: <54C646B0.5050001@redhat.com> Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From doctor at doctor.nl2k.ab.ca Fri Mar 13 17:14:18 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 13 Mar 2015 11:14:18 -0600 Subject: [openssl-dev] SNAPSHOT updates Message-ID: <20150313171418.GA19850@doctor.nl2k.ab.ca> What is happening? In the Moutain Time Zone: It was at 22:22 MST then 23:22 MDT then 00:22 MDT !! -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Never compare your inside with somebody else's outside. -Hugh Macleod From rt at openssl.org Fri Mar 13 18:56:35 2015 From: rt at openssl.org (Peter Sylvester via RT) Date: Fri, 13 Mar 2015 19:56:35 +0100 Subject: [openssl-dev] [openssl.org #3748] do_name_ex in crypto/asn1/a_strex.c does not treat case 0 in XN_FLAG_SEP_MASK In-Reply-To: <5502EC32.1000500@edelweb.fr> References: <5502EC32.1000500@edelweb.fr> Message-ID: Hi, when a single -nameopt utf8 or others is used in openss x509 or others, the separator mask is 0. This preempts the command as soon as the Issuer is formatted. It seems that the case 0 should be treated lin the same ways as XN_FLAG_SEP_CPLUS_SPC Best Peter Sylvester From rt at openssl.org Fri Mar 13 20:00:30 2015 From: rt at openssl.org (Rath, Santosh via RT) Date: Fri, 13 Mar 2015 21:00:30 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> References: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> Message-ID: Thank you Stephen, Since the product is already build on openssl.0.9.8.r, and if we upgrade it to openssl0.1.1l then there could be lot of change in terms of API what our product use. And one more pain point is the product is using .so of libcrypto and libssl. But when I build the openssl with shared mode, then it is failing and reporting below errors. gcc: /home/ratsa02/openssl/openssl-fips-2.0.2/fips_binary/fipsfips_premain.c: No such file or directory gcc: /home/ratsa02/openssl/openssl-fips-2.0.2/fips_binary/fipsfipscanister.o: No such file or directory make[2]: *** [fips_premain_dso] Error 1 Pleas shed some advice here, because I struggling to figureout how to build those libraries. Since my release is due in 4 dyas, I have to submit this in 4 days. Thanks Santosh -----Original Message----- From: Stephen Henson via RT [mailto:rt at openssl.org] Sent: Friday, March 13, 2015 3:34 AM To: Rath, Santosh Cc: openssl-dev at openssl.org Subject: [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd On Thu Mar 12 22:16:37 2015, Santosh.Rath at ca.com wrote: > Hi > > I have downloaded the openssl 0.9.8zd source. > And I tried below steps to get it install. > > 1. ./config fipscanisterbuild > > I did not get any configuration error. > > 2. make > > I got the below linker error. > > > > make[2]: Entering directory `/home/ratsa02/openssl-0.9.8zd/test' > > ../fips/fipscanister.o: In function `RSA_padding_check_PKCS1_OAEP': > > (.text+0x140ab): undefined reference to `CRYPTO_memcmp' > > collect2: ld returned 1 exit status > > make[2]: *** [link_app.gnu] Error 1 > > make[2]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' > > make[1]: *** [fips_shatest] Error 2 > > make[1]: Leaving directory `/home/ratsa02/openssl-0.9.8zd/test' > > make: *** [build_tests] Error 1 > > > > Note: ( if I ran only configure without fipscanisterbuild option in > config, the I don't have any issues.'make' is working fine. > > But I need the libraries should fips compliance). > You don't use that build procedure if you want OpenSSL to be FIPS compliant. You need to build the FIPS module from source first (obeying the security policy) and link the FIPS capable OpenSSL to that. See the user guide for more details. Note that OpenSSL 0.9.8 uses the much older 1.2 module. You should be using the 2.0 module instead and OpenSSL 1.0.1 or later. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From erik at efca.com Fri Mar 13 20:57:33 2015 From: erik at efca.com (Erik Forsberg) Date: Fri, 13 Mar 2015 13:57:33 -0700 Subject: [openssl-dev] Suspicious crash in 1.0.2 Message-ID: Hi, Matt. I have not seen this committed to master or 1.0.2 yet ? Another person complained about it too, so its probably good idea to get it checked in. Patch works fine for all my use cases. >-- Original Message -- > > > > >On 28/02/15 06:53, Erik Forsberg wrote: >> Hi. >> I seem to have run into a really hard to pin down issue in >> OpenSSL 1.0.2. Normally, it simply causes an EFAULT during >> a write syscall, which makes me close the connection, but >> to investigate, I added a core dump at that time. This is what I see >> > > >Hi Erik > >Thanks for the really useful analysis of this issue. > >Please could you try out the attached patch and see if that solves >things for you? Let me know how you get on. > >Many thanks > >Matt > > >Attachment: multiblock.patch (0.5 KB) > >_______________________________________________ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From steve at scheftech.com Fri Mar 13 21:27:30 2015 From: steve at scheftech.com (Steve Schefter) Date: Fri, 13 Mar 2015 17:27:30 -0400 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> Message-ID: <55035642.6030909@scheftech.com> On 3/13/2015 4:00 PM, Rath, Santosh via RT wrote: > But when I build the openssl with shared mode, then it is failing and reporting below errors. > > gcc: /home/ratsa02/openssl/openssl-fips-2.0.2/fips_binary/fipsfips_premain.c: No such file or directory > gcc: /home/ratsa02/openssl/openssl-fips-2.0.2/fips_binary/fipsfipscanister.o: No such file or directory > make[2]: *** [fips_premain_dso] Error 1 Without looking at the old source, it looks to me like an environment variable or configure script option is missing a trailing / so that instead of getting ../fips/fips_premain.c you get ../fipsfips_premain.c Regards, Steve From matt at openssl.org Fri Mar 13 21:54:05 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 13 Mar 2015 21:54:05 +0000 Subject: [openssl-dev] Suspicious crash in 1.0.2 In-Reply-To: References: Message-ID: <55035C7D.3060701@openssl.org> On 13/03/15 20:57, Erik Forsberg wrote: > Hi, Matt. > I have not seen this committed to master or 1.0.2 yet ? > Another person complained about it too, so its probably > good idea to get it checked in. > > Patch works fine for all my use cases. Hi Erik, Don't worry - I've not forgotten about it!! Matt From dragon at dancingdragon.be Fri Mar 13 22:10:12 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Fri, 13 Mar 2015 15:10:12 -0700 Subject: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7 In-Reply-To: <54F8BC10.5000105@openssl.org> References: <54F8C870.1020005@dancingdragon.be> <54F8BC10.5000105@openssl.org> Message-ID: <55036044.9080701@dancingdragon.be> >> tmp32\aesni-sha256-x86_64.asm:113: error: symbol >> `__imp_RtlVirtualUnwind' undefined > > Can you confirm that attached patch addresses the problem? Yes, that fixes it. However, the build then fails during linking: lib /nologo /out:out32\libeay32.lib @C:\Users\dragon\AppData\Local\Temp\ nm60AD.tmp tmp32\x86_64cpuid.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' I was able to build 64-bit no-asm binaries, so I'm not sure what's causing the problem here. > On side note > the error is indication that your nasm is out-of-date and you are > missing out some optimizations. I'm using the nasm-2.07 windows installer from sourceforge: http://sourceforge.net/projects/nasm/ Is there something more recent? thanks, Joey From jeremy.farrell at oracle.com Fri Mar 13 22:34:44 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Fri, 13 Mar 2015 22:34:44 +0000 Subject: [openssl-dev] problems building openssl-1.0, 2 win64a binaries with vs2013 on windows 7 In-Reply-To: <55036044.9080701@dancingdragon.be> References: <54F8C870.1020005@dancingdragon.be> <54F8BC10.5000105@openssl.org> <55036044.9080701@dancingdragon.be> Message-ID: <55036604.1040402@oracle.com> On 13/03/2015 22:10, Joey Yandle wrote: > ... >> On side note >> the error is indication that your nasm is out-of-date and you are >> missing out some optimizations. > > I'm using the nasm-2.07 windows installer from sourceforge: > > http://sourceforge.net/projects/nasm/ > > Is there something more recent? The page that says "This is NASM - the famous Netwide Assembler. Back at SourceForge and in intensive development! Downloads on this page may be out of date. Get the current versions from http://www.nasm.us/" at the top? The current site also shows at the top of Google searches, and says "The latest stable version of NASM is 2.11.08 " -- J. J. Farrell w: +44 161 493 4838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Mar 13 22:51:30 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 13 Mar 2015 23:51:30 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> Message-ID: On Fri Mar 13 21:00:30 2015, Santosh.Rath at ca.com wrote: > Thank you Stephen, > > Since the product is already build on > openssl.0.9.8.r, and if we upgrade it to openssl0.1.1l then there > could be lot of change in terms of API what our product use. Well if you'd used any OpenSSL 0.9.8 using ./config fipscanisterbuild then the result would not be FIPS compliant as you weren't using the validated FIPS module. In outline you need to download the FIPS module appropriate for your version of OpenSSL. For 0.9.8 the latest is 1.2.4 you can get it from: https://www.openssl.org/source/old/fips/openssl-fips-1.2.4.tar.gz Extract the tarball. Build and install using: ./config fipscanisterbuild make make install Download OpenSSL 0.9.8 latest tarball currently: https://www.openssl.org/source/openssl-0.9.8ze.tar.gz and extract it. Then do: ./config fips make Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Mar 14 04:46:13 2015 From: rt at openssl.org (Rath, Santosh via RT) Date: Sat, 14 Mar 2015 05:46:13 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> Message-ID: Thanks Steve, For your valued information. After executing the steps suggested fips module is building fine. But when I build the openssl0.9.8.ze with fips flag. make is success. But make test is failing.. with Below error. test BN_sqr Square test failed: BN_sqr and BN_mul produce different results! make[1]: *** [test_bn] Error 1 make[1]: Leaving directory `/home/OPENSSL_LIBUPDATE/openssl-0.9.8ze/test' make: *** [tests] Error 2 Is there any suggestion on this? Thanks Santosh -----Original Message----- From: Stephen Henson via RT [mailto:rt at openssl.org] Sent: Saturday, March 14, 2015 4:22 AM To: Rath, Santosh Cc: openssl-dev at openssl.org Subject: [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd On Fri Mar 13 21:00:30 2015, Santosh.Rath at ca.com wrote: > Thank you Stephen, > > Since the product is already build on > openssl.0.9.8.r, and if we upgrade it to openssl0.1.1l then there > could be lot of change in terms of API what our product use. Well if you'd used any OpenSSL 0.9.8 using ./config fipscanisterbuild then the result would not be FIPS compliant as you weren't using the validated FIPS module. In outline you need to download the FIPS module appropriate for your version of OpenSSL. For 0.9.8 the latest is 1.2.4 you can get it from: https://www.openssl.org/source/old/fips/openssl-fips-1.2.4.tar.gz Extract the tarball. Build and install using: ./config fipscanisterbuild make make install Download OpenSSL 0.9.8 latest tarball currently: https://www.openssl.org/source/openssl-0.9.8ze.tar.gz and extract it. Then do: ./config fips make Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From kurt at roeckx.be Sat Mar 14 10:22:56 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 14 Mar 2015 11:22:56 +0100 Subject: [openssl-dev] [openssl-users] SNAPSHOT updates In-Reply-To: <20150313171418.GA19850@doctor.nl2k.ab.ca> References: <20150313171418.GA19850@doctor.nl2k.ab.ca> Message-ID: <20150314102256.GA8368@roeckx.be> On Fri, Mar 13, 2015 at 11:14:18AM -0600, The Doctor wrote: > What is happening? > > In the Moutain Time Zone: > > It was at 22:22 MST then 23:22 MDT then 00:22 MDT !! Do you mean when the snapshot is made? The machine runs in UTC, and the files seem to be made at 6:22 UTC. Kurt From rt at openssl.org Sat Mar 14 14:28:47 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 14 Mar 2015 15:28:47 +0100 Subject: [openssl-dev] [openssl.org #3745] OpenSSl Bug, affected release 0.9.8zd In-Reply-To: References: <6b00f0dae7374984af026bce6e6c830c@usilms212.ca.com> Message-ID: On Sat Mar 14 05:46:12 2015, Santosh.Rath at ca.com wrote: > Thanks Steve, > For your valued information. > After executing the steps > suggested fips module is building fine. > But when I build the > openssl0.9.8.ze with fips flag. > make is success. > But make test is > failing.. with Below error. > > test BN_sqr > Square test failed: > BN_sqr and BN_mul produce different results! > make[1]: *** > [test_bn] Error 1 > make[1]: Leaving directory > `/home/OPENSSL_LIBUPDATE/openssl-0.9.8ze/test' > make: *** [tests] > Error 2 > > Is there any suggestion on this? > It's a known issue which can be ignored for now. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From chenyt at cs.sjtu.edu.cn Sat Mar 14 21:46:52 2015 From: chenyt at cs.sjtu.edu.cn (=?utf-8?B?6ZmI6Zuo5Lqt?=) Date: Sat, 14 Mar 2015 14:46:52 -0700 Subject: [openssl-dev] Cannot find the function int (*get_issuer)(X509 **issuer, X509_STORE_CTX *ctx, X509 *x) Message-ID: <217AB163D95B422A8951E5B38354472D@sjtu.edu.cn> Hello, can anyone help me to find where the function get_issuer (...) is defined? Sorry for the na?ve question. The function is referred in crypto/x509/x509_vfy.c 290 /* If we are self signed, we break */ 291 if (ctx->check_issued(ctx,x,x)) break; 292 293 ok = ctx->get_issuer(&xtmp, ctx, x); 294 295 if (ok < 0) return ok; 296 if (ok == 0) break; 297 ... 306 } From kurt at roeckx.be Sat Mar 14 23:03:55 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 15 Mar 2015 00:03:55 +0100 Subject: [openssl-dev] Cannot find the function int (*get_issuer)(X509 **issuer, X509_STORE_CTX *ctx, X509 *x) In-Reply-To: <217AB163D95B422A8951E5B38354472D@sjtu.edu.cn> References: <217AB163D95B422A8951E5B38354472D@sjtu.edu.cn> Message-ID: <20150314230355.GA18131@roeckx.be> On Sat, Mar 14, 2015 at 02:46:52PM -0700, ??? wrote: > Hello, can anyone help me to find where the function get_issuer (...) is > defined? > Sorry for the na?ve question. > > The function is referred in crypto/x509/x509_vfy.c > 290 /* If we are self signed, we break */ > 291 if (ctx->check_issued(ctx,x,x)) break; > 292 > 293 ok = ctx->get_issuer(&xtmp, ctx, x); > 294 295 if (ok < 0) return ok; > 296 if (ok == 0) break; > 297 ... > 306 } check_issuer() is a function pointer in the X509_STORE and X509_STORE_CTX structure. X509_STORE_CTX_init() sets this to the X509_STORE version, or defaults to X509_STORE_CTX_get1_issuer(). X509_STORE_CTX_trusted_stack() will set it to get_issuer_sk. I don't see a way to set any other function. Kurt From doctor at doctor.nl2k.ab.ca Sat Mar 14 23:43:37 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 14 Mar 2015 17:43:37 -0600 Subject: [openssl-dev] [openssl-users] SNAPSHOT updates In-Reply-To: <20150314102256.GA8368@roeckx.be> References: <20150313171418.GA19850@doctor.nl2k.ab.ca> <20150314102256.GA8368@roeckx.be> Message-ID: <20150314234336.GA16107@doctor.nl2k.ab.ca> On Sat, Mar 14, 2015 at 11:22:56AM +0100, Kurt Roeckx wrote: > On Fri, Mar 13, 2015 at 11:14:18AM -0600, The Doctor wrote: > > What is happening? > > > > In the Moutain Time Zone: > > > > It was at 22:22 MST then 23:22 MDT then 00:22 MDT !! > > Do you mean when the snapshot is made? The machine runs in UTC, > and the files seem to be made at 6:22 UTC. > > How many times did they change the time release? > Kurt > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Know how to listen, and you will profit even from those who talk badly.-Plutarch From de.techno at gmail.com Sun Mar 15 04:46:25 2015 From: de.techno at gmail.com (dE) Date: Sun, 15 Mar 2015 10:16:25 +0530 Subject: [openssl-dev] Write PEM to char* Message-ID: <55050EA1.3000908@gmail.com> Hi! I was wondering if there are ways by which you can get a PEM encoded certificate stored into a char* from a X509 structure. I got a lot of ways to write it to FILE, but nothing appears to return a char*. Thanks for any pointers. From openssl-users at dukhovni.org Sun Mar 15 05:51:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 15 Mar 2015 05:51:36 +0000 Subject: [openssl-dev] Write PEM to char* In-Reply-To: <55050EA1.3000908@gmail.com> References: <55050EA1.3000908@gmail.com> Message-ID: <20150315055136.GJ27479@mournblade.imrryr.org> On Sun, Mar 15, 2015 at 10:16:25AM +0530, dE wrote: > I was wondering if there are ways by which you can get a PEM encoded > certificate stored into a char* from a X509 structure. > > I got a lot of ways to write it to FILE, but nothing appears to return a > char*. Use a memory BIO and PEM_write_bio_X509(). In memory the DER representation is generally more useful than PEM. The only plausible reason that comes to mind for using PEM in memory is for a UI that allows users to copy/paste PEM format certificates. Do you really need PEM? Or might i2d_X509() be a better interface for your real needs (serializing X509 data). -- Viktor. From Yair.Elharrar at audiocodes.com Sun Mar 15 07:14:49 2015 From: Yair.Elharrar at audiocodes.com (Yair Elharrar) Date: Sun, 15 Mar 2015 07:14:49 +0000 Subject: [openssl-dev] Write PEM to char* In-Reply-To: <55050EA1.3000908@gmail.com> References: <55050EA1.3000908@gmail.com> Message-ID: Here's one way to do it: BIO *mbio = BIO_new(BIO_s_mem()); PEM_write_bio_X509(mbio, cert); len = BIO_read(mbio, temp_text, MAX_SIZE); if (len>0) temp_text[len]=0; BIO_free(mbio); -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of dE Sent: Sunday, March 15, 2015 6:46 To: openssl-dev at openssl.org Subject: [openssl-dev] Write PEM to char* Hi! I was wondering if there are ways by which you can get a PEM encoded certificate stored into a char* from a X509 structure. I got a lot of ways to write it to FILE, but nothing appears to return a char*. Thanks for any pointers. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ________________________________ This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message From rt at openssl.org Sun Mar 15 10:32:46 2015 From: rt at openssl.org (Richard Godbee via RT) Date: Sun, 15 Mar 2015 11:32:46 +0100 Subject: [openssl-dev] [openssl.org #3749] [PATCH] Fix major bugs in CRYPTO_128_unwrap() In-Reply-To: <20150314022910.1ab02b4a3dc1aaf61d1786161e74fc18.2ee3597842.wbe@email09.secureserver.net> References: <20150314022910.1ab02b4a3dc1aaf61d1786161e74fc18.2ee3597842.wbe@email09.secureserver.net> Message-ID: "crypto/modes/wrap128.c was heavily refactored to support AES Key Wrap with Padding, and four bugs were introduced into CRYPTO_128_unwrap() at that time: [...]" I created a pull request on GitHub for this back in September 2014, but it seems to have gone unnoticed. I've rebased the commits to master and am creating this RT ticket in hopes of getting the pull request seen before the current, buggy code finds its way into the 1.1.0 release: https://github.com/openssl/openssl/pull/179 There is also a GitHub Gist containing the source to a small program that demonstrates the bug: https://gist.github.com/rwg/d9b39167f49adf5b6e12 From rt at openssl.org Sun Mar 15 19:49:43 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sun, 15 Mar 2015 20:49:43 +0100 Subject: [openssl-dev] [openssl.org #3706] [patch] Regression in ASN1_UTCTIME_cmp_time_t in v1.0.2 In-Reply-To: References: Message-ID: Fixed, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Mar 16 09:45:06 2015 From: rt at openssl.org (Kai Engert via RT) Date: Mon, 16 Mar 2015 10:45:06 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <1426499080.2298.11.camel@kuix.de> References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> Message-ID: Thank you very much for your work on this issue! In my testing so far, it works as requested. I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 stable branch, and the test suite succeeeds. Will you consider to add this enhancement in a feature release on the 1.0.2 branch? Regards Kai From rt at openssl.org Mon Mar 16 11:47:34 2015 From: rt at openssl.org (=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= via RT) Date: Mon, 16 Mar 2015 12:47:34 +0100 Subject: [openssl-dev] [openssl.org #3750] Compile 1.0.2 with RC4: rc4_md5_enc not found In-Reply-To: <5505EEE7.3030308@aegee.org> References: <5505EEE7.3030308@aegee.org> Message-ID: Hello, I run ./Configure threads zlib-dynamic linux-x86_64:"gcc -O3 -flto -Wl,-S" && make and then get: make[1]: Entering directory '/home/dilyan/src/openssl-1.0.2/apps' rm -f openssl shlib_target=; if [ -n "" ]; then \ shlib_target=""; \ elif [ -n "" ]; then \ FIPSLD_CC="gcc -O3 -flto -Wl,-S"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC FIPSLD_CC; \ fi; \ LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \ make -f ../Makefile.shared -e \ APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \ LIBDEPS=" $LIBRARIES " \ link_app.${shlib_target} make[2]: Entering directory '/home/dilyan/src/openssl-1.0.2/apps' ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto }"; LDCMD="${LDCMD:-gcc -O3 -flto -Wl,-S}"; LDFLAGS="${LDFLAGS:--DZLIB_SHARED -DZLIB -DOPENSSL_THREADS }"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} ) /tmp/cc3iFMRK.ltrans11.ltrans.o:cc3iFMRK.ltrans11.o:function rc4_hmac_md5_cipher: error: undefined reference to 'rc4_md5_enc' /tmp/cc3iFMRK.ltrans11.ltrans.o:cc3iFMRK.ltrans11.o:function rc4_hmac_md5_cipher: error: undefined reference to 'rc4_md5_enc' collect2: error: ld returned 1 exit status ../Makefile.shared:164: recipe for target 'link_app.' failed make[2]: *** [link_app.] Error 1 make[2]: Leaving directory '/home/dilyan/src/openssl-1.0.2/apps' Makefile:153: recipe for target 'openssl' failed make[1]: *** [openssl] Error 2 make[1]: Leaving directory '/home/dilyan/src/openssl-1.0.2/apps' Makefile:285: recipe for target 'build_apps' failed make: *** [build_apps] Error 1 nm libcrypto.a |grep rc4_md5_enc shows "undefined symbol rc4_md5_enc" and crypto/evp/Makefile does not include e_rc4_hmac_md5.c in LIBSRC . I understand RC4 and M$ are outdated, but this is not a reason for the compilation to fail. Any ideas? Kind regards Dilyan Palauzov From rt at openssl.org Mon Mar 16 14:21:25 2015 From: rt at openssl.org (Bernd Edlinger via RT) Date: Mon, 16 Mar 2015 15:21:25 +0100 Subject: [openssl-dev] [openssl.org #3751] Undefined behavior invoked in aes_core.c In-Reply-To: <859278b9-48d1-4389-b280-9faa387227e3@bhv.softing.com> References: <859278b9-48d1-4389-b280-9faa387227e3@bhv.softing.com> Message-ID: Hi, This gets reported by GCC-5.0.0 with -fsanitize=undefined in OpenSSL 1.0.0m 5 Jun 2014: aes_core.c:1144:30: runtime error: left shift of 136 by 24 places cannot be represented in type 'int' aes_core.c:1151:30: runtime error: left shift of 158 by 24 places cannot be represented in type 'int' aes_core.c:1137:30: runtime error: left shift of 239 by 24 places cannot be represented in type 'int' aes_core.c:1130:30: runtime error: left shift of 139 by 24 places cannot be represented in type 'int' when I look at these lines, I see the following (repeated 4 times): s0 = (Td4[(t0 >> 24) ] << 24) ^ (Td4[(t3 >> 16) & 0xff] << 16) ^ (Td4[(t2 >> 8) & 0xff] << 8) ^ (Td4[(t1 ) & 0xff]) ^ rk[0]; and static const u8 Td4[256] = { 0x52U, 0x09U, 0x6aU, 0xd5U, 0x30U, 0x36U, 0xa5U, 0x38U, ... I assume u8 means unsigned char. GCC converts the u8 to int before the shift left 24. However, this is undefined behavior in C99/C11, and defined behavior in C++11. Quoting C99 6.5.7/4: "The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 ? 2 ^ E2, reduced modulo one more than the maximum value representable in the result type. If E1 has a signed type and nonnegative value, and E1 ? 2 ^ E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined." See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65435 With kind regards, Bernd Edlinger From foleyj at cisco.com Mon Mar 16 15:47:40 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 16 Mar 2015 11:47:40 -0400 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <5501EB09.7090609@openssl.org> References: <14663360495501ae1268d279.71122473@email.t-online.de> <5501BA44.1070803@cisco.com> <5501EB09.7090609@openssl.org> Message-ID: <5506FB1C.2000502@cisco.com> My mistake, it looks like my memory was wrong on two accounts. First, it was AES, not SHA, where I observed the no-asm was faster. Second, it was on the PowerPC cross-compiled target, not ARM. The results from "openssl speed aes-128-cbc" are: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes w/o no-asm 31010.47k 32988.82k 33549.41k 33693.05k 33825.67k no-asm 42431.46k 46485.14k 47479.20k 47874.86k 47829.36k This is using a Freescale 8548. On 03/12/2015 03:37 PM, Andy Polyakov wrote: >> I can't speak directly to your question on the iphone-cross target, but >> can warn you that your mileage will vary when using the ARM assembly >> modules. We observed that some algorithms actually run slower when >> using the ARM assembly modules. It's been a couple of years and I don't >> recall the details, but want to say some of the hash algorithms were >> actually faster when using no-asm. > Well, I can imagine compiler succeeding to generate code better than > sha1-armv4-large, but I can't imagine compiler beating sha256 or sha512. > Was it really some of algorithm*s* or just one? Anyway, why > sha1-amrv4-large? Two reasons: a) inner loops are not unrolled; b) > over-reliance on merged rotate-n-arithmetic. "Over-reliance" means that > it uses more such instructions than actually necessary, which can > negatively affect performance. I realized this after having hard time > getting sha256/512 to work well on Cortex-A53 (see sha512-armv8.pl, it's > 64-bit module, but principle of merged rotate-n-arithmetic is same). It > should also be noted that now there are additional code paths in > sha1-armv4-large, namely NEON and ARMv8. > >> The results are likely to vary >> depending on the actual chipset used. > Right, ARM universe is very diverse. Assembly modules, i.e. all, not > only ARM, are maintained to provide near-optimal performance across > range of platforms, but sometimes optimizations conflict. In either case > prerequisite is access to wide range of platforms and feedback. In order > words, bring it up. > >> You'll probably want to test the >> performance on the target hardware using the "openssl speed" command. >> You can do this on a jailbroken iOS device via SSH. > For the record. I do development on non-jailbroken unit, so that it's > not hard requirement. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From dwmw2 at infradead.org Mon Mar 16 15:52:00 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 16 Mar 2015 15:52:00 +0000 Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello In-Reply-To: References: <1424220216.24248.47.camel@infradead.org> Message-ID: <1426521120.4857.167.camel@infradead.org> On Mon, 2015-03-09 at 12:11 +0100, Matt Caswell via RT wrote: > Fixed in this commit: > > https://github.com/openssl/openssl/commit/f7683aaf36341dc65672ac2ccdbfd4a232e3626d Thanks. I can confirm that OpenConnect is now working with OpenSSL HEAD again, both with DTLS1_BAD_VER talking to 'legacy' Cisco servers, and with DTLS 1.2/AES-GCM to ocserv. In my Copious Spare Time? I will look at ensuring this has better test coverage. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From rt at openssl.org Mon Mar 16 16:11:55 2015 From: rt at openssl.org (David Woodhouse via RT) Date: Mon, 16 Mar 2015 17:11:55 +0100 Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello In-Reply-To: <1426521120.4857.167.camel@infradead.org> References: <1424220216.24248.47.camel@infradead.org> <1426521120.4857.167.camel@infradead.org> Message-ID: On Mon, 2015-03-09 at 12:11 +0100, Matt Caswell via RT wrote: > Fixed in this commit: > > https://github.com/openssl/openssl/commit/f7683aaf36341dc65672ac2ccdbfd4a232e3626d Thanks. I can confirm that OpenConnect is now working with OpenSSL HEAD again, both with DTLS1_BAD_VER talking to 'legacy' Cisco servers, and with DTLS 1.2/AES-GCM to ocserv. In my Copious Spare Time? I will look at ensuring this has better test coverage. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From rt at openssl.org Mon Mar 16 18:21:08 2015 From: rt at openssl.org (John Foley via RT) Date: Mon, 16 Mar 2015 19:21:08 +0100 Subject: [openssl-dev] [openssl.org #3752] Patch to fix thread ID support from FIPS module In-Reply-To: <5506F522.4010007@cisco.com> References: <5506F522.4010007@cisco.com> Message-ID: The following patch allows CRYPTO_thread_id() to be invoked from the FIPS module. Without this patch the thread ID can not be retrieved properly, leading to thread synchronization issues in the FIPS module. Currently there's no way to exploit this problem since CRYPTO_thread_id() isn't used within the FIPS module. However, including this patch may prevent some headaches if the FIPS module should use CRYPTO_thread_id() in the future. diff --git a/crypto/o_init.c b/crypto/o_init.c index b7b969b..8ce85b9 100644 --- a/crypto/o_init.c +++ b/crypto/o_init.c @@ -73,6 +73,7 @@ void OPENSSL_init(void) done = 1; #ifdef OPENSSL_FIPS FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock); + FIPS_crypto_set_id_callback(CRYPTO_thread_id); FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata); FIPS_set_malloc_callbacks(CRYPTO_malloc, CRYPTO_free); RAND_init_fips(); From matt at openssl.org Mon Mar 16 18:22:07 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Mar 2015 18:22:07 +0000 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> Message-ID: <55071F4F.6020506@openssl.org> On 16/03/15 09:45, Kai Engert via RT wrote: > Thank you very much for your work on this issue! > In my testing so far, it works as requested. > > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 > stable branch, and the test suite succeeeds. > > Will you consider to add this enhancement in a feature release on the > 1.0.2 branch? Hi Kai It is our policy to only add defect fixes to released branches. Only in exceptional circumstances will we add a new feature (usually because of some security issue). Therefore I think it is highly unlikely that this will be included in any future 1.0.2 release, and there are no current plans to do so. Matt From rt at openssl.org Mon Mar 16 18:35:25 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 16 Mar 2015 19:35:25 +0100 Subject: [openssl-dev] [openssl.org #3751] Undefined behavior invoked in aes_core.c In-Reply-To: <859278b9-48d1-4389-b280-9faa387227e3@bhv.softing.com> References: <859278b9-48d1-4389-b280-9faa387227e3@bhv.softing.com> Message-ID: On Mon Mar 16 15:21:24 2015, Bernd.Edlinger at Softing.com wrote: > Hi, > > This gets reported by GCC-5.0.0 with -fsanitize=undefined in OpenSSL > 1.0.0m 5 Jun 2014: > > aes_core.c:1144:30: runtime error: left shift of 136 by 24 places > cannot be represented in type 'int' > aes_core.c:1151:30: runtime error: left shift of 158 by 24 places > cannot be represented in type 'int' > aes_core.c:1137:30: runtime error: left shift of 239 by 24 places > cannot be represented in type 'int' > aes_core.c:1130:30: runtime error: left shift of 139 by 24 places > cannot be represented in type 'int' > > > when I look at these lines, I see the following (repeated 4 times): > > s0 = > (Td4[(t0 >> 24) ] << 24) ^ > (Td4[(t3 >> 16) & 0xff] << 16) ^ > (Td4[(t2 >> 8) & 0xff] << 8) ^ > (Td4[(t1 ) & 0xff]) ^ > rk[0]; > > and > static const u8 Td4[256] = { > 0x52U, 0x09U, 0x6aU, 0xd5U, 0x30U, 0x36U, 0xa5U, 0x38U, ... > > I assume u8 means unsigned char. > > GCC converts the u8 to int before the shift left 24. > > However, this is undefined behavior in C99/C11, and defined behavior > in C++11. Hi Bernd This issue has already been fixed in git for master, 1.0.2 and 1.0.1. See, for example, commit 8b37e5c14f in the OpenSSL_1_0_2-stable branch. This will not be fixed in 1.0.0 and 0.9.8 as it is not a security issue and these branches are only receiving security fixes due to their EOL status. Thanks for your report, Matt From matt at openssl.org Mon Mar 16 19:05:31 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 16 Mar 2015 19:05:31 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases Message-ID: <5507297B.8040505@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. These releases will be made available on 19th March. They will fix a number of security defects. The highest severity defect fixed by these releases is classified as "high" severity. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVByl7AAoJENnE0m0OYESRm5MIAJV4ElRSS575QkYwPcOw7VTK 8Ulc6TMHsy2s5UvTXl/THqEoy5n92v99Cm69Y69TSWOgK9FK8aV0BuKkVZVYp3Ko MYV4VMr8a7YiNh/16HctRLfEPH8bg5AkY76Y4RM5i1AXafSR6wMuwlJl21TmqMI+ J+HA39UvlWZ9zI7Lzz0v1BMoGAXg0cr8//QRcrFFgZZuUVtscwRRA9nRS65+AJhX ogd3ncUPUI3YEzxqv0kDfUre/2XeUNOM+N+u9pyfjoXHaMVsSX3A1HtpmEAMyzhE DqF+kmhTEyK0HYCVLnl6PLnBdHpPKY3qNFYd8trFyC2hpB9U6Qsut4KeKNtAi2g= =Uwpw -----END PGP SIGNATURE----- From appro at openssl.org Tue Mar 17 12:37:17 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 17 Mar 2015 13:37:17 +0100 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <5506FB1C.2000502@cisco.com> References: <14663360495501ae1268d279.71122473@email.t-online.de> <5501BA44.1070803@cisco.com> <5501EB09.7090609@openssl.org> <5506FB1C.2000502@cisco.com> Message-ID: <55081FFD.6000203@openssl.org> > My mistake, it looks like my memory was wrong on two accounts. First, > it was AES, not SHA, where I observed the no-asm was faster. Second, it > was on the PowerPC cross-compiled target, not ARM. The results from > "openssl speed aes-128-cbc" are: > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > w/o no-asm 31010.47k 32988.82k 33549.41k 33693.05k > 33825.67k > no-asm 42431.46k 46485.14k 47479.20k 47874.86k > 47829.36k > > This is using a Freescale 8548. This is no mystery at all, and kind of intentional. If you examine commentary in aes-ppc.pl you'll notice that that it relies on "compact" subroutines, those that are using 256-byte S-boxes, which require more computations. It mentions that "compact" encrypt is ~2 times slower than "traditional" encrypt. On the other side of scales is insecurity of "traditional" subroutine which is susceptible to cache-timing attacks. Well, it's not like "compact" is not susceptible, but it's *much* more resistant. Indeed, vulnerability is quantified by probability of a cache line not being accessed as result of block operation, and in "compact" case is as low as (1-32/256)^160=5e-10 vs. (1-4/256)^160=0.08 for processor in question. Note that C version is even worse than "non-compact" assembly subroutine. You might argue that there is no room for adversary in *your* application and performance should be favoured. By "no room" I mean that it's probably locked down embedded system and adversary having ability to execute own code is considered big enough problem. Yes, but you have to *argue* in favour. Maybe it should be a compile option... From Stefan.Neis at t-online.de Tue Mar 17 13:28:44 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Tue, 17 Mar 2015 14:28:44 +0100 Subject: [openssl-dev] =?utf-8?q?Usage_of_assembler_code_on_ARM_architectu?= =?utf-8?q?res?= In-Reply-To: <5501C2AE.2070503@openssl.org> References: <5501C2AE.2070503@openssl.org> Message-ID: <167560946355082c0c95c5d4.82213476@email.t-online.de> Hi, Thanks for the answers to my questions - here come some more. > Apple assembler uses a little bit different syntax and you can't > assemble current modules as they are. ... as I found out myself just after asking the original question, but of course, the following is good to know: > There is perlasm/arm-xlate.pl that enables assembly for 64-bit > iOS, and it's being modified to cover even 32-bit iOS. Is that something that can/will be backported to 1.0.2- (or even 1.0.1-) branch, once it's working? > More specifically. Android has two distinct ARM targets, in sense that if > you build JNI-enabled application, then you'd have to provide two ARM > shared libraries, right? Here, you lost me. So far, I'm building only one shared library for ARM, using the no_asm variant of OpenSSL. And so far, there weren't complaints about unsupported devices, so what do you mean by "two distinct ARM targets"? Regards, Stefan From rt at openssl.org Tue Mar 17 14:04:45 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 17 Mar 2015 15:04:45 +0100 Subject: [openssl-dev] [openssl.org #3750] Compile 1.0.2 with RC4: rc4_md5_enc not found In-Reply-To: <550832AC.3050007@openssl.org> References: <5505EEE7.3030308@aegee.org> <550832AC.3050007@openssl.org> Message-ID: Hi, > I run > > ./Configure threads zlib-dynamic linux-x86_64:"gcc -O3 -flto -Wl,-S" This thing, config-line:command-line, doesn't work as you expect. In the nutshell you're expected to provide *whole* config line with all those fields delimited by colons (see linux-x86_64 line in Configure). And the line has to be coherent, i.e. fields have to match each other. But as it is suggested in above example, it wipes assembly modules, but doesn't define OPENSSL_NO_ASM, which results in e_rc4_hmac_md5.c compiled as if rc4-md5-x86_64 is compiled too, it it isn't. I mean latter isn't compiled, which results in link error. Besides that you're missing a lot of performance, you also venture into unsupported area, as we can't take responsibility for made-up config lines. So I'd recommend to stick to just linux-x86_64, as I can't see that suggested command line options add some excessive value. From appro at openssl.org Tue Mar 17 14:30:23 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 17 Mar 2015 15:30:23 +0100 Subject: [openssl-dev] Usage of assembler code on ARM architectures In-Reply-To: <167560946355082c0c95c5d4.82213476@email.t-online.de> References: <5501C2AE.2070503@openssl.org> <167560946355082c0c95c5d4.82213476@email.t-online.de> Message-ID: <55083A7F.1050205@openssl.org> Hi, >> There is perlasm/arm-xlate.pl that enables assembly for 64-bit >> iOS, and it's being modified to cover even 32-bit iOS. > > Is that something that can/will be backported to 1.0.2- (or even 1.0.1-) > branch, once it's working? Well, it would have to be *your* responsibility, because 1.0.2, as well as 1.0.1, are closed for new features. >> More specifically. Android has two distinct ARM targets, in sense that if >> you build JNI-enabled application, then you'd have to provide two ARM >> shared libraries, right? > > Here, you lost me. So far, I'm building only one shared library for ARM, > using the no_asm variant of OpenSSL. And so far, there weren't complaints > about unsupported devices, so what do you mean by "two distinct ARM > targets"? On Android you can build kind of "fat" apps, when same .apk contains JNI shared object modules targeting different hardware architectures, right? For example ARM, x86, MIPS. As far as I understand contemporary Android ARM platforms come in two "flavours": armhf/armv7-a and traditional armeabi. This means that along with say x86 module there is "room" for *pair* of ARM shared libraries targeting these two ABIs. Google's idea is naturally to provide better performance on former. For OpenSSL performance choice of ABI doesn't really matter (because we don't do much floating point), but it can be part of application that otherwise uses a lot of floating point and therefore is sensitive to ABI choice. This is how pair of shared libraries comes into picture. Does it mean that we better have two config lines reflecting this? That's where we need your support. To help us formulate what is sensible, what are expectations and that it would actually benefit applications. From tgyonjyan at bloomberg.net Tue Mar 17 15:44:32 2015 From: tgyonjyan at bloomberg.net (Tigran Gyonjyan (BLOOMBERG/ 731 LEX)) Date: Tue, 17 Mar 2015 15:44:32 -0000 Subject: [openssl-dev] =?utf-8?q?Using_openssl_with_a_remote_private_key?= Message-ID: <55084BE001E705C20039061F_0_80099@p057> Hi there! Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed. I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version. In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine. Let me know if there is a better solution for this problem. Cheers, Tigran -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedor at indutny.com Tue Mar 17 17:37:04 2015 From: fedor at indutny.com (Fedor Indutny) Date: Tue, 17 Mar 2015 10:37:04 -0700 Subject: [openssl-dev] Using openssl with a remote private key In-Reply-To: <55084BE001E705C20039061F_0_80099@p057> References: <55084BE001E705C20039061F_0_80099@p057> Message-ID: Hello Tigran! I was using: https://github.com/indutny/bud/compare/master...feature/async-key-ex For quite a long time now. It seems that you have your own solution, but anyway posted it here in case you are interested. Cheers! On Tue, Mar 17, 2015 at 8:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) < tgyonjyan at bloomberg.net> wrote: > Hi there! > > Recently I had to work on an openssl project where due to security > requirements I had to place the private key for the server certificate on > another machine. In order to be able to make openssl ignore the fake > private key in the certificate I had to "hack" some data structures to > delegate the handshake decrypt to the remote machine so that the handshake > could succeed. > > I was wondering if this capability to delegate the decrypt function can be > useful enough to incorporate into the official version. > In cases when the client and the server are located on user's machine it > is a risk to keep the private key on that machine. > > Let me know if there is a better solution for this problem. > > Cheers, > Tigran > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From etksubs at gmail.com Tue Mar 17 17:53:36 2015 From: etksubs at gmail.com (Erik Tkal) Date: Tue, 17 Mar 2015 13:53:36 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <55084BE001E705C20039061F_0_80099@p057> References: <55084BE001E705C20039061F_0_80099@p057> Message-ID: <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. I traced this to the following change: Set s->hit when resuming from external pre-shared secret. https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s->hit, which then ?requires* that a finished message is expected next, triggering the alert otherwise. Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. Thanks, Erik .................................... Erik Tkal etkal at cisco.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From karthikeyan.bhargavan at inria.fr Tue Mar 17 18:59:32 2015 From: karthikeyan.bhargavan at inria.fr (Karthikeyan Bhargavan) Date: Tue, 17 Mar 2015 19:59:32 +0100 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). Let?s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack) On 17 Mar 2015, at 18:53, Erik Tkal wrote: > In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. > > RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. > > I traced this to the following change: > > Set s->hit when resuming from external pre-shared secret. > > https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 > > When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s->hit, which then ?requires* that a finished message is expected next, triggering the alert otherwise. > > Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: > > Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset > > https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 > > In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. > > Thanks, > Erik > > .................................... > Erik Tkal > etkal at cisco.com > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dwmw2 at infradead.org Tue Mar 17 20:02:19 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Mar 2015 20:02:19 +0000 Subject: [openssl-dev] Using openssl with a remote private key In-Reply-To: <55084BE001E705C20039061F_0_80099@p057> References: <55084BE001E705C20039061F_0_80099@p057> Message-ID: <1426622539.24662.36.camel@infradead.org> On Tue, 2015-03-17 at 15:44 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote: > > > Recently I had to work on an openssl project where due to security > requirements I had to place the private key for the server certificate > on another machine. In order to be able to make openssl ignore the > fake private key in the certificate I had to "hack" some data > structures to delegate the handshake decrypt to the remote machine so > that the handshake could succeed. > > > I was wondering if this capability to delegate the decrypt function > can be useful enough to incorporate into the official version. > In cases when the client and the server are located on user's machine > it is a risk to keep the private key on that machine. > > > Let me know if there is a better solution for this problem. Yes, PKCS#11. Which is *all* about delegating the decrypt function. If you install the OpenSC ENGINE_pkcs11 (which *really* ought to be part of OpenSSL, either in ENGINE form or preferably just native PKCS#11 support like libp11), you can configure it to use a key in PKCS#11. And it's relatively simple to have a PKCS#11 provider which does the RPC to the remote machine or wherever the key is actually stored. I have patches outstanding to ENGINE_pkcs11 which make it Just Work? with PKCS#11 tokens which are configured in the system's p11-kit configuration, and accept standard PKCS#11 URIs for them instead of the bizarre format it currently requires. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From dwmw2 at infradead.org Tue Mar 17 20:08:29 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Mar 2015 20:08:29 +0000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: <1426622909.24662.38.camel@infradead.org> On Tue, 2015-03-17 at 13:53 -0400, Erik Tkal wrote: > In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour > of a non-resumed EAP-FAST session. Erik, please could you explain what relevance this message has to the message "Using openssl with a remote private key" from Tigran Gyonjyan, to which it is a reply? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From etksubs at gmail.com Tue Mar 17 20:16:10 2015 From: etksubs at gmail.com (Erik Tkal) Date: Tue, 17 Mar 2015 16:16:10 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> I don?t disagree, but I?m looking for independent confirmation that the changes are not correct. They do not appear to specifically have been made for any vulnerabilities. In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client. With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case. The resumption requires determination of the next message. In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension. Erik > On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan wrote: > > I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com ), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). > > Let?s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack) > > > On 17 Mar 2015, at 18:53, Erik Tkal > wrote: > >> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. >> >> RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. >> >> I traced this to the following change: >> >> Set s->hit when resuming from external pre-shared secret. >> >> https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 >> >> When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s->hit, which then ?requires* that a finished message is expected next, triggering the alert otherwise. >> >> Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: >> >> Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset >> >> https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 >> >> In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. >> >> Thanks, >> Erik >> >> .................................... >> Erik Tkal >> etkal at cisco.com >> >> _______________________________________________ >> 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 tgyonjyan at bloomberg.net Tue Mar 17 22:22:56 2015 From: tgyonjyan at bloomberg.net (Tigran Gyonjyan (BLOOMBERG/ 731 LEX)) Date: Tue, 17 Mar 2015 22:22:56 -0000 Subject: [openssl-dev] =?utf-8?q?Using_openssl_with_a_remote_private_key?= Message-ID: <5508A9400030033200390AD0_0_136377@p057> Thank you for your responses, PKCS#11 could be the right way to go. I am hoping there is flexibility as per what functionality I want to delegate (just need the decrypt piece). If I had to implement a fully fledged PKCS#11 module that would be an overkill. I hope that's not the case? From: dwmw2 at infradead.org At: Mar 17 2015 16:02:44 To: Tigran Gyonjyan (BLOOMBERG/ 731 LEX), openssl-dev at openssl.org Subject: Re: [openssl-dev] Using openssl with a remote private key On Tue, 2015-03-17 at 15:44 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote: > > > Recently I had to work on an openssl project where due to security > requirements I had to place the private key for the server certificate > on another machine. In order to be able to make openssl ignore the > fake private key in the certificate I had to "hack" some data > structures to delegate the handshake decrypt to the remote machine so > that the handshake could succeed. > > > I was wondering if this capability to delegate the decrypt function > can be useful enough to incorporate into the official version. > In cases when the client and the server are located on user's machine > it is a risk to keep the private key on that machine. > > > Let me know if there is a better solution for this problem. Yes, PKCS#11. Which is *all* about delegating the decrypt function. If you install the OpenSC ENGINE_pkcs11 (which *really* ought to be part of OpenSSL, either in ENGINE form or preferably just native PKCS#11 support like libp11), you can configure it to use a key in PKCS#11. And it's relatively simple to have a PKCS#11 provider which does the RPC to the remote machine or wherever the key is actually stored. I have patches outstanding to ENGINE_pkcs11 which make it Just Work? with PKCS#11 tokens which are configured in the system's p11-kit configuration, and accept standard PKCS#11 URIs for them instead of the bizarre format it currently requires. -- dwmw2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Tue Mar 17 22:30:17 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 17 Mar 2015 22:30:17 +0000 Subject: [openssl-dev] Using openssl with a remote private key In-Reply-To: <5508A9400030033200390AD0_0_136377@p057> References: <5508A9400030033200390AD0_0_136377@p057> Message-ID: <1426631417.24662.41.camel@infradead.org> On Tue, 2015-03-17 at 22:22 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote: > Thank you for your responses, PKCS#11 could be the right way to go. I > am hoping there is flexibility as per what functionality I want to > delegate (just need the decrypt piece). > If I had to implement a fully fledged PKCS#11 module that would be an > overkill. I hope that's not the case? You don't have to have the *cert* in PKCS#11. Only the key. A module to implement that much can be fairly trivial. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From deengert at gmail.com Tue Mar 17 23:55:59 2015 From: deengert at gmail.com (Douglas E Engert) Date: Tue, 17 Mar 2015 18:55:59 -0500 Subject: [openssl-dev] Using openssl with a remote private key In-Reply-To: <55084BE001E705C20039061F_0_80099@p057> References: <55084BE001E705C20039061F_0_80099@p057> Message-ID: <5508BF0F.6010504@gmail.com> On 3/17/2015 10:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote: > Hi there! > > Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore > the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed. Introducing another machine, will introduce addition trust issues, as to why the "server" trusts the "other machine" holding the private key, how does the "other machine" trust the "server" and trust the network connections between the two machines. If not done correctly, the "other machine" could be attacked to decrypt requests from a man-in-the-middle pretending to be the "server". (The certificate contains the public key, the private key is not part of the certificate.) > > I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version. > In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine. As pointed out in other replies, PKCS#11 and openssl_engine could be used. If used with a smart card, the smart card could be on the "other machine". The PKCS#11 implementation could be using PCSC to talk to the smart card, which can be used across a network. For example remote desktop, rdesktop or RDP can transport the smart card APDUs across the network. This is usually used by a user with a smart card at a remote terminal, and the trust model is different then in your case of a "server" to the "other machine". > > Let me know if there is a better solution for this problem. > > Cheers, > Tigran > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert From rt at openssl.org Wed Mar 18 08:45:07 2015 From: rt at openssl.org (Martin Husemann via RT) Date: Wed, 18 Mar 2015 09:45:07 +0100 Subject: [openssl-dev] [openssl.org #3753] BUG: arm support ASM code incorrect for BE8 In-Reply-To: <20150317162233.GC12689@mail.duskware.de> References: <20150317162233.GC12689@mail.duskware.de> Message-ID: The ARM assembly code implements some probing for the CPU at runtime and uses hard coded byte sequences for the probe code. This way does not work for arm object file formats using new big endian (BE8) mode. It is, however, very simple to fix: The armv4cpuid.S code (generated from armv4cpuid.PL) looks like this: _armv8_aes_probe: .byte 0x00,0x03,0xb0,0xf3 @ aese.8 q0,q0 bx lr but it should simply be: _armv8_aes_probe: .inst 0xf3b00300 @ aese.8 q0,q0 bx lr The .inst pseudo op outputs 32bit as instruction (with whatever byte swapping or $a markup is required for the object format in use) - hint from Matt Thomas. Fixing this may be enough to remove the "can not build universal binary for big endian arm" configure failure, with maybe a few ifdefs for BE8 vs. BE32 big endian formats. While here I notice that the generated .S files always encode "RET" as "bx lr", even on armv4 machines. Martin From matt at openssl.org Wed Mar 18 11:07:59 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 18 Mar 2015 11:07:59 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases In-Reply-To: <5507297B.8040505@openssl.org> References: <5507297B.8040505@openssl.org> Message-ID: <55095C8F.2020804@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16/03/15 19:05, Matt Caswell wrote: > > Forthcoming OpenSSL releases ============================ > > The OpenSSL project team would like to announce the forthcoming > release of OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf. > > These releases will be made available on 19th March. They will fix > a number of security defects. The highest severity defect fixed by > these releases is classified as "high" severity. I have received a number of queries regarding the timing of Thursday's release. To clarify, we are aiming to have the release available sometime between 1100-1500 GMT. Regards Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCVyPAAoJENnE0m0OYESROvYH/1BdqjzpgiTMhAIYsJjDb0xt eWM5GdqwiATa+1FqvYXN1pa3Wencl0UVAKsUh0tsC/6MaQVSqyUVkpJZNvvwTrqt Fmn8sYrF4vFdGNCWoMWWCm0roW9r7V/BGRJrXol0O6b/t5+QrRkVTlEsHTVi3PKD ujQS5heKS5HPNlZEkhWz+MH3i5RcWx7TVTLVGtsKhIlkc0bM5tSKiynMYQyOhkh2 dLfnNvHGC/g7qIeWg3cGXa4P5Y78SrBvKGj5Bu7IouaT2bC01RfAfYH7pJwpISbZ 3qwwKqGuNF31AC8xBM4CPFU+7MJQtRDtcDzQURHud4Vqn4C/rtmnI0r+tkxDi9I= =99aY -----END PGP SIGNATURE----- From rt at openssl.org Wed Mar 18 11:06:10 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 18 Mar 2015 12:06:10 +0100 Subject: [openssl-dev] [openssl.org #3753] BUG: arm support ASM code incorrect for BE8 In-Reply-To: <55095B58.5090106@openssl.org> References: <20150317162233.GC12689@mail.duskware.de> <55095B58.5090106@openssl.org> Message-ID: > The ARM assembly code implements some probing for the CPU at runtime > and uses hard coded byte sequences for the probe code. > > This way does not work for arm object file formats using new big endian > (BE8) mode. It is, however, very simple to fix: > > The armv4cpuid.S code (generated from armv4cpuid.PL) looks like this: > > _armv8_aes_probe: > .byte 0x00,0x03,0xb0,0xf3 @ aese.8 q0,q0 > bx lr > > but it should simply be: > > _armv8_aes_probe: > .inst 0xf3b00300 @ aese.8 q0,q0 > bx lr Original rationale behind choice is following. Unfortunately support for .inst was added relatively recently and, as people are not always in position to update their assembler, using .inst would break compilations. So what to do under the circumstances? ARMv7 (and later) picks instructions always in little-endian byte order(*), even when it's operating in big-endian mode. If there is something that ensures that instruction in question is not reached on platform other than ARMv7 or later, then .byte would be the correct choice in *all* situations. Is there such provision? Yes, probe for crypto extensions if guarded by probe for ARMv7 NEON and NEON probe instruction is assembled by its mnemonic. Or in other words if NEON probe passes, then we know that above .byte encoding is going to be correct one. > The .inst pseudo op outputs 32bit as instruction (with whatever byte swapping > or $a markup is required for the object format in use) - hint from Matt Thomas. > > Fixing this may be enough to remove the "can not build universal binary for > big endian arm" configure failure, with maybe a few ifdefs for BE8 vs. BE32 > big endian formats. Universal binary means that you can take literally same binary and execute it on several processors of same endianness. We're talking about big-endian for the moment. But recall that ARMv7 picks instructions in little-endian order even when it's operating in big-endian mode(*). That means that if big-endian universal binary was option, then code would have to converted on the fly, as it gets loaded to memory for execution. Is there system that does it? ... As for BE8. As far as I understand it allows you to change instruction endianness at link stage, i.e. by the time you already have decided if code is going to be executed on ARMv7 or pre-ARMv7. Which doesn't give you big-endian universal binary :-( > While here I notice that the generated .S files always encode "RET" as "bx lr", > even on armv4 machines. This is done only in ARMv>=7 code paths. I mean if concern is that ARMv4 processor is not capable of executing bx lr, then you have to recall that it won't be able to execute a whole bunch of instructions preceding it. But it never attempts to execute them, because there is run-time switch controlled by processor capability bit-mask. (*) There is an exclusion, namely ARMv7-R profile, but rationale is that NEON is unlikely to be an option, so that NEON probe will fail, and AES probe won't be executed. From Satish.KumarYarru at cognizant.com Wed Mar 18 11:45:35 2015 From: Satish.KumarYarru at cognizant.com (Satish.KumarYarru at cognizant.com) Date: Wed, 18 Mar 2015 11:45:35 +0000 Subject: [openssl-dev] How to enable tls_empty_renegotiation_info_scsv Message-ID: Hello Team, I am testing my SSLClient with HTTPS IIS server. I could see Handshake failed. When I checked the client hello packet, there is no psuedo cipher (SCSV)sent. I suspect this is the issue. Can you please help me what flags or cipher suites I need to enable to send "tls_empty_renegotiation_info_scsv" pseudo cipher in Client Hello packet. Regards, Satish This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Wed Mar 18 18:02:34 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 18 Mar 2015 14:02:34 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> Message-ID: <5509BDBA.20702@cisco.com> Something does seem suspect here. Maybe I'm misusing the API, but when using the attached patch for s_server, the client side does reject the NewSessionTicket message from the server. This only happens when using SSL_set_session_secret_cb() on the server side. When using this callback facility, the server changes the order of the handshake messages. The order without using SSL_set_session_secret_cb() is: <-ServerHello <-Certificate <-ServerKeyExchange <-ServerHelloDone ->ClientKeyExchange ->ChangeCipherSpec <-NewSessionTicket <-ChangeCipherSpec The order when using SSL_set_session_secret_cb() is: <-ServerHello <-NewSessionTicket <-ChangeCipherSpec ->Alert The session ticket extension in the ClientHello is empty in both cases. It appears the server thinks it's using a valid session ticket and proceeds directly to the ChangeCipherSpec. On 03/17/2015 04:16 PM, Erik Tkal wrote: > I don?t disagree, but I?m looking for independent confirmation that > the changes are not correct. They do not appear to specifically have > been made for any vulnerabilities. > > In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 > shows that the server may send a certificate message to continue the > handshake after receiving a sessionTicket from the client. With the > first change I noted below the possession of a tls_session_secret now > implies by the setting of s->hit on the client that the session *will* > be resumed, which is not the case. The resumption requires > determination of the next message. In the case of a pure sessionID > resumption that is the case since the server confirms it in the > serverHello, but not when using the sessionTicket extension. > > Erik > > >> On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan >> > > wrote: >> >> I would be very careful about this code. When we ran our tests on >> OpenSSL (www.smacktls.com ), we found a >> bunch of issues that were narrowly prevented by a combination of >> flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). >> >> Let?s carefully test any change here, so we do not >> re-enable CVE-2014-0224 (Early CCS Attack) >> >> >> On 17 Mar 2015, at 18:53, Erik Tkal > > wrote: >> >>> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour >>> of a non-resumed EAP-FAST session. >>> >>> RFC 4851 indicates that the server can go straight from the >>> serverHello to changeCipherSpec to resume a session but can also >>> fall back to a full handshake. With 1.0.1l the client ends up >>> issuing an unexpected message alert if the server continues with its >>> certificate message. >>> >>> I traced this to the following change: >>> >>> Set s->hit when resuming from external pre-shared secret. >>> >>> >>> https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 >>> >>> When processing the serverHello s->tls_session_secret_cb() is called >>> to see if the client has a session secret, and if so the old code >>> would set the flag that a CCS was acceptable at that point. >>> However, the above change now also sets s->hit, which then >>> ?requires* that a finished message is expected next, triggering the >>> alert otherwise. >>> >>> Also, another change is suspect in that the latest code no longer >>> sets the flag that a CCS is acceptable at that point: >>> >>> Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) >>> is reset >>> >>> >>> https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 >>> >>> In order for EAP-FAST to work it seems that if the client does have >>> a tls_session_secret that s->hit must NOT be set since there is no >>> indication in the serverHello as to whether the session_ticket sent >>> by the client is accepted by the server (the sessionTicket extension >>> is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK >>> has to be set since the server MAY continue immediately with a >>> changeCipherSpec. >>> >>> Thanks, >>> Erik >>> >>> .................................... >>> Erik Tkal >>> etkal at cisco.com >>> >>> _______________________________________________ >>> 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: recreate.patch Type: text/x-patch Size: 1989 bytes Desc: not available URL: From rt at openssl.org Thu Mar 19 10:43:35 2015 From: rt at openssl.org (=?UTF-8?B?7J6l7JiB7ZyY?= via RT) Date: Thu, 19 Mar 2015 11:43:35 +0100 Subject: [openssl-dev] [openssl.org #3754] [OpenSSL bug-report] if malloc failed on EVP_PKEY_new_mac_key() ? In-Reply-To: References: Message-ID: [bug-report] Hi, I am openssl-user Jang Young-Hwi. My webwerver uses OpenSSL-1.0.1h, and downed with core dump. The core dump occurs when the pkey is NULL. (if malloc() failed) I think that the exception code is required.. Below.. ========== [core dump] ... Program terminated with signal 11, Segmentation fault. SEGV_MAPERR - Address not mapped to object #0 EVP_PKEY_assign () at p_lib.c:267 267 p_lib.c: No such file or directory. in p_lib.c (gdb) where #0 EVP_PKEY_assign () at p_lib.c:267 #1 0x400000000051a820:0 in pkey_hmac_keygen () at hm_pmeth.c:132 #2 0x400000000044d830:0 in EVP_PKEY_new_mac_key () at pmeth_gn.c:156 #3 0x400000000031fdc0:0 in tls1_change_cipher_state () at t1_enc.c:500 #4 0x400000000037b6e0:0 in ssl3_do_change_cipher_spec () at s3_pkt.c:1473 #5 0x4000000000379bb0:0 in ssl3_read_bytes () at s3_pkt.c:1334 #6 0x400000000037dbc0:0 in ssl3_get_message () at s3_both.c:457 #7 0x4000000000367130:0 in ssl3_get_cert_verify () at s3_srvr.c:2917 #8 0x400000000035ce90:0 in ssl3_accept () at s3_srvr.c:678 #9 0x400000000032d2e0:0 in SSL_accept () at ssl_lib.c:940 ========== [source 0] #0 EVP_PKEY_assign () at p_lib.c:267 263 int EVP_PKEY_assign(EVP_PKEY *pkey, int type, void *key) 264 { 265 if (!EVP_PKEY_set_type(pkey, type)) 266 return 0; 267 pkey->pkey.ptr=key; /* if pkey is NULL?? */ 268 return (key != NULL); 269 } ========== [source 1] #1 0x400000000051a820:0 in pkey_hmac_keygen () at hm_pmeth.c:132 128 static int pkey_hmac_keygen(EVP_PKEY_CTX *ctx, EVP_PKEY *pkey) 129 { 130 ASN1_OCTET_STRING *hkey = NULL; 131 HMAC_PKEY_CTX *hctx = ctx->data; 132 if (!hctx->ktmp.data) 133 return 0; 134 hkey = ASN1_OCTET_STRING_dup(&hctx->ktmp); 135 if (!hkey) 136 return 0; 137 EVP_PKEY_assign(pkey, EVP_PKEY_HMAC, hkey); 138 139 return 1; 140 } ========== [source 2] #2 0x400000000044d830:0 in EVP_PKEY_new_mac_key () at pmeth_gn.c:156 134 int EVP_PKEY_keygen(EVP_PKEY_CTX *ctx, EVP_PKEY **ppkey) 135 { 136 int ret; 137 138 if (!ctx || !ctx->pmeth || !ctx->pmeth->keygen) 139 { 140 EVPerr(EVP_F_EVP_PKEY_KEYGEN, 141 EVP_R_OPERATION_NOT_SUPPORTED_FOR_THIS_KEYTYPE); 142 return -2; 143 } 144 if (ctx->operation != EVP_PKEY_OP_KEYGEN) 145 { 146 EVPerr(EVP_F_EVP_PKEY_KEYGEN, EVP_R_OPERATON_NOT_INITIALIZED); 147 return -1; 148 } 149 150 if (!ppkey) 151 return -1; 152 153 if (!*ppkey) 154 *ppkey = EVP_PKEY_new(); /* ==> if *ppkey is NULL?? */ 155 156 ret = ctx->pmeth->keygen(ctx, *ppkey); 157 if (ret <= 0) 158 { 159 EVP_PKEY_free(*ppkey); 160 *ppkey = NULL; 161 } 162 return ret; 163 } ========== Thanks.. I always appreciate you.. From openssl at openssl.org Thu Mar 19 14:09:15 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 19 Mar 2015 14:09:15 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2a released Message-ID: <20150319140915.GA544@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2a released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2a of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2a.tar.gz Size: 5262089 MD5 checksum: a06c547dac9044161a477211049f60ef SHA1 checksum: 46ecd325b8e587fa491f6bb02ad4a9fb9f382f5f The checksums were calculated using the following commands: openssl md5 openssl-1.0.2a.tar.gz openssl sha1 openssl-1.0.2a.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCs+pAAoJENnE0m0OYESRxPAH/RnASp6tS9gdV3luvD4FbAr9 EoASYKCPWAnlNdVYobRaAPVreoNC1xGrV2YwpFwh0z3D19Nz7O7utzrEEAgtlTa3 /H3jm91cNOJWldPh+fNIAerfESghf96tVrPFAzHZ2PpGSDvX/oNV8IWgqixtChCe cQLa/EYT1VnFSiLOyoWWVFfICmzqk2Ke+aWKnnXgkS2gEOKTdCgdmkfmzTdRYGok eVHzoFXN5AMY/zxvv4LVbpfdYmp0zynI2HWDRo2F5S3AQ+olVj3qmtJERW4DRlNT ctZ9YStZzT39hbvOFVtE0XhhaERkO/tZMcso4Ouq8CU6qg4A6e7+X3gz2maWjfI= =Qbok -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 19 14:09:28 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 19 Mar 2015 14:09:28 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1m released Message-ID: <20150319140928.GA640@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1m released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1m of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1m is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1m.tar.gz Size: 4533406 MD5 checksum: d143d1555d842a069cb7cc34ba745a06 SHA1 checksum: 4ccaf6e505529652f9fdafa01d1d8300bd9f3179 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1m.tar.gz openssl sha1 openssl-1.0.1m.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCtFhAAoJENnE0m0OYESRqp0H/jPPpLlFSwsSn7IASUzQL9/r 9e7KWLaHw1u2OH9MjgdfvWFSJAczNsc6l/UizpmJNcv26KVMzGcfk+wEGwNS6erO SxlO3IYkQA8HJhRIyOlbkq75NbmOMO/ECfY+yc6NY1uciQpuO5sSk6GKuDiTvh03 d4VyubmKx55ITlmXnj2YTY2igFA1WY+QmHKVAtGN/b0OdakhjCFXY+IdZpbJujw+ UmkjwWrpBngBz/jJ0mRln7i47gT+tAlAw/O/bGLxHb4pMLtRLnT9QkeyKduOCNp8 S/2s+fHs7y2yEQ+hyPVwnp7IaRj+q/bIyg5+kpL/viT7FczXrfEqnbNmRjNumQA= =umSV -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 19 14:09:46 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 19 Mar 2015 14:09:46 +0000 Subject: [openssl-dev] OpenSSL version 1.0.0r released Message-ID: <20150319140946.GA810@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0r released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0r of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.0-notes.html OpenSSL 1.0.0r is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0r.tar.gz Size: 4095201 MD5 checksum: ea48d0ad53e10f06a9475d8cdc209dfa SHA1 checksum: 24508ff8c4ad94bcf1070441a737097f04480c6b The checksums were calculated using the following commands: openssl md5 openssl-1.0.0r.tar.gz openssl sha1 openssl-1.0.0r.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCtJnAAoJENnE0m0OYESRX3AH/1erQLZ5BkGvGE+6yFkB0/Kv 0sDk3GrGEu1NjH3Fwg7ibnfrggr3m8XUc9oO89+cFWdu2pX0m2JC5wBqsGnXWBdu H0kdS6C1v/vDUDZOUfozlnZjop8kwNtXFWpc7K3ALuKHssTyJi/ZH7+PfFUXwyDq d+FVBmishi8UIcxk5Wltg+YrFZkCe7098AL2Yf1wQ3t3aa9zCR5zsHFnsY6nSViI m12a8PIyrJLbKG7gLdxWAZ6y8Irs2avWnegcFomlB1vLmTm2yU302/vYW3DD3qUf hQK7W63NUQ4bKDY1wieWroB8GfnZyf5EXHJaWRf3ECONhSIxMTimAR3YlI5Qsws= =3kWK -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 19 14:09:54 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 19 Mar 2015 14:09:54 +0000 Subject: [openssl-dev] OpenSSL version 0.9.8zf released Message-ID: <20150319140954.GA972@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zf released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zf of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-0.9.8-notes.html OpenSSL 0.9.8zf is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8zf.tar.gz Size: 3822386 MD5 checksum: c69a4a679233f7df189e1ad6659511ec SHA1 checksum: 3f2f4ca864b13a237ae063cd34d01bbdbc8f108f The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zf.tar.gz openssl sha1 openssl-0.9.8zf.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCtNyAAoJENnE0m0OYESRylAH/RYLoFCCjLXCQUzLcwI2d3gq 6Hysl+GiOixeqEaHwMbAyrhkvym8sRGHuCUL94lAos6yhlePrAkcGMk8J5sVfNKN tczUswpQj8EZYTPsb0JdnOEQnBrezauhJphwDMwDPXjR5KGYzYTBpGL4AZIvJ9OT xIodpg/ACqI8Tk6wnc+LHROMjUpAEkpUqbZbW6NilXT0Ajh6NjmDIYy/OT74Y/Cj YzDb4V8pch/WhoF0t62dmOlq4cuBWYDNkw6oKPa5koBCURB2MsoZzF6H/grVgdU6 ADkw8ZSORVsESjVGhSRU9Ptni37BHx9DaIEsj2hLfGzAAcNgf6zUE9/u7iK/uJo= =wJnL -----END PGP SIGNATURE----- From openssl at openssl.org Thu Mar 19 14:12:02 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 19 Mar 2015 14:12:02 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20150319141202.GA1887@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [19 Mar 2015] ======================================= OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291) ===================================================== Severity: High If a client connects to an OpenSSL 1.0.2 server and renegotiates with an invalid signature algorithms extension a NULL pointer dereference will occur. This can be exploited in a DoS attack against the server. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was was reported to OpenSSL on 26th February 2015 by David Ramos of Stanford University. The fix was developed by Stephen Henson and Matt Caswell of the OpenSSL development team. Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ============================================================================ Severity: High This security issue was previously announced by the OpenSSL project and classified as "low" severity. This severity rating has now been changed to "high". This was classified low because it was originally thought that server RSA export ciphersuite support was rare: a client was only vulnerable to a MITM attack against a server which supports an RSA export ciphersuite. Recent studies have shown that RSA export ciphersuites support is far more common. This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team. It was previously announced in the OpenSSL security advisory on 8th January 2015. Multiblock corrupted pointer (CVE-2015-0290) ============================================ Severity: Moderate OpenSSL 1.0.2 introduced the "multiblock" performance improvement. This feature only applies on 64 bit x86 architecture platforms that support AES NI instructions. A defect in the implementation of "multiblock" can cause OpenSSL's internal write buffer to become incorrectly set to NULL when using non-blocking IO. Typically, when the user application is using a socket BIO for writing, this will only result in a failed connection. However if some other BIO is used then it is likely that a segmentation fault will be triggered, thus enabling a potential DoS attack. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL development team. Segmentation fault in DTLSv1_listen (CVE-2015-0207) =================================================== Severity: Moderate The DTLSv1_listen function is intended to be stateless and processes the initial ClientHello from many peers. It is common for user code to loop over the call to DTLSv1_listen until a valid ClientHello is received with an associated cookie. A defect in the implementation of DTLSv1_listen means that state is preserved in the SSL object from one invocation to the next that can lead to a segmentation fault. Errors processing the initial ClientHello can trigger this scenario. An example of such an error could be that a DTLS1.0 only client is attempting to connect to a DTLS1.2 only server. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a. This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The fix was developed by Matt Caswell of the OpenSSL development team. Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) =================================================== Severity: Moderate The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check certificate signature algorithm consistency this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered and fixed by Stephen Henson of the OpenSSL development team. Segmentation fault for invalid PSS parameters (CVE-2015-0208) ============================================================= Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and invalid parameters. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a This issue was was reported to OpenSSL on 31st January 2015 by Brian Carpenter and a fix developed by Stephen Henson of the OpenSSL development team. ASN.1 structure reuse memory corruption (CVE-2015-0287) ======================================================= Severity: Moderate Reusing a structure in ASN.1 parsing may allow an attacker to cause memory corruption via an invalid write. Such reuse is and has been strongly discouraged and is believed to be rare. Applications that parse structures containing CHOICE or ANY DEFINED BY components may be affected. Certificate parsing (d2i_X509 and related functions) are however not affected. OpenSSL clients and servers are not affected. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered by Emilia K??sper and a fix developed by Stephen Henson of the OpenSSL development team. PKCS7 NULL pointer dereferences (CVE-2015-0289) =============================================== Severity: Moderate The PKCS#7 parsing code does not handle missing outer ContentInfo correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with missing content and trigger a NULL pointer dereference on parsing. Applications that verify PKCS#7 signatures, decrypt PKCS#7 data or otherwise parse PKCS#7 structures from untrusted sources are affected. OpenSSL clients and servers are not affected. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was reported to OpenSSL on February 16th 2015 by Michal Zalewski (Google) and a fix developed by Emilia K??sper of the OpenSSL development team. Base64 decode (CVE-2015-0292) ============================= Severity: Moderate A vulnerability existed in previous versions of OpenSSL related to the processing of base64 encoded data. Any code path that reads base64 data from an untrusted source could be affected (such as the PEM processing routines). Maliciously crafted base 64 data could trigger a segmenation fault or memory corruption. This was addressed in previous versions of OpenSSL but has not been included in any security advisory until now. This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1h. OpenSSL 1.0.0 users should upgrade to 1.0.0m. OpenSSL 0.9.8 users should upgrade to 0.9.8za. The fix for this issue can be identified by commits d0666f289a (1.0.1), 84fe686173 (1.0.0) and 9febee0272 (0.9.8). This issue was originally reported by Robert Dugal and subsequently by David Ramos. DoS via reachable assert in SSLv2 servers (CVE-2015-0293) ========================================================= Severity: Moderate A malicious client can trigger an OPENSSL_assert (i.e., an abort) in servers that both support SSLv2 and enable export cipher suites by sending a specially crafted SSLv2 CLIENT-MASTER-KEY message. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered by Sean Burford (Google) and Emilia K??sper (OpenSSL development team) in March 2015 and the fix was developed by Emilia K??sper. Empty CKE with client auth and DHE (CVE-2015-1787) ================================================== Severity: Moderate If client auth is used then a server can seg fault in the event of a DHE ciphersuite being selected and a zero length ClientKeyExchange message being sent by the client. This could be exploited in a DoS attack. This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was discovered and the fix was developed by Matt Caswell of the OpenSSL development team. Handshake with unseeded PRNG (CVE-2015-0285) ============================================ Severity: Low Under certain conditions an OpenSSL 1.0.2 client can complete a handshake with an unseeded PRNG. The conditions are: - - The client is on a platform where the PRNG has not been seeded automatically, and the user has not seeded manually - - A protocol specific client method version has been used (i.e. not SSL_client_methodv23) - - A ciphersuite is used that does not require additional random data from the PRNG beyond the initial ClientHello client random (e.g. PSK-RC4-SHA). If the handshake succeeds then the client random that has been used will have been generated from a PRNG with insufficient entropy and therefore the output may be predictable. For example using the following command with an unseeded openssl will succeed on an unpatched platform: openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA This issue affects OpenSSL version: 1.0.2 OpenSSL 1.0.2 users should upgrade to 1.0.2a. This issue was discovered and the fix was developed by Matt Caswell of the OpenSSL development team. Use After Free following d2i_ECPrivatekey error (CVE-2015-0209) =============================================================== Severity: Low A malformed EC private key file consumed via the d2i_ECPrivateKey function could cause a use after free condition. This, in turn, could cause a double free in several private key parsing functions (such as d2i_PrivateKey or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption for applications that receive EC private keys from untrusted sources. This scenario is considered rare. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered by the BoringSSL project and fixed in their commit 517073cd4b. The OpenSSL fix was developed by Matt Caswell of the OpenSSL development team. X509_to_X509_REQ NULL pointer deref (CVE-2015-0288) =================================================== Severity: Low The function X509_to_X509_REQ will crash with a NULL pointer dereference if the certificate key is invalid. This function is rarely used in practice. This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade to 1.0.1m. OpenSSL 1.0.0 users should upgrade to 1.0.0r. OpenSSL 0.9.8 users should upgrade to 0.9.8zf. This issue was discovered by Brian Carpenter and a fix developed by Stephen Henson of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv_20150319.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCs3bAAoJENnE0m0OYESRxuYH/iQAugnk+JYPe14KVYAoIHWS W63200SoPK4v6Sl6v7CbBzWPXLUe16n4ESlycrmiowAviOAroZKL+yk7iv/SHStL cQN8tx26vzESIgKKWUyMKUsm82JF08dJiZjiw/l+I7ntM+jMkXmvf1bMF2FqmzYl 5dBJmZqUK5sz6sue78iQT5yznJkJ+106oJUVXTHb3NVya4WMDzQ9IFgYFtfaZCQI kRy355VZcEl1ePVYFxE0fDQ2mzBeEejsv8eeOs9VRv5yMnV5dV35RQeKS5YxFXsP sT+ToTkNBF6yMt1HEAMR+2viisUvJDQHePLCodJSqGlfsgOVlM8N3pY6NPT8fDM= =I76k -----END PGP SIGNATURE----- From dominyktiller at gmail.com Thu Mar 19 15:07:53 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Thu, 19 Mar 2015 15:07:53 +0000 Subject: [openssl-dev] Release Checksums Message-ID: <550AE649.7010707@gmail.com> Hey guys, Is there any chance OpenSSL can start issuing SHA256 checksums with OpenSSL Releases as well as/instead of MD5/SHA1? MD5 isn't great these days, to say the least, and SHA1 has some potential long-term issues. Both MacPorts and Homebrew on OS X use SHA256 to verify downloads, and not displaying the SHA256 upstream makes it harder for OS X package-manager users to verify the checksum independently as desired. Would be appreciated if possible, Cheers, Dom -- Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From etksubs at gmail.com Thu Mar 19 15:40:57 2015 From: etksubs at gmail.com (Erik Tkal) Date: Thu, 19 Mar 2015 11:40:57 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> Message-ID: <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> FWIW, RFC 5077 says: 3.4 . Interaction with TLS Session ID ... When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. Since the client generates a Session ID, the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. If a ticket is presented by the client, the server MUST NOT attempt to use the Session ID in the ClientHello for stateful session resumption. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case, the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages. If I do not send a sessionID in the clientHello but do send a valid sessionTicket extension, the server goes straight to changeCipherSpec and the client generates an UnexpectedMessage alert. This is slightly different from the issue I saw before, as I was trying to use stock OpenSSL instead of our application to recreate by making minor changes. In this case I was *not* setting the session secret callback but instead using OpenSSL?s default mechanism and only removing the sessionId from the client. In the full case using EAP-FAST I?ll have to wire up session secret processing and the sessionTicket extension handling on both sides, but this shows something is definitely awry with the recent changes. Erik write to 0x7fafcac26c60 [0x7fafcc004603] (467 bytes => 467 (0x1D3)) 0000 - 16 03 01 01 ce 01 00 01-ca 03 03 a5 20 37 c1 48 ............ 7.H 0010 - 64 46 12 0a d0 1c 70 a8-28 7b 05 51 f0 14 31 7b dF....p.({.Q..1{ 0020 - 1c fe 52 c2 9c 37 74 d9-a9 17 57 00 00 94 c0 30 ..R..7t...W....0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k 0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...* 0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../ 0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g 0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 . at .3.2.....E.D.1 0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./ 0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A............ 00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................ 00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 ................ 00c0 - 00 ff 01 00 01 0d 00 0b-00 04 03 00 01 02 00 0a ................ 00d0 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18 .4.2............ 00e0 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14 ................ 00f0 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03 ................ 0100 - 00 0f 00 10 00 11 00 23-00 a0 d7 39 e6 23 d8 a1 .......#...9.#.. 0110 - 41 bd a1 1a 55 4d 7f 07-6d 4d 1c 89 b0 f8 1d b4 A...UM..mM...... 0120 - 15 a0 e4 96 73 6a 75 53-a3 0d d3 90 2a 48 92 ec ....sjuS....*H.. 0130 - be 57 15 fe 20 c3 0f 34-12 63 e9 87 d6 87 06 d1 .W.. ..4.c...... 0140 - f2 28 5e 3e 7d 6c 96 79-f9 6d 76 27 51 07 fc a3 .(^>}l.y.mv'Q... 0150 - 16 83 64 e1 af 24 03 b0-34 c4 d1 a3 f9 2e f8 75 ..d..$..4......u 0160 - 30 18 27 55 54 3c 53 9a-70 1a cc 97 95 b7 a1 09 0.'UT 5 (0x5)) 0000 - 16 03 03 00 36 ....6 read from 0x7fafcac26c60 [0x7fafcc000008] (54 bytes => 54 (0x36)) 0000 - 02 00 00 32 03 03 89 9d-07 82 8f 74 e7 dd 44 6e ...2.......t..Dn 0010 - 16 28 c9 15 f2 5c d5 5b-f8 70 03 c2 48 f6 1a b4 .(...\.[.p..H... 0020 - 54 d5 1f af ca 09 00 c0-30 00 00 0a ff 01 00 01 T.......0....... 0030 - 00 00 0f 00 01 01 ...... TLS server extension "renegotiation info" (id=65281), len=1 0001 - TLS server extension "heartbeat" (id=15), len=1 0000 - 01 . read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5)) 0000 - 14 03 03 00 01 ..... read from 0x7fafcac26c60 [0x7fafcc000008] (1 bytes => 1 (0x1)) 0000 - 01 . write to 0x7fafcac26c60 [0x7fafcc801000] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 0a ....... 140735260517200:error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early:s3_pkt.c:1340: --- > On 17 Mar 2015, at 4:16 PM, Erik Tkal wrote: > > I don?t disagree, but I?m looking for independent confirmation that the changes are not correct. They do not appear to specifically have been made for any vulnerabilities. > > In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client. With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case. The resumption requires determination of the next message. In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension. > > Erik > > >> On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan > wrote: >> >> I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com ), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). >> >> Let?s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack) >> >> >> On 17 Mar 2015, at 18:53, Erik Tkal > wrote: >> >>> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session. >>> >>> RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake. With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message. >>> >>> I traced this to the following change: >>> >>> Set s->hit when resuming from external pre-shared secret. >>> >>> https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9 >>> >>> When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point. However, the above change now also sets s->hit, which then ?requires* that a finished message is expected next, triggering the alert otherwise. >>> >>> Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point: >>> >>> Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset >>> >>> https://github.com/openssl/openssl/commit/e94a6c0ede623960728415b68650a595e48f5a43 >>> >>> In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec. >>> >>> Thanks, >>> Erik >>> >>> .................................... >>> Erik Tkal >>> etkal at cisco.com >>> >>> _______________________________________________ >>> 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 rt at openssl.org Thu Mar 19 15:46:55 2015 From: rt at openssl.org (A. Klitzing via RT) Date: Thu, 19 Mar 2015 16:46:55 +0100 Subject: [openssl-dev] [PATCH] [openssl.org #2464] TLS-RSA-PSK support In-Reply-To: References: Message-ID: Hi there! I like to ask if this RSA-PSK patch could be reviewed (and maybe added) by someone. We are looking forward to see this feature in 1.1.0 someday. Any comments or hints? Best regards Andr? Klitzing 2015-01-30 16:32 GMT+01:00 Giuseppe D'Angelo via RT : > New version of the patch, targeting master. > > It's basically style changes after the massive OpenSSL refactoring. > > Thanks, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer > KDAB (UK) Ltd., a KDAB Group company > Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Introduce-TLS-RSA-PSK-support.patch Type: text/x-diff Size: 32648 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Mar 19 15:48:10 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Mar 2015 11:48:10 -0400 Subject: [openssl-dev] .txt files on https://openssl.org/ need Content-Type: text/plain; charset=utf-8 Message-ID: <87619xgf9h.fsf@alice.fifthhorseman.net> Thanks for the release today! This is a trivial bug report, but i figure I noticed that the advisory uses UTF-8, but it is being served with an unadorned "Content-Type: text/plain" header: $ (wget -O- -q -S https://openssl.org/news/secadv_20150319.txt | file -) 2>&1 | egrep 'stdin|Content-Type' Content-Type: text/plain /dev/stdin: UTF-8 Unicode text $ since most folks consider text/plain to default to iso-8859-1, that means that Emilia K?sper's name is rendered as Emilia K??sper. You can fix this by configuring the openssl.org webserver to serve text/plain files (or at least this text/plain file) with charset=utf-8. If you know that all the content is UTF-8 encoded, you can just add the following line to your apache config: AddDefaultCharset utf-8 https://httpd.apache.org/docs/2.4/mod/core.html#adddefaultcharset Regards, --dkg PS if there's a better place to report issues with the web site, please let me know. From steve at openssl.org Thu Mar 19 15:49:02 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 19 Mar 2015 15:49:02 +0000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> Message-ID: <20150319154902.GA31792@openssl.org> On Thu, Mar 19, 2015, Erik Tkal wrote: > > If I do not send a sessionID in the clientHello but do send a valid > sessionTicket extension, the server goes straight to changeCipherSpec and > the client generates an UnexpectedMessage alert. > Does the server send back an empty session ticket extension? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From aklitzing at gmail.com Thu Mar 19 15:45:53 2015 From: aklitzing at gmail.com (A. Klitzing) Date: Thu, 19 Mar 2015 16:45:53 +0100 Subject: [openssl-dev] [PATCH] [openssl.org #2464] TLS-RSA-PSK support Message-ID: Hi there! I like to ask if this RSA-PSK patch could be reviewed (and maybe added) by someone. We are looking forward to see this feature in 1.1.0 someday. Any comments or hints? Best regards Andr? Klitzing 2015-01-30 16:32 GMT+01:00 Giuseppe D'Angelo via RT : > New version of the patch, targeting master. > > It's basically style changes after the massive OpenSSL refactoring. > > Thanks, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer > KDAB (UK) Ltd., a KDAB Group company > Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Introduce-TLS-RSA-PSK-support.patch Type: text/x-diff Size: 32647 bytes Desc: not available URL: From rsalz at akamai.com Thu Mar 19 16:40:42 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 19 Mar 2015 16:40:42 +0000 Subject: [openssl-dev] .txt files on https://openssl.org/ need Content-Type: text/plain; charset=utf-8 In-Reply-To: <87619xgf9h.fsf@alice.fifthhorseman.net> References: <87619xgf9h.fsf@alice.fifthhorseman.net> Message-ID: > since most folks consider text/plain to default to iso-8859-1, that means that > Emilia K?sper's name is rendered as Emilia K??sper. Well, that's pretty bad. Fixed, thanks! From rt at openssl.org Thu Mar 19 17:04:10 2015 From: rt at openssl.org (=?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= via RT) Date: Thu, 19 Mar 2015 18:04:10 +0100 Subject: [openssl-dev] [openssl.org #3755] Double #included headers in openssl/bn.h In-Reply-To: <550AC047.8@aegee.org> References: <550AC047.8@aegee.org> Message-ID: Hello, deheader (git://gitorious.org/deheader/deheader.git) found out, that apps/speed.c #included twice and . Feel free to remove one for the duplicated #include . Greetings Dilian From rt at openssl.org Thu Mar 19 17:04:34 2015 From: rt at openssl.org (Chris Drake via RT) Date: Thu, 19 Mar 2015 18:04:34 +0100 Subject: [openssl-dev] [openssl.org #3756] OpenSSL enhancement request (easy - doc) In-Reply-To: <5224F715-99ED-4B00-A5B5-08536AC3DDE1@geek.net.au> References: <5224F715-99ED-4B00-A5B5-08536AC3DDE1@geek.net.au> Message-ID: Please document the differences between your 4 simultaneous releases somewhere easy to find (e.g.: on the main page https://www.openssl.org ) They all have exactly the same date, whether 1.0.2 is bigger or smaller than 1.0.11 is not clear, and which one should I be using? From rt at openssl.org Thu Mar 19 17:11:02 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 19 Mar 2015 18:11:02 +0100 Subject: [openssl-dev] [openssl.org #3756] OpenSSL enhancement request (easy - doc) In-Reply-To: <5224F715-99ED-4B00-A5B5-08536AC3DDE1@geek.net.au> References: <5224F715-99ED-4B00-A5B5-08536AC3DDE1@geek.net.au> Message-ID: https://openssl.org/about/releasestrat.html Letter releases contain only bugfixes. So 1.0.2 has more features than 1.0.1 That release has been out longer so it has more releases after it. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsbecker at nexbridge.com Thu Mar 19 17:41:04 2015 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 19 Mar 2015 13:41:04 -0400 Subject: [openssl-dev] OpenSSL version 1.0.2a released In-Reply-To: <20150319140915.GA544@openssl.org> References: <20150319140915.GA544@openssl.org> Message-ID: <002801d0626b$dff3bd60$9fdb3820$@nexbridge.com> On March 19, 2015 10:09 AM OpenSSL wrote: > To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML > Subject: [openssl-dev] OpenSSL version 1.0.2a released > OpenSSL version 1.0.2a released > =============================== > > OpenSSL - The Open Source toolkit for SSL/TLS > http://www.openssl.org/ > > The OpenSSL project team is pleased to announce the release of > version 1.0.2a of our open source toolkit for SSL/TLS. For details > of changes and known issues see the release notes at: Will there be a git tag on the official commit openssl 1.0.2a released commit? The openssl_1_0_2_stable branch is a moving target. Happily, the 1.0.1 versions all had tags. If not, would someone mind posting the official commit id from the github repo for this? Sincerely, Randall From steve at openssl.org Thu Mar 19 17:57:44 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 19 Mar 2015 17:57:44 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2a released In-Reply-To: <002801d0626b$dff3bd60$9fdb3820$@nexbridge.com> References: <20150319140915.GA544@openssl.org> <002801d0626b$dff3bd60$9fdb3820$@nexbridge.com> Message-ID: <20150319175744.GA3629@openssl.org> On Thu, Mar 19, 2015, Randall S. Becker wrote: > On March 19, 2015 10:09 AM OpenSSL wrote: > > To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML > > Subject: [openssl-dev] OpenSSL version 1.0.2a released > > OpenSSL version 1.0.2a released > > =============================== > > > > OpenSSL - The Open Source toolkit for SSL/TLS > > http://www.openssl.org/ > > > > The OpenSSL project team is pleased to announce the release of > > version 1.0.2a of our open source toolkit for SSL/TLS. For details > > of changes and known issues see the release notes at: > > Will there be a git tag on the official commit openssl 1.0.2a released > commit? The openssl_1_0_2_stable branch is a moving target. Happily, the > 1.0.1 versions all had tags. If not, would someone mind posting the official > commit id from the github repo for this? > All releases have tags. In this case it is OpenSSL_1_0_2a I've just checked and it is on the git.openssl.org repo. If it hasn't shown up on github the commit ID is 1cf0ad8601847cf40d Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsbecker at nexbridge.com Thu Mar 19 18:18:47 2015 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 19 Mar 2015 14:18:47 -0400 Subject: [openssl-dev] OpenSSL version 1.0.2a released In-Reply-To: <20150319175744.GA3629@openssl.org> References: <20150319140915.GA544@openssl.org> <002801d0626b$dff3bd60$9fdb3820$@nexbridge.com> <20150319175744.GA3629@openssl.org> Message-ID: <003301d06271$24bdcf30$6e396d90$@nexbridge.com> On March 19, 2015 1:58 PM Dr. Stephen Henson wrote: > On Thu, Mar 19, 2015, Randall S. Becker wrote: > > On March 19, 2015 10:09 AM OpenSSL wrote: > > > To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce > > > ML > > > Subject: [openssl-dev] OpenSSL version 1.0.2a released > > > OpenSSL version 1.0.2a released > > > =============================== > > > > > > OpenSSL - The Open Source toolkit for SSL/TLS > > > http://www.openssl.org/ > > > > > > The OpenSSL project team is pleased to announce the release of > > > version 1.0.2a of our open source toolkit for SSL/TLS. For details > > > of changes and known issues see the release notes at: > > > > Will there be a git tag on the official commit openssl 1.0.2a released > > commit? The openssl_1_0_2_stable branch is a moving target. Happily, > > the > > 1.0.1 versions all had tags. If not, would someone mind posting the > > official commit id from the github repo for this? > > > > All releases have tags. In this case it is OpenSSL_1_0_2a I've just checked and it > is on the git.openssl.org repo. If it hasn't shown up on github the commit ID is > 1cf0ad8601847cf40d > > Steve. Thanks. I will monitor for it. Neither the commit nor tag is not there yet. Regards, Randall From jcea at jcea.es Thu Mar 19 22:51:02 2015 From: jcea at jcea.es (Jesus Cea) Date: Thu, 19 Mar 2015 23:51:02 +0100 Subject: [openssl-dev] 64 bit compilacion seems to fail with some PERL versions Message-ID: <550B52D6.4020001@jcea.es> When compiling a 64 bit OpenSSL 1.0.2a with a 32 bit PERL interpreter I get this error: """ ./config zlib-dynamic shared make [...] /usr/local/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl line 201, <> line 890. gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -O3 -Wall -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s ghash-x86_64.s: Assembler messages: ghash-x86_64.s:890: Error: junk `.15473355479995e+19' after expression : recipe for target 'ghash-x86_64.o' failed make[2]: *** [ghash-x86_64.o] Error 1 """ In line 890 I have this: """ subq $48,%rcx movq $1.15473355479995e+19,%rax <<<<<<<<<<<<<<<<<< movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 """ Comparing that line in other machines where compilation is done correctly, I see this: """ movq $11547335547999543296,%rax """ Notice that "11547335547999543296" is approximately 1.15473355479995e+19 in scientific notation. When doing "perl -e 'print(11547335547999543296)' I get: 11547335547999543296 in one machine (64 bits), but 1.15473355479995e+19 in the other machine (32 bits). The number is being promoted to scientific notation and compilation will fail. Yes, in Solaris I can mix 32 and 64 bit binaries in the same running system. It is standard practice and the reason I am compiling OpenSSL both in 32 and in 64 bits. Replacing the scientific notation value with "11547335547999543296" the code compiles correctly and the tests complete 100% OK. In the 64 bit PERL version "11547335547999543296" is printed correctly as an integer but "21547335547999543296" (first digit changed) is printed as 2.15473355479995e+19. I think that depending of implementation details (the value when an integer is "promoted" to floating point) of the PERL interpreter is bad practice and should be avoided. Maybe using literal string, of splitting the number in two halfs. -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From omon.edeki at nowellgroup.com Fri Mar 20 00:00:35 2015 From: omon.edeki at nowellgroup.com (Omon Edeki (Nowell Development)) Date: Thu, 19 Mar 2015 19:00:35 -0500 Subject: [openssl-dev] 64 bit compilacion seems to fail with some PERL versions In-Reply-To: <550B52D6.4020001@jcea.es> References: <550B52D6.4020001@jcea.es> Message-ID: <001601d062a0$e55d22c0$b0176840$@nowellgroup.com> I had success compiling and integrating 1.0.2 on Centos Linux 5.10 i686, however for Windows 7 64 bit, my 64 bit compilation of 1.0.2 did not succeed at the first attempt. Instead for our Windows 7 build , I downloaded openssl-1.0.11 and compiled it as a 32 bit library and integrated with our project libraries and that succeeded. I followed these as a guide for Visual Studio: http://developer.covenanteyes.com/building-openssl-for-visual-studio/ Not sure if this helps your situation, but it worked for me Very respectfully, Omon Edeki Omon.edeki at nowellgroup.com https://www.linkedin.com/pub/omon-edeki/8/38b/912 Director, Software Development Nowell Development 512-903-2950 -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Jesus Cea Sent: Thursday, March 19, 2015 5:51 PM To: OpenSSL Developer ML Subject: [openssl-dev] 64 bit compilacion seems to fail with some PERL versions When compiling a 64 bit OpenSSL 1.0.2a with a 32 bit PERL interpreter I get this error: """ ./config zlib-dynamic shared make [...] /usr/local/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl line 201, <> line 890. gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -O3 -Wall -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s ghash-x86_64.s: Assembler messages: ghash-x86_64.s:890: Error: junk `.15473355479995e+19' after expression : recipe for target 'ghash-x86_64.o' failed make[2]: *** [ghash-x86_64.o] Error 1 """ In line 890 I have this: """ subq $48,%rcx movq $1.15473355479995e+19,%rax <<<<<<<<<<<<<<<<<< movdqu 48(%rsi),%xmm14 movdqu 64(%rsi),%xmm15 """ Comparing that line in other machines where compilation is done correctly, I see this: """ movq $11547335547999543296,%rax """ Notice that "11547335547999543296" is approximately 1.15473355479995e+19 in scientific notation. When doing "perl -e 'print(11547335547999543296)' I get: 11547335547999543296 in one machine (64 bits), but 1.15473355479995e+19 in the other machine (32 bits). The number is being promoted to scientific notation and compilation will fail. Yes, in Solaris I can mix 32 and 64 bit binaries in the same running system. It is standard practice and the reason I am compiling OpenSSL both in 32 and in 64 bits. Replacing the scientific notation value with "11547335547999543296" the code compiles correctly and the tests complete 100% OK. In the 64 bit PERL version "11547335547999543296" is printed correctly as an integer but "21547335547999543296" (first digit changed) is printed as 2.15473355479995e+19. I think that depending of implementation details (the value when an integer is "promoted" to floating point) of the PERL interpreter is bad practice and should be avoided. Maybe using literal string, of splitting the number in two halfs. -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea at jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz From rt at openssl.org Fri Mar 20 12:20:07 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 20 Mar 2015 13:20:07 +0100 Subject: [openssl-dev] [openssl.org #3668] [PATCH] Don't use the cert list embedded in the OCSP response to build the trust chain In-Reply-To: <20150320120934.GA5348@kronk.local> References: <20150120133114.GA13866@kronk.local> <20150320120934.GA5348@kronk.local> Message-ID: On mar, gen 20, 2015 at 02:31:14 +0100, Alessandro Ghedini wrote: > Currently the OCSP_basic_verify() function fails with many apparently valid OCSP > responses (e.g. all those sent by Cloudflare servers). Other libraries (GnuTLS, > NSS) have no problem with them. > > Essentially, in crypto/ocsp/ocsp_vfy.c in the OCSP_basic_verify() function, the > X509_STORE_CTX_init() function is called like this: > > init_res = X509_STORE_CTX_init(&ctx, st, signer, bs->certs); > > where ctx is the X509_STORE_CTX to be initialized, st is the trust store passed > by the user, signer is the signer of the OCSP response (which is what needs to > be validated), and bs is the decoded OCSP basic response. > > The problem is the last argument. OpenSSL uses the cert list embedded in the > OCSP response to build the trust chain, but it seems that in some cases this > list is somewhat broken. Other libraries (e.g. GnuTLS), do the verification > differently, without including those bs->certs that OpenSSL uses. > > I attached the patch and a simple test case. You can compile it with: > > $ cc ocsp_test.c -lcrypto -lssl > > To test the problem run: > > $ ./a.out digitalocean.com 443 > OCSP response verification failed > > after the patch: > > $ ./a.out digitalocean.com 443 > OK Months have passed and I haven't received a reply yet (even worse, the recent obfuscation of the OCSP structures in 6ef869d7d0a9d made it impossible to workaround the issue as curl has been doing [0]), so I thought I'd add some more information to hopefully have this issue resolved. The issue affects servers that have an intermediate certificate (so the peer chain is A -> B -> C, with C being the peer cert, B the intermediate cert issuer of C, and A the CA cert issuer of B) when the OCSP response is signed by an additional certificate issued by B (lets call this X), provided by the peer in the "certs" field of the OCSP basic reponse (bs->certs in the OpenSSL code). To put this in drawing: peer chain bs->certs ("certs") A ? B----------? ? ? C X In this case OpenSSL tries to verify that X is trusted, by using the user-provided trust store "st" (OK), and the bs->certs stack (which only includes X itself) *without* including B (that the user is supposed to provide with the "certs" parameter of OCSP_basic_verify()) which actually issued X, thus failing miserably. This is the case for e.g. all CloudFlare sites AFAICT, and possibly many other certificate authorities. Cheers [0] https://github.com/bagder/curl/blob/2b7ac4e/lib/vtls/openssl.c#L1363-L1385 From matt at openssl.org Fri Mar 20 13:19:39 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 20 Mar 2015 13:19:39 +0000 Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD In-Reply-To: <1425395656.3359.68.camel@infradead.org> References: <1424702049.5437.222.camel@infradead.org> <1425370697.3359.47.camel@infradead.org> <54F577BE.3070402@openssl.org> <1425382575.3359.57.camel@infradead.org> <54F5A265.4070902@openssl.org> <1425392889.3033.34.camel@infradead.org> <54F5C885.1050302@openssl.org> <1425395656.3359.68.camel@infradead.org> Message-ID: <550C1E6B.8090608@openssl.org> On 03/03/15 15:14, David Woodhouse wrote: > On Tue, 2015-03-03 at 14:43 +0000, Matt Caswell wrote: >> >> On 03/03/15 14:28, David Woodhouse wrote: >>> On Tue, 2015-03-03 at 12:00 +0000, Matt Caswell wrote: >>>> >>>>> I'll look at adding test cases to exercise the DTLS_BAD_VER support, >>>> to >>>>> try to avoid this kind of thing happening in future. >>>>> >>>> >>>> That would be fantastic to have. >>> >>> I look a quick look at this. Adding DTLSv1 and DTLSv1.2 support to >>> ssl/ssltest.c isn't particularly hard, >> >> If you fancy taking on that task, that would be really useful just in >> itself. > > This works for 'ssltest -dtls1' but not with -bio_pair for some reason. > I got this far before concluding it wasn't going to be a helpful > approach... > I just pushed this patch. Thanks Matt From rt at openssl.org Sat Mar 21 17:39:38 2015 From: rt at openssl.org (Tomas Hoger via RT) Date: Sat, 21 Mar 2015 18:39:38 +0100 Subject: [openssl-dev] [openssl.org #3757] OpenSSL decodes malformed base64 encoded inputs In-Reply-To: <20150320110539.2037a909@redhat.com> References: <20150320110539.2037a909@redhat.com> Message-ID: Hi! Looking at the CVE-2015-0292 fix: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9febee0272 the added (eof > v) check seems somewhat suspicious. While it prevents integer underflow that causes out of bounds memcpy(), it still allows some messing with output via proper number of trailing '=' signs. The code was apparently written under assumption that eof is in the rage of 0 - 2, which are the only valid counts of '=' in proper base64 encoded data. One possible issue is that extraneous '=' will lead to decoded data to contain extraneous trailing '\0's: $ echo T3BlblNTTE9wZW5TU0wK`python -c 'print "="*40'` | openssl enc -d -base64 | hexdump -c 0000000 O p e n S S L O p e n S S L \n \0 0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 000002b However, it can also cause output to be truncated: $ echo T3BlblNTTE9wZW5TU0wK`python -c 'print "="*44'` | openssl enc -d -base64 | hexdump -c 0000000 O p e n 0000004 Decoding should probably reject such malformed inputs. If the expectation is to tolerate malformed inputs with extraneous trailing '='s, it can do something like: if (eof % 4 == 3) { /* error */ } ret+=(v - ((eof/4)*3) - (eof%4)) This should ensure proper number of trailing '\0's are ignored. However, there are other code paths that would need amending, as eof gets reset to the expected 0-2 range in some cases. However, code will also need to check that no '=' appears in the middle of the input. Examples of other malformed inputs that should be rejected: $ echo YQ==YQ==YQ== | openssl enc -d -base64 | hexdump -c 0000000 a \0 \0 a \0 \0 a 0000007 $ echo A=== | openssl enc -d -base64 | hexdump -c 0000000 \0 0000001 -- Tomas Hoger From rt at openssl.org Sat Mar 21 17:41:17 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sat, 21 Mar 2015 18:41:17 +0100 Subject: [openssl-dev] [openssl.org #3758] [PATCH] fix malloc define typo In-Reply-To: <1426929114-27695-1-git-send-email-vapier@gentoo.org> References: <1426929114-27695-1-git-send-email-vapier@gentoo.org> Message-ID: Reported-by: Conrad Kostecki URL: https://bugs.gentoo.org/543828 --- crypto/bio/bss_dgram.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index aef8149..ed275d1 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -1338,7 +1338,7 @@ static int dgram_sctp_read(BIO *b, char *out, int outl) (socklen_t) (sizeof(sctp_assoc_t) + 256 * sizeof(uint8_t)); authchunks = OPENSSL_malloc(optlen); if (!authchunks) { - BIOerr(BIO_F_DGRAM_SCTP_READ, ERR_R_MALLOC_ERROR); + BIOerr(BIO_F_DGRAM_SCTP_READ, ERR_R_MALLOC_FAILURE); return -1; } memset(authchunks, 0, optlen); @@ -1410,7 +1410,7 @@ static int dgram_sctp_write(BIO *b, const char *in, int inl) char *tmp; data->saved_message.bio = b; if(!(tmp = OPENSSL_malloc(inl))) { - BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_ERROR); + BIOerr(BIO_F_DGRAM_SCTP_WRITE, ERR_R_MALLOC_FAILURE); return -1; } if (data->saved_message.data) -- 2.3.3 From rt at openssl.org Sat Mar 21 17:41:30 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sat, 21 Mar 2015 18:41:30 +0100 Subject: [openssl-dev] [openssl.org #3759] [PATCH] crypto: use bigint in x86-64 perl In-Reply-To: <1426935725-11133-1-git-send-email-vapier@gentoo.org> References: <1426935725-11133-1-git-send-email-vapier@gentoo.org> Message-ID: When building on x32 systems where the default type is 32bit, make sure we can transparently represent 64bit integers. Otherwise we end up with build errors like: /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xlate.pl line 201, <> line 890. ... ghash-x86_64.s: Assembler messages: ghash-x86_64.s:890: Error: junk '.15473355479995e+19' after expression We don't enable this globally as there are some cases where we'd get 32bit values interpreted as unsigned when we need them as signed. Reported-by: Bertrand Jacquin URL: https://bugs.gentoo.org/542618 --- crypto/perlasm/x86_64-xlate.pl | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/crypto/perlasm/x86_64-xlate.pl b/crypto/perlasm/x86_64-xlate.pl index aae8288..0bf9774 100755 --- a/crypto/perlasm/x86_64-xlate.pl +++ b/crypto/perlasm/x86_64-xlate.pl @@ -195,6 +195,10 @@ my %globals; sub out { my $self = shift; + # When building on x32 ABIs, the expanded hex value might be too + # big to fit into 32bits. Enable transparent 64bit support here + # so we can safely print it out. + use bigint; if ($gas) { # Solaris /usr/ccs/bin/as can't handle multiplications # in $self->{value} -- 2.3.3 From rt at openssl.org Sat Mar 21 20:06:14 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 21 Mar 2015 21:06:14 +0100 Subject: [openssl-dev] [openssl.org #3749] [PATCH] Fix major bugs in CRYPTO_128_unwrap() In-Reply-To: <20150314022910.1ab02b4a3dc1aaf61d1786161e74fc18.2ee3597842.wbe@email09.secureserver.net> References: <20150314022910.1ab02b4a3dc1aaf61d1786161e74fc18.2ee3597842.wbe@email09.secureserver.net> Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Mar 23 04:29:18 2015 From: rt at openssl.org (Mark.Daniel@wasd.vsm.com.au via RT) Date: Mon, 23 Mar 2015 05:29:18 +0100 Subject: [openssl-dev] [openssl.org #3760] [BUG] Segmentation fault from s3_svr.c ssl3_choose_cipher() In-Reply-To: <14.2.0.218.54642.00af488edd8a5bd8.soymail@slider.vsm.com.au> References: <14.2.0.218.54642.00af488edd8a5bd8.soymail@slider.vsm.com.au> Message-ID: Hi. This issue is not present in 1.0.1k or earlier (my code has worked for years), and is in 1.0.2 and 1.0.2a. I do not have any simple reproducer as it comes from a moderately esoteric environment using asynchronous BIO written for [Open]VMS. The server initiates the SSL listening context using: if (!(SSLversion & SESOLA_SSLV2)) SSLoptions |= SSL_OP_NO_SSLv2; if (!(SSLversion & SESOLA_SSLV3)) SSLoptions |= SSL_OP_NO_SSLv3; if (!(SSLversion & SESOLA_TLSV1)) SSLoptions |= SSL_OP_NO_TLSv1; if (!(SSLversion & SESOLA_TLSV1_1)) SSLoptions |= SSL_OP_NO_TLSv1_1; if (!(SSLversion & SESOLA_TLSV1_2)) SSLoptions |= SSL_OP_NO_TLSv1_2; SslCtx = SSL_CTX_new (SSLv23_method()); (i.e. options-off any non-desired protocol versions) The problem was induced on the command-line: openssl s_client -ssl3 -host -port 443 Trace data from the program shows: |00:53:29.08 SESOLANE 0214 0001 SSL BEGIN| |00:53:29.08 SESOLA 2606 0001 SSL start handshake| |00:53:29.08 SESOLA 2583 0001 SSL SSL_ACCEPT before/accept initialization| |00:53:29.08 SESOLA 2686 0001 SSL READ 11/-1 (outstanding)| |00:53:29.08 SESOLA 2593 0001 SSL SSL_ACCEPT error/blocking in SSLv2/v3 read client hello A| |00:53:29.08 SESOLA 2686 0001 SSL READ 11/11 (complete)| |00:53:29.08 SESOLA 2700 0001 SSL CTRL 6 0| |00:53:29.08 SESOLA 2686 0001 SSL READ 147/-1 (outstanding)| |00:53:29.08 SESOLA 2593 0001 SSL SSL_ACCEPT error/blocking in SSLv3 read client hello B| |00:53:29.08 SESOLA 2593 0001 SSL SSL_ACCEPT error/blocking in SSLv3 read client hello B| |00:53:29.09 SESOLA 2686 0001 SSL READ 147/147 (complete)| |00:53:29.09 SESOLA 2691 0001 SSL WRITE 7/-1 (outstanding)| |00:53:29.09 SESOLA 2602 0001 SSL SSL_BEFORE write SSLv3 read client hello C| |00:53:29.09 SESOLA 2593 0001 SSL SSL_ACCEPT error/blocking in SSLv3 read client hello C| and then without my workaround segmentation faults, apparently when the NULL session is dereferenced by ssl3_choose_cipher(). My workaround in s3_svr.c looks like: #define MGD_150321 #ifdef MGD_150321 /*** OpenSSL v1.0.2 and v1.0.2a ACCVIOs in s3_srvr.c ssl3_get_client_hello() at ssl3_choose_cipher() when SSLv3 is not enabled with an SSLv3 client! OpenSSL v1.0.1k s3_srvr.c ssl3_get_client_hello() is fine!! This seems to be a NULL session being dereferenced here! ***/ if (s->session == NULL) c = NULL; else #endif /* MGD_150321 */ c = ssl3_choose_cipher(s, s->session->ciphers, SSL_get_ciphers(s)); which avoids the issue but the resulting trace data suggests not elegantly. The underlying issue must be upstream in the processing. Trust this is of some assistance. From rt at openssl.org Mon Mar 23 04:30:30 2015 From: rt at openssl.org (Thomas Tanner via RT) Date: Mon, 23 Mar 2015 05:30:30 +0100 Subject: [openssl-dev] [openssl.org #3762] bug report: x509 -x509toreq does not copy extensions In-Reply-To: <550F269A.5000204@gmx.net> References: <550F269A.5000204@gmx.net> Message-ID: converting a certificate to a certificate request openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem does not copy the extensions to the request OpenSSL 1.0.2a From rt at openssl.org Mon Mar 23 04:30:15 2015 From: rt at openssl.org (Thomas Tanner via RT) Date: Mon, 23 Mar 2015 05:30:15 +0100 Subject: [openssl-dev] [openssl.org #3761] bug report: x509 -certopt ca_default documentation mismatch In-Reply-To: <550F25D7.1010505@gmx.net> References: <550F25D7.1010505@gmx.net> Message-ID: According to the manpage "-textopt ca_default" suppresses the signature: ca_default the value used by the ca utility, equivalent to no_issuer, no_pubkey, no_header, no_version, no_sigdump and no_signame. but "openssl x509 -noout -in file.pem -text -certopt ca_default" shows both Signature Algorithm and the dump. Only if no_signame,no_sigdump are added, they are suppressed. OpenSSL 1.0.2a From michel.sales at free.fr Mon Mar 23 11:09:43 2015 From: michel.sales at free.fr (Michel) Date: Mon, 23 Mar 2015 12:09:43 +0100 Subject: [openssl-dev] SRP memory leaks and more leaks Message-ID: <002301d06559$ddff5fa0$99fe1ee0$@sales@free.fr> Hi, Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c . 1) The first kind was due to bad use of OpenSSL 'stack' code and cumbersome / confusing names of structure / functions. In this case, leaks occurs when loading a verifier file containing 'index' lines. Two structures are used : SRP_gN and SRP_gN_cache. And unfortunatly, the SRP_gN_free function free a SRP_gN_cache structure. The SRP_VBASE_free() function, line 276, should call : sk_SRP_gN_cache_pop_free(vb->gN_cache, SRP_gN_cache_free); instead of : sk_SRP_gN_cache_free(vb->gN_cache); And consequently the SRP_gN_cache_free() function, lines 305-312, has to move before SRP_VBASE_free() The attached patch solve this kind of leaks. 2) When simulating a 'fake user' as per RFC 5054, ? '2.5.1.3. Unknown SRP User Name', the SRP_VBASE_get_by_user() function returns a newly allocated SRP_user_pwd structure whose adress is not kept anywhere else. So, the caller should free it later, but from outside the function, there is no way to distinguish between 'fake users' and real ones which are managed and freed throught the use of the SRP_VBASE structure / functions. I am afraid there is no other solution than changing the SRP_VBASE_get_by_user() function prototype. It is better I do not share here my opinion about the comments below : /* need to check whether there are memory leaks */, s_server.c line 433 or : /* there may be still some leaks to fix, */ srp_vfy.c line 449 >:( Hope this will save time to other users, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: srp_vfy.patch Type: application/octet-stream Size: 3157 bytes Desc: not available URL: From michel.sales at free.fr Mon Mar 23 11:11:07 2015 From: michel.sales at free.fr (Michel) Date: Mon, 23 Mar 2015 12:11:07 +0100 Subject: [openssl-dev] suggested patch for no-engine option Message-ID: <002901d0655a$0fe5e110$2fb1a330$@sales@free.fr> Hi, When configured with the no-engine option, compilation fails (OpenSSL 1.0.2a, Windows 7 64). This patch moves up some #include directives (as suggested by other people on the InterNet). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: engines.patch Type: application/octet-stream Size: 14545 bytes Desc: not available URL: From rt at openssl.org Mon Mar 23 11:11:07 2015 From: rt at openssl.org (Thomas Tanner via RT) Date: Mon, 23 Mar 2015 12:11:07 +0100 Subject: [openssl-dev] [openssl.org #3763] bug report: pkeyutl option order In-Reply-To: <550FDA85.6090300@gmx.net> References: <550FDA85.6090300@gmx.net> Message-ID: pkeyutl requires a certain order of the key options to work: -pkeyopt must follow the -inkey option -passin must precede the -inkey option This is not documented and confusing. It would be better if the order was ignored. OpenSSL 1.0.2a From michel.sales at free.fr Mon Mar 23 11:11:50 2015 From: michel.sales at free.fr (Michel) Date: Mon, 23 Mar 2015 12:11:50 +0100 Subject: [openssl-dev] suggested patch for t1_ext.c, no-nextproto arg Message-ID: <003501d0655a$29484ad0$7bd8e070$@sales@free.fr> Hi, When configured with the no-nextproto option, compilation fails (OpenSSL 1.0.2a, Windows 7 64). This patch just add a #ifdef directive around targeted line. Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: no-nextproto.patch Type: application/octet-stream Size: 531 bytes Desc: not available URL: From tgyonjyan at bloomberg.net Mon Mar 23 15:46:00 2015 From: tgyonjyan at bloomberg.net (Tigran Gyonjyan (BLOOMBERG/ 731 LEX)) Date: Mon, 23 Mar 2015 15:46:00 -0000 Subject: [openssl-dev] =?utf-8?q?Using_openssl_with_a_remote_private_key?= Message-ID: <5510353801E20700003906CC_0_97438@p057> This is a very valid security concern. The reason the private key shouldn't be on the same machine is that the Web server is installed on the client's machine (for various reasons). This means for security reasons the private key shouldn't be located on the client's (untrusted) machine. So one of the ways to enable ssl connection betwen client code and the local web server is to delegate decrypting of the pre-master key to another (owned and thus trusted) server which actually has the private key. So no smartcards are involved, just a problem caused by machine topology. There might be other solutions for this, still researching... From: openssl-dev at openssl.org At: Mar 17 2015 20:02:38 To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Using openssl with a remote private key On 3/17/2015 10:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote: > Hi there! > > Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore > the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed. Introducing another machine, will introduce addition trust issues, as to why the "server" trusts the "other machine" holding the private key, how does the "other machine" trust the "server" and trust the network connections between the two machines. If not done correctly, the "other machine" could be attacked to decrypt requests from a man-in-the-middle pretending to be the "server". (The certificate contains the public key, the private key is not part of the certificate.) > > I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version. > In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine. As pointed out in other replies, PKCS#11 and openssl_engine could be used. If used with a smart card, the smart card could be on the "other machine". The PKCS#11 implementation could be using PCSC to talk to the smart card, which can be used across a network. For example remote desktop, rdesktop or RDP can transport the smart card APDUs across the network. This is usually used by a user with a smart card at a remote terminal, and the trust model is different then in your case of a "server" to the "other machine". > > Let me know if there is a better solution for this problem. > > Cheers, > Tigran > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Mar 23 20:47:44 2015 From: rt at openssl.org (Fernando Mognon via RT) Date: Mon, 23 Mar 2015 21:47:44 +0100 Subject: [openssl-dev] [openssl.org #3764] [BUG REPORT] Missing message Alert on ssl23_get_server_hello negotiation failure In-Reply-To: References: Message-ID: Hi, openSSL version: 1.0.1l openSUSE-release 13.1-1.10 This problem only show for s23_clnt.c module. The flow is correct for s3_clnt.c module. If the TLS client starts a client hello, with tls1.1 for example and the server only supports tls1.0, if the TLS client receives a protocol version from the server that it does not support it should break the TLS negotiation by sending a protocol_version Alert to the TLS Server Although there is debug SSLerr the message ALERT is not sent. SSL_connect:error in SSLv2/v3 read server hello A 3074041532:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:740: This behavior is described in RFC5246 Backward Compatibility E.1 . Compatibility with TLS 1.0/1.1 and SSL 3.0 Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server. A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection. A Possible fix would be just call function ssl3_send_alert() like it is done in the function ssl3_get_server_hello(), s3clnt.c, which works fine. I need to use the module s23_xxx.c because the application (Kamailio) needs to be configured to support 1.0 and higher version (TLS_USE_TLSv1_PLUS) Att. Fernando Mognon -------------- next part -------------- A non-text attachment was scrubbed... Name: BadCase_ClientRejectsTLSv10_No_ALERT.pcap Type: application/octet-stream Size: 3253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GoodCase_ClientRejectsTLSv10_withAlertProtocolVersion.pcap Type: application/octet-stream Size: 4330 bytes Desc: not available URL: From rt at openssl.org Mon Mar 23 20:48:21 2015 From: rt at openssl.org (Julien Kauffmann via RT) Date: Mon, 23 Mar 2015 21:48:21 +0100 Subject: [openssl-dev] [openssl.org #3765] [BUG] Crash in PEM write functions with generated EC_KEY on Windows In-Reply-To: References: Message-ID: I'm facing a crash (heap corruption) on Windows ever since I updated OpenSSL to the version 1.0.2a. The same seems to happen in 1.0.1m. I'm using Visual Studio 2013. I'm building the x64-static variant of OpenSSL like so: perl Configure VC-WIN64A no-asm --prefix=F:\git\openssl_crash\third-party\install\x64 ms\do_win64a nmake -f ms\nt.mak nmake -f ms\nt.mak install My sample code goes as follow: ----- main.cpp ----- #include #include #include #include #include #include int main() { OpenSSL_add_all_algorithms(); ERR_load_crypto_strings(); EVP_PKEY_CTX* parameters_context = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, NULL); if (EVP_PKEY_paramgen_init(parameters_context) != 1) { return 1; } if (EVP_PKEY_CTX_set_ec_paramgen_curve_nid(parameters_context, NID_sect571k1) != 1) { return 1; } EVP_PKEY* cparameters = nullptr; if (EVP_PKEY_paramgen(parameters_context, &cparameters) != 1) { return 1; } EVP_PKEY_CTX* key_generation_context = EVP_PKEY_CTX_new(cparameters, NULL); if (!key_generation_context) { return 1; } if (EVP_PKEY_keygen_init(key_generation_context) != 1) { return 1; } EVP_PKEY* private_key = nullptr; if (EVP_PKEY_keygen(key_generation_context, &private_key) != 1) { return 1; } BIO* bio = BIO_new(BIO_s_mem()); PEM_write_bio_PUBKEY(bio, private_key); // <== CRASH HERE. ERR_free_strings(); EVP_cleanup(); ::CRYPTO_cleanup_all_ex_data(); return EXIT_SUCCESS; } ----- end of main.cpp ----- Which is compiled with: cl /Fomain.obj /c main.cpp /TP /EHsc /MT /nologo /Ithird-party\install\x64\include link /nologo /OUT:crash.exe /LIBPATH:third-party\install\x64\lib libeay32.lib user32.lib gdi32.lib advapi32.lib main.obj I tried this sample code with all of the /MD, /MT, /MDd, /MTd variants without success. The code seems to run fine on Linux and OSX (using gcc & clang). Here is the stacktrace I'm getting when the heap corruption occurs: > openssl_crash.exe!free(void * pBlock) Line 51 C openssl_crash.exe!CRYPTO_free(void * str) Line 440 C openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const ASN1_ITEM_st * it, int combine) Line 172 C openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const ASN1_ITEM_st * it, int combine) Line 160 C openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const ASN1_ITEM_st * it, int combine) Line 160 C openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const ASN1_ITEM_st * it, int combine) Line 160 C openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const ASN1_ITEM_st * it, int combine) Line 130 C openssl_crash.exe!ASN1_item_free(ASN1_VALUE_st * val, const ASN1_ITEM_st * it) Line 73 C openssl_crash.exe!i2d_ECPKParameters(const ec_group_st * a, unsigned char * * out) Line 1010 C openssl_crash.exe!eckey_param2type(int * pptype, void * * ppval, ec_key_st * ec_key) Line 93 C openssl_crash.exe!eckey_pub_encode(X509_pubkey_st * pk, const evp_pkey_st * pkey) Line 113 C openssl_crash.exe!X509_PUBKEY_set(X509_pubkey_st * * x, evp_pkey_st * pkey) Line 101 C openssl_crash.exe!i2d_PUBKEY(evp_pkey_st * a, unsigned char * * pp) Line 211 C openssl_crash.exe!PEM_ASN1_write_bio(int (void *, unsigned char * *) * i2d, const char * name, bio_st * bp, void * x, const evp_cipher_st * enc, unsigned char * kstr, int klen, int (char *, int, int, void *) * callback, void * u) Line 357 C openssl_crash.exe!PEM_write_bio_PUBKEY(bio_st * bp, evp_pkey_st * x) Line 427 C openssl_crash.exe!main() Line 40 C++ Is there anything wrong regarding my sample code ? If not, can anyone else reproduce the problem ? Is it a bug in OpenSSL ? Regards, -- Julien. From foleyj at cisco.com Tue Mar 24 00:20:55 2015 From: foleyj at cisco.com (John Foley (foleyj)) Date: Tue, 24 Mar 2015 00:20:55 +0000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <20150319154902.GA31792@openssl.org> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com>, <20150319154902.GA31792@openssl.org> Message-ID: <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> We've found a way to recreate the scenario using s_client/s_server. We're using the -no_ticket option on the server. Therefore, the ServerHello doesn't contain the session ticket extension. It also doesn't send the NewSessionTicket message. To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption. This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message. The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state. As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code: if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { SSL_CIPHER *pref_cipher = NULL; s->session->master_key_length = sizeof(s->session->master_key); if (s->tls_session_secret_cb(s, s->session->master_key, &s->session->master_key_length, NULL, &pref_cipher, s->tls_session_secret_cb_arg)) { s->session->cipher = pref_cipher ? pref_cipher : ssl_get_cipher_by_char(s, p + j); s->hit = 1; } } Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used? ________________________________________ From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Dr. Stephen Henson [steve at openssl.org] Sent: Thursday, March 19, 2015 11:49 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST On Thu, Mar 19, 2015, Erik Tkal wrote: > > If I do not send a sessionID in the clientHello but do send a valid > sessionTicket extension, the server goes straight to changeCipherSpec and > the client generates an UnexpectedMessage alert. > Does the server send back an empty session ticket extension? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From emilia at openssl.org Tue Mar 24 01:17:59 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 24 Mar 2015 02:17:59 +0100 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> Message-ID: On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) wrote: > We've found a way to recreate the scenario using s_client/s_server. We're > using the -no_ticket option on the server. Therefore, the ServerHello > doesn't contain the session ticket extension. It also doesn't send the > NewSessionTicket message. > > To summarize the problem, when the client side is using > SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, > then the logic in ssl3_get_server_hello() assumes the server is doing > session resumption. This puts the client-side state machine into the > SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not > do resumption via the -no_ticket option, the server continues with a normal > handshake by sending the Certificate message. The client aborts the > handshake when it receives the Certificate message while in the > SSL3_ST_CR_FINISHED_A state. > > > As Erik identified earlier in the thread, the cause of this appears to be > the addition of setting s->hit in the following code: > > if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { > SSL_CIPHER *pref_cipher = NULL; > s->session->master_key_length = sizeof(s->session->master_key); > if (s->tls_session_secret_cb(s, s->session->master_key, > &s->session->master_key_length, > NULL, &pref_cipher, > s->tls_session_secret_cb_arg)) { > s->session->cipher = pref_cipher ? > pref_cipher : ssl_get_cipher_by_char(s, p + j); > s->hit = 1; > } > } > > Why does the client-side now assume the server is doing session resumption > simply because the session secret callback facility is being used? > Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch. While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this #ifndef OPENSSL_NO_TLSEXT /* check if we want to resume the session based on external pre-shared secret */ if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { SSL_CIPHER *pref_cipher=NULL; s->session->master_key_length=sizeof(s->session->master_key); if (s->tls_session_secret_cb(s, s->session->master_key, &s->session->master_key_length, NULL, &pref_cipher, s->tls_session_secret_cb_arg)) { s->session->cipher = pref_cipher ? pref_cipher : ssl_get_cipher_by_char(s, p+j); } } #endif /* OPENSSL_NO_TLSEXT */ This is surely wrong as it's just ignoring the failure? Thanks, Emilia ________________________________________ > From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Dr. > Stephen Henson [steve at openssl.org] > Sent: Thursday, March 19, 2015 11:49 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared > secret seem to break EAP-FAST > > On Thu, Mar 19, 2015, Erik Tkal wrote: > > > > > If I do not send a sessionID in the clientHello but do send a valid > > sessionTicket extension, the server goes straight to changeCipherSpec and > > the client generates an UnexpectedMessage alert. > > > > Does the server send back an empty session ticket extension? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > 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 leonb at parsec.co.za Tue Mar 24 09:07:28 2015 From: leonb at parsec.co.za (Leon Brits) Date: Tue, 24 Mar 2015 11:07:28 +0200 Subject: [openssl-dev] Bitlocker Message-ID: <8F01EA4FAE71884AAE2CB4A9DEE158D001A414AD4E3C@exchange.PARSEC.local> Hi all, I have a PC which acts like a USB smartcard on which I have OpenSSLv1.0.1e to simulate the smartcards crypto operations. I use it to sign/verify/encrypt/decrypt etc. and had no problem using Windows to login and sign/verify emails for instance. Recently I tried bitlocker and got the following error: Function call 'EVP_PKEY_decrypt()' failed! (error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02). The part in brackets was returned by OpenSSL. Can anybody shed some light on what possibly I can be doing wrong with regards to the padding. I do implement PKCS1 and PSS. I've written our CSP/KSP for this PC and as I said it works fine with other Windows applications. Thanks for your time LJB -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.yousar at informatik.hu-berlin.de Tue Mar 24 11:10:22 2015 From: a.yousar at informatik.hu-berlin.de (Annie Yousar) Date: Tue, 24 Mar 2015 12:10:22 +0100 (CET) Subject: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken Message-ID: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> Dear all, this should not have happened: $ for i in `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ]; then echo; cat key.pem;else echo -n "."; fi; done .................................................................................... -----BEGIN EC PRIVATE KEY----- MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8 fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY -----END EC PRIVATE KEY----- ............................................................................ ... Conforming to the standards the EC private key has always a fixed length, defined by the group order. Regards, Ann. From dirkx at webweaving.org Tue Mar 24 11:07:26 2015 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 24 Mar 2015 12:07:26 +0100 Subject: [openssl-dev] Bitlocker In-Reply-To: <8F01EA4FAE71884AAE2CB4A9DEE158D001A414AD4E3C@exchange.PARSEC.local> References: <8F01EA4FAE71884AAE2CB4A9DEE158D001A414AD4E3C@exchange.PARSEC.local> Message-ID: > On 24 Mar 2015, at 10:07, Leon Brits wrote: > > Hi all, > > I have a PC which acts like a USB smartcard on which I have OpenSSLv1.0.1e to simulate the smartcards crypto operations. > I use it to sign/verify/encrypt/decrypt etc. and had no problem using Windows to login and sign/verify emails for instance. Recently I tried bitlocker and got the following error: > > Function call 'EVP_PKEY_decrypt()' failed! (error:0407106B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02). > > The part in brackets was returned by OpenSSL. > > Can anybody shed some light on what possibly I can be doing wrong with regards to the padding. I do implement PKCS1 and PSS. I?ve written our CSP/KSP for this PC and as I said it works fine with other Windows applications. > Not sure if this helps you - but I?ve seen the same issue with Windows SOAP requests which where signed with help from the TPM chip; and in that case it truly turned out that the padding was non standard (type 09). HOWEVER - the error message has often misled me - as it is *also* triggered by a the length being wrong (flen != num-1(for the type 02 prefix)). So garbled length data can also trigger it (the note in the source that the flen is only used in no-padding mode may be a bit confusing/misleading). Dw. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Mar 24 11:40:01 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 24 Mar 2015 12:40:01 +0100 Subject: [openssl-dev] [openssl.org #3758] [PATCH] fix malloc define typo In-Reply-To: <1426929114-27695-1-git-send-email-vapier@gentoo.org> References: <1426929114-27695-1-git-send-email-vapier@gentoo.org> Message-ID: Patch applied. Many thanks. Matt From rt at openssl.org Tue Mar 24 12:19:31 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 24 Mar 2015 13:19:31 +0100 Subject: [openssl-dev] [openssl.org #3668] [PATCH] Don't use the cert list embedded in the OCSP response to build the trust chain In-Reply-To: References: <20150120133114.GA13866@kronk.local> <20150320120934.GA5348@kronk.local> Message-ID: On Fri Mar 20 13:20:07 2015, alessandro at ghedini.me wrote: > > Months have passed and I haven't received a reply yet (even worse, the > recent > obfuscation of the OCSP structures in 6ef869d7d0a9d made it impossible > to > workaround the issue as curl has been doing [0]), so I thought I'd add > some more > information to hopefully have this issue resolved. > Sorry for the delay in responding. Unfortunately I can't apply your patch because it would break any applications which rely on the existing behaviour. I have just committed a change which will concatenate the supplied certificates with any internal ones. This should address your problem (the test program now works) and retain compatibility. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From foleyj at cisco.com Tue Mar 24 12:50:19 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 24 Mar 2015 08:50:19 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> Message-ID: <55115D8B.6020004@cisco.com> A non-text attachment was scrubbed... Name: not available Type: application/pgp-encrypted Size: 11 bytes Desc: PGP/MIME version identification URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: encrypted.asc Type: application/octet-stream Size: 5808 bytes Desc: OpenPGP encrypted message URL: From foleyj at cisco.com Tue Mar 24 13:01:10 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 24 Mar 2015 09:01:10 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> Message-ID: <55116016.8010105@cisco.com> Trying again w/o PGP... :-) Thanks for taking a look at this problem. Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match. It would be good to trigger an internal error to aid with troubleshooting. Maybe something like: SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); goto err; It's debatable whether the alert needs to be sent to the server. Since this is an internal error, it should be safe to send the alert. Therefore, maybe you would actually want to do something like: SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); al = SSL_AD_INTERNAL_ERROR; goto f_err; On 03/23/2015 09:17 PM, Emilia K?sper wrote: > > > On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) > wrote: > > We've found a way to recreate the scenario using > s_client/s_server. We're using the -no_ticket option on the > server. Therefore, the ServerHello doesn't contain the session > ticket extension. It also doesn't send the NewSessionTicket message. > > To summarize the problem, when the client side is using > SSL_set_session_secret_cb() and including a valid ticket in the > ClintHello, then the logic in ssl3_get_server_hello() assumes the > server is doing session resumption. This puts the client-side > state machine into the SSL3_ST_CR_FINISHED_A. However, since the > server side is configured to not do resumption via the -no_ticket > option, the server continues with a normal handshake by sending > the Certificate message. The client aborts the handshake when it > receives the Certificate message while in the > SSL3_ST_CR_FINISHED_A state. > > > As Erik identified earlier in the thread, the cause of this > appears to be the addition of setting s->hit in the following code: > > if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { > SSL_CIPHER *pref_cipher = NULL; > s->session->master_key_length = > sizeof(s->session->master_key); > if (s->tls_session_secret_cb(s, s->session->master_key, > &s->session->master_key_length, > NULL, &pref_cipher, > s->tls_session_secret_cb_arg)) { > s->session->cipher = pref_cipher ? > pref_cipher : ssl_get_cipher_by_char(s, p + j); > s->hit = 1; > } > } > > Why does the client-side now assume the server is doing session > resumption simply because the session secret callback facility is > being used? > > > Because a developer (me) introduced a bug. With OpenSSL client > behaviour, peeking ahead is only required for EAP-FAST. I got rid of > the peeking while tightening up the ChangeCipherSpec handling and in > the process, got it wrong for EAP-FAST. Anyway, apologies, I see the > problem and am working on a patch. > > While we're at it, you may be able to help me with the following > question: how should the client handle callback failure? The old code > (pre my refactoring which introduced the bug) did this > > #ifndef OPENSSL_NO_TLSEXT > /* check if we want to resume the session based on external pre-shared secret */ > if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) > { > SSL_CIPHER *pref_cipher=NULL; > s->session->master_key_length=sizeof(s->session->master_key); > if (s->tls_session_secret_cb(s, s->session->master_key, > &s->session->master_key_length, > NULL, &pref_cipher, > s->tls_session_secret_cb_arg)) > { > s->session->cipher = pref_cipher ? > pref_cipher : ssl_get_cipher_by_char(s, p+j); > } > } > #endif /* OPENSSL_NO_TLSEXT */ > This is surely wrong as it's just ignoring the failure? > Thanks, > Emilia > > ________________________________________ > From: openssl-dev [openssl-dev-bounces at openssl.org > ] on behalf of Dr. Stephen > Henson [steve at openssl.org ] > Sent: Thursday, March 19, 2015 11:49 AM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] s3_clnt.c changes regarding external > pre-shared secret seem to break EAP-FAST > > On Thu, Mar 19, 2015, Erik Tkal wrote: > > > > > If I do not send a sessionID in the clientHello but do send a valid > > sessionTicket extension, the server goes straight to > changeCipherSpec and > > the client generates an UnexpectedMessage alert. > > > > Does the server send back an empty session ticket extension? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > 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 darovskikh.andrei at gmail.com Tue Mar 24 14:47:57 2015 From: darovskikh.andrei at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCU0LDRgNC+0LLRgdC60LjRhQ==?=) Date: Tue, 24 Mar 2015 17:47:57 +0300 Subject: [openssl-dev] Using TLSv1.2 Message-ID: I use the openssl library in the project and use client certificate verification. When using protocol TLSv1.2 I have a problem with data encryption, using the private key of the client certificate. This is due to the fact that the certificate validation server selected encryption algorithm that is not supported by the crypt used to encrypt the signature on the client certificate (failure in method capi_rsa_sign of e_capi.c file). Now I have corrected the behavior as follows: - the method ssl3_send_client_certificate after selecting a client certificate makes cleaning pkeys [i].digest - the method ssl_set_cert if pkeys [i] .digest not specified, specify it. After that I worked with an application protocol TLSv1.2 Is this correct or am I wrong to fix the library using openssl? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Index: s3_clnt.c =================================================================== --- s3_clnt.c (revision 365595) +++ s3_clnt.c (working copy) @@ -3276,6 +3276,13 @@ } s->rwstate = SSL_NOTHING; if ((i == 1) && (pkey != NULL) && (x509 != NULL)) { + if (SSL_USE_SIGALGS(s)) { + /* Clear certificate digests and validity flags */ + for (i = 0; i < SSL_PKEY_NUM; i++) { + s->cert->pkeys[i].digest = NULL; + s->cert->pkeys[i].valid_flags = 0; + } + } s->state = SSL3_ST_CW_CERT_B; if (!SSL_use_certificate(s, x509) || !SSL_use_PrivateKey(s, pkey)) i = 0; -------------- next part -------------- Index: ssl_rsa.c =================================================================== --- ssl_rsa.c (revision 365595) +++ ssl_rsa.c (working copy) @@ -222,6 +222,7 @@ c->key = &(c->pkeys[i]); c->valid = 0; + return (1); } @@ -430,6 +431,15 @@ c->pkeys[i].x509 = x; c->key = &(c->pkeys[i]); + // set digest for certificate if it no set earlier + if (c->pkeys[i].digest == NULL) { + X509_ALGOR* alg = x->cert_info->signature; + if (alg == NULL) + c->pkeys[i].digest = EVP_sha1(); + else + c->pkeys[i].digest = EVP_get_digestbyobj(alg->algorithm); + } + c->valid = 0; return (1); } From deengert at gmail.com Tue Mar 24 18:42:48 2015 From: deengert at gmail.com (Douglas E Engert) Date: Tue, 24 Mar 2015 13:42:48 -0500 Subject: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken In-Reply-To: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> References: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> Message-ID: <5511B028.9040005@gmail.com> On 3/24/2015 6:10 AM, Annie Yousar wrote: > Dear all, > this should not have happened: The private key may have leading zero bytes, and the size of the BIGNUM is used for the length of the octetstring rather then the field_len. The length of the BIGNUM does not include any leading zeros. Try the attached diff. > > $ for i in `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name > prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ]; > then echo; cat key.pem;else echo -n "."; fi; done > .................................................................................... > -----BEGIN EC PRIVATE KEY----- > MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D > AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8 > fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY > -----END EC PRIVATE KEY----- > ............................................................................ > ... > > Conforming to the standards the EC private key has always a fixed length, > defined by the group order. > > Regards, > Ann. > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert -------------- next part -------------- A non-text attachment was scrubbed... Name: ecasn1.diff Type: text/x-patch Size: 1545 bytes Desc: not available URL: From susumu.sai_2011 at yahoo.com Tue Mar 24 19:33:03 2015 From: susumu.sai_2011 at yahoo.com (Susumu Sai) Date: Tue, 24 Mar 2015 19:33:03 +0000 (UTC) Subject: [openssl-dev] ASN1_UTCTIME_cmp_time_t behavior changed from 0.9.8 to 1.0.2 ? Message-ID: <162466733.484231.1427225583520.JavaMail.yahoo@mail.yahoo.com> ??? ??? time_t t; ??? ??? time(&t); ??? ??? ASN1_TIME *tmptm = ASN1_TIME_new(); ??? ??? X509_gmtime_adj(tmptm, 0); ??? ??? // ? With 0.9.8, the return value ret = 1 ??? ??? // ? With 1.0.2, the return value ret = -1 ??? ??? int ret = ASN1_UTCTIME_cmp_time_t(tmptm, t); 0.9.8 and 1.0.2 return different values. Is this as expected? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Mar 24 19:55:28 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 24 Mar 2015 19:55:28 +0000 Subject: [openssl-dev] ASN1_UTCTIME_cmp_time_t behavior changed from 0.9.8 to 1.0.2 ? In-Reply-To: <162466733.484231.1427225583520.JavaMail.yahoo@mail.yahoo.com> References: <162466733.484231.1427225583520.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150324195528.GA31132@openssl.org> On Tue, Mar 24, 2015, Susumu Sai wrote: > ??? ??? time_t t; > ??? ??? time(&t); > > ??? ??? ASN1_TIME *tmptm = ASN1_TIME_new(); > ??? ??? X509_gmtime_adj(tmptm, 0); > > ??? ??? // ? With 0.9.8, the return value ret = 1 > ??? ??? // ? With 1.0.2, the return value ret = -1 > ??? ??? int ret = ASN1_UTCTIME_cmp_time_t(tmptm, t); > > 0.9.8 and 1.0.2 return different values. Is this as expected? This is a bug in 1.0.2 which is fixed in 1.0.2a. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From quanah at zimbra.com Tue Mar 24 20:14:26 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Tue, 24 Mar 2015 13:14:26 -0700 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> Message-ID: --On Tuesday, March 03, 2015 3:15 PM -0600 "Short, Todd" wrote: > The previous patch file had two bugs due to a swapped argument and the > formatting changes (missing braces). > > > The attached is an updated patch. Why did you open a new RT when already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Tue Mar 24 20:20:06 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Tue, 24 Mar 2015 21:20:06 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> Message-ID: --On Tuesday, March 03, 2015 3:15 PM -0600 "Short, Todd" wrote: > The previous patch file had two bugs due to a swapped argument and the > formatting changes (missing braces). > > > The attached is an updated patch. Why did you open a new RT when already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From tshort at akamai.com Tue Mar 24 20:29:38 2015 From: tshort at akamai.com (Short, Todd) Date: Tue, 24 Mar 2015 20:29:38 +0000 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> Message-ID: <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> I was unaware of 2501. But that?s fine by me? however, why hasn?t 2051 been applied to the code? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Mar 24, 2015, at 4:14 PM, Quanah Gibson-Mount > wrote: --On Tuesday, March 03, 2015 3:15 PM -0600 "Short, Todd" > wrote: The previous patch file had two bugs due to a swapped argument and the formatting changes (missing braces). The attached is an updated patch. Why did you open a new RT when already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Mar 24 20:30:59 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 24 Mar 2015 21:30:59 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> Message-ID: I was unaware of 2501. But that?s fine by me? however, why hasn?t 2051 been applied to the code? -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On Mar 24, 2015, at 4:14 PM, Quanah Gibson-Mount > wrote: --On Tuesday, March 03, 2015 3:15 PM -0600 "Short, Todd" > wrote: The previous patch file had two bugs due to a swapped argument and the formatting changes (missing braces). The attached is an updated patch. Why did you open a new RT when already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From quanah at zimbra.com Tue Mar 24 20:54:50 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Tue, 24 Mar 2015 13:54:50 -0700 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> Message-ID: <9A149722BCF9B8B527FAEEAD@[192.168.1.9]> --On Tuesday, March 24, 2015 9:29 PM +0000 "Short, Todd" wrote: > I was unaware of 2501. But that's fine by me? however, why hasn't > 2051 been applied to the code? People have been asking this question for years. https://lwn.net/Articles/486369/ Here's an even *older* RT from 2006: There's never been any sort of real substantive answer as to why getting IPv6 support in has taken almost a decade, when people have constantly supplied patches for it. Supposedly it was going to go into 1.0.2. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Tue Mar 24 20:55:22 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Tue, 24 Mar 2015 21:55:22 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <9A149722BCF9B8B527FAEEAD@[192.168.1.9]> References: <56F250FD-5F1D-43B7-9580-02EEBA60FFE7@akamai.com> <4D82F993-B28D-4B96-995C-710874A218EF@akamai.com> <9A149722BCF9B8B527FAEEAD@[192.168.1.9]> Message-ID: --On Tuesday, March 24, 2015 9:29 PM +0000 "Short, Todd" wrote: > I was unaware of 2501. But that's fine by me? however, why hasn't > 2051 been applied to the code? People have been asking this question for years. https://lwn.net/Articles/486369/ Here's an even *older* RT from 2006: There's never been any sort of real substantive answer as to why getting IPv6 support in has taken almost a decade, when people have constantly supplied patches for it. Supposedly it was going to go into 1.0.2. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Tue Mar 24 21:09:18 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 24 Mar 2015 22:09:18 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> References: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: The short answer is that nobody has come up with comprehensive cross-platform IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4, v6, both -- and make it work on our supported platforms? What should the various BIO API's do? Looking forward to diff's. From kurt at roeckx.be Tue Mar 24 22:01:23 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 24 Mar 2015 23:01:23 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: References: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150324220123.GA6948@roeckx.be> On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: > The short answer is that nobody has come up with comprehensive cross-platform IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4, v6, both -- and make it work on our supported platforms? What should the various BIO API's do? Please note that I actually have a patch that does all that. I also said not to actually submit this patch. Kurt From rt at openssl.org Tue Mar 24 22:01:41 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 24 Mar 2015 23:01:41 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <20150324220123.GA6948@roeckx.be> References: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> <20150324220123.GA6948@roeckx.be> Message-ID: On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: > The short answer is that nobody has come up with comprehensive cross-platform IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4, v6, both -- and make it work on our supported platforms? What should the various BIO API's do? Please note that I actually have a patch that does all that. I also said not to actually submit this patch. Kurt From rt at openssl.org Wed Mar 25 10:34:04 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 25 Mar 2015 11:34:04 +0100 Subject: [openssl-dev] [openssl.org #3668] [PATCH] Don't use the cert list embedded in the OCSP response to build the trust chain In-Reply-To: <20150325103334.GA1804@kronk.local> References: <20150120133114.GA13866@kronk.local> <20150320120934.GA5348@kronk.local> <20150325103334.GA1804@kronk.local> Message-ID: On Tue, Mar 24, 2015 at 01:19:31PM +0100, Stephen Henson via RT wrote: > On Fri Mar 20 13:20:07 2015, alessandro at ghedini.me wrote: > > > > Months have passed and I haven't received a reply yet (even worse, the > > recent > > obfuscation of the OCSP structures in 6ef869d7d0a9d made it impossible > > to > > workaround the issue as curl has been doing [0]), so I thought I'd add > > some more > > information to hopefully have this issue resolved. > > > > Sorry for the delay in responding. Unfortunately I can't apply your patch > because it would break any applications which rely on the existing behaviour. I > have just committed a change which will concatenate the supplied certificates > with any internal ones. This should address your problem (the test program now > works) and retain compatibility. Thanks, your patch works for me too. I guess this bug can be closed now. Cheers From rt at openssl.org Wed Mar 25 12:22:33 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 25 Mar 2015 13:22:33 +0100 Subject: [openssl-dev] [openssl.org #3668] [PATCH] Don't use the cert list embedded in the OCSP response to build the trust chain In-Reply-To: <20150120133114.GA13866@kronk.local> References: <20150120133114.GA13866@kronk.local> Message-ID: OK thanks for confirming that. Ticket resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From cuoq at trust-in-soft.com Wed Mar 25 15:33:23 2015 From: cuoq at trust-in-soft.com (Pascal Cuoq) Date: Wed, 25 Mar 2015 15:33:23 +0000 Subject: [openssl-dev] [PATCH] Fix (new!) uninitialized-use undefined behaviors Message-ID: <7D8805B6-DA94-4E79-A859-5F13D7861080@trust-in-soft.com> Hello, we have found some uses of uninitialized memory in OpenSSL that, unlike other infamous ones, have not been previously discussed (to the best of our knowledge). These uses of uninitialized memory have characteristics that might make them worth fixing even if other uses of uninitialized memory remain in OpenSSL: - the uninitialized access occurs in a single branch of an if-then-else. An obvious optimization for a compiler is to compile out the condition and the branch containing undefined behavior (UB), leaving only the non-undefined branch. The blog post below shows the widely used GCC C compiler optimizing a program according to this very idea: http://blog.frama-c.com/index.php?post/2013/03/13/indeterminate-undefined - Sometimes the obligation the compiler has to produce code that must work for inputs that do not cause UB will in practice make the UB relatively harmless. Here, the uninitialized access occurs within a macro, BN_with_flags, meaning that a particular use of the macro for inputs that cause UB is NOT protected by separate compilation compiler constraints. - If a compiler has applied the optimization from the aforementioned blog post, or if a future compiler decides to, the resulting flaw will not be visible in functional tests (it will not be a functional bug) but it could still lead to side-channel vulnerabilities in OpenSSL (as far as I understand the surrounding code). - The uninitialized memory access does add any value. It does not make the PRNG work better or anything, it is purely incidental (it occurs in a pattern that could also have been implemented using bit-fields, the difference being that it is legal to assign x.bitfield1 when x.bitfield2 is uninitialized, whereas doing so by hand as in the macro BN_with_flags invokes undefined behavior). With help of an anonymous good soul on the Internet, we have investigated the code produced by the GCC version that was used for the aforementioned blog post 4.4.3. We have found that: * GCC authors must not have found that this agressive optimization was very desirable, since this GCC behavior had disappeared in 4.4.7. * Nevertheless, GCC 4.4.3 was the packaged compiler for a Ubuntu LTS distribution. The behavior in GCC 4.4.3 was not acknowledged as a bug, and it was not fixed in the Ubuntu distribution, and it could be re-introduced in a future GCC version. The behavior may also already exist or be introduced in another C compiler. * GCC 4.4.3 does not appear to optimize the specific source code pattern in OpenSSL the way it optimizes the one in the blog post. Best regards, Pascal Cuoq TrustInSoft Chief Scientist -------------- next part -------------- A non-text attachment was scrubbed... Name: uninitialized.patch Type: application/octet-stream Size: 3718 bytes Desc: uninitialized.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From quanah at zimbra.com Wed Mar 25 16:24:43 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 25 Mar 2015 09:24:43 -0700 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: References: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> <20150324220123.GA6948@roeckx.be> Message-ID: <92029F4681B3FFD1369C6740@[192.168.1.9]> --On Wednesday, March 25, 2015 12:01 AM +0100 Kurt Roeckx via RT wrote: > On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: >> The short answer is that nobody has come up with comprehensive >> cross-platform IPv6 support. Fixing the apps isn't enough; how does a >> server listen on IPv4, v6, both -- and make it work on our supported >> platforms? What should the various BIO API's do? > > Please note that I actually have a patch that does all that. I > also said not to actually submit this patch. Where can one obtain your patch from? When will it be integrated into OpenSSL? Do you have a version of your patch that works with the 1.0.1 series? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Wed Mar 25 16:25:14 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Wed, 25 Mar 2015 17:25:14 +0100 Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server In-Reply-To: <92029F4681B3FFD1369C6740@[192.168.1.9]> References: <707dcf03b89f40108cce3b9de1275866@usma1ex-dag1mb2.msg.corp.akamai.com> <20150324220123.GA6948@roeckx.be> <92029F4681B3FFD1369C6740@[192.168.1.9]> Message-ID: --On Wednesday, March 25, 2015 12:01 AM +0100 Kurt Roeckx via RT wrote: > On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: >> The short answer is that nobody has come up with comprehensive >> cross-platform IPv6 support. Fixing the apps isn't enough; how does a >> server listen on IPv4, v6, both -- and make it work on our supported >> platforms? What should the various BIO API's do? > > Please note that I actually have a patch that does all that. I > also said not to actually submit this patch. Where can one obtain your patch from? When will it be integrated into OpenSSL? Do you have a version of your patch that works with the 1.0.1 series? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From matt.cross at gmail.com Wed Mar 25 18:56:15 2015 From: matt.cross at gmail.com (Matt Cross) Date: Wed, 25 Mar 2015 14:56:15 -0400 Subject: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing Message-ID: I am working with something that does a lot of SHA1's. I am trying to profile my application and generate flame graphs (see http://www.brendangregg.com/flamegraphs.html ), but profiling tools cannot successfully backtrace when the processor is running the optimized SHA1 code on x86_64. This patch adds CFI directives when compiled with a GNU assembler to enable tools that understand DWARF debugging information to backtrace in this circumstance. I don't have a build environment for win64, but I did verify that the perl code does not generate the CFI directives if we are not generating code for the GNU assembler (IE if $cfi is not set). -Matt commit 9522d706fa58679abd0b6f923aad623fad39abe5 Author: Matt Cross Date: Wed Mar 25 14:15:37 2015 -0400 Add CFI directives to the x86_64 SHA1 implementation to allow DWARF aware utilities to backtrace through these routines. diff --git a/crypto/sha/asm/sha1-x86_64.pl b/crypto/sha/asm/sha1-x86_64.pl index 9bb6b49..9fe7b2b 100755 --- a/crypto/sha/asm/sha1-x86_64.pl +++ b/crypto/sha/asm/sha1-x86_64.pl @@ -95,6 +95,7 @@ die "can't locate x86_64-xlate.pl"; if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` =~ /GNU assembler version ([2-9]\.[0-9]+)/) { $avx = ($1>=2.19) + ($1>=2.22); + $cfi = 1 } if (!$avx && $win64 && ($flavour =~ /nasm/ || $ENV{ASM} =~ /nasm/) && @@ -247,6 +248,8 @@ $code.=<<___; .type sha1_block_data_order,\@function,3 .align 16 sha1_block_data_order: +`".cfi_startproc" if $cfi` + mov OPENSSL_ia32cap_P+0(%rip),%r9d mov OPENSSL_ia32cap_P+4(%rip),%r8d mov OPENSSL_ia32cap_P+8(%rip),%r10d @@ -275,17 +278,35 @@ $code.=<<___; .align 16 .Lialu: mov %rsp,%rax +`".cfi_def_cfa_register rax" if $cfi` push %rbx +# The CFA (Cononical Frame Address) is after the pushed return value, so RBX was just stored at CFA - 16: +`".cfi_offset rbx,-16" if $cfi` push %rbp +`".cfi_offset rbp,-24" if $cfi` push %r12 +`".cfi_offset r12,-32" if $cfi` push %r13 +`".cfi_offset r13,-40" if $cfi` push %r14 +`".cfi_offset r14,-48" if $cfi` mov %rdi,$ctx # reassigned argument sub \$`8+16*4`,%rsp mov %rsi,$inp # reassigned argument and \$-64,%rsp mov %rdx,$num # reassigned argument mov %rax,`16*4`(%rsp) +# This adds a "CFA expression" to say that the CFA is calculated by reading the value at RSP+0x40, and adding 8 to it: +# DW_CFA_def_cfa_expression 0x0f : says CFA is calculated by evaluating the following expression +# BLOCK +# length (ULEB128) 0x06 : number of bytes remaining +# DW_OP_breg7 0x40 0x77 0xc0 0x00 : read RSP, add 0x40, and push onto stack - note SLEB128 encoding of 0x40 +# requires 2 bytes to avoid sign extension +# DW_OP_deref 0x06 : read from addr on top of stack +# DW_OP_plus_uconst 0x8 0x23 0x08 : pop top of stack, add 8, push back onto stack + +`".cfi_escape 0x0f,0x06,0x77,0xc0,0x00,0x06,0x23,0x08" if $cfi` + .Lprologue: mov 0($ctx),$A @@ -319,14 +340,22 @@ $code.=<<___; jnz .Lloop mov `16*4`(%rsp),%rsi +`".cfi_def_cfa rsi,8" if $cfi` mov -40(%rsi),%r14 +`".cfi_restore r14" if $cfi` mov -32(%rsi),%r13 +`".cfi_restore r13" if $cfi` mov -24(%rsi),%r12 +`".cfi_restore r12" if $cfi` mov -16(%rsi),%rbp +`".cfi_restore rbp" if $cfi` mov -8(%rsi),%rbx +`".cfi_restore rbx" if $cfi` lea (%rsi),%rsp +`".cfi_def_cfa rsp,8" if $cfi` .Lepilogue: ret +`".cfi_endproc" if $cfi` .size sha1_block_data_order,.-sha1_block_data_order ___ if ($shaext) {{{ @@ -342,6 +371,7 @@ $code.=<<___; .align 32 sha1_block_data_order_shaext: _shaext_shortcut: +`".cfi_startproc" if $cfi` ___ $code.=<<___ if ($win64); lea `-8-4*16`(%rsp),%rsp @@ -440,6 +470,7 @@ $code.=<<___ if ($win64); ___ $code.=<<___; ret +`".cfi_endproc" if $cfi` .size sha1_block_data_order_shaext,.-sha1_block_data_order_shaext ___ }}} @@ -473,12 +504,19 @@ $code.=<<___; .align 16 sha1_block_data_order_ssse3: _ssse3_shortcut: +`".cfi_startproc" if $cfi` mov %rsp,%rax +`".cfi_def_cfa_register rax" if $cfi` push %rbx +`".cfi_offset rbx,-16" if $cfi` push %rbp +`".cfi_offset rbp,-24" if $cfi` push %r12 +`".cfi_offset r12,-32" if $cfi` push %r13 # redundant, done to share Win64 SE handler +`".cfi_offset r13,-40" if $cfi` push %r14 +`".cfi_offset r14,-48" if $cfi` lea `-64-($win64?6*16:0)`(%rsp),%rsp ___ $code.=<<___ if ($win64); @@ -492,6 +530,7 @@ $code.=<<___ if ($win64); ___ $code.=<<___; mov %rax,%r14 # original %rsp +`".cfi_def_cfa_register r14" if $cfi` and \$-64,%rsp mov %rdi,$ctx # reassigned argument mov %rsi,$inp # reassigned argument @@ -907,14 +946,22 @@ $code.=<<___ if ($win64); ___ $code.=<<___; lea (%r14),%rsi +`".cfi_def_cfa_register rsi" if $cfi` mov -40(%rsi),%r14 +`".cfi_restore r14" if $cfi` mov -32(%rsi),%r13 +`".cfi_restore r13" if $cfi` mov -24(%rsi),%r12 +`".cfi_restore r12" if $cfi` mov -16(%rsi),%rbp +`".cfi_restore rbp" if $cfi` mov -8(%rsi),%rbx +`".cfi_restore rbx" if $cfi` lea (%rsi),%rsp +`".cfi_def_cfa_register rsp" if $cfi` .Lepilogue_ssse3: ret +`".cfi_endproc" if $cfi` .size sha1_block_data_order_ssse3,.-sha1_block_data_order_ssse3 ___ @@ -935,12 +982,19 @@ $code.=<<___; .align 16 sha1_block_data_order_avx: _avx_shortcut: +`".cfi_startproc" if $cfi` mov %rsp,%rax +`".cfi_def_cfa_register rax" if $cfi` push %rbx +`".cfi_offset rbx,-16" if $cfi` push %rbp +`".cfi_offset rbp,-24" if $cfi` push %r12 +`".cfi_offset r12,-32" if $cfi` push %r13 # redundant, done to share Win64 SE handler +`".cfi_offset r13,-40" if $cfi` push %r14 +`".cfi_offset r14,-48" if $cfi` lea `-64-($win64?6*16:0)`(%rsp),%rsp vzeroupper ___ @@ -955,6 +1009,7 @@ $code.=<<___ if ($win64); ___ $code.=<<___; mov %rax,%r14 # original %rsp +`".cfi_def_cfa_register r14" if $cfi` and \$-64,%rsp mov %rdi,$ctx # reassigned argument mov %rsi,$inp # reassigned argument @@ -1271,14 +1326,22 @@ $code.=<<___ if ($win64); ___ $code.=<<___; lea (%r14),%rsi +`".cfi_def_cfa_register rsi" if $cfi` mov -40(%rsi),%r14 +`".cfi_restore r14" if $cfi` mov -32(%rsi),%r13 +`".cfi_restore r13" if $cfi` mov -24(%rsi),%r12 +`".cfi_restore r12" if $cfi` mov -16(%rsi),%rbp +`".cfi_restore rbp" if $cfi` mov -8(%rsi),%rbx +`".cfi_restore rbx" if $cfi` lea (%rsi),%rsp +`".cfi_def_cfa_register rsp" if $cfi` .Lepilogue_avx: ret +`".cfi_endproc" if $cfi` .size sha1_block_data_order_avx,.-sha1_block_data_order_avx ___ @@ -1302,12 +1365,19 @@ $code.=<<___; .align 16 sha1_block_data_order_avx2: _avx2_shortcut: +`".cfi_startproc" if $cfi` mov %rsp,%rax +`".cfi_def_cfa_register rax" if $cfi` push %rbx +`".cfi_offset rbx,-16" if $cfi` push %rbp +`".cfi_offset rbp,-24" if $cfi` push %r12 +`".cfi_offset r12,-32" if $cfi` push %r13 +`".cfi_offset r13,-40" if $cfi` push %r14 +`".cfi_offset r14,-48" if $cfi` vzeroupper ___ $code.=<<___ if ($win64); @@ -1322,6 +1392,7 @@ $code.=<<___ if ($win64); ___ $code.=<<___; mov %rax,%r14 # original %rsp +`".cfi_def_cfa_register r14" if $cfi` mov %rdi,$ctx # reassigned argument mov %rsi,$inp # reassigned argument mov %rdx,$num # reassigned argument @@ -1750,14 +1821,22 @@ $code.=<<___ if ($win64); ___ $code.=<<___; lea (%r14),%rsi +`".cfi_def_cfa_register rsi" if $cfi` mov -40(%rsi),%r14 +`".cfi_restore r14" if $cfi` mov -32(%rsi),%r13 +`".cfi_restore r13" if $cfi` mov -24(%rsi),%r12 +`".cfi_restore r12" if $cfi` mov -16(%rsi),%rbp +`".cfi_restore rbp" if $cfi` mov -8(%rsi),%rbx +`".cfi_restore rbx" if $cfi` lea (%rsi),%rsp +`".cfi_def_cfa_register rsp" if $cfi` .Lepilogue_avx2: ret +`".cfi_endproc" if $cfi` .size sha1_block_data_order_avx2,.-sha1_block_data_order_avx2 ___ } -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiml at omnigroup.com Wed Mar 25 19:19:28 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 25 Mar 2015 12:19:28 -0700 Subject: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing In-Reply-To: References: Message-ID: <7994BE49-765F-45ED-B363-DE72E90239EF@omnigroup.com> On Mar 25, 2015, at 11:56 AM, Matt Cross wrote: > I am working with something that does a lot of SHA1's. I am trying to profile my application and generate flame graphs (see http://www.brendangregg.com/flamegraphs.html ), but profiling tools cannot successfully backtrace when the processor is running the optimized SHA1 code on x86_64. This patch adds CFI directives when compiled with a GNU assembler to enable tools that understand DWARF debugging information to backtrace in this circumstance. FYI, I submitted a patch a few years ago to do this for many of the x86-32 assembly files. The perlasm preprocessor already tries to track the stack offset, which means that a lot of those .cfi directives can be generated automatically, without requiring the programmer to keep track of them. The patches are here: http://rt.openssl.org/Ticket/Display.html?id=2562 As you point out, this is pretty useful to allow profiling and/or debugging code that spends a lot of its time in OpenSSL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igenyar at gmail.com Wed Mar 25 19:59:54 2015 From: igenyar at gmail.com (Igenyar Saharam) Date: Wed, 25 Mar 2015 12:59:54 -0700 Subject: [openssl-dev] server code for SNI? Message-ID: Hi, I am interested in the TLS extension of Server Name Indication (SNI). The link provided here https://wiki.openssl.org/index.php/SSL/TLS_Client only contains the client side code. If I want to write the server side that supports SNI, is there any sample code I can start with? Thanks a lot, Igenyar -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.yousar at informatik.hu-berlin.de Wed Mar 25 21:34:01 2015 From: a.yousar at informatik.hu-berlin.de (Annie) Date: Wed, 25 Mar 2015 22:34:01 +0100 Subject: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken In-Reply-To: <5511B028.9040005@gmail.com> References: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> <5511B028.9040005@gmail.com> Message-ID: <551329C9.9090208@informatik.hu-berlin.de> Am 24.03.2015 um 19:42 schrieb Douglas E Engert: > > On 3/24/2015 6:10 AM, Annie Yousar wrote: >> Dear all, >> this should not have happened: > > The private key may have leading zero bytes, and the size of the > BIGNUM is used > for the length of the octetstring rather then the field_len. > The length of the BIGNUM does not include any leading zeros. > Exactly. > Try the attached diff. The diff solves the issue. One remark: Please remove the line /* to get old behavior, set buf_len = bn_len */ from the diff. There is no need to keep it. OpenSSL handles gently the leading zero bytes in the encoded private key. Your diff changes the ASN.1 encoding only and no bits on the wire. So the old buggy behavior is obsolete. Kind regards, Ann. >> >> $ for i in `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name >> prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ]; >> then echo; cat key.pem;else echo -n "."; fi; done >> .................................................................................... >> >> -----BEGIN EC PRIVATE KEY----- >> MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D >> AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8 >> fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY >> -----END EC PRIVATE KEY----- >> ............................................................................ >> >> ... >> The correct encoded key from above is: -----BEGIN EC PRIVATE KEY----- MHcCAQEEIADYI4NV/xp/V/9lU7rLbF0vzrllfS1OIr36eaHsMWwAoAoGCCqGSM49 AwEHoUQDQgAEZTurC5AsyZe5IWk/DY+s91qXA5zAC0OJyPE6HOP6GB7YFKKXkjBI /H4B8PWJt/9hoApc8HiV2C7k2EQe6EfzGA== -----END EC PRIVATE KEY----- Thanks again. From matt.cross at gmail.com Wed Mar 25 21:42:54 2015 From: matt.cross at gmail.com (Matt Cross) Date: Wed, 25 Mar 2015 17:42:54 -0400 Subject: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing In-Reply-To: <7994BE49-765F-45ED-B363-DE72E90239EF@omnigroup.com> References: <7994BE49-765F-45ED-B363-DE72E90239EF@omnigroup.com> Message-ID: On Wed, Mar 25, 2015 at 3:19 PM, Wim Lewis wrote: > > > FYI, I submitted a patch a few years ago to do this for many of the x86-32 > assembly files. The perlasm preprocessor already tries to track the stack > offset, which means that a lot of those .cfi directives can be generated > automatically, without requiring the programmer to keep track of them. > > The patches are here: > http://rt.openssl.org/Ticket/Display.html?id=2562 > > As you point out, this is pretty useful to allow profiling and/or > debugging code that spends a lot of its time in OpenSSL. > That's an interesting approach, much more maintainable going forward. As you noted in your bug report, there is some code in the sha1 implementation that does something like this: mov %rsp,%rax and $-64,%rsp mov %rax,64(%rsp) [more code that trashes rax] Then, in the epilogue it does something like this: mov 64(%rsp),%rsi [restore callee-saved variables] mov %rsi,%rsp This is done to align %rsp to a 64 byte boundary, and the original %rsp is stored on the stack; so the only way to get the actual frame pointer is to read 64(%rsp) and add an offset to that. I managed to do that by inserting a raw DWARF expression. It's not clear to me that the perlasm preprocessor could (or should) do this; but perhaps it makes sense to add some directives for the perlasm preprocessor and let it generate the raw DWARF expression. If I understand correctly, your patch was not folded in. Do you recall why? -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From deengert at gmail.com Wed Mar 25 23:40:45 2015 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 25 Mar 2015 18:40:45 -0500 Subject: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken In-Reply-To: <551329C9.9090208@informatik.hu-berlin.de> References: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> <5511B028.9040005@gmail.com> <551329C9.9090208@informatik.hu-berlin.de> Message-ID: <5513477D.4080502@gmail.com> The attached patch against https://github.com/openssl/openssl makes sure the EC private key in an OCTETSTRING retains leading zeros when converting from BIGNUM to OCTETSTRING. http://www.secg.org/sec1-v2.pdf 2.3.7 Integer-to-Octet-String Conversion Says: "Output: An octet string M of length mlen octets." https://tools.ietf.org/html/rfc5915 Says: "It is an octet string of length ceiling (log2(n)/8)" https://tools.ietf.org/html/rfc3447 4.1 I2OSP Says: " X corresponding octet string of length xLen" and also says: "(note that one or more leading digits will be zero if x is less than 256^(xLen-1))." On 3/25/2015 4:34 PM, Annie wrote: > Am 24.03.2015 um 19:42 schrieb Douglas E Engert: >> >> On 3/24/2015 6:10 AM, Annie Yousar wrote: >>> Dear all, >>> this should not have happened: >> >> The private key may have leading zero bytes, and the size of the >> BIGNUM is used >> for the length of the octetstring rather then the field_len. >> The length of the BIGNUM does not include any leading zeros. >> > > Exactly. > >> Try the attached diff. > > The diff solves the issue. > One remark: Please remove the line > > /* to get old behavior, set buf_len = bn_len */ > > from the diff. There is no need to keep it. OpenSSL handles gently the leading zero bytes in the encoded private key. > Your diff changes the ASN.1 encoding only and no bits on the wire. So the old buggy behavior is obsolete. > > Kind regards, > Ann. > > >>> >>> $ for i in `seq 1 1000` ; do if [ "x`openssl ecparam -genkey -name >>> prime256v1 -noout > key.pem; ls -l key.pem | sed '/ 227 /d'`" != " x" ]; >>> then echo; cat key.pem;else echo -n "."; fi; done >>> .................................................................................... >>> >>> -----BEGIN EC PRIVATE KEY----- >>> MHYCAQEEH9gjg1X/Gn9X/2VTustsXS/OuWV9LU4ivfp5oewxbACgCgYIKoZIzj0D >>> AQehRANCAARlO6sLkCzJl7khaT8Nj6z3WpcDnMALQ4nI8Toc4/oYHtgUopeSMEj8 >>> fgHw9Ym3/2GgClzweJXYLuTYRB7oR/MY >>> -----END EC PRIVATE KEY----- >>> ............................................................................ >>> >>> ... >>> > > The correct encoded key from above is: > > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIADYI4NV/xp/V/9lU7rLbF0vzrllfS1OIr36eaHsMWwAoAoGCCqGSM49 > AwEHoUQDQgAEZTurC5AsyZe5IWk/DY+s91qXA5zAC0OJyPE6HOP6GB7YFKKXkjBI > /H4B8PWJt/9hoApc8HiV2C7k2EQe6EfzGA== > -----END EC PRIVATE KEY----- > > Thanks again. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert -------------- next part -------------- A non-text attachment was scrubbed... Name: ecprivatekey-asn1.diff Type: text/x-patch Size: 5865 bytes Desc: not available URL: From wiml at omnigroup.com Thu Mar 26 02:29:15 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 25 Mar 2015 19:29:15 -0700 Subject: [openssl-dev] [PATCH] Insert CFI directives in x86_64 SHA1 implementation to enable backtracing In-Reply-To: References: <7994BE49-765F-45ED-B363-DE72E90239EF@omnigroup.com> Message-ID: <6309843A-B8D7-4907-A2C5-07E17B62357B@omnigroup.com> On Mar 25, 2015, at 2:42 PM, Matt Cross wrote: > This is done to align %rsp to a 64 byte boundary, and the original %rsp is stored on the stack; so the only way to get the actual frame pointer is to read 64(%rsp) and add an offset to that. I managed to do that by inserting a raw DWARF expression. It's not clear to me that the perlasm preprocessor could (or should) do this; but perhaps it makes sense to add some directives for the perlasm preprocessor and let it generate the raw DWARF expression. I think the cfi_cfa_indirect pseudo-directive handles that case (it?s defined in x86gas.pl and used in, e.g., aesni-x86, which does a similar stack alignment). It uses a minuscule ?assembler? for DWARF location opcode expressions included in the 3-cfi patch, which makes it easier to handle cases where the assembly is doing something clever. The SHA256 and SHA512 implementations on x86_32 did something trickier: each round adjusted the stack frame forwards by some number of bytes, so that it could read the previous round and write the new data from fixed offsets from $esp (presumably this saves a register). I didn?t try writing DWARF info to unwind that. I don?t think the x86_64 code does that, though, since registers aren?t as scarce. > If I understand correctly, your patch was not folded in. Do you recall why? IIRC, the maintainer said it would be too much trouble to integrate. From hkario at redhat.com Thu Mar 26 09:44:43 2015 From: hkario at redhat.com (Hubert Kario) Date: Thu, 26 Mar 2015 10:44:43 +0100 Subject: [openssl-dev] server code for SNI? In-Reply-To: References: Message-ID: <15518659.CX6GWLyqtp@pintsize.usersys.redhat.com> On Wednesday 25 March 2015 12:59:54 Igenyar Saharam wrote: > Hi, > > > I am interested in the TLS extension of Server Name Indication (SNI). The > link provided here https://wiki.openssl.org/index.php/SSL/TLS_Client only > contains the client side code. If I want to write the server side that > supports SNI, is there any sample code I can start with? > > Thanks a lot, > > > Igenyar s_server utility implements it, look for handling of -servername switch Though this question is more of a topic for openssl-users mailinglist -- Regards, Hubert Kario 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From meissner at suse.de Thu Mar 26 09:53:09 2015 From: meissner at suse.de (Marcus Meissner) Date: Thu, 26 Mar 2015 10:53:09 +0100 Subject: [openssl-dev] [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h In-Reply-To: References: Message-ID: <20150326095308.GA25483@suse.de> On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote: > HI, > > I have a query for SSl cipher on Openssl-1.0.1h > Have an application which is using library compiled with openssl-1.0.1h. > > Application is failing in func SSL_CTX_set_cipher_list() when input is " > RC4-MD5+RC4-SHA" and it gets succeed when input is "RC4-SHA". > Not sure whether "RC4-MD5" is disabled by default on openssl-1.0.1h. > Earlier application was using openssl-0.9.8d. > There it used to work fine.. > If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h. > > Tried looking opensource link, couldn't find a way to explicitly enable > this algorithm or even if it is diabled by default. > Any Inputs for same will be appreciated.. You seem to be using invalid cipher string syntax. : is a delimiter there. openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Ciao, Marcus From rt at openssl.org Thu Mar 26 11:39:44 2015 From: rt at openssl.org (Dan Fulger via RT) Date: Thu, 26 Mar 2015 12:39:44 +0100 Subject: [openssl-dev] [openssl.org #3766] OS/400 port of OpenSSL 1.0.1m In-Reply-To: References: Message-ID: I updated the patch after the OpenSSL team reformatted the code. ________________________________________ De la: Dan Fulger Trimis: 4 iulie 2014 18:03 C?tre: rt at openssl.org Subiect: I updated George Shaw's 0.9.8e port to OS/400 from 2007 The attached patch and notes apply to 1.0.1h. OS/400 fixes since George's port: unit tests now work better, X509 strings are now correctly encoded in generated certificates when not using prompt mode, a dependency to the OS/400 secure random numbers library was added, UTF8 strings in certificates no longer print garbage (but other Unicode encodings are not fixed). Still to be fixed: - tsa test shows "bad time value" when printing but otherwise works - cms verification does not work -------------- next part -------------- A non-text attachment was scrubbed... Name: AS400patch.tar.gz Type: application/x-compressed-tar Size: 48554 bytes Desc: not available URL: From Alexey.Bakhtin at gmail.com Thu Mar 26 13:59:52 2015 From: Alexey.Bakhtin at gmail.com (Alexey Bakhtin) Date: Thu, 26 Mar 2015 13:59:52 +0000 (UTC) Subject: [openssl-dev] Seeking feedback on some #ifdef changes References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150211.123700.841614895056516719.richard@levitte.org> Message-ID: TLS connection could be established without X509 certs and storage support (e.g. CoAP protocol with PSK cipher suites). It would be great to build libssl library without X509 at all. Thank you Alexey From rsalz at akamai.com Thu Mar 26 15:22:31 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 26 Mar 2015 15:22:31 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150211.123700.841614895056516719.richard@levitte.org> Message-ID: <96aa8c67bf0f4eed9e211176ee6483a5@usma1ex-dag1mb2.msg.corp.akamai.com> > TLS connection could be established without X509 certs and storage support > (e.g. CoAP protocol with PSK cipher suites). > It would be great to build libssl library without X509 at all. I'd be interested in working patches. From michel.sales at free.fr Thu Mar 26 16:50:42 2015 From: michel.sales at free.fr (Michel) Date: Thu, 26 Mar 2015 17:50:42 +0100 Subject: [openssl-dev] Explicit call to SSL_CTX_check_private_key() no longer needed ? Message-ID: <001501d067e4$ff65a400$fe30ec00$@sales@free.fr> OpenSSL 1.0.2a A call to SSL_CTX_check_private_key() is already done in ssl_set_pkey() / SSL_CTX_use_PrivateKey() line 597. Consequently, SSL_CTX_check_private_key() is called twice in apps\s_cb.c, set_cert_key_stuff() line 274. This might be enclosed in an include directive testing the version of OpenSSL ? Regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Thu Mar 26 18:13:12 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Thu, 26 Mar 2015 19:13:12 +0100 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <55116016.8010105@cisco.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> Message-ID: On Tue, Mar 24, 2015 at 2:01 PM, John Foley wrote: > Trying again w/o PGP... :-) > > Thanks for taking a look at this problem. Regarding how to handle a > failure in the session secret callback, the legacy logic would likely > result in a "bad record mac" error because the master secrets on the > client/server do not match. > But only in case we are actually resuming - no? Does the client always have a PAC available - I would guess not? Seems the legacy logic is such that it "happens to work", but I'd like to clear it up. > It would be good to trigger an internal error to aid with > troubleshooting. Maybe something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > goto err; > > It's debatable whether the alert needs to be sent to the server. Since > this is an internal error, it should be safe to send the alert. Therefore, > maybe you would actually want to do something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > al = SSL_AD_INTERNAL_ERROR; > goto f_err; > > > > > On 03/23/2015 09:17 PM, Emilia K?sper wrote: > > > > On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) > wrote: > >> We've found a way to recreate the scenario using s_client/s_server. >> We're using the -no_ticket option on the server. Therefore, the >> ServerHello doesn't contain the session ticket extension. It also doesn't >> send the NewSessionTicket message. >> >> To summarize the problem, when the client side is using >> SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, >> then the logic in ssl3_get_server_hello() assumes the server is doing >> session resumption. This puts the client-side state machine into the >> SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not >> do resumption via the -no_ticket option, the server continues with a normal >> handshake by sending the Certificate message. The client aborts the >> handshake when it receives the Certificate message while in the >> SSL3_ST_CR_FINISHED_A state. >> >> >> As Erik identified earlier in the thread, the cause of this appears to be >> the addition of setting s->hit in the following code: >> >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >> SSL_CIPHER *pref_cipher = NULL; >> s->session->master_key_length = sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p + j); >> s->hit = 1; >> } >> } >> >> Why does the client-side now assume the server is doing session >> resumption simply because the session secret callback facility is being >> used? >> > > Because a developer (me) introduced a bug. With OpenSSL client > behaviour, peeking ahead is only required for EAP-FAST. I got rid of the > peeking while tightening up the ChangeCipherSpec handling and in the > process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem > and am working on a patch. > > While we're at it, you may be able to help me with the following > question: how should the client handle callback failure? The old code (pre > my refactoring which introduced the bug) did this > > #ifndef OPENSSL_NO_TLSEXT > /* check if we want to resume the session based on external pre-shared secret */ > if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) > { > SSL_CIPHER *pref_cipher=NULL; > s->session->master_key_length=sizeof(s->session->master_key); > if (s->tls_session_secret_cb(s, s->session->master_key, > &s->session->master_key_length, > NULL, &pref_cipher, > s->tls_session_secret_cb_arg)) > { > s->session->cipher = pref_cipher ? > pref_cipher : ssl_get_cipher_by_char(s, p+j); > } > } > #endif /* OPENSSL_NO_TLSEXT */ > > This is surely wrong as it's just ignoring the failure? > > Thanks, > > Emilia > > ________________________________________ >> From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Dr. >> Stephen Henson [steve at openssl.org] >> Sent: Thursday, March 19, 2015 11:49 AM >> To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] s3_clnt.c changes regarding external >> pre-shared secret seem to break EAP-FAST >> >> On Thu, Mar 19, 2015, Erik Tkal wrote: >> >> > >> > If I do not send a sessionID in the clientHello but do send a valid >> > sessionTicket extension, the server goes straight to changeCipherSpec >> and >> > the client generates an UnexpectedMessage alert. >> > >> >> Does the server send back an empty session ticket extension? >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> _______________________________________________ >> 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 > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Thu Mar 26 20:02:34 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 26 Mar 2015 16:02:34 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> Message-ID: <551465DA.1040508@cisco.com> Someone that understands EAP better than myself should probably provide input. But my limited understand of EAP-FAST is it contributes to the master secret calculation used for the TLS session. See section RFC 4851 Section 5.1. My understanding is this logic applies to both new and resumed sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST. On 03/26/2015 02:13 PM, Emilia K?sper wrote: > > > On Tue, Mar 24, 2015 at 2:01 PM, John Foley > wrote: > > Trying again w/o PGP... :-) > > Thanks for taking a look at this problem. Regarding how to handle > a failure in the session secret callback, the legacy logic would > likely result in a "bad record mac" error because the master > secrets on the client/server do not match. > > > But only in case we are actually resuming - no? Does the client always > have a PAC available - I would guess not? Seems the legacy logic is > such that it "happens to work", but I'd like to clear it up. > > It would be good to trigger an internal error to aid with > troubleshooting. Maybe something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > goto err; > > It's debatable whether the alert needs to be sent to the server. > Since this is an internal error, it should be safe to send the > alert. Therefore, maybe you would actually want to do something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > al = SSL_AD_INTERNAL_ERROR; > goto f_err; > > > > > On 03/23/2015 09:17 PM, Emilia K?sper wrote: >> >> >> On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) >> > wrote: >> >> We've found a way to recreate the scenario using >> s_client/s_server. We're using the -no_ticket option on the >> server. Therefore, the ServerHello doesn't contain the >> session ticket extension. It also doesn't send the >> NewSessionTicket message. >> >> To summarize the problem, when the client side is using >> SSL_set_session_secret_cb() and including a valid ticket in >> the ClintHello, then the logic in ssl3_get_server_hello() >> assumes the server is doing session resumption. This puts >> the client-side state machine into the >> SSL3_ST_CR_FINISHED_A. However, since the server side is >> configured to not do resumption via the -no_ticket option, >> the server continues with a normal handshake by sending the >> Certificate message. The client aborts the handshake when it >> receives the Certificate message while in the >> SSL3_ST_CR_FINISHED_A state. >> >> >> As Erik identified earlier in the thread, the cause of this >> appears to be the addition of setting s->hit in the following >> code: >> >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >> SSL_CIPHER *pref_cipher = NULL; >> s->session->master_key_length = sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p + j); >> s->hit = 1; >> } >> } >> >> Why does the client-side now assume the server is doing >> session resumption simply because the session secret callback >> facility is being used? >> >> >> Because a developer (me) introduced a bug. With OpenSSL client >> behaviour, peeking ahead is only required for EAP-FAST. I got rid >> of the peeking while tightening up the ChangeCipherSpec handling >> and in the process, got it wrong for EAP-FAST. Anyway, apologies, >> I see the problem and am working on a patch. >> >> While we're at it, you may be able to help me with the following >> question: how should the client handle callback failure? The old >> code (pre my refactoring which introduced the bug) did this >> >> #ifndef OPENSSL_NO_TLSEXT >> /* check if we want to resume the session based on external pre-shared secret */ >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) >> { >> SSL_CIPHER *pref_cipher=NULL; >> s->session->master_key_length=sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) >> { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p+j); >> } >> } >> #endif /* OPENSSL_NO_TLSEXT */ >> This is surely wrong as it's just ignoring the failure? >> Thanks, >> Emilia >> >> ________________________________________ >> From: openssl-dev [openssl-dev-bounces at openssl.org >> ] on behalf of Dr. >> Stephen Henson [steve at openssl.org ] >> Sent: Thursday, March 19, 2015 11:49 AM >> To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] s3_clnt.c changes regarding >> external pre-shared secret seem to break EAP-FAST >> >> On Thu, Mar 19, 2015, Erik Tkal wrote: >> >> > >> > If I do not send a sessionID in the clientHello but do send >> a valid >> > sessionTicket extension, the server goes straight to >> changeCipherSpec and >> > the client generates an UnexpectedMessage alert. >> > >> >> Does the server send back an empty session ticket extension? >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> _______________________________________________ >> 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 > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Mar 27 08:38:53 2015 From: rt at openssl.org (Fred .Flintstone via RT) Date: Fri, 27 Mar 2015 09:38:53 +0100 Subject: [openssl-dev] [openssl.org #3767] Enhancement: Use PNG instead of GIF In-Reply-To: References: Message-ID: /usr/share/doc/openssl/openssl_button.gif GIF is an outdated old legacy file format. Please convert it to the modern PNG file format. From rt at openssl.org Fri Mar 27 12:19:26 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 27 Mar 2015 13:19:26 +0100 Subject: [openssl-dev] [openssl.org #3767] Enhancement: Use PNG instead of GIF In-Reply-To: References: Message-ID: not a source code bug. not really a bug, even. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Mar 27 12:46:26 2015 From: rt at openssl.org (Fred .Flintstone via RT) Date: Fri, 27 Mar 2015 13:46:26 +0100 Subject: [openssl-dev] [openssl.org #3767] AutoReply: Enhancement: Use PNG instead of GIF In-Reply-To: References: Message-ID: You are right, it is not a bug. It was failed as an "enhancement", like a feature request. On Fri, Mar 27, 2015 at 9:38 AM, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Enhancement: Use PNG instead of GIF", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #3767]. > > Please include the string: > > [openssl.org #3767] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > /usr/share/doc/openssl/openssl_button.gif > > GIF is an outdated old legacy file format. > Please convert it to the modern PNG file format. > > From rt at openssl.org Fri Mar 27 12:46:25 2015 From: rt at openssl.org (Fred .Flintstone via RT) Date: Fri, 27 Mar 2015 13:46:25 +0100 Subject: [openssl-dev] [openssl.org #3767] Enhancement: Use PNG instead of GIF In-Reply-To: References: Message-ID: You are right, it is not a bug. It was failed as an "enhancement", like a feature request. On Fri, Mar 27, 2015 at 1:19 PM, Rich Salz via RT wrote: > not a source code bug. not really a bug, even. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > From rt at openssl.org Fri Mar 27 13:12:59 2015 From: rt at openssl.org (Linsell, StevenX via RT) Date: Fri, 27 Mar 2015 14:12:59 +0100 Subject: [openssl-dev] [openssl.org #3768] [BUG] using s_server with ECDHE-RSA is broken on OpenSSL 1.0.1m In-Reply-To: References: Message-ID: When testing s_server/s_client with ECDHE-RSA based ciphers - with any protocol version - on the OpenSSL 1.0.1m release - on x86_64 Fedora 16 the handshake fails with: 140305461679776:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1389: Example commands: s_server: ./openssl s_server -cert rsa1024TestServer.cert.pem -key rsa1024TestServer.key.pem -WWW -accept 4411 -cipher ECDHE-RSA-AES128-SHA -nbio -tls1_2 -debug -state s_client: echo "GET /file_1byte.html HTTP/1.0" | ./openssl s_client -host localhost -port 4411 -cipher ECDHE-RSA-AES128-SHA -tls1_2 -ign_eof -debug -state The issue has been tracked back to breaking on the following commit:- commit 059907771b89549cbd07a81df1a5bdf51e062066 Author: Matt Caswell Date: Fri Feb 27 00:02:06 2015 +0000 Fix warning with no-ec This fixes another warning when config'd with no-ec Reviewed-by: Dr. Stephen Henson And I have confirmed it has been broken by the following uninitialised variable: @@ -992,7 +992,10 @@ int MAIN(int argc, char *argv[]) int badop = 0, bugs = 0; int ret = 1; int off = 0; - int no_tmp_rsa = 0, no_dhe = 0, no_ecdhe = 0, nocert = 0; + int no_tmp_rsa = 0, no_dhe = 0, nocert = 0; +#ifndef OPENSSL_NO_ECDH + int no_ecdhe; <---------------- Should have been initialised to 0 +#endif Sorry I would have supplied the fix as a patch but I haven't got my head around how to do that yet. It is still broken in the latest 1.0.1-stable branch. I have checked the other branches and only 1.0.1-stable appears to be affected. Kind Regards, Steve Linsell Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From emilia at openssl.org Fri Mar 27 16:33:13 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 27 Mar 2015 17:33:13 +0100 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <551465DA.1040508@cisco.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> <551465DA.1040508@cisco.com> Message-ID: John, Erik, https://github.com/openssl/openssl/pull/250 Can you verify whether this resolves the problem? (And also, does not create any new problems.) Note this is pending team review so is not a definitive fix. But since we're maintaining this feature more or less blind, we'd appreciate your help testing the fix. Thanks, Emilia On Thu, Mar 26, 2015 at 9:02 PM, John Foley wrote: > Someone that understands EAP better than myself should probably provide > input. But my limited understand of EAP-FAST is it contributes to the > master secret calculation used for the TLS session. See section RFC 4851 > Section 5.1. My understanding is this logic applies to both new and resumed > sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST. > > > > On 03/26/2015 02:13 PM, Emilia K?sper wrote: > > > > On Tue, Mar 24, 2015 at 2:01 PM, John Foley wrote: > >> Trying again w/o PGP... :-) >> >> Thanks for taking a look at this problem. Regarding how to handle a >> failure in the session secret callback, the legacy logic would likely >> result in a "bad record mac" error because the master secrets on the >> client/server do not match. >> > > But only in case we are actually resuming - no? Does the client always > have a PAC available - I would guess not? Seems the legacy logic is such > that it "happens to work", but I'd like to clear it up. > > >> It would be good to trigger an internal error to aid with >> troubleshooting. Maybe something like: >> >> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >> goto err; >> >> It's debatable whether the alert needs to be sent to the server. Since >> this is an internal error, it should be safe to send the alert. Therefore, >> maybe you would actually want to do something like: >> >> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >> al = SSL_AD_INTERNAL_ERROR; >> goto f_err; >> >> >> >> >> On 03/23/2015 09:17 PM, Emilia K?sper wrote: >> >> >> >> On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) >> wrote: >> >>> We've found a way to recreate the scenario using s_client/s_server. >>> We're using the -no_ticket option on the server. Therefore, the >>> ServerHello doesn't contain the session ticket extension. It also doesn't >>> send the NewSessionTicket message. >>> >>> To summarize the problem, when the client side is using >>> SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, >>> then the logic in ssl3_get_server_hello() assumes the server is doing >>> session resumption. This puts the client-side state machine into the >>> SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not >>> do resumption via the -no_ticket option, the server continues with a normal >>> handshake by sending the Certificate message. The client aborts the >>> handshake when it receives the Certificate message while in the >>> SSL3_ST_CR_FINISHED_A state. >>> >>> >>> As Erik identified earlier in the thread, the cause of this appears to >>> be the addition of setting s->hit in the following code: >>> >>> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >>> SSL_CIPHER *pref_cipher = NULL; >>> s->session->master_key_length = sizeof(s->session->master_key); >>> if (s->tls_session_secret_cb(s, s->session->master_key, >>> &s->session->master_key_length, >>> NULL, &pref_cipher, >>> s->tls_session_secret_cb_arg)) { >>> s->session->cipher = pref_cipher ? >>> pref_cipher : ssl_get_cipher_by_char(s, p + j); >>> s->hit = 1; >>> } >>> } >>> >>> Why does the client-side now assume the server is doing session >>> resumption simply because the session secret callback facility is being >>> used? >>> >> >> Because a developer (me) introduced a bug. With OpenSSL client >> behaviour, peeking ahead is only required for EAP-FAST. I got rid of the >> peeking while tightening up the ChangeCipherSpec handling and in the >> process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem >> and am working on a patch. >> >> While we're at it, you may be able to help me with the following >> question: how should the client handle callback failure? The old code (pre >> my refactoring which introduced the bug) did this >> >> #ifndef OPENSSL_NO_TLSEXT >> /* check if we want to resume the session based on external pre-shared secret */ >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) >> { >> SSL_CIPHER *pref_cipher=NULL; >> s->session->master_key_length=sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) >> { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p+j); >> } >> } >> #endif /* OPENSSL_NO_TLSEXT */ >> >> This is surely wrong as it's just ignoring the failure? >> >> Thanks, >> >> Emilia >> >> ________________________________________ >>> From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Dr. >>> Stephen Henson [steve at openssl.org] >>> Sent: Thursday, March 19, 2015 11:49 AM >>> To: openssl-dev at openssl.org >>> Subject: Re: [openssl-dev] s3_clnt.c changes regarding external >>> pre-shared secret seem to break EAP-FAST >>> >>> On Thu, Mar 19, 2015, Erik Tkal wrote: >>> >>> > >>> > If I do not send a sessionID in the clientHello but do send a valid >>> > sessionTicket extension, the server goes straight to changeCipherSpec >>> and >>> > the client generates an UnexpectedMessage alert. >>> > >>> >>> Does the server send back an empty session ticket extension? >>> >>> Steve. >>> -- >>> Dr Stephen N. Henson. OpenSSL project core developer. >>> Commercial tech support now available see: http://www.openssl.org >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Mar 27 17:46:04 2015 From: rt at openssl.org (Julien Kauffmann via RT) Date: Fri, 27 Mar 2015 18:46:04 +0100 Subject: [openssl-dev] [openssl.org #3765] AutoReply: [BUG] Crash in PEM write functions with generated EC_KEY on Windows In-Reply-To: <5515641A.90805@freelan.org> References: <5515641A.90805@freelan.org> Message-ID: Follow up: apparently the problem seems to go away if I add: ::EC_KEY_set_asn1_flag(private_key->pkey.ec, OPENSSL_EC_NAMED_CURVE); Before the call. Sadly, I'm facing a similar with the reverse operation (loading EC_KEY from memory/file) using PEM_read_bio_EC_PUBKEY() when the generated key did not have the OPENSSL_EC_NAMED_CURVE flag set. Le 23/03/2015 16:48, The default queue via RT a ?crit : > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "[BUG] Crash in PEM write functions with generated EC_KEY on Windows", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #3765]. > > Please include the string: > > [openssl.org #3765] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > I'm facing a crash (heap corruption) on Windows ever since I updated > OpenSSL to the version 1.0.2a. The same seems to happen in 1.0.1m. > > I'm using Visual Studio 2013. I'm building the x64-static variant of > OpenSSL like so: > > perl Configure VC-WIN64A no-asm > --prefix=F:\git\openssl_crash\third-party\install\x64 > ms\do_win64a > nmake -f ms\nt.mak > nmake -f ms\nt.mak install > > My sample code goes as follow: > > ----- main.cpp ----- > #include > #include > #include > #include > #include > #include > > int main() > { > OpenSSL_add_all_algorithms(); > ERR_load_crypto_strings(); > > EVP_PKEY_CTX* parameters_context = EVP_PKEY_CTX_new_id(EVP_PKEY_EC, > NULL); > > if (EVP_PKEY_paramgen_init(parameters_context) != 1) { return 1; } > if (EVP_PKEY_CTX_set_ec_paramgen_curve_nid(parameters_context, > NID_sect571k1) != 1) { return 1; } > > EVP_PKEY* cparameters = nullptr; > > if (EVP_PKEY_paramgen(parameters_context, &cparameters) != 1) { return > 1; } > > EVP_PKEY_CTX* key_generation_context = EVP_PKEY_CTX_new(cparameters, > NULL); > > if (!key_generation_context) { return 1; } > if (EVP_PKEY_keygen_init(key_generation_context) != 1) { return 1; } > > EVP_PKEY* private_key = nullptr; > > if (EVP_PKEY_keygen(key_generation_context, &private_key) != 1) { > return 1; } > > BIO* bio = BIO_new(BIO_s_mem()); > PEM_write_bio_PUBKEY(bio, private_key); // <== CRASH HERE. > > ERR_free_strings(); > EVP_cleanup(); > ::CRYPTO_cleanup_all_ex_data(); > > return EXIT_SUCCESS; > } > ----- end of main.cpp ----- > > Which is compiled with: > > cl /Fomain.obj /c main.cpp /TP /EHsc /MT /nologo > /Ithird-party\install\x64\include > link /nologo /OUT:crash.exe /LIBPATH:third-party\install\x64\lib > libeay32.lib user32.lib gdi32.lib advapi32.lib main.obj > > I tried this sample code with all of the /MD, /MT, /MDd, /MTd variants > without success. The code seems to run fine on Linux and OSX (using gcc > & clang). > > Here is the stacktrace I'm getting when the heap corruption occurs: > >> openssl_crash.exe!free(void * pBlock) Line 51 C > openssl_crash.exe!CRYPTO_free(void * str) Line 440 C > openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const > ASN1_ITEM_st * it, int combine) Line 172 C > openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const > ASN1_ITEM_st * it, int combine) Line 160 C > openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const > ASN1_ITEM_st * it, int combine) Line 160 C > openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const > ASN1_ITEM_st * it, int combine) Line 160 C > openssl_crash.exe!asn1_item_combine_free(ASN1_VALUE_st * * pval, const > ASN1_ITEM_st * it, int combine) Line 130 C > openssl_crash.exe!ASN1_item_free(ASN1_VALUE_st * val, const > ASN1_ITEM_st * it) Line 73 C > openssl_crash.exe!i2d_ECPKParameters(const ec_group_st * a, unsigned > char * * out) Line 1010 C > openssl_crash.exe!eckey_param2type(int * pptype, void * * ppval, > ec_key_st * ec_key) Line 93 C > openssl_crash.exe!eckey_pub_encode(X509_pubkey_st * pk, const > evp_pkey_st * pkey) Line 113 C > openssl_crash.exe!X509_PUBKEY_set(X509_pubkey_st * * x, evp_pkey_st * > pkey) Line 101 C > openssl_crash.exe!i2d_PUBKEY(evp_pkey_st * a, unsigned char * * pp) > Line 211 C > openssl_crash.exe!PEM_ASN1_write_bio(int (void *, unsigned char * *) * > i2d, const char * name, bio_st * bp, void * x, const evp_cipher_st * > enc, unsigned char * kstr, int klen, int (char *, int, int, void *) * > callback, void * u) Line 357 C > openssl_crash.exe!PEM_write_bio_PUBKEY(bio_st * bp, evp_pkey_st * x) > Line 427 C > openssl_crash.exe!main() Line 40 C++ > > Is there anything wrong regarding my sample code ? If not, can anyone > else reproduce the problem ? Is it a bug in OpenSSL ? > > Regards, > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4276 bytes Desc: not available URL: From etksubs at gmail.com Fri Mar 27 18:19:22 2015 From: etksubs at gmail.com (Erik Tkal) Date: Fri, 27 Mar 2015 14:19:22 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> <551465DA.1040508@cisco.com> Message-ID: Hi Emelia, I?m not sure that will work as presently designed, as it keys off of the session object: - if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { + if (s->version >= TLS1_VERSION && s->tls_session_secret_cb && + s->session->tlsext_tick) { Our client uses the public API SSL_set_session_ticket_ext(), which populates the SSL->tls_session_ticket, and not the SSL->session copy. Erik > On 27 Mar 2015, at 12:33 PM, Emilia K?sper wrote: > > John, Erik, > > https://github.com/openssl/openssl/pull/250 > > Can you verify whether this resolves the problem? (And also, does not create any new problems.) > > Note this is pending team review so is not a definitive fix. But since we're maintaining this feature more or less blind, we'd appreciate your help testing the fix. > > Thanks, > Emilia > > On Thu, Mar 26, 2015 at 9:02 PM, John Foley > wrote: > Someone that understands EAP better than myself should probably provide input. But my limited understand of EAP-FAST is it contributes to the master secret calculation used for the TLS session. See section RFC 4851 Section 5.1. My understanding is this logic applies to both new and resumed sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST. > > > > On 03/26/2015 02:13 PM, Emilia K?sper wrote: >> >> >> On Tue, Mar 24, 2015 at 2:01 PM, John Foley > wrote: >> Trying again w/o PGP... :-) >> >> Thanks for taking a look at this problem. Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match. >> >> But only in case we are actually resuming - no? Does the client always have a PAC available - I would guess not? Seems the legacy logic is such that it "happens to work", but I'd like to clear it up. >> >> It would be good to trigger an internal error to aid with troubleshooting. Maybe something like: >> >> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >> goto err; >> >> It's debatable whether the alert needs to be sent to the server. Since this is an internal error, it should be safe to send the alert. Therefore, maybe you would actually want to do something like: >> >> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >> al = SSL_AD_INTERNAL_ERROR; >> goto f_err; >> >> >> >> >> On 03/23/2015 09:17 PM, Emilia K?sper wrote: >>> >>> >>> On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) > wrote: >>> We've found a way to recreate the scenario using s_client/s_server. We're using the -no_ticket option on the server. Therefore, the ServerHello doesn't contain the session ticket extension. It also doesn't send the NewSessionTicket message. >>> >>> To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption. This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message. The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state. >>> >>> >>> As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code: >>> >>> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >>> SSL_CIPHER *pref_cipher = NULL; >>> s->session->master_key_length = sizeof(s->session->master_key); >>> if (s->tls_session_secret_cb(s, s->session->master_key, >>> &s->session->master_key_length, >>> NULL, &pref_cipher, >>> s->tls_session_secret_cb_arg)) { >>> s->session->cipher = pref_cipher ? >>> pref_cipher : ssl_get_cipher_by_char(s, p + j); >>> s->hit = 1; >>> } >>> } >>> >>> Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used? >>> >>> Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch. >>> >>> While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this >>> >>> #ifndef OPENSSL_NO_TLSEXT >>> /* check if we want to resume the session based on external pre-shared secret */ >>> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) >>> { >>> SSL_CIPHER *pref_cipher=NULL; >>> s->session->master_key_length=sizeof(s->session->master_key); >>> if (s->tls_session_secret_cb(s, s->session->master_key, >>> &s->session->master_key_length, >>> NULL, &pref_cipher, >>> s->tls_session_secret_cb_arg)) >>> { >>> s->session->cipher = pref_cipher ? >>> pref_cipher : ssl_get_cipher_by_char(s, p+j); >>> } >>> } >>> #endif /* OPENSSL_NO_TLSEXT */ >>> This is surely wrong as it's just ignoring the failure? >>> Thanks, >>> Emilia >>> ________________________________________ >>> From: openssl-dev [openssl-dev-bounces at openssl.org ] on behalf of Dr. Stephen Henson [steve at openssl.org ] >>> Sent: Thursday, March 19, 2015 11:49 AM >>> To: openssl-dev at openssl.org >>> Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST >>> >>> On Thu, Mar 19, 2015, Erik Tkal wrote: >>> >>> > >>> > If I do not send a sessionID in the clientHello but do send a valid >>> > sessionTicket extension, the server goes straight to changeCipherSpec and >>> > the client generates an UnexpectedMessage alert. >>> > >>> >>> Does the server send back an empty session ticket extension? >>> >>> Steve. >>> -- >>> Dr Stephen N. Henson. OpenSSL project core developer. >>> Commercial tech support now available see: http://www.openssl.org >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 brian at briansmith.org Fri Mar 27 21:19:11 2015 From: brian at briansmith.org (Brian Smith) Date: Fri, 27 Mar 2015 11:19:11 -1000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: Erik Tkal wrote: > In order for EAP-FAST to work it seems that if the client does have a > tls_session_secret that s->hit must NOT be set since there is no indication > in the serverHello as to whether the session_ticket sent by the client is > accepted by the server (the sessionTicket extension is not sent by the > server in EAP-FAST) [snip] Although the RFC4851 (an informational RFC documenting EAP-FAST) does not require the server to send the session ticket extension during resumption, it is based on RFC4507/RFC5077 (which are on the standards track), which *does* require the server to send the extension. So, this is a bug in the non-conformant servers, not in the openssl client. The non-standard mechanism recommended by RFC4851 for distinguishing resumption vs. full handshakes in EAP-FAST is quite unfortunate. We should update RFC4851 to require standard RFC5077 semantics to be used. Is there any effort underway to update RFC4851 for this or other reasons? It is worth filing an errata against the document, at least. It would be better to fix this bug on the server (by having them send the session ticket extension during resumption as required by RFC 5077) than in the openssl client. Cheers, Brian From brian at briansmith.org Fri Mar 27 21:40:45 2015 From: brian at briansmith.org (Brian Smith) Date: Fri, 27 Mar 2015 11:40:45 -1000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: Brian Smith wrote: > Although the RFC4851 (an informational RFC documenting EAP-FAST) does > not require the server to send the session ticket extension during > resumption, it is based on RFC4507/RFC5077 (which are on the standards > track), which *does* require the server to send the extension. So, > this is a bug in the non-conformant servers, not in the openssl > client. Sorry. It seems I am wrong about this. RFC 5077 says "It is also permissible to have an exchange similar to Figure 3 using the abbreviated handshake defined in Figure 2 of RFC 4346, where the client uses the SessionTicket extension to resume the session, but the server does not wish to issue a new ticket, and therefore does not send a SessionTicket extension." AFAICT this means that, even outside of EAP-FAST, it is allowed for the server to resume a session using a session ticket without sending the session ticket extension in its ServerHello message. Also, note that RFC 5077 section 3.4 allows the client to use a session ticket and an empty session ID to resume a session, instead of generating a "fake" session ID for the session ticket: "Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case, the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages." If OpenSSL's client code were changed to always use an empty session ID when attempting resumption using a session ticket, then the EAP-FAST case wouldn't be different from the general session ticket resumption case. I think that this is a cleaner approach. Note that RFC4851 would likely still need to be updated, because TLS 1.3 will most likely remove the ChangeCipherSpec messages, and RFC4851's recommended resumption detection is based on detecting ChangeCipherSpec messages. Cheers, Brian From kurt at roeckx.be Sat Mar 28 16:18:22 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 28 Mar 2015 17:18:22 +0100 Subject: [openssl-dev] Fwd: [Ach] Twitter & Cloudflare TLS config + patches Message-ID: <20150328161822.GA25611@roeckx.be> An embedded message was scrubbed... From: Aaron Zauner Subject: [Ach] Twitter & Cloudflare TLS config + patches Date: Fri, 20 Mar 2015 19:05:22 +0100 Size: 6938 URL: From rt at openssl.org Sun Mar 29 18:06:19 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 29 Mar 2015 20:06:19 +0200 Subject: [openssl-dev] [openssl.org #3769] Bug in v3_alt.c In-Reply-To: <43e1595dda1a4d729230a52316e01243@usma1ex-dag1mb2.msg.corp.akamai.com> References: <43e1595dda1a4d729230a52316e01243@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: Found during internal code review. V3_alt.c has this proposed change: ret = X509V3_NAME_from_section(nm, sk, MBSTRING_ASC); - if (!ret) + if (!ret) { X509_NAME_free(nm); + nm = NULL; + } gen->d.dirn = nm; Kurt points out: This looks like a bugfix that should probably go to other branches. But we probably shouldn't touch gen at all in case of failures. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Sun Mar 29 18:06:29 2015 From: rt at openssl.org (cyber flash via RT) Date: Sun, 29 Mar 2015 20:06:29 +0200 Subject: [openssl-dev] [openssl.org #3770] Bug In-Reply-To: References: Message-ID: Customers are unable to view the File Details of OpenSSL.exe (any release, eg., 1.0.1m) to determinethe "File Version", "Product Name", "Copyright", etc.,... the fields are blank: There is a file called ms\version32.rc but does not seem tobe built for OpenSSL.exe. That file follows: #include LANGUAGE 0x09,0x01 1 VERSIONINFO FILEVERSION 1,0,1,13 PRODUCTVERSION 1,0,1,13 FILEFLAGSMASK 0x3fL#ifdef _DEBUG FILEFLAGS 0x01L#else FILEFLAGS 0x00L#endif FILEOS VOS__WINDOWS32 FILETYPE VFT_DLL FILESUBTYPE 0x0LBEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN // Required: VALUE "CompanyName", "The OpenSSL Project, http://www.openssl.org/\0" VALUE "FileDescription", "OpenSSL Shared Library\0" VALUE "FileVersion", "1.0.1m\0"#if defined(CRYPTO) VALUE "InternalName", "libeay32\0" VALUE "OriginalFilename", "libeay32.dll\0"#elif defined(SSL) VALUE "InternalName", "ssleay32\0" VALUE "OriginalFilename", "ssleay32.dll\0"#endif VALUE "ProductName", "The OpenSSL Toolkit\0" VALUE "ProductVersion", "1.0.1m\0" // Optional: //VALUE "Comments", "\0" VALUE "LegalCopyright", "Copyright ? 1998-2005 The OpenSSL Project. Copyright ? 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved.\0" //VALUE "LegalTrademarks", "\0" //VALUE " PrivateBuild", "\0" //VALUE "SpecialBuild", "\0" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 0x4b0 ENDEND I've tried embedding "version32.res" after the build process directly into OpenSSL.exebut it corrupts the EXE for win32. I've spot checked many OpenSSL.exe builds on the internet and none show any info on the Details Tab. Testing with win7 pro x64. Also, tried adding this to the nt.mak file hoping to associate the version info with Openssl.exe: $(OBJ_D)\$(CRYPTO).res: ms\version32.rc $(RSC) /fo"$(OBJ_D)\$(CRYPTO).res" /d CRYPTO ms\version32.rc $(OBJ_D)\$(SSL).res: ms\version32.rc $(RSC) /fo"$(OBJ_D)\$(SSL).res" /d SSL ms\version32.rc $(OBJ_D)\$(E_EXE).res: ms\version32.rc $(RSC) /fo"$(OBJ_D)\$(E_EXE).res" /d E_EXE ms\version32.rc but nothing displays. Would be grateful if someone knows how-to successfully build any windows OpenSSL.exe versionthat contains the missing fields on the Details Tab. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: Capture.PNG Type: image/png Size: 16520 bytes Desc: not available URL: From rt at openssl.org Mon Mar 30 07:51:17 2015 From: rt at openssl.org (John Denker via RT) Date: Mon, 30 Mar 2015 09:51:17 +0200 Subject: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu In-Reply-To: <55183F19.1020608@av8n.com> References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Contrast the following two examples: #1: time : | openssl s_client -connect www.openssl.org:443 >& /dev/null real 0m0.545s user 0m0.000s sys 0m0.000s #2: time : | openssl s_client -quiet -connect www.openssl.org:443 >& /dev/null real 0m21.255s user 0m9.500s sys 0m11.180s - ----------- Note the numerology: 21.225 - 9.5 - 11.18 = 0.545 That means that if you discount the half second it takes to actually fetch the certificate, s_client was using 100% of the cpu the whole time ... for more than 20 seconds. I cannot imagine why it loops when "-quiet" is specified and not otherwise. I cannot imagine why it loops for 20.5 seconds instead of 20.5 minutes or 20.5 hours. This is 100% reproducible chez moi, although the timings naturally vary by a little bit. (gdb) where #0 0x00007ffff7903653 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000000000434d73 in s_client_main (argc=0, argv=0x7fffffffe680) at s_client.c:1794 #2 0x00000000004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffffffe660) at openssl.c:470 #3 0x00000000004035b8 in main (Argc=4, Argv=0x7fffffffe660) at openssl.c:366 openssl version OpenSSL 1.1.0-dev xx XXX xxxx (latest github version) Same symptoms observed in older versions: openssl version OpenSSL 1.0.1f 6 Jan 2014 uname -a Linux asclepias 3.18.0+ #2 SMP Sun Dec 21 18:25:03 MST 2014 x86_64 x86_64 x86_64 GNU/Linux ========= Obvious workaround: Don't specify the "-quiet" option. There are other ways of dealing with the unwanted prolixity. Priority: low. Compared to actual security problems such as the nameconstraints bypass bug [openssl.org #3502] this is nothing. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVRg/GPO9SFghczXtAQJfwxAAzbmfw1gCJYNCoxgI0kVX1davQ2tqq9Pv eC5rVzyrh3+ii/PlvgojjOi9KR4o/nOUoy7CzVKTyidG5PTM1J8nNrCrl2H48vic iv6fNVsLxcibPGs7+De2SqZkiJXl2JvgCZuLACljxq39SrKK0SpNKWqM8DyQrnes 3Mfim3vEcPMHj5lrFTWvVP/tT+/aslW1WGHLuh5kh9KHLBoQQCH2kenVD4Rrxz+F pa5PjRVf7rPQEfaFWKBZ2WLwStelp1ZriJN1TxEXPqWqZsWlUnKwJUhZZaAnBdUt z4Vj9MhgQDPMnyWDy8sVb/5BAyiMoTL6/DJfm949tn3rsef6UHtCu3iHg+GRDTVP AQ6I8TmGnQMpXGTQnmLA5fyHrmGlSbcdmcSDQaIA1noKuWyORT4/CBNMftt+A5gV MuWrSdZg4/l1Tkon4712v3yucg9r2WSMbz5hEGxw99MVd7Kk27OHfSYrDowYvjKC vwBtABvXTmsR387pkcTDpuRU8Ayk/OXM1cbkuK7Vsadr2sfcwvi6iuL02NVDITwQ XyksioIKPf76pXJt5aUOwjnVdRN0XN67LdHSSBZlmjEImUYQxswmZDuWZbdm/ECr 5Ahxeij8wkNZUKDCMCa2HScbQGlx9YveI+jDs2m5pB40lDcSWTqm+FmHtCVImi++ 0atbpVOZanc= =oaVD -----END PGP SIGNATURE----- From rt at openssl.org Mon Mar 30 07:51:30 2015 From: rt at openssl.org (esadovoi@eniks.com via RT) Date: Mon, 30 Mar 2015 09:51:30 +0200 Subject: [openssl-dev] [openssl.org #3772] Bug: Only ActivePerl could be used to build on Windows In-Reply-To: References: Message-ID: It is well known issue with build on Windows: It requires ActivePerl to correctly create configuration. Every other Perl implementation fails to execute correctly. The reason it fails outlined in this report: https://github.com/openssl/openssl/issues/174 Although it is stated that only cloned code exhibits this behavior I believe it also happens when Git or Strawberry Perl is being used for build of official releases. As suggested in the comments adding $/= "\r\n"; line to Perl script fixes this issue for every other Perl implementation. I've successfully built openssl with Perl distributed with Git as well as Strawberry Perl. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6323 bytes Desc: not available URL: From rainer.jung at kippdata.de Mon Mar 30 08:27:24 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 30 Mar 2015 10:27:24 +0200 Subject: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu In-Reply-To: References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> Message-ID: <551908EC.4030101@kippdata.de> Am 30.03.2015 um 09:51 schrieb John Denker via RT: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Contrast the following two examples: > > #1: > time : | openssl s_client -connect www.openssl.org:443 >& /dev/null > > real 0m0.545s > user 0m0.000s > sys 0m0.000s > > #2: > time : | openssl s_client -quiet -connect www.openssl.org:443 >& /dev/null > > real 0m21.255s > user 0m9.500s > sys 0m11.180s > > - ----------- > > Note the numerology: 21.225 - 9.5 - 11.18 = 0.545 > That means that if you discount the half second it takes to actually > fetch the certificate, s_client was using 100% of the cpu the whole > time ... for more than 20 seconds. > > I cannot imagine why it loops when "-quiet" is specified and not > otherwise. I cannot imagine why it loops for 20.5 seconds instead > of 20.5 minutes or 20.5 hours. > > This is 100% reproducible chez moi, although the timings naturally > vary by a little bit. > > > (gdb) where > #0 0x00007ffff7903653 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:81 > #1 0x0000000000434d73 in s_client_main (argc=0, argv=0x7fffffffe680) at s_client.c:1794 > #2 0x00000000004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffffffe660) at openssl.c:470 > #3 0x00000000004035b8 in main (Argc=4, Argv=0x7fffffffe660) at openssl.c:366 That's maybe due to your chosen pipe shell construct. I can see the same behavior, if I choose to let s_client read from /dev/null and set "-quiet". It then loops trying to read from /dev/null, getting 0 bytes but not EOF back. Without -quiet this does not happen. More precisely it seems to happen with -ign_eof, which is set as a side effect of -quiet. Reading from /dev/null without -ign_eof lets s_client end immediately after the connect, with -ign_eof it hangs for 20 seconds (web server timeout?) and eats 1 CPU during that time doing a lot of reads from /dev/null. The behavior is probably due to the following code snippet in s_client: ... i = raw_read_stdin(cbuf, BUFSIZZ); if ((!c_ign_eof) && ((i <= 0) || (cbuf[0] == 'Q'))) { BIO_printf(bio_err, "DONE\n"); ret = 0; goto shut; } Here I expect i==0, so without -ign_eof the code breaks the loop and goes to "shut". So this probably works as designed and when just running openssl s_client -connect www.openssl.org:443 you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect of -quiet I do not know. Regards, Rainer From rt at openssl.org Mon Mar 30 08:27:55 2015 From: rt at openssl.org (Rainer Jung via RT) Date: Mon, 30 Mar 2015 10:27:55 +0200 Subject: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu In-Reply-To: <551908EC.4030101@kippdata.de> References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> <551908EC.4030101@kippdata.de> Message-ID: Am 30.03.2015 um 09:51 schrieb John Denker via RT: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Contrast the following two examples: > > #1: > time : | openssl s_client -connect www.openssl.org:443 >& /dev/null > > real 0m0.545s > user 0m0.000s > sys 0m0.000s > > #2: > time : | openssl s_client -quiet -connect www.openssl.org:443 >& /dev/null > > real 0m21.255s > user 0m9.500s > sys 0m11.180s > > - ----------- > > Note the numerology: 21.225 - 9.5 - 11.18 = 0.545 > That means that if you discount the half second it takes to actually > fetch the certificate, s_client was using 100% of the cpu the whole > time ... for more than 20 seconds. > > I cannot imagine why it loops when "-quiet" is specified and not > otherwise. I cannot imagine why it loops for 20.5 seconds instead > of 20.5 minutes or 20.5 hours. > > This is 100% reproducible chez moi, although the timings naturally > vary by a little bit. > > > (gdb) where > #0 0x00007ffff7903653 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:81 > #1 0x0000000000434d73 in s_client_main (argc=0, argv=0x7fffffffe680) at s_client.c:1794 > #2 0x00000000004039a8 in do_cmd (prog=0x990540, argc=4, argv=0x7fffffffe660) at openssl.c:470 > #3 0x00000000004035b8 in main (Argc=4, Argv=0x7fffffffe660) at openssl.c:366 That's maybe due to your chosen pipe shell construct. I can see the same behavior, if I choose to let s_client read from /dev/null and set "-quiet". It then loops trying to read from /dev/null, getting 0 bytes but not EOF back. Without -quiet this does not happen. More precisely it seems to happen with -ign_eof, which is set as a side effect of -quiet. Reading from /dev/null without -ign_eof lets s_client end immediately after the connect, with -ign_eof it hangs for 20 seconds (web server timeout?) and eats 1 CPU during that time doing a lot of reads from /dev/null. The behavior is probably due to the following code snippet in s_client: ... i = raw_read_stdin(cbuf, BUFSIZZ); if ((!c_ign_eof) && ((i <= 0) || (cbuf[0] == 'Q'))) { BIO_printf(bio_err, "DONE\n"); ret = 0; goto shut; } Here I expect i==0, so without -ign_eof the code breaks the loop and goes to "shut". So this probably works as designed and when just running openssl s_client -connect www.openssl.org:443 you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect of -quiet I do not know. Regards, Rainer From rainer.jung at kippdata.de Mon Mar 30 08:45:45 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Mon, 30 Mar 2015 10:45:45 +0200 Subject: [openssl-dev] [openssl.org #3771] bug: s_client loop at 100% cpu In-Reply-To: <551908EC.4030101@kippdata.de> References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> <551908EC.4030101@kippdata.de> Message-ID: <55190D39.9030807@kippdata.de> Am 30.03.2015 um 10:27 schrieb Rainer Jung: > So this probably works as designed and when just running > > openssl s_client -connect www.openssl.org:443 Oups, I meant: openssl s_client -quiet -connect www.openssl.org:443 > you shouldn't notice CPU hogging. Why -ign_eof is set as a side effect > of -quiet I do not know. From emilia at openssl.org Mon Mar 30 11:20:24 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 30 Mar 2015 13:20:24 +0200 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> <551465DA.1040508@cisco.com> Message-ID: On Fri, Mar 27, 2015 at 7:19 PM, Erik Tkal wrote: > Hi Emelia, > > I?m not sure that will work as presently designed, as it keys off of the > session object: > > - if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { > + if (s->version >= TLS1_VERSION && s->tls_session_secret_cb && > + s->session->tlsext_tick) { > > Our client uses the public API SSL_set_session_ticket_ext(), which > populates the SSL->tls_session_ticket, and not the SSL->session copy. > Yes, I know - but that would get copied to the session when the extension is first sent. Do you have a way of testing the patch? > > Erik > > > On 27 Mar 2015, at 12:33 PM, Emilia K?sper wrote: > > John, Erik, > > https://github.com/openssl/openssl/pull/250 > > Can you verify whether this resolves the problem? (And also, does not > create any new problems.) > > Note this is pending team review so is not a definitive fix. But since > we're maintaining this feature more or less blind, we'd appreciate your > help testing the fix. > > Thanks, > Emilia > > On Thu, Mar 26, 2015 at 9:02 PM, John Foley wrote: > >> Someone that understands EAP better than myself should probably provide >> input. But my limited understand of EAP-FAST is it contributes to the >> master secret calculation used for the TLS session. See section RFC 4851 >> Section 5.1. My understanding is this logic applies to both new and resumed >> sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST. >> >> >> >> On 03/26/2015 02:13 PM, Emilia K?sper wrote: >> >> >> >> On Tue, Mar 24, 2015 at 2:01 PM, John Foley wrote: >> >>> Trying again w/o PGP... :-) >>> >>> Thanks for taking a look at this problem. Regarding how to handle a >>> failure in the session secret callback, the legacy logic would likely >>> result in a "bad record mac" error because the master secrets on the >>> client/server do not match. >>> >> >> But only in case we are actually resuming - no? Does the client always >> have a PAC available - I would guess not? Seems the legacy logic is such >> that it "happens to work", but I'd like to clear it up. >> >> >>> It would be good to trigger an internal error to aid with >>> troubleshooting. Maybe something like: >>> >>> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >>> goto err; >>> >>> It's debatable whether the alert needs to be sent to the server. Since >>> this is an internal error, it should be safe to send the alert. Therefore, >>> maybe you would actually want to do something like: >>> >>> SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); >>> al = SSL_AD_INTERNAL_ERROR; >>> goto f_err; >>> >>> >>> >>> >>> On 03/23/2015 09:17 PM, Emilia K?sper wrote: >>> >>> >>> >>> On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) >>> wrote: >>> >>>> We've found a way to recreate the scenario using s_client/s_server. >>>> We're using the -no_ticket option on the server. Therefore, the >>>> ServerHello doesn't contain the session ticket extension. It also doesn't >>>> send the NewSessionTicket message. >>>> >>>> To summarize the problem, when the client side is using >>>> SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, >>>> then the logic in ssl3_get_server_hello() assumes the server is doing >>>> session resumption. This puts the client-side state machine into the >>>> SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not >>>> do resumption via the -no_ticket option, the server continues with a normal >>>> handshake by sending the Certificate message. The client aborts the >>>> handshake when it receives the Certificate message while in the >>>> SSL3_ST_CR_FINISHED_A state. >>>> >>>> >>>> As Erik identified earlier in the thread, the cause of this appears to >>>> be the addition of setting s->hit in the following code: >>>> >>>> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >>>> SSL_CIPHER *pref_cipher = NULL; >>>> s->session->master_key_length = sizeof(s->session->master_key); >>>> if (s->tls_session_secret_cb(s, s->session->master_key, >>>> &s->session->master_key_length, >>>> NULL, &pref_cipher, >>>> s->tls_session_secret_cb_arg)) { >>>> s->session->cipher = pref_cipher ? >>>> pref_cipher : ssl_get_cipher_by_char(s, p + j); >>>> s->hit = 1; >>>> } >>>> } >>>> >>>> Why does the client-side now assume the server is doing session >>>> resumption simply because the session secret callback facility is being >>>> used? >>>> >>> >>> Because a developer (me) introduced a bug. With OpenSSL client >>> behaviour, peeking ahead is only required for EAP-FAST. I got rid of the >>> peeking while tightening up the ChangeCipherSpec handling and in the >>> process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem >>> and am working on a patch. >>> >>> While we're at it, you may be able to help me with the following >>> question: how should the client handle callback failure? The old code (pre >>> my refactoring which introduced the bug) did this >>> >>> #ifndef OPENSSL_NO_TLSEXT >>> /* check if we want to resume the session based on external pre-shared secret */ >>> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) >>> { >>> SSL_CIPHER *pref_cipher=NULL; >>> s->session->master_key_length=sizeof(s->session->master_key); >>> if (s->tls_session_secret_cb(s, s->session->master_key, >>> &s->session->master_key_length, >>> NULL, &pref_cipher, >>> s->tls_session_secret_cb_arg)) >>> { >>> s->session->cipher = pref_cipher ? >>> pref_cipher : ssl_get_cipher_by_char(s, p+j); >>> } >>> } >>> #endif /* OPENSSL_NO_TLSEXT */ >>> >>> This is surely wrong as it's just ignoring the failure? >>> >>> Thanks, >>> >>> Emilia >>> >>> ________________________________________ >>>> From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Dr. >>>> Stephen Henson [steve at openssl.org] >>>> Sent: Thursday, March 19, 2015 11:49 AM >>>> To: openssl-dev at openssl.org >>>> Subject: Re: [openssl-dev] s3_clnt.c changes regarding external >>>> pre-shared secret seem to break EAP-FAST >>>> >>>> On Thu, Mar 19, 2015, Erik Tkal wrote: >>>> >>>> > >>>> > If I do not send a sessionID in the clientHello but do send a valid >>>> > sessionTicket extension, the server goes straight to changeCipherSpec >>>> and >>>> > the client generates an UnexpectedMessage alert. >>>> > >>>> >>>> Does the server send back an empty session ticket extension? >>>> >>>> Steve. >>>> -- >>>> Dr Stephen N. Henson. OpenSSL project core developer. >>>> Commercial tech support now available see: http://www.openssl.org >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 emilia at openssl.org Mon Mar 30 11:49:47 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Mon, 30 Mar 2015 13:49:47 +0200 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith wrote: > Brian Smith wrote: > > Although the RFC4851 (an informational RFC documenting EAP-FAST) does > > not require the server to send the session ticket extension during > > resumption, it is based on RFC4507/RFC5077 (which are on the standards > > track), which *does* require the server to send the extension. So, > > this is a bug in the non-conformant servers, not in the openssl > > client. > > Sorry. It seems I am wrong about this. RFC 5077 says "It is also > permissible to have an exchange similar to Figure 3 using the > abbreviated handshake defined in Figure 2 of RFC 4346, where the > client uses the SessionTicket extension to resume the session, but the > server does not wish to issue a new ticket, and therefore does not > send a SessionTicket extension." > > AFAICT this means that, even outside of EAP-FAST, it is allowed for > the server to resume a session using a session ticket without sending > the session ticket extension in its ServerHello message. > Correct, but outside EAP-FAST we use the session ID to detect if we're resuming. Honouring the synthetic session ID is a MUST in RFC5077. I have asked, in a separate thread with Erik, whether EAP-FAST servers would honour the session ID (so we could set it and detect resumption based on that) but the answer appears to be "no". > Also, note that RFC 5077 section 3.4 allows the client to use a > session ticket and an empty session ID to resume a session, instead of > generating a "fake" session ID for the session ticket: "Alternatively, > the client MAY include an empty Session ID in the ClientHello. In > this case, the client ignores the Session ID sent in the ServerHello > and determines if the server is resuming a session by the subsequent > handshake messages." > > If OpenSSL's client code were changed to always use an empty session > ID when attempting resumption using a session ticket, then the > EAP-FAST case wouldn't be different from the general session ticket > resumption case. I think that this is a cleaner approach. > 1) The way EAP-FAST diverges from 5246 and 5077 is indeed quite unfortunate. The lookahead is messy, and hard to get right - I don't want another "early CCS" due to lack of determinism in the state machine. Setting the session ID is much cleaner. So, I'd rather put in a workaround that is specific to EAP-FAST and doesn't affect regular handshakes. 2) Removing the session ID upon resumption would be a big change in behaviour that I don't think would qualify for a stable branch anyway unless there was a security or regression issue behind it. But thanks a lot for diving into the RFCs! A second pair of eyes is very much needed here. Cheers, Emilia > Note that RFC4851 would likely still need to be updated, because TLS > 1.3 will most likely remove the ChangeCipherSpec messages, and > RFC4851's recommended resumption detection is based on detecting > ChangeCipherSpec messages. > Cheers, > Brian > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Mar 30 12:20:18 2015 From: rt at openssl.org (Andrew Moon via RT) Date: Mon, 30 Mar 2015 14:20:18 +0200 Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface In-Reply-To: References: Message-ID: (I hope I'm doing this right) These are my Chacha implementations for reference, x86, SSE2, SSSE3, XOP, AVX, and AVX2, and Poly1305 implementations for reference, SSE2, AVX, and AVX2 for both 32 and 64 bits. (djb's floating point poly1305 is used for 32 bits). I do things a bit differently with the assembler code to make supporting multiple versions easier, I don't know if it is too non-standard or not. Everything is as fast as possible, so hopefully some or all of it can be used to fill things out, or give you ideas on how to surpass it. (I have 32 bit ARM and NEON versions as well, but no ARM to test on atm). crypto/perlasm/x86gas.pl had to be modified to get AVX2 and floating point working for 32 bit code. (The floating point modifications are a bit of a hack, I apologize in advance). Also included is an EVP cipher compatible with Chrome's Chacha20-Poly1305 TLS implementation optimized for short messages that takes advantage of however optimized the underlying asm is. The cfrg draft isn't final so I didn't bother to add a generic AEAD construction for it, but the implementations are extremely flexible and can handle whatever is finalized. I didn't create a patch because I have no idea how you want to integrate everything in to the Makefiles/SSL, but it plugs in over this patch fairly easily. CHACHA_ASM_X86/POLY1305_ASM_X86, and CHACHA_ASM_X86_64/POLY1305_ASM_X86_64 are the defines it looks for, and everything else straightforward. -------------- next part -------------- A non-text attachment was scrubbed... Name: chacha_poly1305.tar.gz Type: application/x-gzip Size: 73804 bytes Desc: not available URL: From nmav at redhat.com Mon Mar 30 13:56:35 2015 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Mon, 30 Mar 2015 15:56:35 +0200 Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface In-Reply-To: References: Message-ID: <1427723795.3073.22.camel@redhat.com> On Mon, 2015-03-30 at 14:20 +0200, Andrew Moon via RT wrote: > Also included is an EVP cipher compatible with Chrome's Chacha20-Poly1305 > TLS implementation optimized for short messages that takes advantage of > however optimized the underlying asm is. The cfrg draft isn't final The CFRG draft is final. It has been accepted and sent to RFC editor. https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/ regards, Nikos From jeremy.farrell at oracle.com Mon Mar 30 16:37:47 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 30 Mar 2015 17:37:47 +0100 Subject: [openssl-dev] [openssl.org #3772] Bug: Only ActivePerl could be used to build on Windows In-Reply-To: References: Message-ID: <55197BDB.7050308@oracle.com> For what it's worth: I've been building OpenSSL releases on Windows for many years without problems, and I've only ever used Strawberry Perl. I don't think the problem applies to official release tarballs. On 30/03/2015 08:51, esadovoi at eniks.com via RT wrote: > It is well known issue with build on Windows: It requires ActivePerl to > correctly create configuration. > Every other Perl implementation fails to execute correctly. The reason it > fails outlined in this report: https://github.com/openssl/openssl/issues/174 > Although it is stated that only cloned code exhibits this behavior I believe > it also happens when Git or Strawberry Perl is being used for build of > official releases. > > As suggested in the comments adding $/= "\r\n"; line to Perl script fixes this > issue for every other Perl implementation. > I've successfully built openssl with Perl distributed with Git as well as > Strawberry Perl. -- J. J. Farrell w: +44 161 493 4838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Mar 30 17:54:21 2015 From: rt at openssl.org (Marisetti, Balaji via RT) Date: Mon, 30 Mar 2015 19:54:21 +0200 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: <1427720548359.36445@caviumnetworks.com> References: <1427720548359.36445@caviumnetworks.com> Message-ID: This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. Thanks, Balaji M -------------- next part -------------- A non-text attachment was scrubbed... Name: octeon-configure.patch Type: text/x-patch Size: 1280 bytes Desc: not available URL: From rt at openssl.org Tue Mar 31 04:19:30 2015 From: rt at openssl.org (=?UTF-8?B?TWFydGluIFZlam7DoXI=?= via RT) Date: Tue, 31 Mar 2015 06:19:30 +0200 Subject: [openssl-dev] [openssl.org #3774] Double free in dsa_priv_encode In-Reply-To: <908fd54a4da04c288e2749b21318fd98@EX13-CZ-03.cz.avg.com> References: <908fd54a4da04c288e2749b21318fd98@EX13-CZ-03.cz.avg.com> Message-ID: Hi, in version 1.0.2, in crypto/dsa/dsa/ameth.c, line 318 frees `prkey`, which may be freed again on line 332 if the call on line 320 fails. 318 ASN1_INTEGER_free(prkey); 319 320 if (!PKCS8_pkey_set0(p8, OBJ_nid2obj(NID_dsa), 0, 321 V_ASN1_SEQUENCE, params, dp, dplen)) 322 goto err; 323 324 return 1; 325 326 err: 327 if (dp != NULL) 328 OPENSSL_free(dp); 329 if (params != NULL) 330 ASN1_STRING_free(params); 331 if (prkey != NULL) 332 ASN1_INTEGER_free(prkey); -- Martin From julien.kauffmann at freelan.org Tue Mar 31 12:36:37 2015 From: julien.kauffmann at freelan.org (Julien Kauffmann) Date: Tue, 31 Mar 2015 08:36:37 -0400 Subject: [openssl-dev] Heap corruption in asn1_item_ex_combine_new() Message-ID: <551A94D5.2040507@freelan.org> Hi, I've been hunting down a heap corruption bug in OpenSSL for the past few days and I found the guilty instruction. At this point, I know what causes the problem but I am unsure how to solve it nicely. Here is the minimal sample I used to reproduce the issue on the latest 1.0.2a (happens on every run, on all platforms in 64 bits): int main() { ERR_load_crypto_strings(); OpenSSL_add_all_algorithms(); ENGINE_load_builtin_engines(); EC_GROUP* group = EC_GROUP_new_by_curve_name(NID_sect571k1); EC_GROUP_set_point_conversion_form(group, POINT_CONVERSION_UNCOMPRESSED); EC_KEY* eckey = EC_KEY_new(); EC_KEY_set_group(eckey, group); EC_KEY_generate_key(eckey); BIO* out = BIO_new(BIO_s_file()); BIO_set_fp(out, stdout, BIO_NOCLOSE); PEM_write_bio_ECPrivateKey(out, eckey, NULL, NULL, 0, NULL, NULL); } Basically what happens is that, somewhere inside the call to PEM_write_bio_ECPrivateKey(), an ASN1 sequence of 3 elements is allocated. The corresponding code is as follow (in crypto/asn1/tasn_new.c:181): if (!combine) { *pval = OPENSSL_malloc(it->size); if (!*pval) goto memerr; memset(*pval, 0, it->size); asn1_do_lock(pval, 0, it); asn1_enc_init(pval, it); } for (i = 0, tt = it->templates; i < it->tcount; tt++, i++) { pseqval = asn1_get_field_ptr(pval, tt); if (!ASN1_template_new(pseqval, tt)) goto memerr; } In the sample I gave, at some point OPENSSL_malloc allocates 12 bytes for a 3-elements ASN1 SEQUENCE. The for-loop then initializes every element: ASN1_template_new() calls in turn asn1_item_ex_combine_new() which, at line 103, does: if (!combine) *pval = NULL; The problem is that pval at this point points to an element of the SEQUENCE that is only 4 bytes long. On 64 bits systems this causes the next 4 bytes to be set to 0x00000000. For the first two elements of the sequence, this gets recovered by the next element being initialized. However for the last element, this affectation happens to write 4 bytes past the allocated memory, corrupting the heap. I'm not sure what is the best place to fix this. Do you have any hints ? Julien Kauffmann. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4276 bytes Desc: Signature cryptographique S/MIME URL: From matt at openssl.org Tue Mar 31 15:47:01 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 31 Mar 2015 16:47:01 +0100 Subject: [openssl-dev] Reminder: OpenSSL's EC private key encoding is broken In-Reply-To: <5513477D.4080502@gmail.com> References: <56423.141.39.13.45.1427195422.squirrel@www2.informatik.hu-berlin.de> <5511B028.9040005@gmail.com> <551329C9.9090208@informatik.hu-berlin.de> <5513477D.4080502@gmail.com> Message-ID: <551AC175.1080700@openssl.org> On 25/03/15 23:40, Douglas E Engert wrote: > > The attached patch against https://github.com/openssl/openssl > makes sure the EC private key in an OCTETSTRING retains leading zeros > when converting from BIGNUM to OCTETSTRING. > Thanks for the patch. This has been applied. Matt From rt at openssl.org Tue Mar 31 16:51:49 2015 From: rt at openssl.org (Pevnev, Andrey via RT) Date: Tue, 31 Mar 2015 18:51:49 +0200 Subject: [openssl-dev] [openssl.org #3775] BUG REPORT: misspelled UNKOWN in the source code In-Reply-To: <49480E6BCE32784D89E6AC37C0A0C11B150DF9AA@G4W3222.americas.hpqcorp.net> References: <49480E6BCE32784D89E6AC37C0A0C11B150DF9AA@G4W3222.americas.hpqcorp.net> Message-ID: Hi! This is no impact but it would be nice to have UNKNOWN spelled right. Thank you! /home/pevnev/tmp/openssl-1.0.2a/crypto/asn1 [pevnev at blessed03 asn1]$ grep UNKOWN * asn1_err.c: {ERR_REASON(ASN1_R_UNKOWN_FORMAT), "unknown format"}, asn1_gen.c: ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT); asn1.h:# define ASN1_R_UNKOWN_FORMAT 195 --- Best regards, Andrey Pevnev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6184 bytes Desc: not available URL: From etksubs at gmail.com Tue Mar 31 21:23:45 2015 From: etksubs at gmail.com (Erik Tkal) Date: Tue, 31 Mar 2015 17:23:45 -0400 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> <3ABD7150-1403-464E-8FDD-4B5135FE9CED@gmail.com> <9E24F515-185E-4EAD-AFD4-15A5EC824572@gmail.com> <20150319154902.GA31792@openssl.org> <56838E71322DA64E9AFDDA560D7B19DF16DADBAC@xmb-rcd-x13.cisco.com> <55116016.8010105@cisco.com> <551465DA.1040508@cisco.com> Message-ID: <825C1DFF-08DD-411F-AE26-88110ACBFD4B@gmail.com> Hi Emilia, I was able to test the patch and it does successfully now allow the server to fall back to a Certificate message if it does not accept the SessionTicket sent by the client. Thanks for your help, Erik On 27 Mar2015, at 12:33, Emilia K?sper wrote: John, Erik, https://github.com/openssl/openssl/pull/250 Can you verify whether this resolves the problem? (And also, does not create any new problems.) Note this is pending team review so is not a definitive fix. But since we're maintaining this feature more or less blind, we'd appreciate your help testing the fix. Thanks, Emilia On Thu, Mar 26, 2015 at 9:02 PM, John Foley > wrote: Someone that understands EAP better than myself should probably provide input. But my limited understand of EAP-FAST is it contributes to the master secret calculation used for the TLS session. See section RFC 4851 Section 5.1. My understanding is this logic applies to both new and resumed sessions. Hence, tls_session_secret_cb() is always in play for EAP-FAST. On 03/26/2015 02:13 PM, Emilia K?sper wrote: > > > On Tue, Mar 24, 2015 at 2:01 PM, John Foley > wrote: > Trying again w/o PGP... :-) > > Thanks for taking a look at this problem. Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match. > > But only in case we are actually resuming - no? Does the client always have a PAC available - I would guess not? Seems the legacy logic is such that it "happens to work", but I'd like to clear it up. > > It would be good to trigger an internal error to aid with troubleshooting. Maybe something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > goto err; > > It's debatable whether the alert needs to be sent to the server. Since this is an internal error, it should be safe to send the alert. Therefore, maybe you would actually want to do something like: > > SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR); > al = SSL_AD_INTERNAL_ERROR; > goto f_err; > > > > > On 03/23/2015 09:17 PM, Emilia K?sper wrote: >> >> >> On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) > wrote: >> We've found a way to recreate the scenario using s_client/s_server. We're using the -no_ticket option on the server. Therefore, the ServerHello doesn't contain the session ticket extension. It also doesn't send the NewSessionTicket message. >> >> To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption. This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A. However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message. The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state. >> >> >> As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code: >> >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) { >> SSL_CIPHER *pref_cipher = NULL; >> s->session->master_key_length = sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p + j); >> s->hit = 1; >> } >> } >> >> Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used? >> >> Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch. >> >> While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this >> >> #ifndef OPENSSL_NO_TLSEXT >> /* check if we want to resume the session based on external pre-shared secret */ >> if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) >> { >> SSL_CIPHER *pref_cipher=NULL; >> s->session->master_key_length=sizeof(s->session->master_key); >> if (s->tls_session_secret_cb(s, s->session->master_key, >> &s->session->master_key_length, >> NULL, &pref_cipher, >> s->tls_session_secret_cb_arg)) >> { >> s->session->cipher = pref_cipher ? >> pref_cipher : ssl_get_cipher_by_char(s, p+j); >> } >> } >> #endif /* OPENSSL_NO_TLSEXT */ >> This is surely wrong as it's just ignoring the failure? >> Thanks, >> Emilia >> ________________________________________ >> From: openssl-dev [openssl-dev-bounces at openssl.org ] on behalf of Dr. Stephen Henson [steve at openssl.org ] >> Sent: Thursday, March 19, 2015 11:49 AM >> To: openssl-dev at openssl.org >> Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST >> >> On Thu, Mar 19, 2015, Erik Tkal wrote: >> >> > >> > If I do not send a sessionID in the clientHello but do send a valid >> > sessionTicket extension, the server goes straight to changeCipherSpec and >> > the client generates an UnexpectedMessage alert. >> > >> >> Does the server send back an empty session ticket extension? >> >> Steve. >> -- >> Dr Stephen N. Henson. OpenSSL project core developer. >> Commercial tech support now available see: http://www.openssl.org >> _______________________________________________ >> 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 > > > _______________________________________________ > 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: