From rt at openssl.org Thu Jan 1 17:03:04 2015 From: rt at openssl.org (John Denker via RT) Date: Thu, 1 Jan 2015 18:03:04 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <54A57C1F.5080806@av8n.com> References: <543B2685.3070801@av8n.com> <54A57C1F.5080806@av8n.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/31/2014 10:31 AM, Rich Salz via RT wrote: > This patch from Steve Henson seems better I am happy with the proposed patch. I have looked at the code, and also tested it operationally. The semantics is reasonable. ++ This is what I was arguing for initially. ++ It is AFAICT consistent with Mozilla behavior. ++ It is more strict than pk11-kit (lynx) behavior; see below for details. > and a good candidate for 1.0.2 and master... OK, good, the sooner the better. This is a "security issue" in the sense that is a Type-II error (disallowing good guys). It affects thousands of sites and who-knows-how-many users. It is not a Type-I error (letting bad guys in) and it affects "only" thousands of sites, not millions, so it is not in the same category as heartbleed ... but still it is well worth fixing, the sooner the better. *** It would make sense to fix the nameConstraints bypass bug *** [openssl.org #3502] at the same time. *** Otherwise the whole nameConstraints concept is pretty much *** pointless. http://rt.openssl.org/Ticket/Display.html?id=3502 - ---------------------- Test results: The Henson patch does what it is supposed to: :| $newopenssl s_client -verify 10 -CAfile /usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt -connect auth.edu.gr:443 |& egrep 'Verify' Verify return code: 0 (ok) For more detailed checks, we can use the following signing CA: wget http://www.av8n.com/pdq-root-ca-cert.pem echo 5d9f030c791bcace3580f38286a49c4f /tmp/pdq-root-ca-cert.pem | md5sum -c - Here is another example of the patch allowing stuff, as it should: :| $newopenssl s_client -verify 10 -CAfile pdq-root-ca-cert.pem -connect www.pdq.av8n.com:1446 |& egrep 'Verify' Verify return code: 0 (ok) Here it is disallowing some things, as it should: A rule with a leading dot does /not/ match a domain name without a corresponding dot: :| $newopenssl s_client -verify 10 -CAfile pdq-root-ca-cert.pem -connect pdq.av8n.com:1445 |& egrep 'Verify' Verify return code: 47 (permitted subtree violation) In contrast, note that pk11-kit is more tolerant, and totally ignores the leading dot: SSL_CERT_FILE=pdq-root-ca-cert.pem lynx -source https://pdq.av8n.com:1445/cgi-bin/ipaddr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBVKV8H/O9SFghczXtAQIQIBAAiBsPoCiRqzKqZpE4hNmefyWaFlLagVQ0 Abhw5tBFCULwjGE5f4VlAil/1dNVro3Qlp7yvZ8qIXKkvJ3hk9gO6rUId6hP74Qy xtAiBvs4az+IpxImQ91RRnw+ZYtf9IghKNSQyPkBDVpNMtlr7zr/OTe6ksgH0/h6 HhfKs7YuZ7RkCHmPjL7qDzFSfMxoFQSIXDguBFTrOrLmeOv7XG3O3ZvKnpcH/79M DcxhUATvzzXyoYN9mtkbgw4W13Gcl0ds8S/zeFuencH2UvBVYPBZl/UTDf2stwya wvizplcopgQikTd/p1D+5GnfaBUzRS2YopY77GQIokca0pLq/uO5XRBx/l8jQidX i0KGvVWRsP1Oud0yJ/Ba8pMwunJwkzWpcvoV1kk1copm/KuZwZGb4k2PpQTLGBsG czbRvHm5FbCRE7WDxGpO3GjtqcWZpY5kMlxUe8/yhnTvYQrcXgf7pUChBouS6Un9 GHq1uLGymIP6OtqzIpd0NSR2Fo1JU28mCGJs6gN+r7QtL5FoKpRo+16UrfHvBSt5 D1KuGjOCEb7JSxjsGIVaGK/lFQjMBksqG8MXj4xUR3UB7udj8tjBfxF1X3/rFk9M fvkhMqw2zh8CvzzvIe3URy5t4rVooZ0Alwk7Q9imN4gI7tt8HrSadB5pwsTjfe0E p3Sg79BLMM4= =fbFv -----END PGP SIGNATURE----- From rsalz at akamai.com Thu Jan 1 19:06:56 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Jan 2015 14:06:56 -0500 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: References: <543B2685.3070801@av8n.com> <54A57C1F.5080806@av8n.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D552372FD@USMBX1.msg.corp.akamai.com> > This is a "security issue" in the sense that is a Type-II error (disallowing good > guys). It affects thousands of sites and who-knows-how-many users. Well, kinda. It disallows good guys who made a mistake and are violating the RFC. Sure, they're not written in stone and that particular RFC has its share of issues, but calling this a security issue doesn't seem right. Allowing greater interop, with minimal security exposure, seems a better way to put it. A more compliant fix is to re-issue the CA and its subordinates, while working the RFC issues through the IETF. But OpenSSL is very pragmatic. > *** It would make sense to fix the nameConstraints bypass bug > *** [openssl.org #3502] at the same time. That's a bigger change and the RT commentary has lots of caveats about the code there as you know (since you wrote them). > *** Otherwise the whole nameConstraints concept is pretty much > *** pointless. There are those who think that anyway. From rt at openssl.org Thu Jan 1 19:07:07 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 1 Jan 2015 20:07:07 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D552372FD@USMBX1.msg.corp.akamai.com> References: <543B2685.3070801@av8n.com> <54A57C1F.5080806@av8n.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D552372FD@USMBX1.msg.corp.akamai.com> Message-ID: > This is a "security issue" in the sense that is a Type-II error (disallowing good > guys). It affects thousands of sites and who-knows-how-many users. Well, kinda. It disallows good guys who made a mistake and are violating the RFC. Sure, they're not written in stone and that particular RFC has its share of issues, but calling this a security issue doesn't seem right. Allowing greater interop, with minimal security exposure, seems a better way to put it. A more compliant fix is to re-issue the CA and its subordinates, while working the RFC issues through the IETF. But OpenSSL is very pragmatic. > *** It would make sense to fix the nameConstraints bypass bug > *** [openssl.org #3502] at the same time. That's a bigger change and the RT commentary has lots of caveats about the code there as you know (since you wrote them). > *** Otherwise the whole nameConstraints concept is pretty much > *** pointless. There are those who think that anyway. From rt at openssl.org Thu Jan 1 22:08:22 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 1 Jan 2015 23:08:22 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <20150101220811.GA3141@roeckx.be> References: <543B2685.3070801@av8n.com> <54A57C1F.5080806@av8n.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D552372FD@USMBX1.msg.corp.akamai.com> <20150101220811.GA3141@roeckx.be> Message-ID: On Thu, Jan 01, 2015 at 02:06:56PM -0500, Salz, Rich wrote: > > This is a "security issue" in the sense that is a Type-II error (disallowing good > > guys). It affects thousands of sites and who-knows-how-many users. > > Well, kinda. It disallows good guys who made a mistake and are violating the RFC. Sure, they're not written in stone and that particular RFC has its share of issues, but calling this a security issue doesn't seem right. Allowing greater interop, with minimal security exposure, seems a better way to put it. A more compliant fix is to re-issue the CA and its subordinates, while working the RFC issues through the IETF. But OpenSSL is very pragmatic. You could either see this as violating the RFC or that it's undefined in the RFC. For email and others the RFC says it's about a hostname without the '.' and so doesn't allow an extra label on the left side. If it has the '.' it's about a domain, and it doesn't match as hostname and so requires 1 or more labels on the left side. For DNS it both the hostname and domain. It allows 0 or more extra labels. In the intermediate CA you see them use: DNS:auth.gr email:auth.gr email:.auth.gr The email is there twice to have both the 0 and 1+, while for DNS this isn't needed since it's 0+. The patch would change the behaviour that you can have both 0+ (without '.') and 1+ (with '.'). (I think the original patch changed both of them to 0+.) This would then make it possible for them to say that their root CA can't issue a certificate covering whole .gr but that it needs have at least 1 extra label. I can only really see this as being useful for a TLD. But then I would also think that they don't trust themself. It's my understanding that the only certificate that has a problem is the root CA itself, since that has "DNS:.gr" in it. So in theory the only thing they should do is replace the root CA and have it sign the intermediates again. Kurt From tarunpolisetti at gmail.com Fri Jan 2 12:42:15 2015 From: tarunpolisetti at gmail.com (T@Run..............! Polisetty) Date: Fri, 2 Jan 2015 18:12:15 +0530 Subject: [openssl-dev] Release date of OpenSSL1.0.2 Message-ID: Hai All, Can you please let me know the approximate release date of OpenSSL1.0.2 Regards Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Jan 2 22:32:30 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 2 Jan 2015 23:32:30 +0100 Subject: [openssl-dev] [openssl.org #153] Public API for sending SSL/TLS alerts wanted In-Reply-To: References: Message-ID: I think this is cool, but after a dozen years it's clearly not gonna happen. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 2 22:36:03 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 2 Jan 2015 23:36:03 +0100 Subject: [openssl-dev] [openssl.org #738] enhancement request In-Reply-To: <200310211317.h9LDH0e02988@chandon.edelweb.fr> References: <200310211317.h9LDH0e02988@chandon.edelweb.fr> Message-ID: Useful, but after more than a decade apparently not all that useful or important. Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 2 23:04:20 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 3 Jan 2015 00:04:20 +0100 Subject: [openssl-dev] [openssl.org #2855] [PATCH] Fix forward loops in Squid 3.2 In-Reply-To: <1343401920.2531.40.camel@linux-iz21> References: <1343401920.2531.40.camel@linux-iz21> Message-ID: squid bug, not openssl -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 2 23:07:36 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 3 Jan 2015 00:07:36 +0100 Subject: [openssl-dev] [openssl.org #2857] ssleay32's buffer check bug ? In-Reply-To: References: Message-ID: Lots of local changes. This doesn't happen in the reference code. Closing ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 2 23:11:27 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 3 Jan 2015 00:11:27 +0100 Subject: [openssl-dev] [openssl.org #2864] ASN1_STRING_to_UTF8: fix uninitialized memory read In-Reply-To: References: Message-ID: already fixed ; g show 7f429a5dbf715edace5908dfb4ea4c44815c0fb4 commit 7f429a5dbf715edace5908dfb4ea4c44815c0fb4 Author: Bodo Mller Date: Mon Sep 24 19:49:16 2012 +0000 Fix Valgrind warning. Submitted by: Adam Langley -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 2 23:13:43 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 3 Jan 2015 00:13:43 +0100 Subject: [openssl-dev] [openssl.org #2649] 'make' or 'make install' failed when in another Makefile In-Reply-To: <8B08B66A4C097F428BF7BCC5B245019B5F8E27CA9F@CNHZ-EXCMS-04.ali.com> References: <8B08B66A4C097F428BF7BCC5B245019B5F8E27CA9F@CNHZ-EXCMS-04.ali.com> Message-ID: Seems like an itnegration issue with nginx makefile stuff. Not an openssl bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From Satish.KumarYarru at cognizant.com Sat Jan 3 06:44:28 2015 From: Satish.KumarYarru at cognizant.com (Satish.KumarYarru at cognizant.com) Date: Sat, 3 Jan 2015 06:44:28 +0000 Subject: [openssl-dev] Client Certificate sent though SSL client is configured with NO authentication Message-ID: Hi, I have configured my SSL client with VERIFY_NONE. But when I perform handshake with SSL Server that is configured with "Dual Authentication", Client is still sending Client Certificate for the Certificate Request sent by client. But ideally client should not send certificate as the SSL client is configured with NO Authentication. Correct me if I am wrong. When I debugged, I found client is sending the certificate because Client Certificate is NOT un-loaded in SSL context when client is configured with VERIFY_NONE. OpenSSL is not providing any API to unload certificate from the SSL context. Can you please help me on how to address this issue? 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. From a.yousar at informatik.hu-berlin.de Sat Jan 3 12:41:29 2015 From: a.yousar at informatik.hu-berlin.de (Annie Yousar) Date: Sat, 3 Jan 2015 13:41:29 +0100 (CET) Subject: [openssl-dev] EC key generation in broken in all versions Message-ID: <1347.79.218.222.136.1420288889.squirrel@www2.informatik.hu-berlin.de> Dear all, -----Facts----- The private EC key is always encoded as an OCTET STRING in ASN.1 cf. RFC 5915 http://tools.ietf.org/html/rfc5915#page-3: o privateKey is the private key. It is an octet string of length ceiling (log2(n)/8) (where n is the order of the curve) obtained from the unsigned integer via the Integer-to-Octet-String- Primitive (I2OSP) defined in [RFC3447]. Therefore the length of this OCTECT STRING is fixed by the curve parameters. The EC private key encoding is wrong in OpenSSL from the very beginning: If the byte length of the private key is shorter than the byte length of the order then OpenSSL generates a shorter OCTET STRING than required. Keep in mind that the private key is not a DER encoded integer but an (unsigned) integer encoded in a fixed length byte string. Check that out with, e.g. the attached script and a log that shows up by the script. If you compare in the script the hexdata string length against 64 you will get more broken key encodings: openssl asn1parse gives: 0:d=0 hl=2 l= 117 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0672D2.... 37:d=1 hl=2 l= 10 cons: cont [ 0 ] 39:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 49:d=1 hl=2 l= 68 cons: cont [ 1 ] 51:d=2 hl=2 l= 66 prim: BIT STRING openssl ec -text shows: read EC key Private-Key: (256 bit) priv: 06:72:d2:f7:54:2a:1f:f8:35:06:12:81:94:9d:68: 84:bb:8f:f2:4d:f5:88:62:ad:a7:42:16:1f:15:30 pub: 04:3f:ff:4b:5d:5b:4c:b5:ae:b2:1a:2e:8e:52:14: 7d:fc:1a:56:45:76:cd:ba:45:2e:ef:ea:d1:36:59: 9b:85:f3:c5:d5:09:bd:6c:d8:e3:f0:88:1a:37:2c: 20:1c:21:85:54:f3:53:6c:2e:51:66:67:c1:95:58: a0:64:f8:fa:97 ASN1 OID: prime256v1 -----Remark----- Note that is not required to output the encoded OCTET STRING by the text option, which displays an integer. Look instead at the output of the asn1parse command. As a side effect, if the upper bit of a shorter key is set, the text option shows an additional leading zero byte, which is in fact not in the encoding. -----How to proceed----- The encoding is broken and does not conform with the Specification. Full stop. Because OpenSSL gently handles leading zero bytes in a private key, I'm quite sure that a correction of the EC key encoding has no impact. Try out as examples the following conformaing private EC keys: -----BEGIN EC PRIVATE KEY----- MHcCAQEEIADurCM9Znleeiyft0Ll5fK9HLZiMsEa1prIsF/rj5ZmoAoGCCqGSM49 AwEHoUQDQgAEbf8lX1VO8rfkHQao+D3PTIq9Mtg2Z54DNlTv2Fa4SnyKyjxbm/V9 PmluypK/YofHS+Qsd4JkExbSZ0xC+G78dg== -----END EC PRIVATE KEY----- or -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAAMVeMs6sJ6iKyn+3whuEo9KuAStgwyRo+KxaOCbnfKoAoGCCqGSM49 AwEHoUQDQgAERYtBxIKY6Glq7sRHpYhrJ01KKAvH9LfD4L+B7GeMDht3Sw2IbK+e 82cUTBOXXBRHCL7xfk+DamHAcl9GtoO8XQ== -----END EC PRIVATE KEY----- OpenSSL converts this encoding into the internal structure, where the private key is stored as a BIGNUM, and leading zeros disappear. Any comments on the attached diff for 1.0.2.beta3 are welcome. It works, but I didn't check it carefully. It is applicable to the 1.0.1 branch as well. Regards, Ann. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ec_asn1.diff Type: application/octet-stream Size: 1478 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: script.txt URL: From openssl-users at dukhovni.org Sat Jan 3 17:13:07 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 3 Jan 2015 17:13:07 +0000 Subject: [openssl-dev] Client Certificate sent though SSL client is configured with NO authentication In-Reply-To: References: Message-ID: <20150103171307.GQ24649@mournblade.imrryr.org> On Sat, Jan 03, 2015 at 06:44:28AM +0000, Satish.KumarYarru at cognizant.com wrote: > I have configured my SSL client with VERIFY_NONE. Which allows connections to complete even when the server's certificate is unverified or not present (if aNULL ciphers are not excluded on both ends). This has little effect on the use of client certificates. > But when I perform handshake with SSL Server that is configured with "Dual > Authentication", Client is still sending Client Certificate for the > Certificate Request sent by client. As expected. If you don't want to configured client certificates, create the SSL handle via SSL_CTX context handle which has not been configured with a certificate/private-key pair via: SSL_CTX_use_certificate_chain_file() SSL_CTX_use_PrivateKey_file() or similar. > But ideally client should not send certificate as the SSL client is > configured with NO Authentication. No the client is configured to ignore PKIX authentication errors in verifying the server, the converse is not implied, especially since you've configured client certificates for some reason. > When I debugged, I found client is sending the certificate because > Client Certificate is NOT un-loaded in SSL context when client is > configured with VERIFY_NONE. Indeed, if you don't want to use client certificates, don't "load" the key and certificate in the first place. > OpenSSL is not providing any API to unload certificate from the SSL context. > Can you please help me on how to address this issue? Use an SSL_CTX in which you have NOT loaded any client certificates. -- Viktor. From steve at openssl.org Sat Jan 3 18:39:03 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 3 Jan 2015 18:39:03 +0000 Subject: [openssl-dev] unloading certificates In-Reply-To: References: Message-ID: <20150103183903.GA22226@openssl.org> On Tue, Dec 30, 2014, Satish.KumarYarru at cognizant.com wrote: > Hi > Is there any way to unload client certificate and private key from SSL context? > I could not find any openss api to unload client cert from SSL object. > There is a function SSL_certs_clear() but it is only in OpenSSL 1.0.2+ Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From deengert at gmail.com Sat Jan 3 18:34:40 2015 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 03 Jan 2015 12:34:40 -0600 Subject: [openssl-dev] EC key generation in broken in all versions In-Reply-To: <1347.79.218.222.136.1420288889.squirrel@www2.informatik.hu-berlin.de> References: <1347.79.218.222.136.1420288889.squirrel@www2.informatik.hu-berlin.de> Message-ID: <54A83640.4060100@gmail.com> On 1/3/2015 6:41 AM, Annie Yousar wrote: > Dear all, > -----Facts----- > The private EC key is always encoded as an OCTET STRING in ASN.1 It depends on its context, there are a number of ways to encode it: PKCS#15 6.3.3 Private Elliptic Curve key objects PrivateECKeyAttributes ::= SEQUENCE { value ObjectValue {ECPrivateKey}, keyInfo KeyInfo {Parameters, PublicKeyOperations} OPTIONAL, ... -- For future extensions } ECPrivateKey ::= INTEGER > cf. RFC 5915 http://tools.ietf.org/html/rfc5915#page-3: > o privateKey is the private key. It is an octet string of length > ceiling (log2(n)/8) (where n is the order of the curve) obtained > from the unsigned integer via the Integer-to-Octet-String- > Primitive (I2OSP) defined in [RFC3447].view > > Therefore the length of this OCTECT STRING is fixed by the curve parameters. In the context of RFC5915, the OCTET STRING has a fixed length and the I2OSP routine is provided with the length. RFC3447 is a more important reference, as it says how to do a conversion. https://tools.ietf.org/html/rfc344 This related to problem: http://rt.openssl.org/Ticket/Display.html?id=3465&user=guest&pass=guest It could have been addressed if the OCTET STRING was kept at the fixed length, as the OCTET STRING should be xLen, which can be derived from the parameters if they are present. In the github master src/crypto/ec/ec_lcl.h defines struct ec_key_st BIGNUM *priv_key; OpenSSL is losing the xLen when converting internally to a BIGNUM. Maybe it should be storing the xLen for use when group=NULL; to convert the BIGNUM to OCTET STRING of the correct length. > > The EC private key encoding is wrong in OpenSSL from the very beginning: > If the byte length of the private key is shorter than the byte length of > the order then OpenSSL generates a shorter OCTET STRING than required. > Keep in mind that the private key is not a DER encoded integer but an > (unsigned) integer encoded in a fixed length byte string. > > Check that out with, e.g. the attached script and a log that shows up by > the script. > If you compare in the script the hexdata string length against 64 you will > get more broken key encodings: > > openssl asn1parse gives: > 0:d=0 hl=2 l= 117 cons: SEQUENCE > 2:d=1 hl=2 l= 1 prim: INTEGER :01 > 5:d=1 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0672D2.... > 37:d=1 hl=2 l= 10 cons: cont [ 0 ] > 39:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 > 49:d=1 hl=2 l= 68 cons: cont [ 1 ] > 51:d=2 hl=2 l= 66 prim: BIT STRING > > openssl ec -text shows: > read EC key > Private-Key: (256 bit) > priv: > 06:72:d2:f7:54:2a:1f:f8:35:06:12:81:94:9d:68: > 84:bb:8f:f2:4d:f5:88:62:ad:a7:42:16:1f:15:30 > pub: > 04:3f:ff:4b:5d:5b:4c:b5:ae:b2:1a:2e:8e:52:14: > 7d:fc:1a:56:45:76:cd:ba:45:2e:ef:ea:d1:36:59: > 9b:85:f3:c5:d5:09:bd:6c:d8:e3:f0:88:1a:37:2c: > 20:1c:21:85:54:f3:53:6c:2e:51:66:67:c1:95:58: > a0:64:f8:fa:97 > ASN1 OID: prime256v1 > > -----Remark----- > Note that is not required to output the encoded OCTET STRING by the text > option, which displays an integer. Look instead at the output of the > asn1parse command. > As a side effect, if the upper bit of a shorter key is set, the text > option shows an additional leading zero byte, which is in fact not in the > encoding. > > -----How to proceed----- > The encoding is broken and does not conform with the Specification. > Full stop. > > Because OpenSSL gently handles leading zero bytes in a private key, I'm > quite sure that a correction of the EC key encoding has no impact. > > Try out as examples the following conformaing private EC keys: > > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIADurCM9Znleeiyft0Ll5fK9HLZiMsEa1prIsF/rj5ZmoAoGCCqGSM49 > AwEHoUQDQgAEbf8lX1VO8rfkHQao+D3PTIq9Mtg2Z54DNlTv2Fa4SnyKyjxbm/V9 > PmluypK/YofHS+Qsd4JkExbSZ0xC+G78dg== > -----END EC PRIVATE KEY----- > or > -----BEGIN EC PRIVATE KEY----- > MHcCAQEEIAAMVeMs6sJ6iKyn+3whuEo9KuAStgwyRo+KxaOCbnfKoAoGCCqGSM49 > AwEHoUQDQgAERYtBxIKY6Glq7sRHpYhrJ01KKAvH9LfD4L+B7GeMDht3Sw2IbK+e > 82cUTBOXXBRHCL7xfk+DamHAcl9GtoO8XQ== > -----END EC PRIVATE KEY----- > > OpenSSL converts this encoding into the internal structure, where the > private key is stored as a BIGNUM, and leading zeros disappear. > > Any comments on the attached diff for 1.0.2.beta3 are welcome. It works, > but I didn't check it carefully. It is applicable to the 1.0.1 branch as > well. > > Regards, > Ann. > > > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -- Douglas E. Engert From rt at openssl.org Sun Jan 4 19:53:21 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 4 Jan 2015 20:53:21 +0100 Subject: [openssl-dev] [openssl.org #2914] Crash in x_name.c on out of memory In-Reply-To: <1381008629.134813.1353039442701.JavaMail.root@mail.gslab.com> References: <141143736.134810.1353039391217.JavaMail.root@mail.gslab.com> <1381008629.134813.1353039442701.JavaMail.root@mail.gslab.com> Message-ID: Thanks. OpenSSL_1_0_1-stable 9e9ee7e RT2914: NULL check missing in X509_name_canon OpenSSL_1_0_2-stable 9f49067 RT2914: NULL check missing in X509_name_canon master 2c60925 RT2914: NULL check missing in X509_name_canon Author: Rich Salz Date: Sun Jan 4 14:51:04 2015 -0500 RT2914: NULL check missing in X509_name_canon Check for NULL return from X509_NAME_ENTRY_new() Reviewed-by: Dr. Stephen Henson ; -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From matt at openssl.org Mon Jan 5 12:09:31 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 05 Jan 2015 12:09:31 +0000 Subject: [openssl-dev] OpenSSL source reformat Message-ID: <54AA7EFB.1060409@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have previously announced our intention to reformat the entire codebase into a more consistent style (see our roadmap document here: https://www.openssl.org/about/roadmap.html) Since then we have been busy working towards doing that. I'd like to make available for comment a sample reformat. So far I've run it for master and 1.0.2, but the current thinking is that this will also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to significantly ease the maintenance overhead) I've put the results of the reformat up on my github account here: https://github.com/mattcaswell/openssl The reformat of master is on the "sample-master-reformat" branch, and the 1.0.2 reformat is on "sample-1.0.2-reformat". The style itself is heavily influenced by the Linux Kernel Coding style: https://www.kernel.org/doc/Documentation/CodingStyle Although there are some significant differences - most notably that we are using spaces not tabs for indents, and the indent depth is 4 characters not 8. We will be publishing our own style guide in due course. I'm not looking to open any religious wars here - so I'm not looking for comments on the style itself (e.g. debates about whether 2, 4 or 8 character indents are better (we've already had those!)) - but I'm mainly seeking feedback on anywhere where the reformatting has failed. We've already looked of course...but sometimes many sets of eyes are better! I've also made available the script that was used to do the reformatting. The script is called openssl-format-source and is in the util directory of the branches mentioned above. This script depends on GNU indent being available. It should be executed from the root of the source tree as follows: util/openssl-format-source -v -c . There are also some one-off manual tweaks (both before and after running the script) that need to be done which are present in the sample reformat branches. These are related to multi-line comments which have their own internal formatting - these aren't handled too well. The manual steps should be a one-off exercise though. The hope is that we will be able to re-run the script at regular intervals. Thanks Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqn77AAoJENnE0m0OYESRlD8H/j8U2mxUhe7yPoJ8gwUZzy3k 4RMelsCzjBMPfiA8VgL8IvtYl7GpBZaG938RXPS9uHLSaUhGJt7vCghKEEO+OQqM qYlNm3BNutRWAJ8S63qHqL6sgN+tUCktnwN9MJUIHLDE9Eh9natRf8sJjanBdmg+ F46RXzaQJSe2BuSvSdzaD0aamjAM3qbhESbz6Que5IlP+gkMyCCf2Ug5wB9XPQF8 VGLE2umGxaGB/qzGim/jwSIJ4q56+f+MWqdh64Sz8IxYNGeYtQ5dIgWyZ7rzb8G4 +jJkRL3WTEsBQYRHTjM4R+OM4ZreMaWqgWkdOIr4AikUgSujFOpeaNQQnOfQfVo= =17Ml -----END PGP SIGNATURE----- From openssl at openssl.org Mon Jan 5 14:13:38 2015 From: openssl at openssl.org (OpenSSL) Date: Mon, 5 Jan 2015 15:13:38 +0100 Subject: [openssl-dev] Forthcoming OpenSSL releases Message-ID: <20150105141338.GA19261@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.1k, 1.0.0p and 0.9.8zd. These releases will be made available on 8th January. They will fix a number of security defects. Since these security defects are considered as moderate severity or less no further details or patches will be made available in advance of the release. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqpq7AAoJENnE0m0OYESRCeQH/3i7C8kpk+n6cqwaEedjt5Mo eU0F+d8OrxPMqzEo4qftGe+7ygvwJBdA8tb0/4fQuqmg9wBSbJMa7qku20qOpKF9 daYfOPQCXgdGUjomp5GYz86/7Aq7aND8qQLnCcWWdwBv+8ypP0Hgywilr1LW+nnv xBNNbQSBERPayGcSIqFI0xYd2r8Q8vUp9BMKnkHoR5ty3nO43/nGQnPwEX5O3tJc XZzWVVxrKhp/wMiAueWz44vc0juO8LdfkuWUtjJj3F9cL9qLOG877ho4cM/t9WX/ jheVNun1Cd9Z0wIn0nHYgtJUn/eVyTc9LckoVKt9pg4+HhsJd4cTC8X92HQbB6E= =fM80 -----END PGP SIGNATURE----- From rt at openssl.org Mon Jan 5 14:33:28 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 5 Jan 2015 15:33:28 +0100 Subject: [openssl-dev] [openssl.org #3638] [PATCH] Fix build with -DOPENSSL_NO_SRTP In-Reply-To: References: Message-ID: Many thanks. Patch applied. Regards Matt From rt at openssl.org Mon Jan 5 21:08:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 5 Jan 2015 22:08:01 +0100 Subject: [openssl-dev] [openssl.org #3546] Remove IRIX_CC_BUG #ifdef's In-Reply-To: References: Message-ID: commit b5526482ef81ee7906b967e326d23a45fbcf3abc Author: Rich Salz Date: Mon Jan 5 16:05:54 2015 -0500 RT3546: Remove #define IRIX_CC_BUG Leftovers from commit 448155e9bbda27cbba365ff549a7e2044a8a399f Remove now-unused #define's Reviewed-by: Matt Caswell -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From aiacono at teletu.it Tue Jan 6 11:22:43 2015 From: aiacono at teletu.it (antonio) Date: Tue, 06 Jan 2015 12:22:43 +0100 Subject: [openssl-dev] OPENSSL_NO_SHA is still useful? Message-ID: <54ABC583.1040406@teletu.it> Hi, you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and other similar) that compiling with -DOPENSSL_NO_SHA gives an endless series of errors and warnings. Regards, Antonio From paulo.a.o.caetano at gmail.com Tue Jan 6 13:48:32 2015 From: paulo.a.o.caetano at gmail.com (Paulo Caetano) Date: Tue, 6 Jan 2015 13:48:32 +0000 Subject: [openssl-dev] [PATCH] Debug build configuration for mingw32 Message-ID: Hallo. Attached is a patch that creates a debug configuration to mingw32, and makes Configure usable both on msys and msys2. It's diffed from openssl-1.0.2-stable-SNAP-20150106.tar.gz. I've looked at debug-cygwin debug #defines and used it as a starting point. Thanks. -- Paulo Caetano http://cidebycide.blogspot.pt/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug-mingw32.patch Type: application/octet-stream Size: 5847 bytes Desc: not available URL: From rt at openssl.org Tue Jan 6 16:53:28 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 6 Jan 2015 17:53:28 +0100 Subject: [openssl-dev] [openssl.org #3489] [PATCH] DTLS/sctp stored shutdown memory leak In-Reply-To: <53E4D06E.9000405@acision.com> References: <53E4D06E.9000405@acision.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 rt at openssl.org Tue Jan 6 17:42:08 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 6 Jan 2015 18:42:08 +0100 Subject: [openssl-dev] [openssl.org #3642] Bug in OpenSSL 1.0.1j version: Decode error in TLS 1.2 handshake failure from client In-Reply-To: References: Message-ID: On Fri Dec 26 12:19:01 2014, sameerpjoshi at gmail.com wrote: > Hi, > > I see a problem in OpenSSL code and want to confirm if this has been > already reported as a bug or not. > > If the server sends CertificateRequest during TLS handshake in case of > TLS1.2, the Client processes this request in method > ssl3_get_certificate_request(SSL* s). > > While processing the request it calls tls1_process_sigalgs() method to > process the signature algorithms. > > In this method tls1_process_sigalgs(), its being checked if the s->cert > pointer is NULL . This actually means the check whether the client has its > own certificate or not. In case the pointer is NULL, indicating the client > does not have certificate, the function returns zero or failure. TLS > handshake fails here with "decode error" owing to > SSL_R_SIGNATURE_ALGORITHMS_ERROR. > Can you actually produce the above error using s_client/s_server? The s->cert field is not NULL if there is no client certificate: it is a structure which contains certificate related information which is set up in SSL_new(). It should never be NULL hence the "Should never happen" comment. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From BenBE at geshi.org Tue Jan 6 17:43:24 2015 From: BenBE at geshi.org (Benny Baumann) Date: Tue, 06 Jan 2015 18:43:24 +0100 Subject: [openssl-dev] OpenSSL source reformat In-Reply-To: <54AA7EFB.1060409@openssl.org> References: <54AA7EFB.1060409@openssl.org> Message-ID: <54AC1EBC.3050905@geshi.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Matt, first of all: THANK YOU! This has been overdue for ages! Just a small tweak that would be nice I'd like to see would be to always have block markers for loops and conditions. The lack of those was one of the many pitfalls with the old source especially as the indentation had been off by one level in contrast to common rules. Including the the block markers (AKA curly brackets) at all times even for single statements has two advantages: - - You always have a block grouping statements to the proper statement - - You won't create a Apple-Style Goto Fail that easily AFAIK indent should support adding all of them automagically; otherwise astyle is another powerful solution. Anyway: BIG THANKS for finally making the code readable*. Kind regards, BenBE. *Comprehensible is a different kettle of fish ;-) Am 05.01.2015 um 13:09 schrieb Matt Caswell: > We have previously announced our intention to reformat the entire > codebase into a more consistent style (see our roadmap document > here: https://www.openssl.org/about/roadmap.html) > > Since then we have been busy working towards doing that. I'd like > to make available for comment a sample reformat. So far I've run it > for master and 1.0.2, but the current thinking is that this will > also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to > significantly ease the maintenance overhead) > > I've put the results of the reformat up on my github account here: > https://github.com/mattcaswell/openssl > > The reformat of master is on the "sample-master-reformat" branch, > and the 1.0.2 reformat is on "sample-1.0.2-reformat". > > The style itself is heavily influenced by the Linux Kernel Coding > style: https://www.kernel.org/doc/Documentation/CodingStyle > > Although there are some significant differences - most notably that > we are using spaces not tabs for indents, and the indent depth is > 4 characters not 8. We will be publishing our own style guide in > due course. > > I'm not looking to open any religious wars here - so I'm not > looking for comments on the style itself (e.g. debates about > whether 2, 4 or 8 character indents are better (we've already had > those!)) - but I'm mainly seeking feedback on anywhere where the > reformatting has failed. We've already looked of course...but > sometimes many sets of eyes are better! > > I've also made available the script that was used to do the > reformatting. The script is called openssl-format-source and is in > the util directory of the branches mentioned above. This script > depends on GNU indent being available. It should be executed from > the root of the source tree as follows: > > util/openssl-format-source -v -c . > > There are also some one-off manual tweaks (both before and after > running the script) that need to be done which are present in the > sample reformat branches. These are related to multi-line comments > which have their own internal formatting - these aren't handled > too well. The manual steps should be a one-off exercise though. The > hope is that we will be able to re-run the script at regular > intervals. > > Thanks > > Matt > > _______________________________________________ openssl-dev mailing > list openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUrB67AAoJEPHTXLno4S6tdR0P/R7MQGYZ5cRErk/55luMZLgi Om9JmXBa4NCKedVVUXLQOlkiWu4Oa3s/J0xezTwzCR5P+B9x0miDUMjm9yKy6g4q t3mhAAiGOKfofLVq7M6iOE72SO2Pd4FTCywVMPuE6p9vAK7o/Gufn/8W52ud8oBb l7O5l2o6B0191q+6v3oLb8zY028FESrJgTDfq4htzvVlOkl3mnzvXP87juyrEzIb Y4FY7DzGi146mkRro3Q3Yb0fQcNTvVajQyAMLsLTRWDSXFs998BFxMih3hlJa+gc SvPi/rjE/gNaRxB3obc0o48hdy3Q7Q6DvpxVqwxb7Y2i3kWwJaCRCcOsEvYhfqkt 5kevKe/exKEyDWtjokWat9alB/Qla6Yb725OjOo4UQvmjT2OwULB9uFoXxig3/H/ oBES33FAAU0Kul4YwmfWb17m2QWeXHcqTITXUuS2zasMxF+2wbgb5o3bcQx7QUnd Fxf4emHb9OVqLdiN7WyNkUBceot2IBB73hud2myfKZS9g71F5hhsdsXvoWp5e3/I Cp1hnD2ViE5hWF4bGbKM7Eom9IeEho1idKCGGhfgRJ2tjweP66ORZnUK+Dz84N7a Je1peZ95uAUCy2F/PI2QFpxgvSU9lHiHGpRoEQRGbCn0N24La6mi0B7APjhWgHXk tiPO8GEKG7W5TGq0thzL =iwE9 -----END PGP SIGNATURE----- From jean-louis.thekekara at openwide.fr Tue Jan 6 17:53:00 2015 From: jean-louis.thekekara at openwide.fr (Jean-louis Thekekara) Date: Tue, 6 Jan 2015 18:53:00 +0100 (CET) Subject: [openssl-dev] [PATCH] timestamping: add digest algorithm selection during response In-Reply-To: <724928173.29985497.1420566325732.JavaMail.root@openwide.fr> Message-ID: <339942659.29985915.1420566780405.JavaMail.root@openwide.fr> Dear OpenSSL developers, I made an application which tests various digest and public key algorithms for timestamp generation, and I needed to make some changes to OpenSSL codebase. Here is a small contribution which allows to select the digest algorithm used during signature generation. This patch applies on top of current master (c1669e1). Feel free to give me any feedback on this. A small script is also attached to test this feature, which I executed from apps/ directory. Regards, Jean-Louis. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ts-Add-digest-algorithm-selection-during-response.patch Type: text/x-patch Size: 5836 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.sh Type: application/x-shellscript Size: 759 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-demoTS.cnf Type: application/octet-stream Size: 10839 bytes Desc: not available URL: From foleyj at cisco.com Tue Jan 6 20:08:31 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 06 Jan 2015 15:08:31 -0500 Subject: [openssl-dev] make errors broken Message-ID: <54AC40BF.4050505@cisco.com> The following problem occurs when doing "make errors" on the 1.0.1 stable branch: foleyj at foley-w520:/nobackup/tmp/x90/openssl$ make errors /usr/bin/perl util/ck_errf.pl -strict */*.c */*/*.c ssl/s3_clnt.c:1544:ssl3_get_key_exchange:ssl3_get_server_certificate crypto/asn1/a_verify.c:157:asn1_item_verify:asn1_verify FATAL: error discrepancy make: *** [errors] Error 1 The problem appears to be related to commit a8565530e27718760220df469f0a071c85b9e731. Please see my comments in github under this commit for the proposed resolution. From rt at openssl.org Tue Jan 6 20:39:09 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 6 Jan 2015 21:39:09 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <543B2685.3070801@av8n.com> References: <543B2685.3070801@av8n.com> Message-ID: Fixed in 1.0.2 and master. Even tho the commit message says 3662 not 3552 :( OpenSSL_1_0_2-stable 129344a RT3662: Allow leading . in nameConstraints master 77ff1f3 RT3662: Allow leading . in nameConstraints Author: Dr. Stephen Henson Date: Tue Jan 6 15:29:28 2015 -0500 RT3662: Allow leading . in nameConstraints Change by SteveH from original by John Denker (in the RT) Reviewed-by: Rich Salz -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From wfu at SonicWALL.com Wed Jan 7 07:58:47 2015 From: wfu at SonicWALL.com (Frey (Wei) Fu) Date: Tue, 6 Jan 2015 23:58:47 -0800 Subject: [openssl-dev] OpenSSL source reformat In-Reply-To: <54AA7EFB.1060409@openssl.org> References: <54AA7EFB.1060409@openssl.org> Message-ID: Hi Matt, I've checked the util dir in your branch and official branch, but the openssl-format-source script file seems unavailable. Would you please point out the exact location? Thanks, Frey -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: 2015?1?5? 20:10 To: openssl-dev at openssl.org Subject: [openssl-dev] OpenSSL source reformat -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have previously announced our intention to reformat the entire codebase into a more consistent style (see our roadmap document here: https://www.openssl.org/about/roadmap.html) Since then we have been busy working towards doing that. I'd like to make available for comment a sample reformat. So far I've run it for master and 1.0.2, but the current thinking is that this will also be applied to 1.0.1, 1.0.0 and 0.9.8 (this is necessary to significantly ease the maintenance overhead) I've put the results of the reformat up on my github account here: https://github.com/mattcaswell/openssl The reformat of master is on the "sample-master-reformat" branch, and the 1.0.2 reformat is on "sample-1.0.2-reformat". The style itself is heavily influenced by the Linux Kernel Coding style: https://www.kernel.org/doc/Documentation/CodingStyle Although there are some significant differences - most notably that we are using spaces not tabs for indents, and the indent depth is 4 characters not 8. We will be publishing our own style guide in due course. I'm not looking to open any religious wars here - so I'm not looking for comments on the style itself (e.g. debates about whether 2, 4 or 8 character indents are better (we've already had those!)) - but I'm mainly seeking feedback on anywhere where the reformatting has failed. We've already looked of course...but sometimes many sets of eyes are better! I've also made available the script that was used to do the reformatting. The script is called openssl-format-source and is in the util directory of the branches mentioned above. This script depends on GNU indent being available. It should be executed from the root of the source tree as follows: util/openssl-format-source -v -c . There are also some one-off manual tweaks (both before and after running the script) that need to be done which are present in the sample reformat branches. These are related to multi-line comments which have their own internal formatting - these aren't handled too well. The manual steps should be a one-off exercise though. The hope is that we will be able to re-run the script at regular intervals. Thanks Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUqn77AAoJENnE0m0OYESRlD8H/j8U2mxUhe7yPoJ8gwUZzy3k 4RMelsCzjBMPfiA8VgL8IvtYl7GpBZaG938RXPS9uHLSaUhGJt7vCghKEEO+OQqM qYlNm3BNutRWAJ8S63qHqL6sgN+tUCktnwN9MJUIHLDE9Eh9natRf8sJjanBdmg+ F46RXzaQJSe2BuSvSdzaD0aamjAM3qbhESbz6Que5IlP+gkMyCCf2Ug5wB9XPQF8 VGLE2umGxaGB/qzGim/jwSIJ4q56+f+MWqdh64Sz8IxYNGeYtQ5dIgWyZ7rzb8G4 +jJkRL3WTEsBQYRHTjM4R+OM4ZreMaWqgWkdOIr4AikUgSujFOpeaNQQnOfQfVo= =17Ml -----END PGP SIGNATURE----- _______________________________________________ openssl-dev mailing list openssl-dev at openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jan 7 08:56:15 2015 From: rt at openssl.org (Annie Yousar via RT) Date: Wed, 7 Jan 2015 09:56:15 +0100 Subject: [openssl-dev] [openssl.org #3644] Encoding of EC private key is broken in all version In-Reply-To: <1196.79.218.222.136.1420579412.squirrel@www2.informatik.hu-berlin.de> References: <1196.79.218.222.136.1420579412.squirrel@www2.informatik.hu-berlin.de> Message-ID: Dear all, all versions of OpenSSL do not encode private EC key correctly. This shows up every time the private key is at least one byte shorter than the order. If the private key has full length then the encoding looks correct. Consider the following three ECPrivateKey encondings: -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/oAoGCCqGSM49 AwEHoUQDQgAE9Es5dZoubbcjpvkCSZct/QjpU4Dx/KRw6s0dA+Xt8hS++vzPIjyg ZfCg207qk/8GohFvyoH3pKlDao2RegLe3g== -----END EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY----- MGYCAQEEDwAAAAAAAAAAAAAAAAAA/6AKBggqhkjOPQMBB6FEA0IABPRLOXWaLm23 I6b5AkmXLf0I6VOA8fykcOrNHQPl7fIUvvr8zyI8oGXwoNtO6pP/BqIRb8qB96Sp Q2qNkXoC3t4= -----END EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY----- MFgCAQEEAf+gCgYIKoZIzj0DAQehRANCAAT0Szl1mi5ttyOm+QJJly39COlTgPH8 pHDqzR0D5e3yFL76/M8iPKBl8KDbTuqT/waiEW/KgfekqUNqjZF6At7e -----END EC PRIVATE KEY----- Despite the different base64 encodings all the corresponding private keys are the same, and therefore any signature made by one can be verified by any other. You may try it out: openssl dgst -sign key1.pem -out ec.sig test.txt openssl dgst prverify key2.pem -signature ec.sig test.txt Try also the OpenSSL "ec" command with the -text option on these keys. You can see that the private key is always the same (0xFF) and that OpenSSL recodes the keys. The PEM output is always identical to the last of the three. This is not correct. The SEC1 specification OpenSSL is using requires the full encoding in byte length of the order as e.g. given by the first of these three encodings. The patch that works is given as annex. It is applicable to 1.0.1j as well as to 1.0.2-beta3. There is no strong need to change any other things, even the documentation ec.pod is already correct (beside the description of the very strange -modulus option in line 96++. Attached is also a deeper analysis made by an answer to Douglas E Engert, who replies to my e-mail on openssl-dev with a different but non-appropriate subject line (EC key generation is broken in all versions). Sorry for this misleading subject line, not the key generation is broken, but the encoding. Regards, /Ann. -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.0.2-beta3.ec_pk_enc.patch Type: application/octet-stream Size: 1227 bytes Desc: not available URL: -------------- next part -------------- Hi Douglas, thank you for pointing me to PCKS#15 encoding of PrivateECKeyAttributes and thanks for spending time on this issue. Sorry for the long answer, there were many points to be considered. Keep in mind: The proposed patch does not change any bits on the wire. Kind regards, /Ann. 1. PrivateECKeyAttributes vs. ECPrivateKey OpenSSL generates an EC key with the command openssl ecparam -genkey -noout -name prime256v1 not in the PKCS#15 format but according to a SEC1 structure (cf. crypto/ec/ec_asn1.c line 191), which is defined in http://www.secg.org/sec1-v2.pdf (version 2.0 Annex C.4 p.108): ECPrivateKey ::= SEQUENCE { version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), privateKey OCTET STRING, parameters [0] ECDomainParameters {{ SECGCurveNames }} OPTIONAL, publicKey [1] BIT STRING OPTIONAL } The ASN.1 definition which is used by OpenSSL can be found in ec_asn1.c too (cf. lines 266-271): ASN1_SEQUENCE(EC_PRIVATEKEY) = { ASN1_SIMPLE(EC_PRIVATEKEY, version, LONG), ASN1_SIMPLE(EC_PRIVATEKEY, privateKey, ASN1_OCTET_STRING), ASN1_EXP_OPT(EC_PRIVATEKEY, parameters, ECPKPARAMETERS, 0), ASN1_EXP_OPT(EC_PRIVATEKEY, publicKey, ASN1_BIT_STRING, 1) } ASN1_SEQUENCE_END(EC_PRIVATEKEY) So OpenSSL uses the structure of SEC1 and refers to SEC1 (cf. also doc/apps/ec.pod lines 31++). Why not to follow consequently the requirement of SEC1 (see v2.0 p. 109)? -----BEGIN LaTeX----- \item The component \texttt{privateKey} is the private key defined to be the octet string of length $\lceil \log_2 n/8\rceil$ (where $n$ is the order of the curve) obtained from the unsigned integer via the encoding of Section 2.3.7. -----END LaTeX----- This is almost the same text as given in RFC 5915. The encoding to be used is given in the Section 2.3.7 of SEC1. The specifcations in PKCS#15 and RFC 3447 are not applicable here. 2. SEC1 vs. RFC 5480 Note the subtle difference in the definitions of SEC1 and RFC 5915. SEC1 uses ECDomainParameters{{ SECGCurveNames }}, restricted to SECGCurveNames, whereas RFC 5480 and RFC 5915 use (unrestricted) ECParameters, defined in RFC 5480. Note also that the corrected definition of RFC5915 is ECPrivateKey ::= SEQUENCE { version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), privateKey OCTET STRING, parameters [0] ECParameters OPTIONAL, publicKey [1] BIT STRING OPTIONAL } because the type ECParameters defined in RFC 5480 is not parametrized (see http://www.rfc-editor.org/errata_search.php?rfc=5915). OpenSSL uses the definition of RFC 3279 (ECpkParameters) obsoleted by RFC 5480, which changes only the naming but not the bits on the wire ("ECpkParameters" of RFC 3279 becomes "ECParameters" in RFC 5480, and "ECParameters" of RFC 3279 becomes "SpecifiedECDomain" in RFC 5480 according to SEC1v2). 3. Issue #3465 of RT http://rt.openssl.org/Ticket/Display.html?id=3465&user=guest&pass=guest This is *not* releated to the wrong private key encoding. It addresses the fact that the OpenSSL command "ec" fails to parse a generic (without parameters component) ECPrivateKey. But this is not failure at all, because the OpenSSL command ec is certainly restricted to the structures generated and used by OpenSSL itself. OpenSSL does not claim that it parses or accepts an arbitrary ECPrivateKey structure. The Doctor said "A private key without parameters is unusable anyway". Additionally the RFC 5915 mandates the use of the parameters component (RFC 5915 p. 3): Though the ASN.1 indicates that the parameters field is OPTIONAL, implementations that conform to this document MUST always include the parameters field. Therefore OpenSSL is fully conformant with the RFC 5915 (in this case Truth be told, OpenSSL fails to parse an ECPrivateKey structure even if the parameters field is present but is implicitCurve (aka implicitCA aka NULL). This is in line with RFC 5480 which deprecates the use of NULL parameter in PKIX: implicitCurve allows the elliptic curve domain parameters to be inherited. This choice MUST NOT be used. But for OpenSSL a private key with NULL parameters is unusable too. Note that OpenSSL can handle keys with the specifiedCurve parameters and also ECPrivateKey with the optional publicKey field missing. 4. Recoding of private keys Consider the following "three" ECPrivateKeys: -----BEGIN EC PRIVATE KEY----- MHcCAQEEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/oAoGCCqGSM49 AwEHoUQDQgAE9Es5dZoubbcjpvkCSZct/QjpU4Dx/KRw6s0dA+Xt8hS++vzPIjyg ZfCg207qk/8GohFvyoH3pKlDao2RegLe3g== -----END EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY----- MGYCAQEEDwAAAAAAAAAAAAAAAAAA/6AKBggqhkjOPQMBB6FEA0IABPRLOXWaLm23 I6b5AkmXLf0I6VOA8fykcOrNHQPl7fIUvvr8zyI8oGXwoNtO6pP/BqIRb8qB96Sp Q2qNkXoC3t4= -----END EC PRIVATE KEY----- -----BEGIN EC PRIVATE KEY----- MFgCAQEEAf+gCgYIKoZIzj0DAQehRANCAAT0Szl1mi5ttyOm+QJJly39COlTgPH8 pHDqzR0D5e3yFL76/M8iPKBl8KDbTuqT/waiEW/KgfekqUNqjZF6At7e -----END EC PRIVATE KEY----- Despite the different base64 encodings all the corresponding private keys are the same, so any signature made by one can be verified by any other: openssl dgst -sign key1.pem -out ec.sig test.txt openssl dgst prverify key2.pem -signature ec.sig test.txt Try out the OpenSSL "ec" command with the -text option. You can see that OpenSSL recodes the keys and the PEM output is always the last of them. But this is the wrong one. Only the first encoding conforms to the specification. This recoding must be corrected to solve the contradiction of description and realization. To conform to its own specification OpenSSL shall recode an ECPrivateKey into the first of the given three variants (fixed length OCTET STRING). The patch that works is given as annex. It is applicable to 1.0.1j as well as to 1.0.2-beta3. There is no strong need to change any other things even the documentation ec.pod is already correct (beside the description of the very strange -modulus option in line 96++ . Please check the patches carefully. 5. full SEC1/RFC5480 conformance To acchieve a complete SEC1/RFC5480 conformance some identifiers should be renamed. Apply the following sed commands (in this order) to all files in apps and crypto directory: s/ec_parameters_st/ec_specifiedDomain_st/g s/ecpk_parameters_st/ec_parameters_st/g s/implicitlyCA/implicitCurve/g s/ECPARAMETERS/SPECIFIEDCURVE/g s/ECParameters/SpecifiedCurve/g s/ECPKPARAMETERS/ECPARAMETERS/g s/ECPKParameters/ECParameters/g s/ecpkparameters/ecparameters/g s/parameters2group/specifiedCurve2group/g s/group2parameters/group2specifiedCurve/g s/pkparameters2group/ecparameters2group/g s/group2pkparameters/group2ecparameters/g There are two header files to be considered (ec.h and pem.h) carefully. Here the old names may be kept as aliases because there are no name collisions, if I'm not wrong. I will provide the full patch on request. Note also that this renaming does not change any bits on the wire, too. From matt at openssl.org Wed Jan 7 09:42:22 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 07 Jan 2015 09:42:22 +0000 Subject: [openssl-dev] OpenSSL source reformat In-Reply-To: References: <54AA7EFB.1060409@openssl.org> Message-ID: <54ACFF7E.8080105@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/01/15 07:58, Frey (Wei) Fu wrote: > Hi Matt, > > I've checked the util dir in your branch and official branch, but > the openssl-format-source script file seems unavailable. Would you > please point out the exact location? Did you look in the sample-1.0.2-reformat/sample-master-reformat branches in my repo? The script is here: https://github.com/mattcaswell/openssl/blob/sample-1.0.2-reformat/util/openssl-format-source Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrP9+AAoJENnE0m0OYESRs+wH/0G1B2qy7wAQmZjSS409BOOU 5hV8tgQbc+TNuvsrG59VwY3YhJQiEA4WoAimXVeX1iA3lIj9TNniJAqBz4AnTN2d wPKoyjPTOan0gVxu4+YG1+cYwuurNRWxVfIaNvSORmlSNRiCJhw2yqj0fleai/nQ ruCSMKnIbZI5uAmpE9IRuZUWPoJ8L1ah7qA2aTcjYyB1XB1/+SG3tbsgEQv8hZ1e 1InQKwbpvdmeaFjQE6pjfSeARxT/IuQ5snGbl48HuTTj3Bu/uPvXl+AQLZeXu0S/ 9h3AuoFHvq2G4qLes0nOy4dRQFiQ9i6ZPqRi+JE7Z2Gq0hW6wDbYEGl6XypupNw= =tsMt -----END PGP SIGNATURE----- From foleyj at cisco.com Wed Jan 7 16:40:21 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 07 Jan 2015 11:40:21 -0500 Subject: [openssl-dev] Make errors broken in s3_clnt.c Message-ID: <54AD6175.6040102@cisco.com> It appears there's another error num breakage in ssl/s3_clnt.c at line 1544. Please see the details at the bottom of the following log: http://173.39.238.160:8080/job/1_0_1_make_errors/1/console Please see my comment under commit 37580f43b5a39f5f4e920d17273fab9713d3a744 in github with the suggested resolution. From rt at openssl.org Wed Jan 7 17:06:32 2015 From: rt at openssl.org (Syed Ajim Hussain via RT) Date: Wed, 7 Jan 2015 18:06:32 +0100 Subject: [openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue In-Reply-To: References: Message-ID: Hi I am using Open SSL Code version openssl-1.0.1h-cmp , I am getting some linking problem , all the symbols "sk_CMP_XXX" is missing . Can you please help me which file contains "sk_CMP_XXX" functions , do i need to do something at compilation. Below is the compolation logs. cmpforopenssl-code-766/src/openssl-1.0.1h-cmp] ./config cmpforopenssl-code-766/src/openssl-1.0.1h-cmp] make ../libcrypto.a(cmp_ses.o): In function `save_certrep_statusInfo': cmp_ses.c:(.text+0xf1): undefined reference to `sk_CMP_CERTRESPONSE_num' cmp_ses.c:(.text+0x106): undefined reference to `sk_CMP_CERTRESPONSE_value' ../libcrypto.a(cmp_ses.o): In function `pollForResponse': cmp_ses.c:(.text+0xb7b): undefined reference to `sk_CMP_POLLREP_value' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_certResponse_get0': cmp_lib.c:(.text+0x260): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_certType_get': cmp_lib.c:(.text+0x280): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_PKIStatusString_get0': cmp_lib.c:(.text+0x2a0): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_PKIFailureInfoString_get0': cmp_lib.c:(.text+0x2e0): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_PKIFailureInfo_get0': cmp_lib.c:(.text+0x320): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o):cmp_lib.c:(.text+0x360): more undefined references to `sk_CMP_CERTRESPONSE_num' follow ../libcrypto.a(cmp_lib.o): In function `CMP_ITAV_stack_item_push0': cmp_lib.c:(.text+0x8f4): undefined reference to `sk_CMP_INFOTYPEANDVALUE_push' cmp_lib.c:(.text+0x90a): undefined reference to `sk_CMP_INFOTYPEANDVALUE_pop_free' cmp_lib.c:(.text+0x94b): undefined reference to `sk_CMP_INFOTYPEANDVALUE_new_null' ../libcrypto.a(cmp_lib.o): In function `CMP_PKIMESSAGE_check_implicitConfirm': cmp_lib.c:(.text+0x986): undefined reference to `sk_CMP_INFOTYPEANDVALUE_num' cmp_lib.c:(.text+0x9ad): undefined reference to `sk_CMP_INFOTYPEANDVALUE_value' ../libcrypto.a(cmp_lib.o): In function `CMP_REVREPCONTENT_PKIStatus_get': cmp_lib.c:(.text+0x142f): undefined reference to `sk_CMP_PKISTATUSINFO_value' ../libcrypto.a(cmp_lib.o): In function `CMP_PKIHEADER_generalInfo_item_push0': cmp_lib.c:(.text+0x14b7): undefined reference to `sk_CMP_INFOTYPEANDVALUE_push' cmp_lib.c:(.text+0x14ce): undefined reference to `sk_CMP_INFOTYPEANDVALUE_pop_free' cmp_lib.c:(.text+0x150b): undefined reference to `sk_CMP_INFOTYPEANDVALUE_new_null' ../libcrypto.a(cmp_lib.o): In function `CMP_CERTREPMESSAGE_get_certificate': cmp_lib.c:(.text+0x154c): undefined reference to `sk_CMP_CERTRESPONSE_num' cmp_lib.c:(.text+0x1580): undefined reference to `sk_CMP_CERTRESPONSE_num' cmp_lib.c:(.text+0x15b4): undefined reference to `sk_CMP_CERTRESPONSE_num' cmp_lib.c:(.text+0x1631): undefined reference to `sk_CMP_CERTRESPONSE_num' ../libcrypto.a(cmp_lib.o): In function `CMP_PKIMESSAGE_set_implicitConfirm': cmp_lib.c:(.text+0x16e9): undefined reference to `sk_CMP_INFOTYPEANDVALUE_push' cmp_lib.c:(.text+0x1705): undefined reference to `sk_CMP_INFOTYPEANDVALUE_pop_free' cmp_lib.c:(.text+0x1743): undefined reference to `sk_CMP_INFOTYPEANDVALUE_new_null' ../libcrypto.a(cmp_lib.o): In function `CMP_PKIMESSAGE_genm_item_push0': cmp_lib.c:(.text+0x1869): undefined reference to `sk_CMP_INFOTYPEANDVALUE_push' cmp_lib.c:(.text+0x1880): undefined reference to `sk_CMP_INFOTYPEANDVALUE_pop_free' cmp_lib.c:(.text+0x18a3): undefined reference to `sk_CMP_INFOTYPEANDVALUE_new_null' ../libcrypto.a(cmp_msg.o): In function `CMP_genm_new': cmp_msg.c:(.text+0x94): undefined reference to `sk_CMP_INFOTYPEANDVALUE_new_null' ../libcrypto.a(cmp_msg.o): In function `CMP_certConf_new': cmp_msg.c:(.text+0x1d5): undefined reference to `sk_CMP_CERTSTATUS_new_null' cmp_msg.c:(.text+0x208): undefined reference to `sk_CMP_CERTSTATUS_push' ../libcrypto.a(cmp_msg.o): In function `CMP_kur_new': cmp_msg.c:(.text+0x698): undefined reference to `sk_CRMF_CERTREQMSG_new_null' cmp_msg.c:(.text+0x6d1): undefined reference to `sk_CRMF_CERTREQMSG_push' ../libcrypto.a(cmp_msg.o): In function `CMP_cr_new': cmp_msg.c:(.text+0x91b): undefined reference to `sk_CRMF_CERTREQMSG_new_null' cmp_msg.c:(.text+0x959): undefined reference to `sk_CRMF_CERTREQMSG_push' ../libcrypto.a(cmp_msg.o): In function `CMP_rr_new': cmp_msg.c:(.text+0xac5): undefined reference to `sk_CMP_REVDETAILS_new_null' cmp_msg.c:(.text+0xaf4): undefined reference to `sk_CMP_REVDETAILS_push' ../libcrypto.a(cmp_msg.o): In function `CMP_ir_new': cmp_msg.c:(.text+0xc95): undefined reference to `sk_CRMF_CERTREQMSG_new_null' cmp_msg.c:(.text+0xcce): undefined reference to `sk_CRMF_CERTREQMSG_push' ../libcrypto.a(cmp_msg.o): In function `CMP_pollReq_new': cmp_msg.c:(.text+0xeec): undefined reference to `sk_CMP_POLLREQ_new_null' cmp_msg.c:(.text+0xf0d): undefined reference to `sk_CMP_POLLREQ_push' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_push0_regInfo': crmf_lib.c:(.text+0x7dd): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x81c): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x86b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_push0_control': crmf_lib.c:(.text+0x8d9): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x91c): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x97b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_regInfo_utf8Pairs': crmf_lib.c:(.text+0xa11): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0xa4e): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0xacb): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_regInfo_regToken': crmf_lib.c:(.text+0xb81): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0xbbe): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0xc3b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_regInfo_certReq': crmf_lib.c:(.text+0xcf1): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0xd2e): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0xdab): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_pkiArchiveOptions': crmf_lib.c:(.text+0xe6a): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0xeab): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0xf2b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_pkiPublicationInfo': crmf_lib.c:(.text+0xffa): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x103b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x10bb): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_authenticator': crmf_lib.c:(.text+0x118a): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x11cb): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x124b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_regToken': crmf_lib.c:(.text+0x131a): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x135b): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x13db): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_protocolEncrKey': crmf_lib.c:(.text+0x14af): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x14f0): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x1573): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' ../libcrypto.a(crmf_lib.o): In function `CRMF_CERTREQMSG_set1_control_oldCertId': crmf_lib.c:(.text+0x1696): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_push' crmf_lib.c:(.text+0x16db): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_pop_free' crmf_lib.c:(.text+0x17bb): undefined reference to `sk_CRMF_ATTRIBUTETYPEANDVALUE_new_null' collect2: ld returned 1 exit status make[2]: *** [link_app.] Error 1 With Regards Syed Ajim From noreply at openssl.org Thu Jan 8 00:22:14 2015 From: noreply at openssl.org (Returned mail) Date: Thu, 8 Jan 2015 13:22:14 +1300 Subject: [openssl-dev] *****SPAM***** Delivery reports about your e-mail Message-ID: <20150108002222.B9ADD205A4@mta.openssl.org> Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: The original message was received at Thu, 8 Jan 2015 13:22:14 +1300 from openssl.org [123.105.170.60] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- while talking to openssl.org.: >>> MAIL From:"Returned mail" <<< 501 "Returned mail" ... Refused [...] Content analysis details: (14.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 1.5 BASE64_LENGTH_79_INF BODY: No description available. 1.5 BAYES_60 BODY: Bayes spam probability is 60 to 80% [score: 0.7276] 0.5 MISSING_MID Missing Message-Id: header 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Returned mail" Subject: Delivery reports about your e-mail Date: Thu, 8 Jan 2015 13:22:14 +1300 Size: 32001 URL: From postmaster at openssl.org Thu Jan 8 01:26:42 2015 From: postmaster at openssl.org (Mail Delivery Subsystem) Date: Thu, 8 Jan 2015 09:26:42 +0800 Subject: [openssl-dev] *****SPAM***** Delivery reports about your e-mail Message-ID: <20150108012718.728332058A@mta.openssl.org> Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (14.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Mail Delivery Subsystem" Subject: Delivery reports about your e-mail Date: Thu, 8 Jan 2015 09:26:42 +0800 Size: 31428 URL: From MAILER-DAEMON at openssl.org Thu Jan 8 04:18:41 2015 From: MAILER-DAEMON at openssl.org (The Post Office) Date: Thu, 8 Jan 2015 09:48:41 +0530 Subject: [openssl-dev] *****SPAM***** Returned mail: Data format error Message-ID: <20150108041845.28E6E20668@mta.openssl.org> Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (14.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "The Post Office" Subject: Returned mail: Data format error Date: Thu, 8 Jan 2015 09:48:41 +0530 Size: 40197 URL: From postmaster at openssl.org Thu Jan 8 06:25:50 2015 From: postmaster at openssl.org (The Post Office) Date: Thu, 8 Jan 2015 14:25:50 +0800 Subject: [openssl-dev] *****SPAM***** Delivery reports about your e-mail Message-ID: <20150108062602.1D9CF20689@mta.openssl.org> Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: The original message was received at Thu, 8 Jan 2015 14:25:50 +0800 from openssl.org [39.60.32.41] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- while talking to openssl.org.: >>> MAIL From:"The Post Office" <<< 501 "The Post Office" ... Refused [...] Content analysis details: (20.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 0.9979] 1.5 BASE64_LENGTH_79_INF BODY: No description available. 2.7 BASE64_LENGTH_78_79 BODY: No description available. 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [59.40.26.199 listed in dnsbl.sorbs.net] 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [59.40.26.199 listed in bl.score.senderscore.com] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "The Post Office" Subject: Delivery reports about your e-mail Date: Thu, 8 Jan 2015 14:25:50 +0800 Size: 31447 URL: From noreply at openssl.org Thu Jan 8 09:38:33 2015 From: noreply at openssl.org (Mail Administrator) Date: Thu, 8 Jan 2015 16:38:33 +0700 Subject: [openssl-dev] *****SPAM***** Returned mail: see transcript for details Message-ID: <20150108093837.7C334206BE@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (19.1 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [125.234.5.94 listed in psbl.surriel.com] 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. [125.234.5.94 listed in bb.barracudacentral.org] 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Mail Administrator" Subject: Returned mail: see transcript for details Date: Thu, 8 Jan 2015 16:38:33 +0700 Size: 40035 URL: From rt at openssl.org Thu Jan 8 11:21:50 2015 From: rt at openssl.org (Paulo Caetano via RT) Date: Thu, 8 Jan 2015 12:21:50 +0100 Subject: [openssl-dev] [openssl.org #2330] Debug build configuration for mingw32 In-Reply-To: References: Message-ID: Hallo. Attached is a patch that creates a debug configuration to mingw32, and makes Configure usable both on msys and msys2. It's diffed from openssl-1.0.2-stable-SNAP-20150106.tar.gz. I've looked at debug-cygwin debug #defines and used it as a starting point. I've sent this to the openssl-dev list, but I've since found out there was an issue on RT for this. Thanks. -- Paulo Caetano http://cidebycide.blogspot.pt/ -------------- next part -------------- A non-text attachment was scrubbed... Name: debug-mingw32.patch Type: application/octet-stream Size: 5847 bytes Desc: not available URL: From openssl at openssl.org Thu Jan 8 15:37:53 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:37:53 +0100 Subject: [openssl-dev] OpenSSL version 0.9.8zd released Message-ID: <20150108153753.GA29145@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 0.9.8zd 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.8zd 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.8zd 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.8zd.tar.gz Size: 3737538 MD5 checksum: e9b9ee12f2911e1a378e2458d9bfff77 SHA1 checksum: b9a6356d5385e0bd6b8af660576bfdef7b45666e The checksums were calculated using the following commands: openssl md5 openssl-0.9.8zd.tar.gz openssl sha1 openssl-0.9.8zd.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrpVNAAoJENnE0m0OYESRDe0H/3AKK345ct3rR0QEQ1YN6d33 T4upEE2CKGaDhhqfPl0iHPDVxec+st98JxF3Yg5wQxWO7DxMe5bbKCYl/hM0ZSQd zTzeECDH5WtzlyXTCp5TZdLMwpPL3kkW0Q7D4q/RXZ6DE3fNVLDsxJOiVa4cWtHL JnuJCCqwSC5a5CfhcyAu5Tqt2/0xoFxcai8NmmhIWe806pfrwsN9PoD0YW9ARlLC hySrcCLy4MHtZYie4dv7JIOtVb1PPyX6qNsoKriGdpwb+drPvRtQFxSkbif+2gkf Y7YkDs8nKCdLwJvgonprl6HgcHh4eeBNpxOgfwMo/Vnw02HZvm7na2t4jxvmm+E= =+Z6j -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:38:58 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:38:58 +0100 Subject: [openssl-dev] OpenSSL version 1.0.0p released Message-ID: <20150108153858.GA29225@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.0p 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.0p 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.0p 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.0p.tar.gz Size: 4008663 MD5 checksum: f66da50ff3624aeaf292948f27d8ae7d SHA1 checksum: 04dd495c47c7a11f7f311747121b6b77e08abb5b The checksums were calculated using the following commands: openssl md5 openssl-1.0.0p.tar.gz openssl sha1 openssl-1.0.0p.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUrpJ5AAoJENnE0m0OYESRXL4IAJ66ZB4N5/nhxPCYV0vGMjCE A6jBTMPNfcF+CX26rFr3nWTX85zvmAFW9r+nIddlvnLSsWtDKtOpZsyWiFzFSrtK gp7xPhI3B//Di1bkDk0zkhUcAT/7DU/8yp8Nm5J0XMu71H+3Uxh/QP6ZpyW1ZSJ7 eWeZGr+PoVaC0gcRR2HBPtaArL0fhbgGI7HggRslvNupiwBqJ42Z0wDY12ONaA38 Be6jiUBElRQqr5VmjPOSdezX0ZTErI7NZ5It1DCtsLuglbVsmrim57PSpOkWwVh0 FRi39qNR7T4/2SEcUN01EX7VENarqZaxIxJuYCIx6v8DXYQQ8NloUudBe6icmE8= =9lIN -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:39:33 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:39:33 +0100 Subject: [openssl-dev] OpenSSL version 1.0.1k released Message-ID: <20150108153933.GA29291@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1k 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.1k 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.1k 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.1k.tar.gz Size: 4434910 MD5 checksum: d4f002bd22a56881340105028842ae1f SHA1 checksum: 19d818e202558c212a9583fcdaf876995a633ddf The checksums were calculated using the following commands: openssl md5 openssl-1.0.1k.tar.gz openssl sha1 openssl-1.0.1k.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUro4+AAoJENnE0m0OYESRxuQH/2TFznmtvL92IMO6rjeCClYM bBqxvIaVs/l7sflcsENo67HNCn0/RmblmfULVY96Pvoin7z19wMyEFL+3NSM1w8v HkX2mRz23V8PEDxn23f3i1ltCCZgc+aQyKoOf6Rbo4WHxgIHKXdKqm8dhyVj6ODw s2Go3TvaUNtG1BoW6AJtr1ZHosq+WKaOjq5yiRdFb1o/00GipSOb6gRsT2qJHEXS NpFEJm1CRguJ7qe3SPgu7gGyQ34MVl9jO1onRlMqsE4anvZBtm5sK97YXRrc4fqK 0E/SO1sW+mz359fHJMYmYnefG0hs1+KNnA1ydEfLLrf1Bc8Lqft37rN0cVfKdzg= =oLV9 -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 8 15:44:33 2015 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Jan 2015 16:44:33 +0100 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20150108154433.GA30257@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [08 Jan 2015] ======================================= DTLS segmentation fault in dtls1_get_record (CVE-2014-3571) =========================================================== Severity: Moderate A carefully crafted DTLS message can cause a segmentation fault in OpenSSL due to a NULL pointer dereference. This could lead to a Denial Of Service attack. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. OpenSSL 0.9.8 DTLS users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Markus Stenberg of Cisco Systems, Inc. The fix was developed by Stephen Henson of the OpenSSL core team. DTLS memory leak in dtls1_buffer_record (CVE-2015-0206) ======================================================= Severity: Moderate A memory leak can occur in the dtls1_buffer_record function under certain conditions. In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1k. OpenSSL 1.0.0 DTLS users should upgrade to 1.0.0p. This issue was reported to OpenSSL on 7th January 2015 by Chris Mueller who also provided an initial patch. Further analysis was performed by Matt Caswell of the OpenSSL development team, who also developed the final patch. no-ssl3 configuration sets method to NULL (CVE-2014-3569) ========================================================= Severity: Low When openssl is built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl method would be set to NULL which could later result in a NULL pointer dereference. This issue affects all current 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 17th October 2014 by Frank Schmirler. The fix was developed by Kurt Roeckx. ECDHE silently downgrades to ECDH [Client] (CVE-2014-3572) ========================================================== Severity: Low An OpenSSL client will accept a handshake using an ephemeral ECDH ciphersuite using an ECDSA certificate if the server key exchange message is omitted. This effectively removes forward secrecy from the ciphersuite. This issue affects all current 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. RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ============================================================== Severity: Low An OpenSSL client will accept the use of an RSA temporary key in a non-export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session. This issue affects all current 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. DH client certificates accepted without verification [Server] (CVE-2015-0205) ============================================================================= Severity: Low An OpenSSL server will accept a DH certificate for client authentication without the certificate verify message. This effectively allows a client to authenticate without the use of a private key. This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This issue affects OpenSSL versions: 1.0.1 and 1.0.0. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. 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. Certificate fingerprints can be modified (CVE-2014-8275) ======================================================== Severity: Low OpenSSL accepts several non-DER-variations of certificate signature algorithm and signature encodings. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions of the certificate. By modifying the contents of the signature algorithm or the encoding of the signature, it is possible to change the certificate's fingerprint. This does not allow an attacker to forge certificates, and does not affect certificate verification or OpenSSL servers/clients in any other way. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint (e.g. certificate blacklists) may be affected. This issue affects all current 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. One variant of this issue was discovered by Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS program and reported to OpenSSL on 1st December 2014 by NCSC-FI Vulnerability Co-ordination. Another variant was independently reported to OpenSSL on 12th December 2014 by Konrad Kraszewski from Google. Further analysis was conducted and fixes were developed by Stephen Henson of the OpenSSL core team. Bignum squaring may produce incorrect results (CVE-2014-3570) ============================================================= Severity: Low Bignum squaring (BN_sqr) may produce incorrect results on some platforms, including x86_64. This bug occurs at random with a very low probability, and is not known to be exploitable in any way, though its exact impact is difficult to determine. The following has been determined: *) The probability of BN_sqr producing an incorrect result at random is very low: 1/2^64 on the single affected 32-bit platform (MIPS) and 1/2^128 on affected 64-bit platforms. *) On most platforms, RSA follows a different code path and RSA operations are not affected at all. For the remaining platforms (e.g. OpenSSL built without assembly support), pre-existing countermeasures thwart bug attacks [1]. *) Static ECDH is theoretically affected: it is possible to construct elliptic curve points that would falsely appear to be on the given curve. However, there is no known computationally feasible way to construct such points with low order, and so the security of static ECDH private keys is believed to be unaffected. *) Other routines known to be theoretically affected are modular exponentiation, primality testing, DSA, RSA blinding, JPAKE and SRP. No exploits are known and straightforward bug attacks fail - either the attacker cannot control when the bug triggers, or no private key material is involved. This issue affects all current 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 2nd November 2014 by Pieter Wuille (Blockstream) who also suggested an initial fix. Further analysis was conducted by the OpenSSL development team and Adam Langley of Google. The final fix was developed by Andy Polyakov of the OpenSSL core team. [1] http://css.csail.mit.edu/6.858/2013/readings/rsa-bug-attacks.pdf 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_20150108.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 iQEcBAEBAgAGBQJUrpY9AAoJENnE0m0OYESReyMH/1e6o6yRRKVKUUV7wvkoGreO rqdvmG0dRmtPFKvuWlDO6+6nLtBorj5B/Ebqkd+oPfQhZ9is2xyrCIRT1jwqiHPA w35fwEWMD8P1Fpq/hqBVE4QF3zSflS13GIuOBc1Q8dR7JO9TN+xXYy3TkLXzyDOR jSRtqUq2QaHevlpZU2e9olErpQX9mvcOd31JHs8aFyt/hbWsxiY1EUbU7CUfKC5L 4BicWJl4v/OKsy3Ctxx0ajtYE7bbPCElWDwzHaI+FF5pnC6MlI9fUy97fELmniEy tIIxgH9YK0YAnDBoHEH3w5NZtI1qgrhRIasuk9sS7J5ILTB44X9hgQDqnZUVMfA= =7bjl -----END PGP SIGNATURE----- From rt at openssl.org Thu Jan 8 17:49:15 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 8 Jan 2015 18:49:15 +0100 Subject: [openssl-dev] [openssl.org #3036] openssl-0.9.8y config removes symbolic link /dev/null on Solaris In-Reply-To: References: Message-ID: This is a platform bug that can be avoided by not running "./config" as root. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From gmane.bl4 at gishpuppy.com Thu Jan 8 18:39:50 2015 From: gmane.bl4 at gishpuppy.com (gmane.bl4 at gishpuppy.com) Date: Thu, 8 Jan 2015 18:39:50 +0000 (UTC) Subject: [openssl-dev] openssl-1.0.1k - undeclared identifier [GishPuppy] Message-ID: <20150108183950.E9EF272396@mail.gishpuppy.com> Hello, I try to buld openssl-1.0.1k with Visual Studio... PERL Configure VC-WIN32... ms\do_nasm NMAKE -f ms\ntdll.mak and have one error: .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier Simple patch: diff U3 a/openssl-1.0.1k/crypto/cversion.c b/openssl-1.0.1k/crypto/cversion.c --- a/openssl-1.0.1k/crypto/cversion.c Thu Jan 08 08:00:56 2015 +++ b/openssl-1.0.1k/crypto/cversion.c Thu Jan 08 10:16:03 2015 @@ -77,7 +77,7 @@ if (t == SSLEAY_CFLAGS) { #ifdef CFLAGS - return(cflags); + return(CFLAGS); #else return("compiler: information not available"); #endif Gishpuppy | To change the delivery settings for this email, click here: http://www.gishpuppy.com/cgi-bin/edit.py?email=gmane.bl4 at gishpuppy.com From gmane.bl4 at gishpuppy.com Thu Jan 8 18:50:38 2015 From: gmane.bl4 at gishpuppy.com (gmane.bl4 at gishpuppy.com) Date: Thu, 8 Jan 2015 18:50:38 +0000 (UTC) Subject: [openssl-dev] openssl-0.9.8zd - macro redefinition [GishPuppy] Message-ID: <20150108185038.246D97239F@mail.gishpuppy.com> Hello, I try to buld openssl-0.9.8zd with Visual Studio... PERL Configure VC-WIN32... ms\do_nasm NMAKE -f ms\ntdll.mak and receive error: ecs_vrf.c tmp32dll\cryptlib.h(68) : error C2220: warning treated as error - no 'object' file generated tmp32dll\cryptlib.h(68) : warning C4005: 'BIO_FLAGS_UPLINK' : macro redefinition inc32\openssl/bio.h(180) : see previous definition of 'BIO_FLAGS_UPLINK' This I do not know how to fix. Thank you. Gishpuppy | To change the delivery settings for this email, click here: http://www.gishpuppy.com/cgi-bin/edit.py?email=gmane.bl4 at gishpuppy.com From foleyj at cisco.com Thu Jan 8 20:41:24 2015 From: foleyj at cisco.com (John Foley) Date: Thu, 08 Jan 2015 15:41:24 -0500 Subject: [openssl-dev] 1.0.2-stable broken Windows build? Message-ID: <54AEEB74.7030708@cisco.com> Is the Windows build broken on 1.0.2-stable, am I doing something wrong, or is this a tool chain issue? I'm using VS 2013. Using the following steps works on 1.0.1-stable: perl Configure VC-WIN32 ms\do_ms.bat nmake -f ms\nt.mak Here's the log from the broken 1.0.2 build: http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console Here's the log from the working 1.0.1 build: http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console From noreply at openssl.org Fri Jan 9 06:12:07 2015 From: noreply at openssl.org (Mail Administrator) Date: Fri, 9 Jan 2015 12:12:07 +0600 Subject: [openssl-dev] *****SPAM***** Message-ID: <20150109071212.DE68620A0D@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (15.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 1.5 BASE64_LENGTH_79_INF BODY: No description available. 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Mail Administrator" Subject: Date: Fri, 9 Jan 2015 12:12:07 +0600 Size: 31730 URL: From rt at openssl.org Fri Jan 9 07:28:52 2015 From: rt at openssl.org (Goldsmith, Benjamin via RT) Date: Fri, 9 Jan 2015 08:28:52 +0100 Subject: [openssl-dev] [openssl.org #3646] Compile bug in 1.0.1k In-Reply-To: References: Message-ID: Hello, I've discovered a compile time bug. The situation is: OS: Windows 7-64 bit Compiler: Visual C++ 11 (2012) Build steps: > perl Configure VC-WIN64A no-asm --prefix=deps_x64 > ms\do_win64a > nmake -a -f ms\nt.mak cl /Fotmp32\cryptlib.obj -Iinc32 -Itmp32 /MT /Ox -DOPENSSL_THREADS -DD SO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_NO_RC5 -DOPENSS L_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE /Zl /Z i /Fdtmp32/lib -c .\crypto\cryptlib.c cryptlib.c .\crypto\cryptlib.c(863) : warning C4267: 'function' : conversion from 'size_t' to 'int', possible loss of data cl /Fotmp32\mem.obj -Iinc32 -Itmp32 /MT /Ox -DOPENSSL_THREADS -DDSO_WI N32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIA N -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_NO_RC5 -DOPENSSL_NO_ MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE /Zl /Zi /Fd tmp32/lib -c .\crypto\mem.c mem.c cl /Fotmp32\mem_dbg.obj -Iinc32 -Itmp32 /MT /Ox -DOPENSSL_THREADS -DDS O_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_E NDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_NO_RC5 -DOPENSSL _NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE /Zl /Zi /Fdtmp32/lib -c .\crypto\mem_dbg.c mem_dbg.c cl /Fotmp32\cversion.obj -Iinc32 -Itmp32 /MT /Ox -DOPENSSL_THREADS -DD SO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_NO_RC5 -DOPENSS L_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE /Zl /Z i /Fdtmp32/lib -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WIN64A -c .\crypto\cversion.c cversion.c .\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier .\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in le vels of indirection from 'int' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 \VC\BIN\x86_amd64\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 \VC\BIN\nmake.EXE"' : return code '0x2' Stop. Inspecting crypto\cversion.c, it appears that there's a typo on line 80. My speculation is that "cflags" should really be "CFLAGS". When I make that change, the system compiles. Best, -Ben Benjamin Goldsmith Research Engineer Nuance Communications, Inc. 1198 E. Arques Ave. Sunnyvale, CA 94085 Direct: 408-992-6187 Mobile: 310-963-5790 Email: Benjamin.Goldsmith at nuance.com From rt at openssl.org Fri Jan 9 07:29:06 2015 From: rt at openssl.org (Aaron Zauner via RT) Date: Fri, 9 Jan 2015 08:29:06 +0100 Subject: [openssl-dev] [openssl.org #3647] Remove Heartbeat Extension entirely In-Reply-To: <54AF17BA.9030902@azet.org> References: <54AF17BA.9030902@azet.org> Message-ID: Hi, It seems the DTLS heartbeat extension is still supported in current OpenSSL versions (at least that's my impression while playing around with `s_server` with verbose debug logging). I've talked extensively to cryptographers and implementors about this extension, I'm not aware of a single use case of DTLS heartbeats. WebRTC applications are probably not going to rely on DTLS to manage /something like/ heartbeats but will manage that on a application level. As far as I know, most WebRTC clients do exactly that. Going through your RT I could not find a appropriate bug filed for the removal of this -- rather unnecessary -- extension (I'm sure there has been discussion previously, but opening a bug seems reasonable). Please correct me if I'm wrong. Since the feature is in there, it might make more sense to have a compile-time option to _enable_ DTLS heartbeats rather than to disable them (which a lot of hosting companies and CDNs do right now). Thanks for your consideration and time, Aaron -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From zoli at polarhome.com Sat Jan 10 00:00:50 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Sat, 10 Jan 2015 01:00:50 +0100 Subject: [openssl-dev] [PATCH] 1.0.1k CFLAGS issue on OpenVMS Message-ID: <004b01d02c68$7e89ded0$7b9d9c70$@com> Hi, Unfortunately, Matt's latest fix around CFLAGS define ( for making the build work on Windows) does not help on OpenVMS. The following additional patch is needed. SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p []makevms.com;1 []makevms.com;2 *** []makevms.com;1 Wed Jan 7 16:00:30 2015 --- []makevms.com;2 Fri Jan 9 19:41:20 2015 *************** $ if (CFLAGS .nes. "") then CFLAGS = C *** 646,652 **** $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" $ endif $! ! $ WRITE H_FILE "#define CFLAGS" $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' ''VMS_VERSION'""" $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " --- 646,652 ---- $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" $ endif $! ! $ WRITE H_FILE "#define CFLAGS cflags" $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' ''VMS_VERSION'""" $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " Please note, the 1.0.0 branch works fine. Regards, Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From postmaster at openssl.org Sat Jan 10 03:03:41 2015 From: postmaster at openssl.org (Mail Delivery Subsystem) Date: Sat, 10 Jan 2015 09:03:41 +0600 Subject: [openssl-dev] *****SPAM***** Message-ID: <20150110040352.6308320904@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: ??F?Ds,?8?!?????,o??~ $P|??CiN?Mj??Rj?E(_?T?-???\U5????t?VRV???N"DL_?uMp1?????????M`vbr?4hl?????? ?s????3?[_?O?I??>#rs? [\?i9?????;~??t?eJ???uC?J??\!z?_?^??M?F?L( [.??.s?? q 6(??? ?Du?`,5?? ????A)???9u?v5|?m*z???o??a? ?{w?Z???P??56??????~w';k??z??? 8????R?/??5?5?;k???v??/????rp&9?$z?)?????6???x??-??[??:?????KRiht???Yh?$??.?e#?hv6?!? 6S??u.?>!? 7???????? ! ?-Dp???M? 91] ???}????b????"???;Z??]x\N??m?V!u?Y?L??Uh(?? D?\?`?|??1?hU??_QkO???2?8?u??E?K"X??g?9?jlEJ~#?1??????IP????????.?K????UDZ??)?x??????????6????8^"a?F`??3????g??? ???ym???????Ns??xZ ???a^??i/S?E???? ????x6s3???P]A???W?#W$?s?&?t&?xR?[???ep????' 0??o}?]?97??8?a???y?3)?)?? tt)De?2??1??B??7?5m?c/s?.???W?}?!s??????e?U-?TV? ?????}3?p`]???`?%~??s??wJ?t}?k?}_? y?{?X]??`&s?8?7f????l??P???a???G????# ?P??m|"R??X?????:H_???u??w????u???0P9??(?>]\??????1gR:?e??? ????v?1?????{5?????mm??3?Zi??(??.????_`??_1uH???k???T???? ?????vb`6???-Tf(??xl????S?c?(/??g?e7 ?e??,K??Td???4 ???$??y?6?%]t#?? g??&??J? ???????o?L?Z??????*/%\????]?i?BG(?pBX?F??/.LcM????u?|?> ' R?J?J?3z?qvb?)?K|??W?]?LO?sk?H??Eet???j?As??????????????K:??0H?; ^L??H??P Subject: Date: Sat, 10 Jan 2015 09:03:41 +0600 Size: 33702 URL: From MAILER-DAEMON at openssl.org Sat Jan 10 05:15:57 2015 From: MAILER-DAEMON at openssl.org (Bounced mail) Date: Sat, 10 Jan 2015 13:15:57 +0800 Subject: [openssl-dev] *****SPAM***** DELIVERY REPORTS ABOUT YOUR E-MAIL Message-ID: <20150110051615.5C0EE20956@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. [...] Content analysis details: (16.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 1.5 SUBJ_ALL_CAPS Subject is all capitals 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [59.40.208.41 listed in dnsbl.sorbs.net] 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Bounced mail" Subject: DELIVERY REPORTS ABOUT YOUR E-MAIL Date: Sat, 10 Jan 2015 13:15:57 +0800 Size: 31845 URL: From matt at openssl.org Sat Jan 10 22:50:36 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 10 Jan 2015 22:50:36 +0000 Subject: [openssl-dev] openssl-0.9.8zd - macro redefinition [GishPuppy] In-Reply-To: References: <20150108185038.246D97239F@mail.gishpuppy.com> Message-ID: <54B1ACBC.7050503@openssl.org> On 10/01/15 02:39, Guy wrote: > Hello, > > Is this correct list for query; or should I write to users? > > I fix this problem like below, is this proper? > > Thank you. > > > diff U3 a/openssl-0.9.8zd/crypto/cryptlib.h b/openssl-0.9.8zd/crypto/cryptlib.h > --- a/openssl-0.9.8zd/crypto/cryptlib.h Thu Jan 08 08:12:48 2015 > +++ b/openssl-0.9.8zd/crypto/cryptlib.h Fri Jan 09 19:00:00 2015 > @@ -65,6 +65,9 @@ > #include "e_os.h" > > #ifdef OPENSSL_USE_APPLINK > +# ifdef BIO_FLAGS_UPLINK > +# undef BIO_FLAGS_UPLINK > +# endif > #define BIO_FLAGS_UPLINK 0x8000 > #include "ms/uplink.h" > #endif > Yes, that fix is fine. Matt From postmaster at openssl.org Sun Jan 11 03:45:47 2015 From: postmaster at openssl.org (Mail Delivery Subsystem) Date: Sun, 11 Jan 2015 11:45:47 +0800 Subject: [openssl-dev] *****SPAM***** Returned mail: see transcript for details Message-ID: <20150111034605.57297202D8@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. [...] Content analysis details: (14.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100% [score: 1.0000] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [59.40.208.41 listed in dnsbl.sorbs.net] 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Mail Delivery Subsystem" Subject: Returned mail: see transcript for details Date: Sun, 11 Jan 2015 11:45:47 +0800 Size: 31504 URL: From postmaster at openssl.org Sun Jan 11 04:50:02 2015 From: postmaster at openssl.org (Post Office) Date: Sun, 11 Jan 2015 12:50:02 +0800 Subject: [openssl-dev] *****SPAM***** MESSAGE COULD NOT BE DELIVERED Message-ID: <20150111045010.8CC70202FD@mta.openssl.org> Spam detection software, running on the system "mta.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: The original message was received at Sun, 11 Jan 2015 12:50:02 +0800 from openssl.org [160.204.107.34] ----- The following addresses had permanent fatal errors ----- [...] Content analysis details: (15.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: openssl.org] 1.5 SUBJ_ALL_CAPS Subject is all capitals 1.5 BAYES_60 BODY: Bayes spam probability is 60 to 80% [score: 0.6373] 1.5 BASE64_LENGTH_79_INF BODY: No description available. 2.2 AXB_XMAILER_MIMEOLE_OL_024C2 No description available. 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.5 MISSING_MID Missing Message-Id: header 1.9 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook 2.5 DOS_OE_TO_MX Delivered direct to MX with OE headers 3.5 TO_NO_BRKTS_MSFT To: misformatted and supposed Microsoft tool The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: "Post Office" Subject: MESSAGE COULD NOT BE DELIVERED Date: Sun, 11 Jan 2015 12:50:02 +0800 Size: 31398 URL: From dominyktiller at gmail.com Mon Jan 12 00:02:34 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Mon, 12 Jan 2015 00:02:34 +0000 Subject: [openssl-dev] ChaCha20 & Poly1305 Message-ID: <54B30F1A.10101@gmail.com> Hey guys, I wanted to check the status of the two ciphers referenced in the subject in OpenSSL. I thought, for some reason, the ChaCha and Poly cipher support was landing in the 1.0.2 branch, but I can't find the respective folders/headers/etc in the git branch. Was I wildly mistaken in that thought? If it hasn't landed, does anyone know the status of the patch AGL provided a while back? https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b 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 matt at openssl.org Mon Jan 12 00:08:30 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Jan 2015 00:08:30 +0000 Subject: [openssl-dev] ChaCha20 & Poly1305 In-Reply-To: <54B30F1A.10101@gmail.com> References: <54B30F1A.10101@gmail.com> Message-ID: <54B3107E.4030602@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/15 00:02, Dominyk Tiller wrote: > Hey guys, > > I wanted to check the status of the two ciphers referenced in the > subject in OpenSSL. > > I thought, for some reason, the ChaCha and Poly cipher support was > landing in the 1.0.2 branch, but I can't find the respective > folders/headers/etc in the git branch. Was I wildly mistaken in > that thought? > > If it hasn't landed, does anyone know the status of the patch AGL > provided a while back? > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b > > Its not in 1.0.2. Andy is working on the implementation. IIRC AGL's patch is out of date. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUsxB+AAoJENnE0m0OYESRkhAIAID4ccxRh+TWRVtJ6xzV6iHl lp8lhzy4saR2GKAxFK9PMf7howwwW0uO0MxS6VNB6zS8O3Dh7m6bj/1eS+3tvFZ3 OsZ14DsfOdhpOmxF0hd8CDYFhVpngtRCfW58RhyvbH5rj5WQL0s5EWYHC+p1P560 1B4K7g3Kboc0hk76ITvJOBF49qJblosnszg8x46aCSH8pt6pLEiESoSKLznZ9djW OwAhtrmQfFpl5XUbRbCKSfOsN17P8dU1yJ5h96xa5dx4T8H0PHZPn5Noc4GKayrm RIilozYRMuzyqHo5n8DYmHV2Ssey38EDgErSjAZtEtfjoOikOQVuNhl1CUJVFjY= =zptM -----END PGP SIGNATURE----- From rsalz at akamai.com Mon Jan 12 03:09:58 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 11 Jan 2015 22:09:58 -0500 Subject: [openssl-dev] ChaCha20 & Poly1305 In-Reply-To: <54B30F1A.10101@gmail.com> References: <54B30F1A.10101@gmail.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55675E7D@USMBX1.msg.corp.akamai.com> > If it hasn't landed, does anyone know the status of the patch AGL provided a > while back? > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b I can answer this, easy, one. That patch is outdated by the latest I-D From foleyj at cisco.com Tue Jan 13 14:05:19 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 13 Jan 2015 09:05:19 -0500 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54AEEB74.7030708@cisco.com> References: <54AEEB74.7030708@cisco.com> Message-ID: <54B5261F.5060402@cisco.com> Given the 1.0.2 release is forthcoming in the near future, it would be good if someone could look at this issue. It looks like there were a lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA extensions, which aren't available until Skylake. Is there a new tool chain requirement for building 1.0.2 on Windows? Has the build procedure changed? Or is this simply a bug in sha1-586.pl? On 01/08/2015 03:41 PM, John Foley wrote: > Is the Windows build broken on 1.0.2-stable, am I doing something wrong, > or is this a tool chain issue? I'm using VS 2013. Using the following > steps works on 1.0.1-stable: > > perl Configure VC-WIN32 > ms\do_ms.bat > nmake -f ms\nt.mak > > > Here's the log from the broken 1.0.2 build: > > http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console > > Here's the log from the working 1.0.1 build: > > http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console From matt at openssl.org Tue Jan 13 14:24:05 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 14:24:05 +0000 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54B5261F.5060402@cisco.com> References: <54AEEB74.7030708@cisco.com> <54B5261F.5060402@cisco.com> Message-ID: <54B52A85.1050000@openssl.org> On 13/01/15 14:05, John Foley wrote: > Given the 1.0.2 release is forthcoming in the near future, it would be > good if someone could look at this issue. It looks like there were a > lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA > extensions, which aren't available until Skylake. > > Is there a new tool chain requirement for building 1.0.2 on Windows? > Has the build procedure changed? Or is this simply a bug in sha1-586.pl? Hmmmmm...I have built 1.0.2 on Windows myself today without this problem. The tool chain and build procedure are unchanged. Strange. Matt From foleyj at cisco.com Tue Jan 13 14:27:50 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 13 Jan 2015 09:27:50 -0500 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54B52A85.1050000@openssl.org> References: <54AEEB74.7030708@cisco.com> <54B5261F.5060402@cisco.com> <54B52A85.1050000@openssl.org> Message-ID: <54B52B66.4030709@cisco.com> Thanks for responding. Which tool chain are you using? I'm using VS 2013 with the ml compiler. Given this assembly is generated by a perl script, maybe it's a perl issue. Which perl interpreter are you using? On 01/13/2015 09:24 AM, Matt Caswell wrote: > > On 13/01/15 14:05, John Foley wrote: >> Given the 1.0.2 release is forthcoming in the near future, it would be >> good if someone could look at this issue. It looks like there were a >> lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA >> extensions, which aren't available until Skylake. >> >> Is there a new tool chain requirement for building 1.0.2 on Windows? >> Has the build procedure changed? Or is this simply a bug in sha1-586.pl? > Hmmmmm...I have built 1.0.2 on Windows myself today without this > problem. The tool chain and build procedure are unchanged. Strange. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From matt at openssl.org Tue Jan 13 14:35:00 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Jan 2015 14:35:00 +0000 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54B52B66.4030709@cisco.com> References: <54AEEB74.7030708@cisco.com> <54B5261F.5060402@cisco.com> <54B52A85.1050000@openssl.org> <54B52B66.4030709@cisco.com> Message-ID: <54B52D14.4070204@openssl.org> On 13/01/15 14:27, John Foley wrote: > Thanks for responding. Which tool chain are you using? I'm using VS > 2013 with the ml compiler. Given this assembly is generated by a perl > script, maybe it's a perl issue. Which perl interpreter are you using? > Visual Studio 2013 with Active State perl: This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x64-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2012, Larry Wall Binary build 1604 [298023] provided by ActiveState http://www.ActiveState.com Built Apr 14 2014 15:29:45 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. and nasm: NASM version 2.11.06 compiled on Oct 20 2014 Matt From appro at openssl.org Tue Jan 13 15:00:06 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 13 Jan 2015 16:00:06 +0100 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54B52B66.4030709@cisco.com> References: <54AEEB74.7030708@cisco.com> <54B5261F.5060402@cisco.com> <54B52A85.1050000@openssl.org> <54B52B66.4030709@cisco.com> Message-ID: <54B532F6.6070105@openssl.org> > Thanks for responding. Which tool chain are you using? I'm using VS > 2013 with the ml compiler. Given this assembly is generated by a perl > script, maybe it's a perl issue. Which perl interpreter are you using? Quoting INSTALL.W32: "Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler." You can drop nasm.exe to any place on %PATH% to get it working. This means that we formally don't accept problem reports for ml. One can argue that we ought to, because ml might be not as bad as it used to. But if we change this, it would probably be more appropriate to do in post-1.0.2 context. But it doesn't harm to ask for more details. I tried to emit code for ml and lines in question, i.e. 1432 and 1576, appear totally innocent, as there are similar instructions next to them. How do these lines look like for you? I mean could you just copy-n-paste say 5 lines fragments around those line numbers? >>> Given the 1.0.2 release is forthcoming in the near future, it would be >>> good if someone could look at this issue. It looks like there were a >>> lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA >>> extensions, SHA-extension-specific code doesn't require explicit support from assembler, or in other words, it can be assembled with assembler that is not aware of SHA extensions. This is because those instructions are encoded "manually" with DB/.byte directive. >>> which aren't available until Skylake. For reference, first processor that will have SHA extensions is Goldmont, Silvermont's successor, i.e. one from Atom family. From foleyj at cisco.com Tue Jan 13 15:32:40 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 13 Jan 2015 10:32:40 -0500 Subject: [openssl-dev] 1.0.2-stable broken Windows build? In-Reply-To: <54B532F6.6070105@openssl.org> References: <54AEEB74.7030708@cisco.com> <54B5261F.5060402@cisco.com> <54B52A85.1050000@openssl.org> <54B52B66.4030709@cisco.com> <54B532F6.6070105@openssl.org> Message-ID: <54B53A98.1000105@cisco.com> Thanks for setting me straight. 1.0.2 works for me when using nasm. On 01/13/2015 10:00 AM, Andy Polyakov wrote: >> Thanks for responding. Which tool chain are you using? I'm using VS >> 2013 with the ml compiler. Given this assembly is generated by a perl >> script, maybe it's a perl issue. Which perl interpreter are you using? > Quoting INSTALL.W32: > > "Netwide Assembler, a.k.a. NASM, available from > http://nasm.sourceforge.net/ is required if you intend to utilize > assembler modules. Note that NASM is now the only supported assembler." > > You can drop nasm.exe to any place on %PATH% to get it working. > > This means that we formally don't accept problem reports for ml. One can > argue that we ought to, because ml might be not as bad as it used to. > But if we change this, it would probably be more appropriate to do in > post-1.0.2 context. But it doesn't harm to ask for more details. I tried > to emit code for ml and lines in question, i.e. 1432 and 1576, appear > totally innocent, as there are similar instructions next to them. How do > these lines look like for you? I mean could you just copy-n-paste say 5 > lines fragments around those line numbers? > >>>> Given the 1.0.2 release is forthcoming in the near future, it would be >>>> good if someone could look at this issue. It looks like there were a >>>> lot of changes made to sha1-586.pl in 1.0.2 to support the new Intel SHA >>>> extensions, > SHA-extension-specific code doesn't require explicit support from > assembler, or in other words, it can be assembled with assembler that is > not aware of SHA extensions. This is because those instructions are > encoded "manually" with DB/.byte directive. > >>>> which aren't available until Skylake. > For reference, first processor that will have SHA extensions is > Goldmont, Silvermont's successor, i.e. one from Atom family. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Mon Jan 12 22:35:56 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 12 Jan 2015 23:35:56 +0100 Subject: [openssl-dev] [openssl.org #3548] Remove some unsupported platforms In-Reply-To: References: Message-ID: Closed in a series of commits. 6d23cf97443bfedf755341b4f2d0d7fce254e020 fcf64ba0ace1bb76c6e00ca7d0c7cf7f9bebe628 b5526482ef81ee7906b967e326d23a45fbcf3abc 32dfde107636ac9bc62a5b3233fe2a54dbc27008 6c23ca0cbb0181f803f38694e3f25e53e409a238 5ad4fdce41bb1ce7762b70fb50f732f70e3772cf f2319414445ef5991d77c015af86276d84b9fec1 e03b29871b2b87af9a4ec21c49eb3e1826eb772a 59ff1ce06108508eba0f289b295dd89582c9fbfc b317819b2e74f1f84925695596aa3c7487a2264d (Yeah, that's as clear as mud :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Jan 12 22:36:37 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 12 Jan 2015 23:36:37 +0100 Subject: [openssl-dev] [openssl.org #478] make uninstall In-Reply-To: References: Message-ID: commit 9405a9a2e1594cea9c963c29d9898bb03cb0f24f Author: Rich Salz Date: Mon Jan 12 10:28:05 2015 -0500 RT478: Add uninstall make target Add INSTALLDIRS variable, list of directories where things get installed. Change install_html_docs to use perl mkdir-p script. Add uninstall, uninstall_sw, uninstall_docs, uninstall_html_docs to Makefile.org. The actions of these targets were figured out by "inverting" the install target. Recurse into subdirs to do uninstall as needed. Added uninstall targets whose actions were similarly figured out by "inverting" the install target. Also remove some 'space before tab' complaints in Makefile.org Reviewed-by: Tim Hudson -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Jan 13 19:44:15 2015 From: rt at openssl.org (Mark Andrews via RT) Date: Tue, 13 Jan 2015 20:44:15 +0100 Subject: [openssl-dev] [openssl.org #3652] [PATCH] openssl-1.0.1k fails to compile under Windows In-Reply-To: <20150112010352.2EF21274B4B1@rock.dv.isc.org> References: <20150112010352.2EF21274B4B1@rock.dv.isc.org> Message-ID: CFLAGS has the wrong case. --- openssl-1.0.1k/crypto/cversion.c.orig 2015-01-09 01:00:56.000000000 +1100 +++ openssl-1.0.1k/crypto/cversion.c 2015-01-12 12:00:16.000000000 +1100 @@ -77,7 +77,7 @@ if (t == SSLEAY_CFLAGS) { #ifdef CFLAGS - return(cflags); + return(CFLAGS); #else return("compiler: information not available"); #endif -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rt at openssl.org Tue Jan 13 19:43:59 2015 From: rt at openssl.org (Julien Kauffmann via RT) Date: Tue, 13 Jan 2015 20:43:59 +0100 Subject: [openssl-dev] [openssl.org #3651] Compilation error on Windows x64 in crypto/cversion.c In-Reply-To: <54B2F888.3060103@freelan.org> References: <54B2F888.3060103@freelan.org> Message-ID: Hi, I just tried to compile OpenSSL 1.0.1k on Windows using the same compilation steps I used for previous versions (1.0.1j.tar.gz built fine) but encountered an error: In crypto/cversion.c, line 79 are the following lines: #ifdef CFLAGS return(cflags); #else The error is on line 80, where the existence for CFLAGS is tested but (cflags) is actually returned. Changing "cflags" for "CFLAGS" seems to solve it and the compilation succeeds. I figured I let you know. :) Julien. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4276 bytes Desc: not available URL: From rt at openssl.org Tue Jan 13 19:41:53 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 13 Jan 2015 20:41:53 +0100 Subject: [openssl-dev] [openssl.org #3648] BUG: Undefined behavior in easy_tls.c In-Reply-To: References: Message-ID: Around line 731 of demos/easy_tls/easy_tls.c: if (tls_dhe1024 == NULL) { int i; RAND_bytes((unsigned char *) &i, sizeof i); /* make sure that i is non-negative -- pick one of the provided * seeds */ if (i < 0) i = -i; if (i < 0) i = 0; tls_set_dhe1024(i, apparg); if (tls_dhe1024 == NULL) goto err_return; } In a correct program, the assumptions does not hold. I think some of it could be optimized away (http://www.airs.com/blog/archives/120): if (i < 0) i = -i; if (i < 0) i = 0; Perhaps the test should be something like: if(i < 0 && i != INT_MIN) i = -i; else if (i == INT_MIN) i = 0; Or perhaps more tersely: if(i < 0) i = (int)((unsigned int)i >> 1); Or: if(i < 0) i = (int)((unsigned int)i % INT_MAX); I think the last is most portable, but I'm not sure how it affects a uniform distribution. From rt at openssl.org Tue Jan 13 19:42:23 2015 From: rt at openssl.org (Leopert Li via RT) Date: Tue, 13 Jan 2015 20:42:23 +0100 Subject: [openssl-dev] [openssl.org #3649] Unnecessary engine lookup in EVP_DigestInit_ex In-Reply-To: References: Message-ID: Hi, I am using 1.0.1h, but believe the problem still exists in later versions. I have following code to calculate HMAC for messages in a multi-threaded application. The locking is expensive so locking on hmac calculation of every message is unaffordable. sessesion initialization - initialize the context with evp_digest only, engine lookup will occur which needs to lock: HMAC_CTX_init(&ctx); HMAC_Init_ex(&ctx, NULL, 0, evp_digest, NULL); hmac calculation - update context with key only, no engine lookup should occur. However, engine lookup does occur inside HMAC_Init_ex. This means lock is called for every message, that is too often. HMAC_Init_ex(&ctx, key_in, key_len, NULL, NULL); HMAC_Update(&ctx, msg_buffer, msg_len); HMAC_Final(&ctx, hmac_buffer, &hmac_len) Had a look into OpenSSL's source code, the reason for the problem is that there is no engine available for the evp_digest (sha256 in my case). The code that I think should be corrected are: 1. in HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len, const EVP_MD *md, ENGINE *impl): even if I pass NULL for md, it will pass the non-NULL one that I passed in previous call to EVP_DigestInit_ex() anyway 2. in EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl): even if I pass NULL for type, engine lookup is still not bypassed. And that is because the last engine lookup returned NULL and the bypass check requires that we got a valid engine before. And when it checks if type is a new digest compared with the existing one in the context (digest.c:202), it does not consider the case when type==NULL. This may seem a minor issue, but for multi-threaded high performance applications, the impact incurred by the unnecessary locking is huge. There is no way to work it around unless make update to OpenSSL. Let me know if you need more information. Thanks Leopert Li From rt at openssl.org Tue Jan 13 19:42:57 2015 From: rt at openssl.org (John Foley via RT) Date: Tue, 13 Jan 2015 20:42:57 +0100 Subject: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds In-Reply-To: <54B3D99B.4080605@cisco.com> References: <54B3D99B.4080605@cisco.com> Message-ID: Is the Windows build broken on 1.0.2-stable, am I doing something wrong, or is this a tool chain issue? Assembling: tmp32\sha1-586.asm tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\ml.EXE"' : return code '0x1' Stop. I'm using VS 2013. This problem does not occur on 1.0.1. Using the following steps works on 1.0.1-stable: perl Configure VC-WIN32 ms\do_ms.bat nmake -f ms\nt.mak Here's the log from the broken 1.0.2 build: http://173.39.238.160:8080/view/1.0.2%20Stable/job/1_0_2_windows/1/console Here's the log from the working 1.0.1 build: http://173.39.238.160:8080/view/1.0.1%20Stable/job/1_0_1_windows/6/console From rt at openssl.org Tue Jan 13 19:46:08 2015 From: rt at openssl.org (Zoltan Arpadffy via RT) Date: Tue, 13 Jan 2015 20:46:08 +0100 Subject: [openssl-dev] [openssl.org #3653] [PATCH] 1.0.1k CFLAGS issue on OpenVMS In-Reply-To: <003a01d02c42$3b6bf960$b243ec20$@com> References: <003a01d02c42$3b6bf960$b243ec20$@com> Message-ID: Hi, Unfortunately, the Matt's latest fix around CFLAGS define ( for making the build work on Windows) does not help on OpenVMS. The following path is needed. SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p []makevms.com;1 []makevms.com;2 *** []makevms.com;1 Wed Jan 7 16:00:30 2015 --- []makevms.com;2 Fri Jan 9 19:41:20 2015 *************** $ if (CFLAGS .nes. "") then CFLAGS = C *** 646,652 **** $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" $ endif $! ! $ WRITE H_FILE "#define CFLAGS" $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' ''VMS_VERSION'""" $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " --- 646,652 ---- $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" $ endif $! ! $ WRITE H_FILE "#define CFLAGS cflags" $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' ''VMS_VERSION'""" $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " Please note, the 1.0.0 branch works fine. Regards, Z From rsalz at akamai.com Tue Jan 13 19:50:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 13 Jan 2015 14:50:25 -0500 Subject: [openssl-dev] OpenSSL coding style published Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> The OpenSSL coding style document is now available on our web site: https://www.openssl.org/about/codingstyle.txt It is derived from the Linux Kernel coding style, and we are grateful to them for providing such an excellent document that we could use as our base. Because it is derived from the GPL'd kernel style, the OpenSSL coding style will not be part of the distribution. As Matt mentioned in earlier mail, we will be reformatting all release branches. See his message[1] for sample output and pointers to the script. The target date for doing this is "very soon." :) /r$ [1] https://mta.openssl.org/pipermail/openssl-dev/2015-January/000299.html -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Jan 13 20:16:11 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 13 Jan 2015 21:16:11 +0100 Subject: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds In-Reply-To: <54B57D00.8090104@openssl.org> References: <54B3D99B.4080605@cisco.com> <54B57D00.8090104@openssl.org> Message-ID: > Is the Windows build broken on 1.0.2-stable, am I doing something wrong, > or is this a tool chain issue? > > Assembling: tmp32\sha1-586.asm > tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands > tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\ml.EXE"' : return code '0x1' > Stop. This was already answered on , but despite the fact that ml is not really supported, offer to have a closer look at what's upsetting it still stands. I mean the suggestion to send few lines surrounding the lines in question. From rt at openssl.org Sat Jan 10 21:04:49 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 10 Jan 2015 22:04:49 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <543B2685.3070801@av8n.com> References: <543B2685.3070801@av8n.com> Message-ID: And also in 1.0.1 for the next time we put out a patch. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Jan 13 21:01:42 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 13 Jan 2015 22:01:42 +0100 Subject: [openssl-dev] [openssl.org #3653] [PATCH] 1.0.1k CFLAGS issue on OpenVMS In-Reply-To: <003a01d02c42$3b6bf960$b243ec20$@com> References: <003a01d02c42$3b6bf960$b243ec20$@com> Message-ID: Thanks for the notification... I was actually thinking about this earlier today. Fix coming up! On Tue Jan 13 20:46:08 2015, zoli at polarhome.com wrote: > Hi, > > Unfortunately, the Matt's latest fix around CFLAGS define ( for making the > build work on Windows) does not help on OpenVMS. > The following path is needed. > SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p []makevms.com;1 []makevms.com;2 > *** []makevms.com;1 Wed Jan 7 16:00:30 2015 > --- []makevms.com;2 Fri Jan 9 19:41:20 2015 > *************** $ if (CFLAGS .nes. "") then CFLAGS = C > *** 646,652 **** > $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" > $ endif > $! > ! $ WRITE H_FILE "#define CFLAGS" > $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" > $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' > ''VMS_VERSION'""" > $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " > --- 646,652 ---- > $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" > $ endif > $! > ! $ WRITE H_FILE "#define CFLAGS cflags" > $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" > $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' > ''VMS_VERSION'""" > $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " > > Please note, the 1.0.0 branch works fine. > > Regards, > Z -- Richard Levitte levitte at openssl.org From jifl at eCosCentric.com Tue Jan 13 21:20:11 2015 From: jifl at eCosCentric.com (Jonathan Larmour) Date: Tue, 13 Jan 2015 21:20:11 +0000 Subject: [openssl-dev] OpenSSL coding style published In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> Message-ID: <54B58C0B.6090007@eCosCentric.com> On 13/01/15 19:50, Salz, Rich wrote: > > As Matt mentioned in earlier mail, we will be reformatting all release > branches. See his message[1] for sample output and pointers to the > script. The target date for doing this is ?very soon.? J One concern I have is that I, and no doubt others, look through the diffs between OpenSSL releases to see what the ramifications of changes are. If important changes are mixed in with wholesale cosmetic reformatting, that is going to be much harder to do. There are a number of ways round this, but may I suggest that the reformat be one of the last, if not the last, git revision before the next release. Or equivalently, one of the first changes _after_ the next release. That way, we can see the substantive changes coherently. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine From Geoff_Lowe at McAfee.com Tue Jan 13 21:44:15 2015 From: Geoff_Lowe at McAfee.com (Lowe, Geoff) Date: Tue, 13 Jan 2015 21:44:15 +0000 Subject: [openssl-dev] OpenSSL coding style published In-Reply-To: <54B58C0B.6090007@eCosCentric.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> <54B58C0B.6090007@eCosCentric.com> Message-ID: <667f6ca027234f8cab71b2e0ce10235f@MIVEXUSR1N06.corpzone.internalzone.com> +1 Geoff On 13/01/15 19:50, Salz, Rich wrote: > > As Matt mentioned in earlier mail, we will be reformatting all release > branches. See his message[1] for sample output and pointers to the > script. The target date for doing this is "very soon." J One concern I have is that I, and no doubt others, look through the diffs between OpenSSL releases to see what the ramifications of changes are. If important changes are mixed in with wholesale cosmetic reformatting, that is going to be much harder to do. There are a number of ways round this, but may I suggest that the reformat be one of the last, if not the last, git revision before the next release. Or equivalently, one of the first changes _after_ the next release. That way, we can see the substantive changes coherently. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rsalz at akamai.com Tue Jan 13 22:04:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 13 Jan 2015 17:04:25 -0500 Subject: [openssl-dev] OpenSSL coding style published In-Reply-To: <54B58C0B.6090007@eCosCentric.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> <54B58C0B.6090007@eCosCentric.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC4F6@USMBX1.msg.corp.akamai.com> > One concern I have is that I, and no doubt others, look through the diffs > between OpenSSL releases to see what the ramifications of changes are. We appreciate the issue. At a minimum, there will be pre- and post-indent tags. And the script we use to do the indentation is available (and will be in the release) so that people with modified versions can "play along at home" as it were. We had a great deal of discussion about this, and it's not something we're doing casually. We think it's the best way to move forward, even though some folks will be inconvenienced. /r$ From colmmacc at amazon.com Tue Jan 13 22:42:06 2015 From: colmmacc at amazon.com (MacCarthaigh, Colm) Date: Tue, 13 Jan 2015 22:42:06 +0000 Subject: [openssl-dev] OpenSSL coding style published In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC4F6@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC451@USMBX1.msg.corp.akamai.com> <54B58C0B.6090007@eCosCentric.com>, <2A0EFB9C05D0164E98F19BB0AF3708C71D55AEC4F6@USMBX1.msg.corp.akamai.com> Message-ID: <5D1B2011BD19A347AC342C95EC4A630727881AA3@ex10-mbx-36004.ant.amazon.com> I maintain a few private branches of the OpenSSL source code, including some custom patches and changes. To keep up with things and stay up to date I review the changes at least every release, and semi-regularly try to keep up with what's in change control. I'm actually looking forward to the change; although it will mean a one-time reformat I don't think it'll be a big inconvenience. And once it's done I think it'll make the future changes easier to read. Thanks for doing it! ________________________________________ From: openssl-dev [openssl-dev-bounces at openssl.org] on behalf of Salz, Rich [rsalz at akamai.com] Sent: 13 January 2015 14:04 To: openssl-dev at openssl.org Subject: Re: [openssl-dev] OpenSSL coding style published > One concern I have is that I, and no doubt others, look through the diffs > between OpenSSL releases to see what the ramifications of changes are. We appreciate the issue. At a minimum, there will be pre- and post-indent tags. And the script we use to do the indentation is available (and will be in the release) so that people with modified versions can "play along at home" as it were. We had a great deal of discussion about this, and it's not something we're doing casually. We think it's the best way to move forward, even though some folks will be inconvenienced. /r$ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From michel.sales at OnLine.fr Tue Jan 13 23:00:14 2015 From: michel.sales at OnLine.fr (Michel SALES) Date: Wed, 14 Jan 2015 00:00:14 +0100 Subject: [openssl-dev] openssl 1.0.2 fails to compile when configured with no-nextprotoneg (ssl/t1_ext.c) Message-ID: <001b01d02f84$b1440d40$13cc27c0$@sales@OnLine.fr> Hi, I failed to compile version 1.0.2 snapshot 20150113 configured with no-nextprotoneg because of : ssl/t1_ext.c, line 285, 'TLSEXT_TYPE_next_proto_neg' : undeclared identifier (error C2065) May I suggest as for other lines (296, 299) : #ifdef TLSEXT_TYPE_next_proto_neg case TLSEXT_TYPE_next_proto_neg: #endif Best regards, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Jan 13 23:59:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 14 Jan 2015 00:59:34 +0100 Subject: [openssl-dev] [openssl.org #3653] [PATCH] 1.0.1k CFLAGS issue on OpenVMS In-Reply-To: References: <003a01d02c42$3b6bf960$b243ec20$@com> Message-ID: Fix now present in the branches for 1.0.2, 1.0.1 and even 1.0.0. On Tue Jan 13 22:01:42 2015, levitte wrote: > Thanks for the notification... I was actually thinking about this earlier > today. Fix coming up! > > On Tue Jan 13 20:46:08 2015, zoli at polarhome.com wrote: > > Hi, > > > > Unfortunately, the Matt's latest fix around CFLAGS define ( for making the > > build work on Windows) does not help on OpenVMS. > > The following path is needed. > > SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p []makevms.com;1 []makevms.com;2 > > *** []makevms.com;1 Wed Jan 7 16:00:30 2015 > > --- []makevms.com;2 Fri Jan 9 19:41:20 2015 > > *************** $ if (CFLAGS .nes. "") then CFLAGS = C > > *** 646,652 **** > > $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" > > $ endif > > $! > > ! $ WRITE H_FILE "#define CFLAGS" > > $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" > > $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' > > ''VMS_VERSION'""" > > $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " > > --- 646,652 ---- > > $ CFLAGS = CFLAGS+ "/DEFINE=ZLIB" > > $ endif > > $! > > ! $ WRITE H_FILE "#define CFLAGS cflags" > > $ WRITE H_FILE "static const char cflags[] = ""compiler: ''CFLAGS'"";" > > $ WRITE H_FILE "#define PLATFORM ""platform: VMS ''ARCHD' > > ''VMS_VERSION'""" > > $ WRITE H_FILE "#define DATE ""built on: ''TIME'"" " > > > > Please note, the 1.0.0 branch works fine. > > > > Regards, > > Z > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org From rt at openssl.org Wed Jan 14 02:36:35 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 14 Jan 2015 03:36:35 +0100 Subject: [openssl-dev] [openssl.org #611] Fw: Bug in SSL_Shutdown? In-Reply-To: <006b01c3158f$fba11390$16e1ab3f@JOELDXP> References: <006b01c3158f$fba11390$16e1ab3f@JOELDXP> Message-ID: This appears to be an old stunnel/openssl integration issue that has since been resolved. Closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From zoli at polarhome.com Wed Jan 14 07:44:41 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Wed, 14 Jan 2015 08:44:41 +0100 Subject: [openssl-dev] [PATCH] install issue on OpenVMS in 1.0.0 branch Message-ID: <001101d02fcd$f50a04a0$df1e0de0$@com> Hi, during installation of 1.0.0 branch on OpenVMS the following error appears. %COPY-E-OPENIN, error opening IA64$DKA0:[WORK.OPENSSL-100-STABLE-SNAP-20150109.CRYPTO.SRP]SRP.H; as input -RMS-E-DNF, directory not found -SYSTEM-W-NOSUCHFILE, no such file The solution is to apply the following patch. SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p [.crypto]install-crypto.com;1 [.crypto]install-crypto.com;4 *** [.crypto]install-crypto.com;1 Wed Oct 15 11:00:38 2014 --- [.crypto]install-crypto.com;4 Mon Jan 12 11:24:39 2015 *************** $ sdirs := , - *** 81,87 **** buffer, bio, stack, lhash, rand, err, - evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - ui, krb5, - ! cms, pqueue, ts, jpake, srp, store, cmac $! $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ exheader_'archd' := opensslconf.h --- 81,87 ---- buffer, bio, stack, lhash, rand, err, - evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - ui, krb5, - ! cms, pqueue, ts, jpake, store $! $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h $ exheader_'archd' := opensslconf.h *************** $ exheader_cms := cms.h *** 139,147 **** $ exheader_pqueue := pqueue.h $ exheader_ts := ts.h $ exheader_jpake := jpake.h - $ exheader_srp := srp.h $ exheader_store := store.h - $ exheader_cmac := cmac.h $ libs := ssl_libcrypto $! $ exe_dir := [-.'archd'.exe.crypto] --- 139,145 ---- Thank you. Regards, Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Jan 14 11:47:54 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 14 Jan 2015 12:47:54 +0100 Subject: [openssl-dev] [openssl.org #3646] Compile bug in 1.0.1k In-Reply-To: References: Message-ID: Hi Ben There is a fix for this issue currently in git (see commit 56cd7404). Closing this ticket. Matt From rt at openssl.org Wed Jan 14 11:49:15 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 14 Jan 2015 12:49:15 +0100 Subject: [openssl-dev] [openssl.org #3651] Compilation error on Windows x64 in crypto/cversion.c In-Reply-To: <54B2F888.3060103@freelan.org> References: <54B2F888.3060103@freelan.org> Message-ID: Hi Julien There is a fix for this issue currently in git (see commit 56cd7404). Closing this ticket. Matt From rt at openssl.org Wed Jan 14 11:50:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 14 Jan 2015 12:50:05 +0100 Subject: [openssl-dev] [openssl.org #3652] [PATCH] openssl-1.0.1k fails to compile under Windows In-Reply-To: <20150112010352.2EF21274B4B1@rock.dv.isc.org> References: <20150112010352.2EF21274B4B1@rock.dv.isc.org> Message-ID: Hi Mark There is a fix for this issue currently in git (see commit 56cd7404). Closing this ticket. Matt From matt at openssl.org Wed Jan 14 15:32:34 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Jan 2015 15:32:34 +0000 Subject: [openssl-dev] Forthcoming OpenSSL releases and reformat Message-ID: <54B68C12.5000507@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The OpenSSL Project are pleased to make the following announcements: - - There will be new releases made available on Thursday 15th January for versions 1.0.1, 1.0.0 and 0.9.8. These will be bug fix only releases to address build problems with the current releases on the Windows and OpenVMS platforms. No new security issues will be included in these releases. - - The whole OpenSSL codebase will be reformatted according to the newly published OpenSSL coding style (https://www.openssl.org/about/codingstyle.txt) on Wednesday 21st January. This will include the master, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 branches. See [1] for further background information. - - Between the releases being made available on 15th January and the code reformat on 21st January the 1.0.1, 1.0.0 and 0.9.8 branches in the public repository will be frozen and no changes will be made (except in the case of very high priority fixes). - - OpenSSL 1.0.2 will be released on Thursday 22nd January. Yours The OpenSSL Project Team [1] https://mta.openssl.org/pipermail/openssl-dev/2015-January/000299.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUtowSAAoJENnE0m0OYESRjr0H/3ui088oz8ZDcHEkhXoF1Pd/ bJStjZPtWUq4BJTTKq/GTTK7TGsjW+z+OwXFuLOX6ZfvVTG0aMpCGEU4OT7PO2zt NC76X56bTA+sFrJt65Ks3xMZ4pppBRq6irSJsvihEb1rWiAGDlTTjJJLKfgP76Xc ZxHnQ4LKmWcqqZmuK+XFqkitf6DuVMNlPa6yJ9jjbq6gSibxSNvhbu+qTfH2M30g 9X854pWKj5j76RLmDvFBPqP+sGHNBhs45THZO7BuGPQV5lJzRvnJxQKreAcHAyhq BihHEdsk9wKMKJNjrcVgfKSulx3PLvAIn8mZW9CIuxmEfn9LKsGyrJvwJLBk5DY= =d482 -----END PGP SIGNATURE----- From rt at openssl.org Wed Jan 14 16:59:39 2015 From: rt at openssl.org (r03@mdjnet.dk via RT) Date: Wed, 14 Jan 2015 17:59:39 +0100 Subject: [openssl-dev] [openssl.org #3654] 1.0.1k not compiling In-Reply-To: <54B291D0.1070506@mdjnet.dk> References: <54B291D0.1070506@mdjnet.dk> Message-ID: Hi - I have never reported bugs here before, so I hope I am doing it right. I have downloaded 1.0.1k, and I am trying to build it on Windows (for W32) using the build script I usually use, but compilation fails in crypto\cversion.c line 80, "cflags" is unknown. Comparing the entire cversion.c with the previous version makes it clear that the line should have read CFLAGS (uppercase) instead. Making that change makes it compile, and the resulting dll's (which I use in my Apache/mod_ssl among other things) appear to be working just fine. I hope my little analysis is correct, and that I can indeed trust the resulting build. Regards, -- Morten Due J?rgensen http://www.mdjnet.dk From rt at openssl.org Wed Jan 14 17:00:25 2015 From: rt at openssl.org (Jonathan Larmour via RT) Date: Wed, 14 Jan 2015 18:00:25 +0100 Subject: [openssl-dev] [openssl.org #3655] Inconsistency in d2i_SSL_SESSION In-Reply-To: <54B591F3.6090808@eCosCentric.com> References: <54B591F3.6090808@eCosCentric.com> Message-ID: Hi, I sent this to openssl-dev before and was advised to file it under rt... The implementation of d2i_SSL_SESSION() (in ssl_asn1.c) doesn't seem correct to me. d2i_SSL_SESSION() decodes an ASN1 encoding of an SSL_SESSION object previously encoded by i2d_SSL_SESSION(). Various SSL_SESSION fields are optional, and tags are used to identify which fields are present... so far, so good. But in two cases when they are not present, d2i_SSL_SESSION() actually sets values which were not in the original. Specifically, if 'time' is not present (which means it was 0 when i2d_SSL_SESSION() looked at it) it is set to the current time(). And if 'timeout' was not present, it is set to 3. Surely d2i_SSL_SESSION() should return exactly the session data that was passed into i2d_SSL_SESSION()? This came to my attention because I am working on an embedded device, and OpenSSL is used before the device has had its real time clock set, which means time() is returning 0. This resulted in ssl3_send_newsession_ticket() getting different asn1 sizes for a session encoded with i2d_SSL_SESSION, and decoded with d2i_SSL_SESSION, resulting in an error being returned due to this check: if (slen > slen_full) /* shouldn't ever happen */ (because the decoded session now had a 'time' field the original did not have). While I know this won't affect big Linux/Unix/BSD users, it may affect other embedded device users. The inconsistency with the 'timeout' field could affect other people too though - why change it to 3? So I have attached a patch for your consideration to resolve the inconsistency. Thanks, Jifl -- ------["Si fractum non sit, noli id reficere"]------ Opinions==mine -------------- next part -------------- A non-text attachment was scrubbed... Name: asn1_d2i_session.patch Type: text/x-patch Size: 1050 bytes Desc: not available URL: From rt at openssl.org Wed Jan 14 17:01:05 2015 From: rt at openssl.org (Prabhat Chauhan via RT) Date: Wed, 14 Jan 2015 18:01:05 +0100 Subject: [openssl-dev] [openssl.org #3656] Regarding Elliptic Curve Cryptography Issue In-Reply-To: References: Message-ID: Dear Sir, When i try to compile and run my Bitcoin code in fedora 18. It give me error root at localhost bitcoin-0.10.0rc1]# bitcoind *Error: OpenSSL appears to lack support for elliptic curve cryptography. For more information, visithttps://en.bitcoin.it/wiki/OpenSSL_and_EC_Libraries Error: Initialization sanity check failed. Bitcoin Core is shutting down.* [root at localhost bitcoin-0.10.0rc1]# I am not able to understand why it is coming. So please tell me some solution to resolve this. Thanks & waiting for response. From rt at openssl.org Wed Jan 14 17:23:47 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 14 Jan 2015 18:23:47 +0100 Subject: [openssl-dev] [openssl.org #3656] Regarding Elliptic Curve Cryptography Issue In-Reply-To: References: Message-ID: It looks like your openssl libraries were built without elliptic curve. Did look at the instructions in the link? This is not an openssl issue. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Jan 14 17:25:45 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 14 Jan 2015 18:25:45 +0100 Subject: [openssl-dev] [openssl.org #474] [PATCH] Crypto Engine Support for Chrysalis-ITS In-Reply-To: <918C70B01822D411A87400B0D0204DFF018960D1@panda.chrysalis-its.com> References: <918C70B01822D411A87400B0D0204DFF018960D1@panda.chrysalis-its.com> Message-ID: company acquired, this ticket is ten years old, not going to happen. please re-open with updated patches if important. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From richard at levitte.org Wed Jan 14 18:35:58 2015 From: richard at levitte.org (Richard Levitte) Date: Wed, 14 Jan 2015 19:35:58 +0100 (CET) Subject: [openssl-dev] [PATCH] install issue on OpenVMS in 1.0.0 branch In-Reply-To: <001101d02fcd$f50a04a0$df1e0de0$@com> References: <001101d02fcd$f50a04a0$df1e0de0$@com> Message-ID: <20150114.193558.401546991621005056.richard@levitte.org> Thanks. I've applied the fix and made an extra test, it only needs reviewing and pushed. Cheers, Richard In message <001101d02fcd$f50a04a0$df1e0de0$@com> on Wed, 14 Jan 2015 08:44:41 +0100, "Zoltan Arpadffy" said: zoli> Hi, zoli> zoli> during installation of 1.0.0 branch on OpenVMS the following error appears. zoli> zoli> %COPY-E-OPENIN, error opening IA64$DKA0:[WORK.OPENSSL-100-STABLE-SNAP-20150109.CRYPTO.SRP]SRP.H; zoli> as input zoli> -RMS-E-DNF, directory not found zoli> -SYSTEM-W-NOSUCHFILE, no such file zoli> zoli> The solution is to apply the following patch. zoli> zoli> SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p [.crypto]install-crypto.com;1 [.crypto]install-crypto.com; zoli> 4 zoli> *** [.crypto]install-crypto.com;1 Wed Oct 15 11:00:38 2014 zoli> --- [.crypto]install-crypto.com;4 Mon Jan 12 11:24:39 2015 zoli> *************** $ sdirs := , - zoli> *** 81,87 **** zoli> buffer, bio, stack, lhash, rand, err, - zoli> evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - zoli> ui, krb5, - zoli> ! cms, pqueue, ts, jpake, srp, store, cmac zoli> $! zoli> $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h zoli> $ exheader_'archd' := opensslconf.h zoli> --- 81,87 ---- zoli> buffer, bio, stack, lhash, rand, err, - zoli> evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - zoli> ui, krb5, - zoli> ! cms, pqueue, ts, jpake, store zoli> $! zoli> $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h zoli> $ exheader_'archd' := opensslconf.h zoli> *************** $ exheader_cms := cms.h zoli> *** 139,147 **** zoli> $ exheader_pqueue := pqueue.h zoli> $ exheader_ts := ts.h zoli> $ exheader_jpake := jpake.h zoli> - $ exheader_srp := srp.h zoli> $ exheader_store := store.h zoli> - $ exheader_cmac := cmac.h zoli> $ libs := ssl_libcrypto zoli> $! zoli> $ exe_dir := [-.'archd'.exe.crypto] zoli> --- 139,145 ---- zoli> zoli> Thank you. zoli> zoli> Regards, zoli> Z From richard at levitte.org Wed Jan 14 20:04:42 2015 From: richard at levitte.org (Richard Levitte) Date: Wed, 14 Jan 2015 21:04:42 +0100 (CET) Subject: [openssl-dev] [PATCH] install issue on OpenVMS in 1.0.0 branch In-Reply-To: <20150114.193558.401546991621005056.richard@levitte.org> References: <001101d02fcd$f50a04a0$df1e0de0$@com> <20150114.193558.401546991621005056.richard@levitte.org> Message-ID: <20150114.210442.668242019380617758.richard@levitte.org> Pushed! It's in commit 0c8dc6ebe5a969a57fb678b793d0dea651e33af7 I didn't remove the exheader_* variables. It's really of no practical consequence. Cheers, Richard In message <20150114.193558.401546991621005056.richard at levitte.org> on Wed, 14 Jan 2015 19:35:58 +0100 (CET), Richard Levitte said: richard> Thanks. I've applied the fix and made an extra test, it only needs richard> reviewing and pushed. richard> richard> Cheers, richard> Richard richard> richard> In message <001101d02fcd$f50a04a0$df1e0de0$@com> on Wed, 14 Jan 2015 08:44:41 +0100, "Zoltan Arpadffy" said: richard> richard> zoli> Hi, richard> zoli> richard> zoli> during installation of 1.0.0 branch on OpenVMS the following error appears. richard> zoli> richard> zoli> %COPY-E-OPENIN, error opening IA64$DKA0:[WORK.OPENSSL-100-STABLE-SNAP-20150109.CRYPTO.SRP]SRP.H; richard> zoli> as input richard> zoli> -RMS-E-DNF, directory not found richard> zoli> -SYSTEM-W-NOSUCHFILE, no such file richard> zoli> richard> zoli> The solution is to apply the following patch. richard> zoli> richard> zoli> SYSTEM at ia64$ mc DKA0:[UTIL]gdiff.exe -p [.crypto]install-crypto.com;1 [.crypto]install-crypto.com; richard> zoli> 4 richard> zoli> *** [.crypto]install-crypto.com;1 Wed Oct 15 11:00:38 2014 richard> zoli> --- [.crypto]install-crypto.com;4 Mon Jan 12 11:24:39 2015 richard> zoli> *************** $ sdirs := , - richard> zoli> *** 81,87 **** richard> zoli> buffer, bio, stack, lhash, rand, err, - richard> zoli> evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - richard> zoli> ui, krb5, - richard> zoli> ! cms, pqueue, ts, jpake, srp, store, cmac richard> zoli> $! richard> zoli> $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h richard> zoli> $ exheader_'archd' := opensslconf.h richard> zoli> --- 81,87 ---- richard> zoli> buffer, bio, stack, lhash, rand, err, - richard> zoli> evp, asn1, pem, x509, x509v3, conf, txt_db, pkcs7, pkcs12, comp, ocsp, - richard> zoli> ui, krb5, - richard> zoli> ! cms, pqueue, ts, jpake, store richard> zoli> $! richard> zoli> $ exheader_ := crypto.h, opensslv.h, ebcdic.h, symhacks.h, ossl_typ.h richard> zoli> $ exheader_'archd' := opensslconf.h richard> zoli> *************** $ exheader_cms := cms.h richard> zoli> *** 139,147 **** richard> zoli> $ exheader_pqueue := pqueue.h richard> zoli> $ exheader_ts := ts.h richard> zoli> $ exheader_jpake := jpake.h richard> zoli> - $ exheader_srp := srp.h richard> zoli> $ exheader_store := store.h richard> zoli> - $ exheader_cmac := cmac.h richard> zoli> $ libs := ssl_libcrypto richard> zoli> $! richard> zoli> $ exe_dir := [-.'archd'.exe.crypto] richard> zoli> --- 139,145 ---- richard> zoli> richard> zoli> Thank you. richard> zoli> richard> zoli> Regards, richard> zoli> Z From shiretu at gmail.com Wed Jan 14 20:08:17 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 22:08:17 +0200 Subject: [openssl-dev] Bug report: OpenSSL 1.0.1k DTLS handshake no longer works Message-ID: <017247FC-5255-4B11-A217-D0934C258621@gmail.com> Hi all, I believe I have found a bug which is only present in the latest versions (1.0.1k). I ran this test on a linux 64 ubuntu 14.10 and mac os x yosemite I have created a simple C test which does the following things in this order: 1. initialize the SSL library 2. creates an X509 key and cert 3. creates an DTLS server SSL context 4. Setup 2 memory BIO instances on the SSL context 5. Feed the input BIO with a hardcoded "Client Hello" packet 6. Call SSL_accept Wanted: The output BIO should contain a packet ("Server Hello") to be sent over the wire Observed: The output BIO is empty, the handshake never succeeds Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. I have attached the C file. Best regards, Andrei -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls_bug.c Type: application/octet-stream Size: 6377 bytes Desc: not available URL: -------------- next part -------------- From shiretu at gmail.com Wed Jan 14 20:10:49 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 22:10:49 +0200 Subject: [openssl-dev] Bug report: OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <017247FC-5255-4B11-A217-D0934C258621@gmail.com> References: <017247FC-5255-4B11-A217-D0934C258621@gmail.com> Message-ID: <21DBEEA3-6828-4D22-8CD3-D86183329205@gmail.com> Sorry for the mistake. here is the attachment again -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dtls_bug.c.txt URL: -------------- next part -------------- > On Jan 14, 2015, at 22:08, Eugen-Andrei Gavriloaie wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k). I ran this test on a linux 64 ubuntu 14.10 and mac os x yosemite > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > From rt at openssl.org Wed Jan 14 20:21:47 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Wed, 14 Jan 2015 21:21:47 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Hi all, I believe I have found a bug which is only present in the latest versions (1.0.1k) I have created a simple C test which does the following things in this order: 1. initialize the SSL library 2. creates an X509 key and cert 3. creates an DTLS server SSL context 4. Setup 2 memory BIO instances on the SSL context 5. Feed the input BIO with a hardcoded "Client Hello" packet 6. Call SSL_accept Wanted: The output BIO should contain a packet ("Server Hello") to be sent over the wire Observed: The output BIO is empty, the handshake never succeeds Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. I have attached the C file. Best regards, Andrei -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls_bug.c Type: application/octet-stream Size: 6377 bytes Desc: not available URL: -------------- next part -------------- From rt at openssl.org Wed Jan 14 20:40:38 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 14 Jan 2015 21:40:38 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: On Wed Jan 14 21:21:46 2015, shiretu at gmail.com wrote: > Hi all, > > I believe I have found a bug which is only present in the latest > versions (1.0.1k) > > I have created a simple C test which does the following things in this > order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent > over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the > output is generated. > Not sure what I'm supposed to be seeing here? I get the same result with both 1.01j and 1.0.1k...no errors reported. What platform are you on? Matt From shiretu at gmail.com Wed Jan 14 20:54:57 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 22:54:57 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Hi Matt, Here are more explanations: On my Mac OS X Yosemite, the OS provided OpenSSL version $ openssl version OpenSSL 1.0.1j 15 Oct 2014 Compiling the test $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto -o /tmp/dtls_bug Running the test $ /tmp/dtls_bug $ As we can see, everything looks good, nothing happens, the app exist with 0 error code On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug Running: $ /tmp/dtls_bug Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. Abort trap: 6 As we can see, it fails that that line where I expect the output buffer to be populated with an answer and is not happening. The pSSLBuffer->length != 0 fails Same behavior can be seen on Ubuntu 14.10 64 bit Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jan 14 20:55:17 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Wed, 14 Jan 2015 21:55:17 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Message-ID: Hi Matt, Here are more explanations: On my Mac OS X Yosemite, the OS provided OpenSSL version $ openssl version OpenSSL 1.0.1j 15 Oct 2014 Compiling the test $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto -o /tmp/dtls_bug Running the test $ /tmp/dtls_bug $ As we can see, everything looks good, nothing happens, the app exist with 0 error code On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug Running: $ /tmp/dtls_bug Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. Abort trap: 6 As we can see, it fails that that line where I expect the output buffer to be populated with an answer and is not happening. The pSSLBuffer->length != 0 fails Same behavior can be seen on Ubuntu 14.10 64 bit Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From shiretu at gmail.com Wed Jan 14 20:56:33 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 22:56:33 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Message-ID: Forgot to add the 1.0.1k version info: $ /tmp/ssl/bin/openssl version OpenSSL 1.0.1k 8 Jan 2015 > On Jan 14, 2015, at 22:54, Eugen-Andrei Gavriloaie wrote: > > Hi Matt, > > Here are more explanations: > > On my Mac OS X Yosemite, the OS provided OpenSSL version > $ openssl version > OpenSSL 1.0.1j 15 Oct 2014 > > Compiling the test > $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto -o /tmp/dtls_bug > > Running the test > $ /tmp/dtls_bug > $ > > As we can see, everything looks good, nothing happens, the app exist with 0 error code > > On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: > $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug > > Running: > $ /tmp/dtls_bug > Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. > Abort trap: 6 > > As we can see, it fails that that line where I expect the output buffer to be populated with an answer and is not happening. The pSSLBuffer->length != 0 fails > > Same behavior can be seen on Ubuntu 14.10 64 bit > > Best regards, > Andrei > > >> On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: >> >> Hi all, >> >> I believe I have found a bug which is only present in the latest versions (1.0.1k) >> >> I have created a simple C test which does the following things in this order: >> >> 1. initialize the SSL library >> 2. creates an X509 key and cert >> 3. creates an DTLS server SSL context >> 4. Setup 2 memory BIO instances on the SSL context >> 5. Feed the input BIO with a hardcoded "Client Hello" packet >> 6. Call SSL_accept >> >> Wanted: >> The output BIO should contain a packet ("Server Hello") to be sent over the wire >> >> Observed: >> The output BIO is empty, the handshake never succeeds >> >> Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. >> >> I have attached the C file. >> >> Best regards, >> Andrei >> >> >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Wed Jan 14 20:57:05 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Wed, 14 Jan 2015 21:57:05 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Message-ID: Forgot to add the 1.0.1k version info: $ /tmp/ssl/bin/openssl version OpenSSL 1.0.1k 8 Jan 2015 > On Jan 14, 2015, at 22:54, Eugen-Andrei Gavriloaie wrote: > > Hi Matt, > > Here are more explanations: > > On my Mac OS X Yosemite, the OS provided OpenSSL version > $ openssl version > OpenSSL 1.0.1j 15 Oct 2014 > > Compiling the test > $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl -lcrypto -o /tmp/dtls_bug > > Running the test > $ /tmp/dtls_bug > $ > > As we can see, everything looks good, nothing happens, the app exist with 0 error code > > On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: > $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug > > Running: > $ /tmp/dtls_bug > Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. > Abort trap: 6 > > As we can see, it fails that that line where I expect the output buffer to be populated with an answer and is not happening. The pSSLBuffer->length != 0 fails > > Same behavior can be seen on Ubuntu 14.10 64 bit > > Best regards, > Andrei > > >> On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: >> >> Hi all, >> >> I believe I have found a bug which is only present in the latest versions (1.0.1k) >> >> I have created a simple C test which does the following things in this order: >> >> 1. initialize the SSL library >> 2. creates an X509 key and cert >> 3. creates an DTLS server SSL context >> 4. Setup 2 memory BIO instances on the SSL context >> 5. Feed the input BIO with a hardcoded "Client Hello" packet >> 6. Call SSL_accept >> >> Wanted: >> The output BIO should contain a packet ("Server Hello") to be sent over the wire >> >> Observed: >> The output BIO is empty, the handshake never succeeds >> >> Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. >> >> I have attached the C file. >> >> Best regards, >> Andrei >> >> >> >> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From shiretu at gmail.com Wed Jan 14 21:03:11 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 23:03:11 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: <1B20BED0-22F2-4B24-8005-F1F5575BEC21@gmail.com> And from an Ubuntu box (apparently, it runs 1.0.1f) shiretu at ubuntu:/tmp$ gcc -std=c99 dtls_bug.c -lssl -lcrypto -o dtls_bug shiretu at ubuntu:/tmp$ ./dtls_bug dtls_bug: dtls_bug.c:110: main: Assertion `pSSLBuffer->length != 0' failed. Aborted (core dumped) shiretu at ubuntu:/tmp$ uname -a Linux ubuntu 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux shiretu at ubuntu:/tmp$ openssl version OpenSSL 1.0.1f 6 Jan 2014 shiretu at ubuntu:/tmp$ ldd dtls_bug linux-vdso.so.1 => (0x00007fff0fbe7000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fec11f22000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fec11b3f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec11779000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec11575000) /lib64/ld-linux-x86-64.so.2 (0x00007fec12189000) > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jan 14 21:03:41 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Wed, 14 Jan 2015 22:03:41 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <1B20BED0-22F2-4B24-8005-F1F5575BEC21@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <1B20BED0-22F2-4B24-8005-F1F5575BEC21@gmail.com> Message-ID: And from an Ubuntu box (apparently, it runs 1.0.1f) shiretu at ubuntu:/tmp$ gcc -std=c99 dtls_bug.c -lssl -lcrypto -o dtls_bug shiretu at ubuntu:/tmp$ ./dtls_bug dtls_bug: dtls_bug.c:110: main: Assertion `pSSLBuffer->length != 0' failed. Aborted (core dumped) shiretu at ubuntu:/tmp$ uname -a Linux ubuntu 3.16.0-23-generic #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux shiretu at ubuntu:/tmp$ openssl version OpenSSL 1.0.1f 6 Jan 2014 shiretu at ubuntu:/tmp$ ldd dtls_bug linux-vdso.so.1 => (0x00007fff0fbe7000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fec11f22000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fec11b3f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec11779000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec11575000) /lib64/ld-linux-x86-64.so.2 (0x00007fec12189000) > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jan 14 21:05:26 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 14 Jan 2015 22:05:26 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Message-ID: On Wed Jan 14 21:55:17 2015, shiretu at gmail.com wrote: > Hi Matt, > > Here are more explanations: > > On my Mac OS X Yosemite, the OS provided OpenSSL version > $ openssl version > OpenSSL 1.0.1j 15 Oct 2014 > > Compiling the test > $ gcc ~/Dropbox/Public/dtls_bug.c -Wno-deprecated-declarations -lssl > -lcrypto -o /tmp/dtls_bug > > Running the test > $ /tmp/dtls_bug > $ > > As we can see, everything looks good, nothing happens, the app exist > with 0 error code > > On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and > installed it into /tmp/ssl as a static lib (with shared lib behaves > the same) Compiling: > $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a > /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug > > Running: > $ /tmp/dtls_bug > Assertion failed: (pSSLBuffer->length != 0), function main, file > /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. > Abort trap: 6 > > As we can see, it fails that that line where I expect the output > buffer to be populated with an answer and is not happening. The > pSSLBuffer->length != 0 fails > > Same behavior can be seen on Ubuntu 14.10 64 bit Does it work in s_client/s_server? i.e. Start an s_server (you'll need an appropriate cert/key): openssl s_server -dtls1 Start an s_client: openssl s_client -dtls1 They should complete a handshake successfully. Matt From openssl-users at dukhovni.org Wed Jan 14 21:00:32 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Jan 2015 21:00:32 +0000 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> Message-ID: <20150114210032.GB7322@mournblade.imrryr.org> On Wed, Jan 14, 2015 at 10:54:57PM +0200, Eugen-Andrei Gavriloaie wrote: > On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: > > $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug This picks up libraries from 1.0.1k and headers from some other release. Try with -I/tmp/ssl/include or similar making sure the right headers are used. You should not need "-Wno-deprecated-declarations", that should only be needed to silence consequences of including Apple's headers. -- Viktor. From shiretu at gmail.com Wed Jan 14 21:31:02 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 23:31:02 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <20150114210032.GB7322@mournblade.imrryr.org> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> <20150114210032.GB7322@mournblade.imrryr.org> Message-ID: <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> Dynamic: $ ls -Al /tmp/ssl/lib/ total 11336 drwxr-xr-x 14 shiretu wheel 476 Jan 14 23:27 engines -r-xr-xr-x 1 shiretu wheel 1602352 Jan 14 23:27 libcrypto.1.0.0.dylib -rw-r--r-- 1 shiretu wheel 3196880 Jan 14 23:27 libcrypto.a lrwxr-xr-x 1 shiretu wheel 21 Jan 14 23:27 libcrypto.dylib -> libcrypto.1.0.0.dylib -r-xr-xr-x 1 shiretu wheel 382440 Jan 14 23:27 libssl.1.0.0.dylib -rw-r--r-- 1 shiretu wheel 605504 Jan 14 23:27 libssl.a lrwxr-xr-x 1 shiretu wheel 18 Jan 14 23:27 libssl.dylib -> libssl.1.0.0.dylib drwxr-xr-x 5 shiretu wheel 170 Jan 14 23:27 pkgconfig $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl -lcrypto -o /tmp/dtls_bug $ otool -L /tmp/dtls_bug /tmp/dtls_bug: /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) $ /tmp/dtls_bug Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. Abort trap: 6 Static: $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug $ otool -L /tmp/dtls_bug /tmp/dtls_bug: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) $ /tmp/dtls_bug Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. Abort trap: 6 $ uname -a Darwin shiretu.local 14.1.0 Darwin Kernel Version 14.1.0: Sun Dec 28 21:20:58 PST 2014; root:xnu-2782.10.72~3/RELEASE_X86_64 x86_64 > On Jan 14, 2015, at 23:00, Viktor Dukhovni wrote: > > On Wed, Jan 14, 2015 at 10:54:57PM +0200, Eugen-Andrei Gavriloaie wrote: > >> On my Mac OS X Yosemite, manually compiled OpenSSL 1.0.1k and installed it into /tmp/ssl as a static lib (with shared lib behaves the same) Compiling: >> >> $ gcc dtls_bug.c -Wno-deprecated-declarations /tmp/ssl/lib/libssl.a /tmp/ssl/lib/libcrypto.a -o /tmp/dtls_bug > > This picks up libraries from 1.0.1k and headers from some other > release. Try with -I/tmp/ssl/include or similar making sure the > right headers are used. You should not need "-Wno-deprecated-declarations", > that should only be needed to silence consequences of including > Apple's headers. > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From openssl-users at dukhovni.org Wed Jan 14 21:39:10 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Jan 2015 21:39:10 +0000 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> <20150114210032.GB7322@mournblade.imrryr.org> <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> Message-ID: <20150114213910.GC7322@mournblade.imrryr.org> On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote: > Dynamic: > $ ls -Al /tmp/ssl/lib/ > total 11336 > drwxr-xr-x 14 shiretu wheel 476 Jan 14 23:27 engines > -r-xr-xr-x 1 shiretu wheel 1602352 Jan 14 23:27 libcrypto.1.0.0.dylib > -rw-r--r-- 1 shiretu wheel 3196880 Jan 14 23:27 libcrypto.a > lrwxr-xr-x 1 shiretu wheel 21 Jan 14 23:27 libcrypto.dylib -> libcrypto.1.0.0.dylib > -r-xr-xr-x 1 shiretu wheel 382440 Jan 14 23:27 libssl.1.0.0.dylib > -rw-r--r-- 1 shiretu wheel 605504 Jan 14 23:27 libssl.a > lrwxr-xr-x 1 shiretu wheel 18 Jan 14 23:27 libssl.dylib -> libssl.1.0.0.dylib > drwxr-xr-x 5 shiretu wheel 170 Jan 14 23:27 pkgconfig And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)? And "/tmp/ssl/bin/openssl version -a" output is what? > $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl -lcrypto -o /tmp/dtls_bug > > $ otool -L /tmp/dtls_bug > /tmp/dtls_bug: > /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) > $ /tmp/dtls_bug > Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. > Abort trap: 6 You should also update your code to report error return values from SSL_accept() and print the contents of error stack. -- Viktor. From shiretu at gmail.com Wed Jan 14 21:54:43 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Wed, 14 Jan 2015 23:54:43 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <20150114213910.GC7322@mournblade.imrryr.org> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> <20150114210032.GB7322@mournblade.imrryr.org> <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> <20150114213910.GC7322@mournblade.imrryr.org> Message-ID: <9205B292-14A2-4CA6-BA00-3A947D5569C0@gmail.com> > On Jan 14, 2015, at 23:39, Viktor Dukhovni wrote: > > On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote: > >> Dynamic: >> $ ls -Al /tmp/ssl/lib/ >> total 11336 >> drwxr-xr-x 14 shiretu wheel 476 Jan 14 23:27 engines >> -r-xr-xr-x 1 shiretu wheel 1602352 Jan 14 23:27 libcrypto.1.0.0.dylib >> -rw-r--r-- 1 shiretu wheel 3196880 Jan 14 23:27 libcrypto.a >> lrwxr-xr-x 1 shiretu wheel 21 Jan 14 23:27 libcrypto.dylib -> libcrypto.1.0.0.dylib >> -r-xr-xr-x 1 shiretu wheel 382440 Jan 14 23:27 libssl.1.0.0.dylib >> -rw-r--r-- 1 shiretu wheel 605504 Jan 14 23:27 libssl.a >> lrwxr-xr-x 1 shiretu wheel 18 Jan 14 23:27 libssl.dylib -> libssl.1.0.0.dylib >> drwxr-xr-x 5 shiretu wheel 170 Jan 14 23:27 pkgconfig > > And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)? $ ls -Al /tmp/ssl/include/ total 0 drwxr-xr-x 77 shiretu wheel 2618 Jan 14 23:27 openssl > And "/tmp/ssl/bin/openssl version -a" output is what? $ /tmp/ssl/bin/openssl version OpenSSL 1.0.1k 8 Jan 2015 > >> $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl -lcrypto -o /tmp/dtls_bug >> >> $ otool -L /tmp/dtls_bug >> /tmp/dtls_bug: >> /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) > >> $ /tmp/dtls_bug >> Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. >> Abort trap: 6 > > You should also update your code to report error return values from > SSL_accept() and print the contents of error stack. > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From shiretu at gmail.com Wed Jan 14 22:01:35 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 00:01:35 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <20150114213910.GC7322@mournblade.imrryr.org> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> <20150114210032.GB7322@mournblade.imrryr.org> <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> <20150114213910.GC7322@mournblade.imrryr.org> Message-ID: <4A719E9F-E89D-4153-AA8B-BE7236C3F757@gmail.com> > On Jan 14, 2015, at 23:39, Viktor Dukhovni wrote: > > On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote: > >> Dynamic: >> $ ls -Al /tmp/ssl/lib/ >> total 11336 >> drwxr-xr-x 14 shiretu wheel 476 Jan 14 23:27 engines >> -r-xr-xr-x 1 shiretu wheel 1602352 Jan 14 23:27 libcrypto.1.0.0.dylib >> -rw-r--r-- 1 shiretu wheel 3196880 Jan 14 23:27 libcrypto.a >> lrwxr-xr-x 1 shiretu wheel 21 Jan 14 23:27 libcrypto.dylib -> libcrypto.1.0.0.dylib >> -r-xr-xr-x 1 shiretu wheel 382440 Jan 14 23:27 libssl.1.0.0.dylib >> -rw-r--r-- 1 shiretu wheel 605504 Jan 14 23:27 libssl.a >> lrwxr-xr-x 1 shiretu wheel 18 Jan 14 23:27 libssl.dylib -> libssl.1.0.0.dylib >> drwxr-xr-x 5 shiretu wheel 170 Jan 14 23:27 pkgconfig > > And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)? > And "/tmp/ssl/bin/openssl version -a" output is what? > >> $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl -lcrypto -o /tmp/dtls_bug >> >> $ otool -L /tmp/dtls_bug >> /tmp/dtls_bug: >> /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) > >> $ /tmp/dtls_bug >> Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. >> Abort trap: 6 > > You should also update your code to report error return values from > SSL_accept() and print the contents of error stack. $ /tmp/dtls_bug ret: -1 sslErrorCode: 2 Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 114. Abort trap: 6 errorCode 2 means SSL_ERROR_WANT_READ, which is consistent with the rejection of the input packet. And the updated source: https://dl.dropboxusercontent.com/u/2918563/dtls_bug.c > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From shiretu at gmail.com Wed Jan 14 22:10:26 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 00:10:26 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <4A719E9F-E89D-4153-AA8B-BE7236C3F757@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6877D500-7720-4AA2-80EB-B28DAFA8DFAC@gmail.com> <20150114210032.GB7322@mournblade.imrryr.org> <8B8ECC34-27DB-4182-86AD-EEF89DB1BEE3@gmail.com> <20150114213910.GC7322@mournblade.imrryr.org> <4A719E9F-E89D-4153-AA8B-BE7236C3F757@gmail.com> Message-ID: Looks like dtls1_get_record is always returning -1 Still digging... > On Jan 15, 2015, at 00:01, Eugen-Andrei Gavriloaie wrote: > > >> On Jan 14, 2015, at 23:39, Viktor Dukhovni wrote: >> >> On Wed, Jan 14, 2015 at 11:31:02PM +0200, Eugen-Andrei Gavriloaie wrote: >> >>> Dynamic: >>> $ ls -Al /tmp/ssl/lib/ >>> total 11336 >>> drwxr-xr-x 14 shiretu wheel 476 Jan 14 23:27 engines >>> -r-xr-xr-x 1 shiretu wheel 1602352 Jan 14 23:27 libcrypto.1.0.0.dylib >>> -rw-r--r-- 1 shiretu wheel 3196880 Jan 14 23:27 libcrypto.a >>> lrwxr-xr-x 1 shiretu wheel 21 Jan 14 23:27 libcrypto.dylib -> libcrypto.1.0.0.dylib >>> -r-xr-xr-x 1 shiretu wheel 382440 Jan 14 23:27 libssl.1.0.0.dylib >>> -rw-r--r-- 1 shiretu wheel 605504 Jan 14 23:27 libssl.a >>> lrwxr-xr-x 1 shiretu wheel 18 Jan 14 23:27 libssl.dylib -> libssl.1.0.0.dylib >>> drwxr-xr-x 5 shiretu wheel 170 Jan 14 23:27 pkgconfig >> >> And you have the 1.0.1k include files (/tmp/ssl/include/openssl/*.h)? >> And "/tmp/ssl/bin/openssl version -a" output is what? >> >>> $ gcc ~/Dropbox/Public/dtls_bug.c -I/tmp/ssl/include -L/tmp/ssl/lib -lssl -lcrypto -o /tmp/dtls_bug >>> >>> $ otool -L /tmp/dtls_bug >>> /tmp/dtls_bug: >>> /tmp/ssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >>> /tmp/ssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) >> >>> $ /tmp/dtls_bug >>> Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 110. >>> Abort trap: 6 >> >> You should also update your code to report error return values from >> SSL_accept() and print the contents of error stack. > $ /tmp/dtls_bug > ret: -1 > sslErrorCode: 2 > Assertion failed: (pSSLBuffer->length != 0), function main, file /Users/shiretu/Dropbox/Public/dtls_bug.c, line 114. > Abort trap: 6 > > errorCode 2 means SSL_ERROR_WANT_READ, which is consistent with the rejection of the input packet. > > And the updated source: > https://dl.dropboxusercontent.com/u/2918563/dtls_bug.c > >> >> -- >> Viktor. >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From shiretu at gmail.com Wed Jan 14 22:29:30 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 00:29:30 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: <4501F25A-5287-4797-BC55-7BC005D9F93A@gmail.com> The openssl s_server/s_client -dtls1 works I now suspect a special edge case of dtls1_get_record function. That buffer I'm feeding into OpenSSL is taken from Chrome WebRTC DTLS handshake, and as we saw, is perfectly valid in older OpenSSL versions. Still digging... > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed Jan 14 22:29:53 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Wed, 14 Jan 2015 23:29:53 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <4501F25A-5287-4797-BC55-7BC005D9F93A@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <4501F25A-5287-4797-BC55-7BC005D9F93A@gmail.com> Message-ID: The openssl s_server/s_client -dtls1 works I now suspect a special edge case of dtls1_get_record function. That buffer I'm feeding into OpenSSL is taken from Chrome WebRTC DTLS handshake, and as we saw, is perfectly valid in older OpenSSL versions. Still digging... > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 15 09:24:16 2015 From: rt at openssl.org (Praveen Kariyanahalli via RT) Date: Thu, 15 Jan 2015 10:24:16 +0100 Subject: [openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message In-Reply-To: References: Message-ID: Seeing the memory leak (process DTLS server) in the latest released 1.01k version on the server side. Any clue as to how to get this fixed? Regards -Praveen Kariyanahalli ==1162== 36,480 (1,920 direct, 34,560 indirect) bytes in 30 blocks are definitely lost in loss record 119 of 130 ==1162== at 0x4A08219: calloc (vg_replace_malloc.c:623) ==1162== by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170) ==1162== by 0x5BFDC86: default_malloc_ex (mem.c:79) ==1162== by 0x5BFE33D: CRYPTO_malloc (mem.c:312) ==1162== by 0x5D24C9D: pitem_new (pqueue.c:73) ==1162== by 0x595A31F: dtls1_buffer_message (d1_both.c:1267) ==1162== by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629) ==1162== by 0x594E439: dtls1_accept (d1_srvr.c:430) ==1162== by 0x595D8A4: SSL_accept (ssl_lib.c:934) ==1162== by 0x5954BBF: dtls1_listen (d1_lib.c:515) ==1162== by 0x59544DA: dtls1_ctrl (d1_lib.c:271) ==1162== by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087) ==1162== by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887) ==1162== by 0x54C2162: event_persist_closure (event.c:1301) ==1162== by 0x54C2271: event_process_active_single_queue (event.c:1345) ==1162== by 0x54C2540: event_process_active (event.c:1420) ==1162== by 0x54C2BA7: event_base_loop (event.c:1621) ==1162== by 0x41C0B6: vbond_main (vdaemon.c:5428) ==1162== by 0x41E096: main (vdaemon.c:6017) ==1162== ==1162== LEAK SUMMARY: ==1162== definitely lost: 4,032 bytes in 68 blocks ==1162== by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170) ==1162== by 0x5BFDC86: default_malloc_ex (mem.c:79) ==1162== by 0x5BFE33D: CRYPTO_malloc (mem.c:312) ==1162== by 0x5D24C9D: pitem_new (pqueue.c:73) ==1162== by 0x595A31F: dtls1_buffer_message (d1_both.c:1267) ==1162== by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629) ==1162== by 0x594E439: dtls1_accept (d1_srvr.c:430) ==1162== by 0x595D8A4: SSL_accept (ssl_lib.c:934) ==1162== by 0x5954BBF: dtls1_listen (d1_lib.c:515) ==1162== by 0x59544DA: dtls1_ctrl (d1_lib.c:271) ==1162== by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087) ==1162== by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887) ==1162== by 0x54C2162: event_persist_closure (event.c:1301) ==1162== by 0x54C2271: event_process_active_single_queue (event.c:1345) ==1162== by 0x54C2540: event_process_active (event.c:1420) ==1162== by 0x54C2BA7: event_base_loop (event.c:1621) ==1162== by 0x41C0B6: vbond_main (vdaemon.c:5428) ==1162== by 0x41E096: main (vdaemon.c:6017) ==1162== ==1162== LEAK SUMMARY: ==1162== definitely lost: 4,032 bytes in 68 blocks ==1162== indirectly lost: 41,024 bytes in 128 blocks ==1162== possibly lost: 9,160 bytes in 109 blocks ==1162== still reachable: 1,296,276 bytes in 21,109 blocks ==1162== suppressed: 0 bytes in 0 blocks ==1162== Reachable blocks (those to which a pointer was found) are not shown. ==1162== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==1162== ==1162== For counts of detected and suppressed errors, rerun with: -v ==1162== ERROR SUMMARY: 46 errors from 46 contexts (suppressed: 1 from 1) From rt at openssl.org Thu Jan 15 09:24:28 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 15 Jan 2015 10:24:28 +0100 Subject: [openssl-dev] [openssl.org #3659] BUG: EVP_DigestVerifyFinal does not take a const pointer In-Reply-To: References: Message-ID: According to https://www.openssl.org/docs/crypto/EVP_DigestVerifyInit.html, EVP_DigestVerifyFinal does not take a const pointer. The signature already exists, and it was passed into the function as a 'const unsigned char*'. This creates a compile problem in practice: t-hmac.c:212:41: warning: passing 'const byte *' (aka 'const unsigned char *') to parameter of type 'unsigned char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] rc = EVP_DigestVerifyFinal(ctx, sig, slen); ^~~ /usr/local/ssl/include/openssl/evp.h:623:19: note: passing argument to parameter 'sig' here unsigned char *sig, size_t siglen); From rt at openssl.org Thu Jan 15 09:25:22 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Jan 2015 10:25:22 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Please could you try making the following call: SSL_CTX_set_read_ahead(ctx, 1); Insert it immediately after these lines in your test code: pSslContext = SSL_CTX_new(DTLSv1_server_method()); assert(pSslContext != NULL); assert(SSL_CTX_use_certificate(pSslContext, pX509) == 1); assert(SSL_CTX_use_PrivateKey(pSslContext, pX509Key) == 1); assert(SSL_CTX_check_private_key(pSslContext) == 1); Thanks Matt From rt at openssl.org Thu Jan 15 09:38:59 2015 From: rt at openssl.org (Huzaifa Sidhpurwala via RT) Date: Thu, 15 Jan 2015 10:38:59 +0100 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: Hi, I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 bytes for each connection request. Patch is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: application/octet-stream Size: 1073 bytes Desc: not available URL: From rt at openssl.org Thu Jan 15 10:24:11 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Jan 2015 11:24:11 +0100 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: On Thu Jan 15 10:38:58 2015, sidhpurwala.huzaifa at gmail.com wrote: > Hi, > > I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 > bytes for each connection request. > > Patch is attached. I'm not seeing this memory leak. The kctx object should be being freed in the call to SSL_free - and in my tests it was being. How are you testing this, and how have you determined that there was a leak? Thanks Matt From rt at openssl.org Thu Jan 15 12:38:25 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 15 Jan 2015 13:38:25 +0100 Subject: [openssl-dev] [openssl.org #3656] Regarding Elliptic Curve Cryptography Issue In-Reply-To: <10315296.eNV54DRl7R@pintsize.usersys.redhat.com> References: <10315296.eNV54DRl7R@pintsize.usersys.redhat.com> Message-ID: On Wednesday 14 January 2015 18:01:05 Prabhat Chauhan via RT wrote: > Dear Sir, > > When i try to compile and run my Bitcoin code in fedora 18. It give me error > > root at localhost bitcoin-0.10.0rc1]# bitcoind > > *Error: OpenSSL appears to lack support for elliptic curve cryptography. > For more information, > visithttps://en.bitcoin.it/wiki/OpenSSL_and_EC_Libraries > Error: Initialization > sanity check failed. Bitcoin Core is shutting down.* > [root at localhost bitcoin-0.10.0rc1]# > > I am not able to understand why it is coming. So please tell me some > solution to resolve this. This is expected, see: https://bugzilla.redhat.com/show_bug.cgi?id=1019390 https://bugzilla.redhat.com/show_bug.cgi?id=1021898 Fedora up till 20 didn't support any ECC. Unfortunately because of the second bug, you won't be able to compile Bitcoin software on Fedora. I don't know when or if support for secp256k1 will be added. Also, Fedora 18, as well as Fedora 19, are not supported any more and don't receive any security fixes, please upgrade. -- Regards, Hubert Kario From sidhpurwala.huzaifa at gmail.com Thu Jan 15 13:24:59 2015 From: sidhpurwala.huzaifa at gmail.com (Huzaifa Sidhpurwala) Date: Thu, 15 Jan 2015 18:54:59 +0530 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: Here is how to test it: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \ /CN=localhost -nodes -batch -sha256 valgrind --leak-check=full openssl s_server -key localhost.key -cert \ localhost.crt -accept 4433 ./poc.py Every run of poc.py causes 56 byte memory leak: ==11278== HEAP SUMMARY: ==11278== in use at exit: 910,716 bytes in 20,383 blocks ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes allocated ==11278== ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823 ==11278== at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) ==11278== by 0x5A6AD12: CRYPTO_malloc (mem.c:308) ==11278== by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) ==11278== by 0x4E759E9: SSL_new (ssl_lib.c:295) ==11278== by 0x436387: sv_body (s_server.c:2004) ==11278== by 0x44AC30: do_server (s_socket.c:324) ==11278== by 0x439C36: s_server_main (s_server.c:1901) ==11278== by 0x419377: do_cmd (openssl.c:489) ==11278== by 0x41906D: main (openssl.c:381) ==11278== ==11278== LEAK SUMMARY: ==11278== definitely lost: 56 bytes in 1 blocks ==11278== indirectly lost: 0 bytes in 0 blocks ==11278== possibly lost: 0 bytes in 0 blocks ==11278== still reachable: 910,660 bytes in 20,382 blocks ==11278== suppressed: 0 bytes in 0 blocks ==11278== Reachable blocks (those to which a pointer was found) are not shown. ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==11278== ==11278== For counts of detected and suppressed errors, rerun with: -v ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) """ Acknowledgement Text Required: Yes Community Trackers Required : Yes Ticket Response Required : Yes poc.py is attached On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT wrote: > Hi, > > I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 > bytes for each connection request. > > Patch is attached. > > > _______________________________________________ > 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: poc.py Type: text/x-python Size: 469 bytes Desc: not available URL: From rt at openssl.org Thu Jan 15 13:25:54 2015 From: rt at openssl.org (Huzaifa Sidhpurwala via RT) Date: Thu, 15 Jan 2015 14:25:54 +0100 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: Here is how to test it: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \ /CN=localhost -nodes -batch -sha256 valgrind --leak-check=full openssl s_server -key localhost.key -cert \ localhost.crt -accept 4433 ./poc.py Every run of poc.py causes 56 byte memory leak: ==11278== HEAP SUMMARY: ==11278== in use at exit: 910,716 bytes in 20,383 blocks ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes allocated ==11278== ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823 ==11278== at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck- amd64-linux.so) ==11278== by 0x5A6AD12: CRYPTO_malloc (mem.c:308) ==11278== by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) ==11278== by 0x4E759E9: SSL_new (ssl_lib.c:295) ==11278== by 0x436387: sv_body (s_server.c:2004) ==11278== by 0x44AC30: do_server (s_socket.c:324) ==11278== by 0x439C36: s_server_main (s_server.c:1901) ==11278== by 0x419377: do_cmd (openssl.c:489) ==11278== by 0x41906D: main (openssl.c:381) ==11278== ==11278== LEAK SUMMARY: ==11278== definitely lost: 56 bytes in 1 blocks ==11278== indirectly lost: 0 bytes in 0 blocks ==11278== possibly lost: 0 bytes in 0 blocks ==11278== still reachable: 910,660 bytes in 20,382 blocks ==11278== suppressed: 0 bytes in 0 blocks ==11278== Reachable blocks (those to which a pointer was found) are not shown. ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==11278== ==11278== For counts of detected and suppressed errors, rerun with: -v ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) """ Acknowledgement Text Required: Yes Community Trackers Required : Yes Ticket Response Required : Yes poc.py is attached On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT wrote: > Hi, > > I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 > bytes for each connection request. > > Patch is attached. > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: poc.py Type: text/x-python Size: 469 bytes Desc: not available URL: From rt at openssl.org Thu Jan 15 13:54:06 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Jan 2015 14:54:06 +0100 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: On Thu Jan 15 14:25:54 2015, sidhpurwala.huzaifa at gmail.com wrote: > Here is how to test it: > > openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt > -subj \ > /CN=localhost -nodes -batch -sha256 > > valgrind --leak-check=full openssl s_server -key localhost.key -cert \ > localhost.crt -accept 4433 > > ./poc.py > > Every run of poc.py causes 56 byte memory leak: > > ==11278== HEAP SUMMARY: > ==11278== in use at exit: 910,716 bytes in 20,383 blocks > ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 > bytes > allocated > ==11278== > ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 > of 823 What version of OpenSSL/platform are you running? Is this with vanilla OpenSSL source, or with OS pre-installed binaries? I'm not seeing this. I've tried on 1.0.1 and 1.0.0. Matt From fedor at indutny.com Thu Jan 15 14:13:49 2015 From: fedor at indutny.com (Fedor Indutny) Date: Thu, 15 Jan 2015 18:13:49 +0400 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 Message-ID: Hello! During the course of deprecation of stale 1024bit CA certs, node.js and io.js project teams have identified the problem with how OpenSSL client handles the server's certificate chain. It is quite evident that it ignores certificate store and loads issuer from the chain that was received. This leads to the problems with AWS and probably other service providers who sent the stale **alternative** certificate chain with same serial numbers, but 1024bit CA certificates. I have already tried proposing a solution to the OpenSSL team: https://www.mail-archive.com/openssl-dev at openssl.org/msg37721.html But one of the node.js contributors we have found this commit (from 2010): https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3 The main question that I have is: Is it safe to float this patch on top of 1.0.1k and use it? From my knowledge of code it appears to be pretty harmless, however the fact that it wasn't backported in 5 years makes me wonder if it was considered safe after all. Thank you, Fedor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 15 14:21:06 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Jan 2015 14:21:06 +0000 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 In-Reply-To: References: Message-ID: <54B7CCD2.108@openssl.org> On 15/01/15 14:13, Fedor Indutny wrote: > Hello! > > During the course of deprecation of stale 1024bit CA certs, > node.js and io.js project teams have identified the problem with > how OpenSSL client handles the server's certificate chain. It is > quite evident that it ignores certificate store and loads issuer > from the chain that was received. This leads to the problems with > AWS and probably other service providers who sent the stale > **alternative** certificate chain with same serial numbers, but > 1024bit CA certificates. > > I have already tried proposing a solution to the OpenSSL team: > > https://www.mail-archive.com/openssl-dev at openssl.org/msg37721.html > > But one of the node.js contributors we have found this commit (from 2010): > > https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3 > > The main question that I have is: > > Is it safe to float this patch on top of 1.0.1k and use it? From > my knowledge of code it appears to be pretty harmless, however > the fact that it wasn't backported in 5 years makes me wonder if > it was considered safe after all. There are some concerns about the performance of trusted_first. Successful certificate look ups are cached, whilst failed ones are not. Therefore using trusted_first *could* have an adverse impact. This issue is currently under discussion within the dev team. I have an alternative patch that addresses the same issue in a different way. Essentially it works in a similar way to that which you proposed in RT3637. However I have some issues with that patch, so I've done it slightly differently. RT3621 is also relevant here. Matt From matt at openssl.org Thu Jan 15 14:22:51 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 15 Jan 2015 14:22:51 +0000 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 In-Reply-To: <54B7CCD2.108@openssl.org> References: <54B7CCD2.108@openssl.org> Message-ID: <54B7CD3B.8040706@openssl.org> On 15/01/15 14:21, Matt Caswell wrote: > > > On 15/01/15 14:13, Fedor Indutny wrote: >> Hello! >> >> During the course of deprecation of stale 1024bit CA certs, >> node.js and io.js project teams have identified the problem with >> how OpenSSL client handles the server's certificate chain. It is >> quite evident that it ignores certificate store and loads issuer >> from the chain that was received. This leads to the problems with >> AWS and probably other service providers who sent the stale >> **alternative** certificate chain with same serial numbers, but >> 1024bit CA certificates. >> >> I have already tried proposing a solution to the OpenSSL team: >> >> https://www.mail-archive.com/openssl-dev at openssl.org/msg37721.html >> >> But one of the node.js contributors we have found this commit (from 2010): >> >> https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3 >> >> The main question that I have is: >> >> Is it safe to float this patch on top of 1.0.1k and use it? From >> my knowledge of code it appears to be pretty harmless, however >> the fact that it wasn't backported in 5 years makes me wonder if >> it was considered safe after all. > > There are some concerns about the performance of trusted_first. > Successful certificate look ups are cached, whilst failed ones are not. > Therefore using trusted_first *could* have an adverse impact. > > This issue is currently under discussion within the dev team. I have an > alternative patch that addresses the same issue in a different way. > Essentially it works in a similar way to that which you proposed in > RT3637. However I have some issues with that patch, so I've done it > slightly differently. > > RT3621 is also relevant here. I should add that in any case this functionality would never be backported to 1.0.1 (only considered for future versions). 1.0.1 is a stable release and only sees bug fixes. This would be considered a feature and a significant change to the way certificates are verified. Matt From sidhpurwala.huzaifa at gmail.com Thu Jan 15 14:34:25 2015 From: sidhpurwala.huzaifa at gmail.com (Huzaifa Sidhpurwala) Date: Thu, 15 Jan 2015 20:04:25 +0530 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here is a brief analysis: Consider sv_body() in server.c 2237 con=SSL_new(ctx); Here a new context is initialized. From ssl_lib.c:295, this also causes the krb context to be initialized via 295 s->kssl_ctx = kssl_ctx_new(); So SSL_new basically also allocates memory for con->kssl Later in sv_body() at line 2252: 2252 if ((kctx = kssl_ctx_new()) != NULL) 2253 { 2254 SSL_set0_kssl_ctx(con, kctx); This causes con->kssl_ctx to be rewritten by kctx, in doing so 56 bytes of previously allocated memory is lost and hence the memory leak for each connection made. On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT wrote: > Here is how to test it: > > openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt > -subj \ > /CN=localhost -nodes -batch -sha256 > > valgrind --leak-check=full openssl s_server -key localhost.key -cert \ > localhost.crt -accept 4433 > > ./poc.py > > Every run of poc.py causes 56 byte memory leak: > > ==11278== HEAP SUMMARY: > ==11278== in use at exit: 910,716 bytes in 20,383 blocks > ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes > allocated > ==11278== > ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of > 823 > ==11278== at 0x4C2745D: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck- > amd64-linux.so) > ==11278== by 0x5A6AD12: CRYPTO_malloc (mem.c:308) > ==11278== by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) > ==11278== by 0x4E759E9: SSL_new (ssl_lib.c:295) > ==11278== by 0x436387: sv_body (s_server.c:2004) > ==11278== by 0x44AC30: do_server (s_socket.c:324) > ==11278== by 0x439C36: s_server_main (s_server.c:1901) > ==11278== by 0x419377: do_cmd (openssl.c:489) > ==11278== by 0x41906D: main (openssl.c:381) > ==11278== > ==11278== LEAK SUMMARY: > ==11278== definitely lost: 56 bytes in 1 blocks > ==11278== indirectly lost: 0 bytes in 0 blocks > ==11278== possibly lost: 0 bytes in 0 blocks > ==11278== still reachable: 910,660 bytes in 20,382 blocks > ==11278== suppressed: 0 bytes in 0 blocks > ==11278== Reachable blocks (those to which a pointer was found) are not > shown. > ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==11278== > ==11278== For counts of detected and suppressed errors, rerun with: -v > ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) > """ > > > Acknowledgement Text Required: Yes > Community Trackers Required : Yes > Ticket Response Required : Yes > > poc.py is attached > > > > On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT < > rt at openssl.org> > wrote: > > > Hi, > > > > I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 > > bytes for each connection request. > > > > Patch is attached. > > > > > > _______________________________________________ > > 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 Jan 15 14:34:43 2015 From: rt at openssl.org (Huzaifa Sidhpurwala via RT) Date: Thu, 15 Jan 2015 15:34:43 +0100 Subject: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c In-Reply-To: References: Message-ID: This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here is a brief analysis: Consider sv_body() in server.c 2237 con=SSL_new(ctx); Here a new context is initialized. From ssl_lib.c:295, this also causes the krb context to be initialized via 295 s->kssl_ctx = kssl_ctx_new(); So SSL_new basically also allocates memory for con->kssl Later in sv_body() at line 2252: 2252 if ((kctx = kssl_ctx_new()) != NULL) 2253 { 2254 SSL_set0_kssl_ctx(con, kctx); This causes con->kssl_ctx to be rewritten by kctx, in doing so 56 bytes of previously allocated memory is lost and hence the memory leak for each connection made. On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT wrote: > Here is how to test it: > > openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt > -subj \ > /CN=localhost -nodes -batch -sha256 > > valgrind --leak-check=full openssl s_server -key localhost.key -cert \ > localhost.crt -accept 4433 > > ./poc.py > > Every run of poc.py causes 56 byte memory leak: > > ==11278== HEAP SUMMARY: > ==11278== in use at exit: 910,716 bytes in 20,383 blocks > ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes > allocated > ==11278== > ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of > 823 > ==11278== at 0x4C2745D: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck- > amd64-linux.so) > ==11278== by 0x5A6AD12: CRYPTO_malloc (mem.c:308) > ==11278== by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790) > ==11278== by 0x4E759E9: SSL_new (ssl_lib.c:295) > ==11278== by 0x436387: sv_body (s_server.c:2004) > ==11278== by 0x44AC30: do_server (s_socket.c:324) > ==11278== by 0x439C36: s_server_main (s_server.c:1901) > ==11278== by 0x419377: do_cmd (openssl.c:489) > ==11278== by 0x41906D: main (openssl.c:381) > ==11278== > ==11278== LEAK SUMMARY: > ==11278== definitely lost: 56 bytes in 1 blocks > ==11278== indirectly lost: 0 bytes in 0 blocks > ==11278== possibly lost: 0 bytes in 0 blocks > ==11278== still reachable: 910,660 bytes in 20,382 blocks > ==11278== suppressed: 0 bytes in 0 blocks > ==11278== Reachable blocks (those to which a pointer was found) are not > shown. > ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all > ==11278== > ==11278== For counts of detected and suppressed errors, rerun with: -v > ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) > """ > > > Acknowledgement Text Required: Yes > Community Trackers Required : Yes > Ticket Response Required : Yes > > poc.py is attached > > > > On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT < > rt at openssl.org> > wrote: > > > Hi, > > > > I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56 > > bytes for each connection request. > > > > Patch is attached. > > > > > > _______________________________________________ > > 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 shiretu at gmail.com Thu Jan 15 15:49:59 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 17:49:59 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: <6EDE8917-F9F0-486D-8C52-0F3ADE024E9D@gmail.com> Hi, Adding "SSL_CTX_set_read_ahead(pSslContext, 1);" fixed both the test app and the real app I'm working on. May I ask where should I read more about this function? I'm grateful that it now works, but is kind of a tough thing to just swallow this info without chewing on it a bit :) Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 15 15:50:21 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Thu, 15 Jan 2015 16:50:21 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: <6EDE8917-F9F0-486D-8C52-0F3ADE024E9D@gmail.com> References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> <6EDE8917-F9F0-486D-8C52-0F3ADE024E9D@gmail.com> Message-ID: Hi, Adding "SSL_CTX_set_read_ahead(pSslContext, 1);" fixed both the test app and the real app I'm working on. May I ask where should I read more about this function? I'm grateful that it now works, but is kind of a tough thing to just swallow this info without chewing on it a bit :) Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From shiretu at gmail.com Thu Jan 15 16:01:31 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 18:01:31 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Hi all, Also, just for completeness, I want to point out I'm a fortunate case where I can actually touch the code and recompile it to fix the issue. I'm sure that other cases are not so fortunate. IMHO, when DTLS method is used, that call should be made by default in the internals of OpenSSL Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 15 16:01:51 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Thu, 15 Jan 2015 17:01:51 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Hi all, Also, just for completeness, I want to point out I'm a fortunate case where I can actually touch the code and recompile it to fix the issue. I'm sure that other cases are not so fortunate. IMHO, when DTLS method is used, that call should be made by default in the internals of OpenSSL Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 15 16:21:35 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Jan 2015 17:21:35 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: On Thu Jan 15 17:01:51 2015, shiretu at gmail.com wrote: > Hi all, > > Also, just for completeness, I want to point out I'm a fortunate case > where I can actually touch the code and recompile it to fix the > issue. I'm sure that other cases are not so fortunate. IMHO, when > DTLS method is used, that call should be made by default in the > internals of OpenSSL In response to your previous documentation question it is (unfortunately) undocumented. :-( The best I can offer you is the source code: int read_ahead; /* Read as many input bytes as possible * (for non-blocking reads) */ With regards to your second point, I consider it a bug that this is not the default for DTLS. Unfortunately that bug has remained dormant until the fix for CVE-2014-0206 exposed it. I'm keeping this ticket open, until we have a proper fix. For now though the workaround is to use the SSL_CTX_set_read_ahead function directly. Matt From fedor at indutny.com Thu Jan 15 17:06:05 2015 From: fedor at indutny.com (Fedor Indutny) Date: Thu, 15 Jan 2015 21:06:05 +0400 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 In-Reply-To: <54B7CD3B.8040706@openssl.org> References: <54B7CCD2.108@openssl.org> <54B7CD3B.8040706@openssl.org> Message-ID: Matt, Thank you for reply. May I ask you when do you think your patch may land in 1.0.2 or whatever? If this is something of your long term goals and not going to land anywhere soon. Could you please tell me about issues in my patch (either privately or in publi?)? Thank you again, Fedor. On Thursday, January 15, 2015, Matt Caswell wrote: > > > On 15/01/15 14:21, Matt Caswell wrote: > > > > > > On 15/01/15 14:13, Fedor Indutny wrote: > >> Hello! > >> > >> During the course of deprecation of stale 1024bit CA certs, > >> node.js and io.js project teams have identified the problem with > >> how OpenSSL client handles the server's certificate chain. It is > >> quite evident that it ignores certificate store and loads issuer > >> from the chain that was received. This leads to the problems with > >> AWS and probably other service providers who sent the stale > >> **alternative** certificate chain with same serial numbers, but > >> 1024bit CA certificates. > >> > >> I have already tried proposing a solution to the OpenSSL team: > >> > >> https://www.mail-archive.com/openssl-dev at openssl.org/msg37721.html > >> > >> But one of the node.js contributors we have found this commit (from > 2010): > >> > >> > https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3 > >> > >> The main question that I have is: > >> > >> Is it safe to float this patch on top of 1.0.1k and use it? From > >> my knowledge of code it appears to be pretty harmless, however > >> the fact that it wasn't backported in 5 years makes me wonder if > >> it was considered safe after all. > > > > There are some concerns about the performance of trusted_first. > > Successful certificate look ups are cached, whilst failed ones are not. > > Therefore using trusted_first *could* have an adverse impact. > > > > This issue is currently under discussion within the dev team. I have an > > alternative patch that addresses the same issue in a different way. > > Essentially it works in a similar way to that which you proposed in > > RT3637. However I have some issues with that patch, so I've done it > > slightly differently. > > > > RT3621 is also relevant here. > > I should add that in any case this functionality would never be > backported to 1.0.1 (only considered for future versions). 1.0.1 is a > stable release and only sees bug fixes. This would be considered a > feature and a significant change to the way certificates are verified. > > Matt > > _______________________________________________ > 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 Jan 15 17:42:45 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Thu, 15 Jan 2015 18:42:45 +0100 Subject: [openssl-dev] [openssl.org #3661] BUG: errstr cannot decode a failed signature verification when using EVP_DigestVerifyFinal In-Reply-To: References: Message-ID: When using EVP_DigestSign and EVP_DigestVerify functions, errstr cannot decode a failed verification error under RSA. To duplicate, create a signature with EVP_DigestSign. Tamper with the signature: sig[0] ^= 0x1. Then run it through EVP_DigestVerify. In the case of OpenSSL 1.0.1: $ ./t-rsa.exe Testing RSA functions with EVP_DigestSign and EVP_DigestVerify Signature: 9023EF59A4ED046E... Tampering with signature... EVP_DigestVerifyFinal failed, return code 0, error 0x407006ad $ openssl errstr 0x407006ad error:407006AD:lib(64):func(1792):reason(1709) $ /usr/local/ssl/darwin/bin/openssl errstr 0x407006ad error:407006AD:lib(64):func(1792):reason(1709) From shiretu at gmail.com Thu Jan 15 18:55:09 2015 From: shiretu at gmail.com (Eugen-Andrei Gavriloaie) Date: Thu, 15 Jan 2015 20:55:09 +0200 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Matt, Thank you for the support. This was lucrative and good response time! Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Jan 15 18:55:20 2015 From: rt at openssl.org (Eugen-Andrei Gavriloaie via RT) Date: Thu, 15 Jan 2015 19:55:20 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: Matt, Thank you for the support. This was lucrative and good response time! Best regards, Andrei > On Jan 14, 2015, at 22:21, Eugen-Andrei Gavriloaie via RT wrote: > > Hi all, > > I believe I have found a bug which is only present in the latest versions (1.0.1k) > > I have created a simple C test which does the following things in this order: > > 1. initialize the SSL library > 2. creates an X509 key and cert > 3. creates an DTLS server SSL context > 4. Setup 2 memory BIO instances on the SSL context > 5. Feed the input BIO with a hardcoded "Client Hello" packet > 6. Call SSL_accept > > Wanted: > The output BIO should contain a packet ("Server Hello") to be sent over the wire > > Observed: > The output BIO is empty, the handshake never succeeds > > Same file test app linked with OpenSSL 1.0.1j works as expected, the output is generated. > > I have attached the C file. > > Best regards, > Andrei > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From hanno at hboeck.de Thu Jan 15 23:45:46 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Fri, 16 Jan 2015 00:45:46 +0100 Subject: [openssl-dev] [PATCH] better ordering of cipher suites, always prefer GCM/AEAD over CBC Message-ID: <20150116004546.2ea2c23e@pc> Hi, Please see attached patch which changes the ordering of the cipher suites in openssl. It makes the mac algorithm the main criterion for the cipher sorting, with the intent to always prefer AEAD ciphersuites over non-AEAD ciphersuites. The main reason for that is that right now in a lot of situations a cbc ciphersuite will be preferred over a gcm cipher suite. This is not good, because gcm ciphersuites are the only ones that haven't suffered from attacks in the past. It may be argued whether another cipher suite ordering is better, but I think this is definitely much better than the current state. These days the key size is only a very weak indicator of a cipher's strength. I just saw yesterday that 1.0.2 is about to be released. I had hoped we could get something like this patch in before. Is there a chance to do that? Or could it be considered for one of the follow-up versions (1.0.2a/b)? I would prefer not having to wait with that till 1.1.0. cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.0.2-better-cipher-suite-order.diff Type: text/x-patch Size: 1279 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Fri Jan 16 08:00:33 2015 From: rt at openssl.org (=?UTF-8?B?5aSP5bCP6ZO2?= via RT) Date: Fri, 16 Jan 2015 09:00:33 +0100 Subject: [openssl-dev] [openssl.org #3662] [bug report]DTLS memory leak in dtls1_accept when use PSK in opensll 1.0.1j In-Reply-To: References: Message-ID: Hi: I am using DTLS PSK, and I found memory leak in DTLS establishment. I use valgrind to check memory and find some unreachable point. valgrind --tool=memcheck --leak-check=full --show-reachable=yes 24 bytes in 1 blocks are still reachable in loss record 539 of 622 ==12007== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==12007== by 0x463E1D: CRYPTO_malloc (mem.c:308) ==12007== by 0x465AF3: def_get_class (ex_data.c:308) ==12007== by 0x465D98: int_new_ex_data (ex_data.c:408) ==12007== by 0x438BD6: SSL_SESSION_new (ssl_sess.c:216) ==12007== by 0x438C52: ssl_get_new_session (ssl_sess.c:280) ==12007== by 0x445BBF: ssl3_get_client_hello (s3_srvr.c:1028) ==12007== by 0x42A1FE: dtls1_accept (d1_srvr.c:299) ==12007== ==12007== 24 bytes in 1 blocks are still reachable in loss record 540 of 622 ==12007== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==12007== by 0x463E1D: CRYPTO_malloc (mem.c:308) ==12007== by 0x486FD8: lh_insert (lhash.c:193) ==12007== by 0x465B25: def_get_class (ex_data.c:320) ==12007== by 0x465D98: int_new_ex_data (ex_data.c:408) ==12007== by 0x438BD6: SSL_SESSION_new (ssl_sess.c:216) ==12007== by 0x438C52: ssl_get_new_session (ssl_sess.c:280) ==12007== by 0x445BBF: ssl3_get_client_hello (s3_srvr.c:1028) ==12007== by 0x42A1FE: dtls1_accept (d1_srvr.c:299) 32 bytes in 1 blocks are still reachable in loss record 553 of 622 ==12007== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==12007== by 0x463E1D: CRYPTO_malloc (mem.c:308) ==12007== by 0x486844: sk_new_null (stack.c:125) ==12007== by 0x465B09: def_get_class (ex_data.c:313) ==12007== by 0x465D98: int_new_ex_data (ex_data.c:408) ==12007== by 0x438BD6: SSL_SESSION_new (ssl_sess.c:216) ==12007== by 0x438C52: ssl_get_new_session (ssl_sess.c:280) ==12007== by 0x445BBF: ssl3_get_client_hello (s3_srvr.c:1028) ==12007== by 0x42A1FE: dtls1_accept (d1_srvr.c:299) ==12007== ==12007== 32 bytes in 1 blocks are still reachable in loss record 554 of 622 ==12007== at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==12007== by 0x463E1D: CRYPTO_malloc (mem.c:308) ==12007== by 0x486860: sk_new_null (stack.c:127) ==12007== by 0x465B09: def_get_class (ex_data.c:313) ==12007== by 0x465D98: int_new_ex_data (ex_data.c:408) ==12007== by 0x438BD6: SSL_SESSION_new (ssl_sess.c:216) ==12007== by 0x438C52: ssl_get_new_session (ssl_sess.c:280) ==12007== by 0x445BBF: ssl3_get_client_hello (s3_srvr.c:1028) ==12007== by 0x42A1FE: dtls1_accept (d1_srvr.c:299) thanks From rt at openssl.org Fri Jan 16 08:28:20 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 16 Jan 2015 09:28:20 +0100 Subject: [openssl-dev] [openssl.org #3654] 1.0.1k not compiling In-Reply-To: <54B291D0.1070506@mdjnet.dk> References: <54B291D0.1070506@mdjnet.dk> Message-ID: We just released 1.0.1l to resolve exactly this. On Wed Jan 14 17:59:39 2015, r03 at mdjnet.dk wrote: > Hi - I have never reported bugs here before, so I hope I am doing it right. > > I have downloaded 1.0.1k, and I am trying to build it on Windows (for > W32) using the build script I usually use, but compilation fails in > crypto\cversion.c line 80, "cflags" is unknown. Comparing the entire > cversion.c with the previous version makes it clear that the line should > have read CFLAGS (uppercase) instead. Making that change makes it > compile, and the resulting dll's (which I use in my Apache/mod_ssl among > other things) appear to be working just fine. > > I hope my little analysis is correct, and that I can indeed trust the > resulting build. > > Regards, -- Richard Levitte levitte at openssl.org From rt at openssl.org Fri Jan 16 09:20:21 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Jan 2015 10:20:21 +0100 Subject: [openssl-dev] [openssl.org #3661] BUG: errstr cannot decode a failed signature verification when using EVP_DigestVerifyFinal In-Reply-To: References: Message-ID: Closed following offline discussion with Jeff. No action required. Matt From rt at openssl.org Fri Jan 16 13:54:35 2015 From: rt at openssl.org (Adam Williamson via RT) Date: Fri, 16 Jan 2015 14:54:35 +0100 Subject: [openssl-dev] [openssl.org #3663] [PATCH] clarify 'verify' command operation In-Reply-To: <1421395664-8660-1-git-send-email-awilliam@redhat.com> References: <1421395664-8660-1-git-send-email-awilliam@redhat.com> Message-ID: Explain that chains cannot be passed as the [certificates] but the intermediates must be passed to -untrusted, explain in a bit more detail how CApath and CAfile are used, and try a bit harder in VERIFY OPERATION to explain what it means in terms of the command line parameters. This foxed me for a while until I figured it out, and there's a question on StackOverflow illustrating the same confusion: https://stackoverflow.com/questions/23304139 So it seems worth explaining. --- doc/apps/verify.pod | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/doc/apps/verify.pod b/doc/apps/verify.pod index a5a0063..782b46d 100644 --- a/doc/apps/verify.pod +++ b/doc/apps/verify.pod @@ -54,7 +54,9 @@ The B command verifies certificate chains. =item B<-CAfile file> A file of trusted certificates. The file should contain multiple certificates -in PEM format concatenated together. +in PEM format concatenated together. If not passed, the default location set +at compile time will be checked and certificates from that location will be +included in the list of trusted certificates if found. =item B<-CApath directory> @@ -62,7 +64,9 @@ A directory of trusted certificates. The certificates should have names of the form: hash.0 or have symbolic links to them of this form ("hash" is the hashed certificate subject name: see the B<-hash> option of the B utility). Under Unix the B script will automatically -create symbolic links to a directory of certificates. +create symbolic links to a directory of certificates. If not passed, the +default location set at compile time will be checked and certificates from +that location will be included in the list of trusted certificates if found. =item B<-attime timestamp> @@ -166,8 +170,8 @@ This is mainly useful in environments with Bridge CA or Cross-Certified CAs. =item B<-untrusted file> -A file of untrusted certificates. The file should contain multiple certificates -in PEM format concatenated together. +A file of untrusted certificates. The file should contain one or more +certificates in PEM format concatenated together. =item B<-use_deltas> @@ -215,9 +219,14 @@ with a B<->. =item B -One or more certificates to verify. If no certificates are given, B -will attempt to read a certificate from standard input. Certificates must be -in PEM format. +One or more certificates to verify. Each will be verified independently of all +the others. If no certificates are given, B will attempt to read a +certificate from standard input. Certificates must be in PEM format. Only one +certificate will be read from each file: passing a chain of certificates +concatenated together will not verify the chain, it will verify the first +certificate in the file and ignore the others. To verify a chain, pass the +intermediate certificate(s) to B<-untrusted> and give only the final +certificate in the chain here. =back @@ -252,11 +261,12 @@ of the current certificate (if present) must match the subject key identifier the keyUsage extension of the candidate issuer (if present) must permit certificate signing. -The lookup first looks in the list of untrusted certificates and if no match -is found the remaining lookups are from the trusted certificates. The root CA -is always looked up in the trusted certificate list: if the certificate to -verify is a root certificate then an exact match must be found in the trusted -list. +The lookup first looks in the list of untrusted certificates passed to +B<-untrusted> and if no match is found the remaining lookups are from the trusted +certificates passed to B<-CAfile> and/or B<-CApath> and/or found in the default +locations. The root CA is always looked up in the trusted certificate list: if +the certificate to verify is a root certificate then an exact match must be +found in the trusted certificate list. The second operation is to check every untrusted certificate's extensions for consistency with the supplied purpose. If the B<-purpose> option is not included -- 2.2.1 From rt at openssl.org Fri Jan 16 20:13:26 2015 From: rt at openssl.org (Jonathan Larmour via RT) Date: Fri, 16 Jan 2015 21:13:26 +0100 Subject: [openssl-dev] [openssl.org #3664] IDEA patent in Readme In-Reply-To: <54B9337F.6060208@eCosCentric.com> References: <54B9337F.6060208@eCosCentric.com> Message-ID: Just a minor thing, but the top level OpenSSL 1.0.1 README includes: "The IDEA algorithm is patented by Ascom in Austria, France, Germany, Italy, Japan, the Netherlands, Spain, Sweden, Switzerland, UK and the USA. They should be contacted if that algorithm is to be used; their web page is http://www.ascom.ch/." However IDEA is no longer patented anywhere. You could replace the text with the following: -=-=-=-=- The IDEA algorithm used to be patented by Ascom, but as of 2012, there are no longer any valid patents remaining so it may now be used patent-free. -=-=-=-=- The FAQ (online and in git including master branch) also briefly mentions IDEA among other patent-encumbered algorithms, but it can be removed from there too. While in this area, might it be worth importing README.ECC from the master branch into both the 1.0.1 and 1.0.2 branches? People might read things like http://en.wikipedia.org/wiki/ECC_patents and be concerned. I know you don't want to make pronouncements on what may or may not infringe patents, but pulling this file in seems like an easy thing to do. Jifl -- ------["Si fractum non sit, noli id reficere"]------ Opinions==mine From rt at openssl.org Sun Jan 18 11:58:27 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Sun, 18 Jan 2015 12:58:27 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: Message-ID: OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test certificate and its CA cert that illustrate the problem are attached, as well as the patch/workaround). Here?s how the problem manifests itself: $ openssl version -f compiler: -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US error 7 at 0 depth lookup:certificate signature failure $ /usr/bin/openssl version -f compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6 $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem RabbitMQ_Test.pem: OK $ Probable cause: certificate decoder either fails to encode ASN.1 NULL for "signature algorithm parameters? when it should, or encodes an explicit ASN.1 NULL when it shouldn?t. As a result, the comparison code ASN1_TYPE_cmp in crypto/asn1/a_type.c is presented with a case when one argument is empty (a null pointer), and the other one is of type ASN.1 NULL (0x5). In result, the comparison fails when it actually should return OK (0). Here?s the workaround that I consider secure. I think it should be used, at least until the cause for the above decoding confusion is could and fixed. Also, since I?m not an OpenSSL developer and thus am not a member of the mailing list, I?d appreciate if you could copy replies to this email as well. Thanks! --- crypto/asn1/a_type.c.~1~ 2015-01-15 09:43:14.000000000 -0500 +++ crypto/asn1/a_type.c 2015-01-17 15:12:17.000000000 -0500 @@ -117,7 +117,22 @@ { int result = -1; - if (!a || !b || a->type != b->type) return -1; + if (!a || !b) { + if (!a && !b) /* both types are empty (null) */ + return 0; + /* one is null, the other is maybe ASN.1 NULL (explicit) */ + if (a && !b) { + if (a->type == V_ASN1_NULL) + return 0; + } + if (b && !a) { + if (b->type == V_ASN1_NULL) + return 0; + } + return -1; /* the non-null (present) type isn't ASN.1 NULL */ + } + + if (a->type != b->type) return -1; switch (a->type) { -- Uri Blumenthal uri at mit.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RabbitMQ_Test_CA.pem Type: application/x-x509-ca-cert Size: 1277 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RabbitMQ_Test.pem Type: application/x-x509-ca-cert Size: 1371 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.0.1k.patch Type: application/octet-stream Size: 662 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1842 bytes Desc: not available URL: From dkg at fifthhorseman.net Sun Jan 18 15:02:39 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 18 Jan 2015 10:02:39 -0500 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: Message-ID: <874mroxhbk.fsf@alice.fifthhorseman.net> On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote: > OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test certificate and its CA cert that illustrate the problem are attached, as well as the patch/workaround). > > Here?s how the problem manifests itself: > $ openssl version -f > compiler: -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem > RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US > error 7 at 0 depth lookup:certificate signature failure > $ /usr/bin/openssl version -f > compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6 > $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem > RabbitMQ_Test.pem: OK > $ the "version" commands above don't indicate what version was tried in each case. I tested the verify command on 1.0.1j on debian unstable, and found that it returns: RabbitMQ_Test.pem: OK this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l. I haven't tested those version yet. I also tested the certificate chain with gnutls and NSS, and both seemed to think the chain was OK. GnuTLS 3.3.8: 1 dkg at alice:~/tmp$ cat RabbitMQ_Test.pem RabbitMQ_Test_CA.pem | certtool --verify-chain Loaded 2 certificates, 1 CAs and 0 CRLs Subject: CN=RabbitMQ_Test,C=US Issuer: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse008 at gmail.com Checked against: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse008 at gmail.com Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. 0 dkg at alice:~/tmp$ NSS 3.17.2 (from an empty directory, where we're going to create an NSS certificate db): 0 dkg at alice:/tmp/cdtemp.hknE0D$ certutil -d $(pwd) -A -n rabbitmq -t cT,, < ~/tmp/RabbitMQ_Test_CA.pem 0 dkg at alice:/tmp/cdtemp.hknE0D$ vfychain -a -d $(pwd) -u 0 ~/tmp/RabbitMQ_Test.pem Chain is good! 0 dkg at alice:/tmp/cdtemp.hknE0D$ --dkg From rt at openssl.org Sun Jan 18 15:08:38 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Sun, 18 Jan 2015 16:08:38 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <874mroxhbk.fsf@alice.fifthhorseman.net> References: <874mroxhbk.fsf@alice.fifthhorseman.net> Message-ID: On Sun 2015-01-18 06:58:27 -0500, Uri Blumenthal via RT wrote: > OpenSSL 1.0.1k and 1.0.1l. Problem: good certificates fail verification (test certificate and its CA cert that illustrate the problem are attached, as well as the patch/workaround). > > Here?s how the problem manifests itself: > $ openssl version -f > compiler: -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > $ openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem > RabbitMQ_Test.pem: CN = RabbitMQ_Test, C = US > error 7 at 0 depth lookup:certificate signature failure > $ /usr/bin/openssl version -f > compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6 > $ /usr/bin/openssl verify -CAfile RabbitMQ_Test_CA.pem RabbitMQ_Test.pem > RabbitMQ_Test.pem: OK > $ the "version" commands above don't indicate what version was tried in each case. I tested the verify command on 1.0.1j on debian unstable, and found that it returns: RabbitMQ_Test.pem: OK this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l. I haven't tested those version yet. I also tested the certificate chain with gnutls and NSS, and both seemed to think the chain was OK. GnuTLS 3.3.8: 1 dkg at alice:~/tmp$ cat RabbitMQ_Test.pem RabbitMQ_Test_CA.pem | certtool --verify-chain Loaded 2 certificates, 1 CAs and 0 CRLs Subject: CN=RabbitMQ_Test,C=US Issuer: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse008 at gmail.com Checked against: CN=RabbitMQ_Test_CA,C=US,EMAIL=mouse008 at gmail.com Output: Verified. The certificate is trusted. Chain verification output: Verified. The certificate is trusted. 0 dkg at alice:~/tmp$ NSS 3.17.2 (from an empty directory, where we're going to create an NSS certificate db): 0 dkg at alice:/tmp/cdtemp.hknE0D$ certutil -d $(pwd) -A -n rabbitmq -t cT,, < ~/tmp/RabbitMQ_Test_CA.pem 0 dkg at alice:/tmp/cdtemp.hknE0D$ vfychain -a -d $(pwd) -u 0 ~/tmp/RabbitMQ_Test.pem Chain is good! 0 dkg at alice:/tmp/cdtemp.hknE0D$ --dkg From rt at openssl.org Sun Jan 18 16:21:56 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 18 Jan 2015 17:21:56 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <20150118161613.GA12056@roeckx.be> References: <874mroxhbk.fsf@alice.fifthhorseman.net> <20150118161613.GA12056@roeckx.be> Message-ID: On Sun, Jan 18, 2015 at 04:08:38PM +0100, Daniel Kahn Gillmor via RT wrote: > > this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l. > I haven't tested those version yet. The change in behaviour seems to be this commit: commit a8565530e27718760220df469f0a071c85b9e731 Author: Dr. Stephen Henson Date: Sat Dec 20 15:09:50 2014 +0000 Fix various certificate fingerprint issues. [...] 2. Check certificate algorithm consistency. Check the AlgorithmIdentifier inside TBS matches the one in the certificate signature. NB: this will result in signature failure errors for some broken certificates. [...] (The order of the commits is wrong resulting in it not building because of the missing X509_ALGOR_cmp that's added in the next commit.) The backtrace is: #0 ASN1_TYPE_cmp (a=0x944240, b=0x0) at a_type.c:118 #1 0x0000000000524e4b in X509_ALGOR_cmp (a=0x9409a0, b=0x939d80) at x_algor.c:154 #2 0x00000000005484c7 in X509_verify (a=0x939a50, r=0x945360) at x_all.c:75 #3 0x00000000005433eb in internal_verify (ctx=0x939300) at x509_vfy.c:1637 #4 0x0000000000540d37 in X509_verify_cert (ctx=0x939300) at x509_vfy.c:367 #5 0x0000000000404328 in check (ctx=0x937f60, file=0x7fffffffee1c "/home/kurt/RabbitMQ_Test.pem", uchain=0x0, tchain=0x0, crls=0x0, e=0x0) at verify.c:294 #6 0x0000000000404065 in verify_main (argc=1, argv=0x7fffffffeba8) at verify.c:234 #7 0x000000000040304a in do_cmd (prog=0x9328d0, argc=4, argv=0x7fffffffeb90) at openssl.c:491 #8 0x0000000000402cd8 in main (Argc=4, Argv=0x7fffffffeb90) at openssl.c:382 Kurt From rt at openssl.org Sun Jan 18 16:29:16 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sun, 18 Jan 2015 17:29:16 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: Message-ID: On Sun Jan 18 12:58:26 2015, uri at mit.edu wrote: > > Probable cause: certificate decoder either fails to encode ASN.1 NULL > for "signature algorithm parameters? when it should, or encodes an > explicit ASN.1 NULL when it shouldn?t. As a result, the comparison > code ASN1_TYPE_cmp in crypto/asn1/a_type.c is presented with a case > when one argument is empty (a null pointer), and the other one is > of type ASN.1 NULL (0x5). In result, the comparison fails when it > actually should return OK (0). > In the example you gave the signature and signatureAlgorithm fields in the certificate don't match. OpenSSL tolerated this before but the fix for CVE-2014-8275 now rejects this case. How did you generate this certificate? Do you have any pubic CA examples which do this? 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 Jan 19 03:49:28 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Mon, 19 Jan 2015 04:49:28 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> References: <874mroxhbk.fsf@alice.fifthhorseman.net> <20150118161613.GA12056@roeckx.be> <6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> Message-ID: I think it is not a regression, because the reported problem existed for as long as crypto/asn1/a_type.c has been around in its current shape. This commit in the 1.0.1k patch manifested (exposed) this problem, possibly for the first time. Yes I think Kurt is perfectly correct pointing at the commit a8565530e27718760220df469f0a071c85b9e731. But the problem is not in this commit, and it wouldn?t be good to revert it, I think. And IMHO X509_ALGOR_cmp() is implemented correctly. The problem is in the old ASN1_TYPE_cmp(), which I?m proposing a fix to. Does the consensus on the list agree with my statement of the problem, and the proposed fix? I hope we all agree that semantically parameter list presented as ASN.1 NULL is equivalent to an empty parameter list, and should be treated as such? Thanks! On Jan 18, 2015, at 11:16 , Kurt Roeckx > wrote: On Sun, Jan 18, 2015 at 04:08:38PM +0100, Daniel Kahn Gillmor via RT wrote: this suggests that Uri is reporting a regression in 1.0.1k and 1.0.1l. I haven't tested those version yet. The change in behaviour seems to be this commit: commit a8565530e27718760220df469f0a071c85b9e731 Author: Dr. Stephen Henson > Date: Sat Dec 20 15:09:50 2014 +0000 Fix various certificate fingerprint issues. [...] 2. Check certificate algorithm consistency. Check the AlgorithmIdentifier inside TBS matches the one in the certificate signature. NB: this will result in signature failure errors for some broken certificates. [...] (The order of the commits is wrong resulting in it not building because of the missing X509_ALGOR_cmp that's added in the next commit.) The backtrace is: #0 ASN1_TYPE_cmp (a=0x944240, b=0x0) at a_type.c:118 #1 0x0000000000524e4b in X509_ALGOR_cmp (a=0x9409a0, b=0x939d80) at x_algor.c:154 #2 0x00000000005484c7 in X509_verify (a=0x939a50, r=0x945360) at x_all.c:75 #3 0x00000000005433eb in internal_verify (ctx=0x939300) at x509_vfy.c:1637 #4 0x0000000000540d37 in X509_verify_cert (ctx=0x939300) at x509_vfy.c:367 #5 0x0000000000404328 in check (ctx=0x937f60, file=0x7fffffffee1c "/home/kurt/RabbitMQ_Test.pem", uchain=0x0, tchain=0x0, crls=0x0, e=0x0) at verify.c:294 #6 0x0000000000404065 in verify_main (argc=1, argv=0x7fffffffeba8) at verify.c:234 #7 0x000000000040304a in do_cmd (prog=0x9328d0, argc=4, argv=0x7fffffffeb90) at openssl.c:491 #8 0x0000000000402cd8 in main (Argc=4, Argv=0x7fffffffeb90) at openssl.c:382 Kurt -- Uri Blumenthal uri at mit.edu From rt at openssl.org Mon Jan 19 04:29:21 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Mon, 19 Jan 2015 05:29:21 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net> <20150118161613.GA12056@roeckx.be> Message-ID: > In the example you gave the signature and signatureAlgorithm fields in the > certificate don't match. Well, technically you?re correct - but from semantic point of view, how different is an empty list, and a list presented as ASN.1 NULL? Don?t we have an empty list in both cases? And aren?t these two the only two ways to represent an empty list (so there?s little chance of somebody utilizing this difference to craft an attack)? > OpenSSL tolerated this before but the fix for CVE-2014-8275 now rejects this case. Yes I checked http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8275. I don?t think the intent of the above fix was to deal with this specific ? empty list" case that I?m bringing up. I think they were addressing real mismatches rather than the two possible representations of "nothing". > How did you generate this certificate? Certificates I?m bringing in that demonstrate the problem are generated by Apple software, Certificate Assistant. Please note that I provided two certificates - and the one for CA (RabbitMQ_Test_CA.pem) appears to pass even the current openssl-1.0.1k acceptance, despite having the same difference in encoding. Please check ASN.1 dump offsets 20 and 628 - and enjoy the difference between ?empty? and ?ASN.1 NULL?. > Do you have any pubic CA examples which do this? Unfortunately, I don?t have enough of public CA samples to find other ?offenders?. Those few that I checked, seem to always encode empty list as 0x05 0x00 (ASN.1 NULL). But regardless, isn?t it obvious that semantically the two can (and IMHO should) be treated the same? And even if it is a bug in Apple code, what harm would come from following the IETF motto of ?being liberal in what you receive and conservative in what you send?? A need to blacklist two fingerprints instead of one in the very worst case? Thanks! -- Uri Blumenthal uri at mit.edu From rt at openssl.org Mon Jan 19 08:30:25 2015 From: rt at openssl.org (Annie Yousar via RT) Date: Mon, 19 Jan 2015 09:30:25 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <1434.79.218.222.136.1421655667.squirrel@www2.informatik.hu-berlin.de> References: <1434.79.218.222.136.1421655667.squirrel@www2.informatik.hu-berlin.de> Message-ID: Am 19.01.2015 um 05:29 schrieb Uri Blumenthal via RT: > Well, technically you?re correct - but from semantic point of view, > how different is an empty list, and a list presented as ASN.1 NULL? > Don?t we have an empty list in both cases? And aren?t these two the > only two ways to represent an empty list (so there?s little chance of > somebody utilizing this difference to craft an attack)? It is the difference as of an empty tumbler on the table and no tumbler at all ;-) RFC 4055 as well as RFC 5754 do not make this difference, both say: When any of these four object identifiers appears within an AlgorithmIdentifier, the parameters MUST be NULL. Implementations MUST accept the parameters being absent as well as present. If OpenSSL declines an empty paramter field then this is non-conformant with theses RFCs. /Ann. From rt at openssl.org Mon Jan 19 13:40:33 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 19 Jan 2015 14:40:33 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net> <20150118161613.GA12056@roeckx.be> <6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> Message-ID: On Mon Jan 19 04:49:27 2015, uri at mit.edu wrote: > > Does the consensus on the list agree with my statement of the problem, > and the proposed fix? I hope we all agree that semantically > parameter list presented as ASN.1 NULL is equivalent to an empty > parameter list, and should be treated as such? > The problem is that the two fields containing the signature algorithm do not match. >From RFC5280: 4.1.2.3. Signature ... This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (Section 4.1.1.2). Now whether "the same algorithm identifier" means "identical" or "the same meaning" is debatable. Currently it goes with the former and if that is taken to be the case the certificate presented is encoded incorrectly. The question is whether an OpenSSL workaround should be added to tolerate this. Before this change OpenSSL completely ignored the signature field (so it could contain anything) and only used the signatureAlgorithm field. In general the ASN.1 NULL value and absent can be very different depending on the ASN.1 structure being represented and "empty" can have a third distinct meaning. Example: imagine an OPTIONAL field where "NULL" represents a status value of some sort. In that case an absent field would indicate no status available while a NULL would indicate a specific status. So in general changing ASN1_TYPE_cmp in the proposed fashion is not a good idea. In the very specific case of a certificate and certain digest algorithms absent and NULL do have the same meaning. 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 Jan 19 13:46:27 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 19 Jan 2015 14:46:27 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <1434.79.218.222.136.1421655667.squirrel@www2.informatik.hu-berlin.de> Message-ID: On Mon Jan 19 09:30:24 2015, a.yousar at informatik.hu-berlin.de wrote: > > RFC 4055 as well as RFC 5754 do not make this difference, both say: > When any of these four object identifiers appears within an > AlgorithmIdentifier, the parameters MUST be NULL. Implementations > MUST accept the parameters being absent as well as present. > > If OpenSSL declines an empty paramter field then this is non-conformant > with theses RFCs. > OpenSSL will tolerate both an absent parameter list and a NULL one. It did before this change and still does after it. This specific case rejects a certificate where the two AlgorithmIdentifier values in the certificate (signature and signatureAlgorithm) do not match. It seems odd that an implementation having decided it should represent an algorithm in one way for one field should then decide to represent an identical algorithm in a different way for another. 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 Jan 19 14:47:34 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 19 Jan 2015 15:47:34 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net> <20150118161613.GA12056@roeckx.be> <6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> Message-ID: On Mon Jan 19 14:40:32 2015, steve wrote: > > The problem is that the two fields containing the signature algorithm > do not match. > The current 'x509' utility can't show this difference (I have an option I'm testing which will). It is possible to use the cms command diagnostic output though: openssl crl2pkcs7 -nocrl -certfile RabbitMQ_Test.pem | openssl cms -cmsout -print -inform PEM ... signature: algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11) parameter: ... sig_alg: algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11) parameter: NULL [sig_alg is the name of the field used internally by OpenSSL to store the signatureAlgorithm field] Whereas another case (e.g. test apps/server.pem) shows: signature: algorithm: sha1WithRSAEncryption (1.2.840.113549.1.1.5) parameter: NULL sig_alg: algorithm: sha1WithRSAEncryption (1.2.840.113549.1.1.5) parameter: NULL 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 Jan 19 14:55:22 2015 From: rt at openssl.org (s.reschke@avm.de via RT) Date: Mon, 19 Jan 2015 15:55:22 +0100 Subject: [openssl-dev] [openssl.org #3666] [PATCH] build with no-ts fails In-Reply-To: References: Message-ID: Hello, Fix build of apps without ts (define OPENSSL_NO_TS) Regards Sebastian -- Mit freundlichem Gru? Sebastian Reschke AVM GmbH Sebastian Reschke Internetworking Telefon 030 39976-794 s.reschke at avm.de www.avm.de AVM Audiovisuelles Marketing und Computersysteme GmbH, Alt-Moabit 95, 10559 Berlin HRB 23075 AG Charlottenburg, Gesch?ftsf?hrer: Johannes Nill -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl.no-ts.patch Type: application/octet-stream Size: 942 bytes Desc: not available URL: From rt at openssl.org Mon Jan 19 15:19:50 2015 From: rt at openssl.org (Rob Stradling via RT) Date: Mon, 19 Jan 2015 16:19:50 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <54BD1EFE.4050201@comodo.com> References: <874mroxhbk.fsf@alice.fifthhorseman.net><20150118161613.GA12056@roeckx.be><6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> <54BD1EFE.4050201@comodo.com> Message-ID: On 19/01/15 14:47, Stephen Henson via RT wrote: > On Mon Jan 19 14:40:32 2015, steve wrote: >> >> The problem is that the two fields containing the signature algorithm >> do not match. > > The current 'x509' utility can't show this difference (I have an option I'm > testing which will). Steve, while you're there... I've been caught out a few times in the past because the 'x509' utility displays the "outer" signature algorithm in the place where it should display the "inner" signature algorithm. This is fine when they match, but it's rather unhelpful when they don't match! Please consider this trivial patch. Thanks. diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c index 89115c7..97abd51 100644 --- a/crypto/asn1/t_x509.c +++ b/crypto/asn1/t_x509.c @@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long nmflags, unsigned long cflag) if(!(cflag & X509_FLAG_NO_SIGNAME)) { - if(X509_signature_print(bp, x->sig_alg, NULL) <= 0) + if(X509_signature_print(bp, ci->signature, NULL) <= 0) goto err; #if 0 if (BIO_printf(bp,"%8sSignature Algorithm: ","") <= 0) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rt at openssl.org Mon Jan 19 16:29:43 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 19 Jan 2015 17:29:43 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net><20150118161613.GA12056@roeckx.be><6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> <54BD1EFE.4050201@comodo.com> Message-ID: On Mon Jan 19 16:19:50 2015, rob.stradling at comodo.com wrote: > > Steve, while you're there... > > I've been caught out a few times in the past because the 'x509' > utility > displays the "outer" signature algorithm in the place where it should > display the "inner" signature algorithm. This is fine when they > match, > but it's rather unhelpful when they don't match! > > Please consider this trivial patch. Thanks. > > diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c > index 89115c7..97abd51 100644 > --- a/crypto/asn1/t_x509.c > +++ b/crypto/asn1/t_x509.c > @@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long > nmflags, unsigned long cflag) > > if(!(cflag & X509_FLAG_NO_SIGNAME)) > { > - if(X509_signature_print(bp, x->sig_alg, NULL) <= 0) > + if(X509_signature_print(bp, ci->signature, NULL) <= 0) > goto err; > #if 0 > if (BIO_printf(bp,"%8sSignature Algorithm: ","") <= > 0) > Ah that's a bug. It will be fixed. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Tue Jan 20 03:00:51 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Tue, 20 Jan 2015 04:00:51 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net><20150118161613.GA12056@roeckx.be><6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> <54BD1EFE.4050201@comodo.com> Message-ID: Steve, you?ve made several good points. But please consider: > The problem is that the two fields containing the signature algorithm do not match. But they do according to RFC 5754 - I interpret it as declaring that in this particular case (optional parameters of AlgorithmIdentifier) NULL is equivalent to (the same as) absent. In fact, RFC 5754 (page 4) states that the correct encoding is omitting the empty list altogether, but some uses defined their encoding as NULL, and it?s OK. It reveals some history of this duality: The two alternatives arise from the loss of the OPTIONAL associated with the algorithm identifier parameters when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax. Later, the OPTIONAL was recovered via a defect report, but by then many people thought that algorithm parameters were mandatory. Because of this history, some implementations encode parameters as a NULL element while others omit them entirely. > Now whether "the same algorithm identifier" means "identical" or "the same meaning" is debatable. Currently it goes with the former and if that is taken to be the case the certificate presented is encoded incorrectly. I see your point. However I don?t find it stated anywhere that the same object in a certificate must be encoded the same way if it occurs more than once. Thus, it may be a silly and bad idea to encode AlgorithmIdentifier one way first, and the other way next time - but it doesn?t appear prohibited. Is 2*2 the same as 4? :-) Or better, is ?2? the same as ?two?? :-) > The question is whether an OpenSSL workaround should be added to tolerate this. Considering the growing popularity of Apple platforms, my humble opinion is yes - a workaround should be added to tolerate this legal (and ugly) case. > Before this change OpenSSL completely ignored the signature field (so it could contain anything) and only used the signatureAlgorithm field. Exactly. And there are a few certificates deployed that are legal in every aspect of the published RFCs that 1.0.1k patch invalidates unnecessarily. > In general the ASN.1 NULL value and absent can be very different depending on the ASN.1 structure being represented and "empty" can have a third distinct meaning. Example: imagine an OPTIONAL field where "NULL" represents a status value of some sort. In that case an absent field would indicate no status available while a NULL would indicate a specific status. So in general changing ASN1_TYPE_cmp in the proposed fashion is not a good idea. Yes I see your point, and I agree with you. In general it isn?t a good idea to change ASN1_TYPE_cmp(). That means my patch isn?t good as is, and should be re-worked. > In the very specific case of a certificate and certain digest algorithms absent and NULL do have the same meaning. Exactly. I understand you as stating that a patch like what I?m proposing should be limited to this specific narrow case. > It seems odd that an implementation having decided it should represent an algorithm in one way for one field should then decide to represent an identical algorithm in a different way for another. Yes it is very odd, and I can only speculate as to how that implementation came about to doing that weird and strange thing. But it is not illegal, because both representations are legal, and there is no explicit requirement to stick with one representation, and no prohibition to mix representations. I?m not saying that it makes sense to do so, merely that (a) it appears legal, and (b) it has already been implemented and deployed by a big vendor - this is not just a theoretical discussion. > This specific case rejects a certificate where the two AlgorithmIdentifier values in the certificate (signature and signatureAlgorithm) do not match. Since such a ?mixed? representation is legal, according to the definition of that specific object AlgorithmIdentifier, these two do match. Therefore, I think rejecting such a certificate is wrong, and a workaround is necessary. Such a workaround - if correctly implemented - will not detract from OpenSSL security, and will ensure that corner cases are handled correctly (even if we don?t love corner cases very much). Thanks! -- Uri Blumenthal uri at mit.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1842 bytes Desc: not available URL: From rt at openssl.org Tue Jan 20 03:15:32 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Tue, 20 Jan 2015 04:15:32 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: References: <874mroxhbk.fsf@alice.fifthhorseman.net><20150118161613.GA12056@roeckx.be><6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> <54BD1EFE.4050201@comodo.com> Message-ID: Also, the way I read the current code (crypto/asn1/a_type.c, line 120 - it would (incorrectly) reject a certificate where both algorithms are encoded with absent parameter lists: if (!a || !b || a->type != b->type) return -1; I think we all agree that such a certificate would be valid/legal? -- Uri Blumenthal uri at mit.edu From rt at openssl.org Tue Jan 20 11:04:15 2015 From: rt at openssl.org (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JrQvtC80L3QuNC9?= via RT) Date: Tue, 20 Jan 2015 12:04:15 +0100 Subject: [openssl-dev] [openssl.org #3628] In-Reply-To: References: Message-ID: Greetings, I wonder have you refused the patch or it will be applied? Thanks, Alex Komnin. 2014-12-10 23:35 GMT+03:00 The default queue via RT : > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "[PATCH] NDEBUG macro and redundant strings", > 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 #3628]. > > Please include the string: > > [openssl.org #3628] > > 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 > > ------------------------------------------------------------------------- > During the development process we found that libcrypto contains a lot of > redundant strings in the final binary even when it was built with Debugging > turned off. These strings undesirably reveal absolute paths to the source > files of libcrypto. The paths usually contain private information, e.g. > "/Users/john.johnson/Projects/libssl/crypto/evp/encode.c". > > That happens because several macros, like OPENSSL_malloc(), > OPENSSL_assert() etc., > pass __FILE__ as an operand to the underlying routines. > > I'd like to propose a new macro, NDEBUG, which turns on/off passing > __FILE__ as > an argument. > > Thanks, > Alex Komnin. > From rt at openssl.org Tue Jan 20 14:02:25 2015 From: rt at openssl.org (Billy Brumley via RT) Date: Tue, 20 Jan 2015 15:02:25 +0100 Subject: [openssl-dev] [openssl.org #3667] [PATCH] Faster GLV elliptic curves In-Reply-To: References: Message-ID: This patch gives about 50% speed improvement for existing GLV elliptic curves in OpenSSL. Read about it here: http://eprint.iacr.org/2015/036 It could use a review. Perhaps the best known use case for secp256k1 right now is Bitcoin. BBB Before: op op/s 160 bit ecdh (secp160r1) 0.0001s 6730.6 192 bit ecdh (nistp192) 0.0002s 5714.8 224 bit ecdh (nistp224) 0.0002s 4153.6 256 bit ecdh (nistp256) 0.0003s 3573.1 160 bit ecdh (secp160k1) 0.0002s 6198.2 192 bit ecdh (secp192k1) 0.0002s 5191.9 224 bit ecdh (secp224k1) 0.0003s 3789.3 256 bit ecdh (secp256k1) 0.0003s 3281.2 sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19289.6 5581.5 192 bit ecdsa (nistp192) 0.0001s 0.0002s 16011.7 4650.7 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12987.1 3378.2 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11061.8 2913.0 160 bit ecdsa (secp160k1) 0.0001s 0.0002s 18946.5 5290.5 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15605.9 4289.9 224 bit ecdsa (secp224k1) 0.0001s 0.0003s 12752.6 3145.9 256 bit ecdsa (secp256k1) 0.0001s 0.0004s 10803.0 2733.2 After: op op/s 160 bit ecdh (secp160r1) 0.0001s 6798.4 192 bit ecdh (nistp192) 0.0002s 5667.2 224 bit ecdh (nistp224) 0.0002s 4081.5 256 bit ecdh (nistp256) 0.0003s 3578.9 160 bit ecdh (secp160k1) 0.0001s 9102.5 192 bit ecdh (secp192k1) 0.0001s 7784.3 224 bit ecdh (secp224k1) 0.0002s 5554.4 256 bit ecdh (secp256k1) 0.0002s 4890.4 sign verify sign/s verify/s 160 bit ecdsa (secp160r1) 0.0001s 0.0002s 19264.6 5416.7 192 bit ecdsa (nistp192) 0.0001s 0.0002s 15956.0 4723.1 224 bit ecdsa (nistp224) 0.0001s 0.0003s 12855.8 3379.9 256 bit ecdsa (nistp256) 0.0001s 0.0003s 11017.8 2911.7 160 bit ecdsa (secp160k1) 0.0001s 0.0001s 18959.9 6705.4 192 bit ecdsa (secp192k1) 0.0001s 0.0002s 15624.0 5681.4 224 bit ecdsa (secp224k1) 0.0001s 0.0002s 12513.0 4189.3 256 bit ecdsa (secp256k1) 0.0001s 0.0003s 10621.2 3569.8 $ 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 : 6384.88 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: SNIP -------------- next part -------------- diff -ru --new-file openssl-1.0.1l-orig/apps/speed.c openssl-1.0.1l/apps/speed.c --- openssl-1.0.1l-orig/apps/speed.c 2015-01-15 16:43:49.000000000 +0200 +++ openssl-1.0.1l/apps/speed.c 2015-01-19 13:44:38.232456333 +0200 @@ -244,7 +244,7 @@ #define RSA_NUM 4 #define DSA_NUM 3 -#define EC_NUM 16 +#define EC_NUM 8 #define MAX_ECDH_SIZE 256 static const char *names[ALGOR_NUM]={ @@ -512,18 +512,10 @@ #define R_EC_P192 1 #define R_EC_P224 2 #define R_EC_P256 3 -#define R_EC_P384 4 -#define R_EC_P521 5 -#define R_EC_K163 6 -#define R_EC_K233 7 -#define R_EC_K283 8 -#define R_EC_K409 9 -#define R_EC_K571 10 -#define R_EC_B163 11 -#define R_EC_B233 12 -#define R_EC_B283 13 -#define R_EC_B409 14 -#define R_EC_B571 15 +#define R_EC_K160 4 +#define R_EC_K192 5 +#define R_EC_K224 6 +#define R_EC_K256 7 #ifndef OPENSSL_NO_RSA RSA *rsa_key[RSA_NUM]; @@ -553,19 +545,10 @@ NID_X9_62_prime192v1, NID_secp224r1, NID_X9_62_prime256v1, - NID_secp384r1, - NID_secp521r1, - /* Binary Curves */ - NID_sect163k1, - NID_sect233k1, - NID_sect283k1, - NID_sect409k1, - NID_sect571k1, - NID_sect163r2, - NID_sect233r1, - NID_sect283r1, - NID_sect409r1, - NID_sect571r1 + NID_secp160k1, + NID_secp192k1, + NID_secp224k1, + NID_secp256k1 }; static const char * test_curves_names[EC_NUM] = { @@ -574,25 +557,15 @@ "nistp192", "nistp224", "nistp256", - "nistp384", - "nistp521", - /* Binary Curves */ - "nistk163", - "nistk233", - "nistk283", - "nistk409", - "nistk571", - "nistb163", - "nistb233", - "nistb283", - "nistb409", - "nistb571" + "secp160k1", + "secp192k1", + "secp224k1", + "secp256k1" }; static int test_curves_bits[EC_NUM] = { - 160, 192, 224, 256, 384, 521, - 163, 233, 283, 409, 571, - 163, 233, 283, 409, 571 + 160, 192, 224, 256, + 160, 192, 224, 256 }; #endif @@ -962,18 +935,10 @@ else if (strcmp(*argv,"ecdsap192") == 0) ecdsa_doit[R_EC_P192]=2; else if (strcmp(*argv,"ecdsap224") == 0) ecdsa_doit[R_EC_P224]=2; else if (strcmp(*argv,"ecdsap256") == 0) ecdsa_doit[R_EC_P256]=2; - else if (strcmp(*argv,"ecdsap384") == 0) ecdsa_doit[R_EC_P384]=2; - else if (strcmp(*argv,"ecdsap521") == 0) ecdsa_doit[R_EC_P521]=2; - else if (strcmp(*argv,"ecdsak163") == 0) ecdsa_doit[R_EC_K163]=2; - else if (strcmp(*argv,"ecdsak233") == 0) ecdsa_doit[R_EC_K233]=2; - else if (strcmp(*argv,"ecdsak283") == 0) ecdsa_doit[R_EC_K283]=2; - else if (strcmp(*argv,"ecdsak409") == 0) ecdsa_doit[R_EC_K409]=2; - else if (strcmp(*argv,"ecdsak571") == 0) ecdsa_doit[R_EC_K571]=2; - else if (strcmp(*argv,"ecdsab163") == 0) ecdsa_doit[R_EC_B163]=2; - else if (strcmp(*argv,"ecdsab233") == 0) ecdsa_doit[R_EC_B233]=2; - else if (strcmp(*argv,"ecdsab283") == 0) ecdsa_doit[R_EC_B283]=2; - else if (strcmp(*argv,"ecdsab409") == 0) ecdsa_doit[R_EC_B409]=2; - else if (strcmp(*argv,"ecdsab571") == 0) ecdsa_doit[R_EC_B571]=2; + else if (strcmp(*argv,"ecdsak160") == 0) ecdsa_doit[R_EC_K160]=2; + else if (strcmp(*argv,"ecdsak192") == 0) ecdsa_doit[R_EC_K192]=2; + else if (strcmp(*argv,"ecdsak224") == 0) ecdsa_doit[R_EC_K224]=2; + else if (strcmp(*argv,"ecdsak256") == 0) ecdsa_doit[R_EC_K256]=2; else if (strcmp(*argv,"ecdsa") == 0) { for (i=0; i < EC_NUM; i++) @@ -986,18 +951,10 @@ else if (strcmp(*argv,"ecdhp192") == 0) ecdh_doit[R_EC_P192]=2; else if (strcmp(*argv,"ecdhp224") == 0) ecdh_doit[R_EC_P224]=2; else if (strcmp(*argv,"ecdhp256") == 0) ecdh_doit[R_EC_P256]=2; - else if (strcmp(*argv,"ecdhp384") == 0) ecdh_doit[R_EC_P384]=2; - else if (strcmp(*argv,"ecdhp521") == 0) ecdh_doit[R_EC_P521]=2; - else if (strcmp(*argv,"ecdhk163") == 0) ecdh_doit[R_EC_K163]=2; - else if (strcmp(*argv,"ecdhk233") == 0) ecdh_doit[R_EC_K233]=2; - else if (strcmp(*argv,"ecdhk283") == 0) ecdh_doit[R_EC_K283]=2; - else if (strcmp(*argv,"ecdhk409") == 0) ecdh_doit[R_EC_K409]=2; - else if (strcmp(*argv,"ecdhk571") == 0) ecdh_doit[R_EC_K571]=2; - else if (strcmp(*argv,"ecdhb163") == 0) ecdh_doit[R_EC_B163]=2; - else if (strcmp(*argv,"ecdhb233") == 0) ecdh_doit[R_EC_B233]=2; - else if (strcmp(*argv,"ecdhb283") == 0) ecdh_doit[R_EC_B283]=2; - else if (strcmp(*argv,"ecdhb409") == 0) ecdh_doit[R_EC_B409]=2; - else if (strcmp(*argv,"ecdhb571") == 0) ecdh_doit[R_EC_B571]=2; + else if (strcmp(*argv,"ecdhk160") == 0) ecdh_doit[R_EC_K160]=2; + else if (strcmp(*argv,"ecdhk192") == 0) ecdh_doit[R_EC_K192]=2; + else if (strcmp(*argv,"ecdhk224") == 0) ecdh_doit[R_EC_K224]=2; + else if (strcmp(*argv,"ecdhk256") == 0) ecdh_doit[R_EC_K256]=2; else if (strcmp(*argv,"ecdh") == 0) { for (i=0; i < EC_NUM; i++) diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ec_curve.c openssl-1.0.1l/crypto/ec/ec_curve.c --- openssl-1.0.1l-orig/crypto/ec/ec_curve.c 2015-01-15 16:43:49.000000000 +0200 +++ openssl-1.0.1l/crypto/ec/ec_curve.c 2015-01-19 13:43:51.375897173 +0200 @@ -1836,18 +1836,18 @@ { NID_secp112r2, &_EC_SECG_PRIME_112R2.h, 0, "SECG curve over a 112 bit prime field" }, { NID_secp128r1, &_EC_SECG_PRIME_128R1.h, 0, "SECG curve over a 128 bit prime field" }, { NID_secp128r2, &_EC_SECG_PRIME_128R2.h, 0, "SECG curve over a 128 bit prime field" }, - { NID_secp160k1, &_EC_SECG_PRIME_160K1.h, 0, "SECG curve over a 160 bit prime field" }, + { NID_secp160k1, &_EC_SECG_PRIME_160K1.h, EC_GFp_glv_method, "SECG curve over a 160 bit prime field" }, { NID_secp160r1, &_EC_SECG_PRIME_160R1.h, 0, "SECG curve over a 160 bit prime field" }, { NID_secp160r2, &_EC_SECG_PRIME_160R2.h, 0, "SECG/WTLS curve over a 160 bit prime field" }, /* SECG secp192r1 is the same as X9.62 prime192v1 and hence omitted */ - { NID_secp192k1, &_EC_SECG_PRIME_192K1.h, 0, "SECG curve over a 192 bit prime field" }, - { NID_secp224k1, &_EC_SECG_PRIME_224K1.h, 0, "SECG curve over a 224 bit prime field" }, + { NID_secp192k1, &_EC_SECG_PRIME_192K1.h, EC_GFp_glv_method, "SECG curve over a 192 bit prime field" }, + { NID_secp224k1, &_EC_SECG_PRIME_224K1.h, EC_GFp_glv_method, "SECG curve over a 224 bit prime field" }, #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128 { NID_secp224r1, &_EC_NIST_PRIME_224.h, EC_GFp_nistp224_method, "NIST/SECG curve over a 224 bit prime field" }, #else { NID_secp224r1, &_EC_NIST_PRIME_224.h, 0, "NIST/SECG curve over a 224 bit prime field" }, #endif - { NID_secp256k1, &_EC_SECG_PRIME_256K1.h, 0, "SECG curve over a 256 bit prime field" }, + { NID_secp256k1, &_EC_SECG_PRIME_256K1.h, EC_GFp_glv_method, "SECG curve over a 256 bit prime field" }, /* SECG secp256r1 is the same as X9.62 prime256v1 and hence omitted */ { NID_secp384r1, &_EC_NIST_PRIME_384.h, 0, "NIST/SECG curve over a 384 bit prime field" }, #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128 diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ec.h openssl-1.0.1l/crypto/ec/ec.h --- openssl-1.0.1l-orig/crypto/ec/ec.h 2015-01-15 16:43:49.000000000 +0200 +++ openssl-1.0.1l/crypto/ec/ec.h 2015-01-19 13:43:50.864153182 +0200 @@ -146,6 +146,11 @@ */ const EC_METHOD *EC_GFp_mont_method(void); +/** Returns GFp methods using optimized methods for GLV curves + * \return EC_METHOD object + */ +const EC_METHOD *EC_GFp_glv_method(void); + /** Returns GFp methods using optimized methods for NIST recommended curves * \return EC_METHOD object */ diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ec_lcl.h openssl-1.0.1l/crypto/ec/ec_lcl.h --- openssl-1.0.1l-orig/crypto/ec/ec_lcl.h 2015-01-15 16:43:49.000000000 +0200 +++ openssl-1.0.1l/crypto/ec/ec_lcl.h 2015-01-19 13:43:51.080045178 +0200 @@ -348,6 +348,13 @@ int ec_GFp_mont_field_set_to_one(const EC_GROUP *, BIGNUM *r, BN_CTX *); +/* method functions in ecp_glv.c */ +int ec_GFp_glv_mul(const EC_GROUP *group, EC_POINT *r, const BIGNUM *scalar, + size_t num, const EC_POINT *points[], const BIGNUM *scalars[], BN_CTX *ctx); +int ec_GFp_glv_precompute_mult(EC_GROUP *group, BN_CTX *ctx); +int ec_GFp_glv_have_precompute_mult(const EC_GROUP *group); + + /* method functions in ecp_nist.c */ int ec_GFp_nist_group_copy(EC_GROUP *dest, const EC_GROUP *src); int ec_GFp_nist_group_set_curve(EC_GROUP *, const BIGNUM *p, const BIGNUM *a, const BIGNUM *b, BN_CTX *); diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/ecp_glv.c openssl-1.0.1l/crypto/ec/ecp_glv.c --- openssl-1.0.1l-orig/crypto/ec/ecp_glv.c 1970-01-01 02:00:00.000000000 +0200 +++ openssl-1.0.1l/crypto/ec/ecp_glv.c 2015-01-20 11:30:44.442723943 +0200 @@ -0,0 +1,336 @@ +#include + +#ifdef OPENSSL_FIPS +#include +#endif + +#include "ec_lcl.h" + +/** + * Faster scalar multiplication for GLV curves: + * http://eprint.iacr.org/2015/036 + * + * @author Billy Brumley + */ + +const EC_METHOD *EC_GFp_glv_method(void) + { + static const EC_METHOD ret = { + EC_FLAGS_DEFAULT_OCT, + NID_X9_62_prime_field, + ec_GFp_mont_group_init, + ec_GFp_mont_group_finish, + ec_GFp_mont_group_clear_finish, + ec_GFp_mont_group_copy, + ec_GFp_mont_group_set_curve, + ec_GFp_simple_group_get_curve, + ec_GFp_simple_group_get_degree, + ec_GFp_simple_group_check_discriminant, + ec_GFp_simple_point_init, + ec_GFp_simple_point_finish, + ec_GFp_simple_point_clear_finish, + ec_GFp_simple_point_copy, + ec_GFp_simple_point_set_to_infinity, + ec_GFp_simple_set_Jprojective_coordinates_GFp, + ec_GFp_simple_get_Jprojective_coordinates_GFp, + ec_GFp_simple_point_set_affine_coordinates, + ec_GFp_simple_point_get_affine_coordinates, + 0,0,0, + ec_GFp_simple_add, + ec_GFp_simple_dbl, + ec_GFp_simple_invert, + ec_GFp_simple_is_at_infinity, + ec_GFp_simple_is_on_curve, + ec_GFp_simple_cmp, + ec_GFp_simple_make_affine, + ec_GFp_simple_points_make_affine, + ec_GFp_glv_mul, + ec_GFp_glv_precompute_mult, + ec_GFp_glv_have_precompute_mult, + ec_GFp_mont_field_mul, + ec_GFp_mont_field_sqr, + 0 /* field_div */, + ec_GFp_mont_field_encode, + ec_GFp_mont_field_decode, + ec_GFp_mont_field_set_to_one }; + +#ifdef OPENSSL_FIPS + if (FIPS_mode()) + return fips_ec_gfp_glv_method(); +#endif + + return &ret; + } + +/* GLV-related per-curve constants */ +static const unsigned char glv_constants_secp160k1[] = { + /* beta */ + 0x9b,0xa4,0x8c,0xba,0x5e,0xbc,0xb9,0xb6, + 0xbd,0x33,0xb9,0x28,0x30,0xb2,0xa2,0xe0, + 0xe1,0x92,0xf1,0x0a, + /* a1 */ + 0x91,0x62,0xfb,0xe7,0x39,0x84,0x47,0x2a, + 0x0a,0x9e, + /* b1 */ + 0x96,0x34,0x1f,0x11,0x38,0x93,0x3b,0xc2, + 0xf5,0x05, + /* a2 */ + 0x01,0x27,0x97,0x1a,0xf8,0x72,0x17,0x82, + 0xec,0xff,0xa3, + /* b2 */ + 0x91,0x62,0xfb,0xe7,0x39,0x84,0x47,0x2a, + 0x0a,0x9e +}; + +static const unsigned char glv_constants_secp192k1[] = { + /* beta */ + 0xbb,0x85,0x69,0x19,0x39,0xb8,0x69,0xc1, + 0xd0,0x87,0xf6,0x01,0x55,0x4b,0x96,0xb8, + 0x0c,0xb4,0xf5,0x5b,0x35,0xf4,0x33,0xc2, + /* a1 */ + 0x71,0x16,0x9b,0xe7,0x33,0x0b,0x30,0x38, + 0xed,0xb0,0x25,0xf1, + /* b1 */ + 0xb3,0xfb,0x34,0x00,0xde,0xc5,0xc4,0xad, + 0xce,0xb8,0x65,0x5c, + /* a2 */ + 0x01,0x25,0x11,0xcf,0xe8,0x11,0xd0,0xf4, + 0xe6,0xbc,0x68,0x8b,0x4d, + /* b2 */ + 0x71,0x16,0x9b,0xe7,0x33,0x0b,0x30,0x38, + 0xed,0xb0,0x25,0xf1 +}; + +static const unsigned char glv_constants_secp224k1[] = { + /* beta */ + 0x01,0xf1,0x78,0xff,0xa4,0xb1,0x7c,0x89, + 0xe6,0xf7,0x3a,0xec,0xe2,0xaa,0xd5,0x7a, + 0xf4,0xc0,0xa7,0x48,0xb6,0x3c,0x83,0x09, + 0x47,0xb2,0x7e,0x04, + /* a1 */ + 0xb8,0xad,0xf1,0x37,0x8a,0x6e,0xb7,0x34, + 0x09,0xfa,0x6c,0x9c,0x63,0x7d, + /* b1 */ + 0x6b,0x8c,0xf0,0x7d,0x4c,0xa7,0x5c,0x88, + 0x95,0x7d,0x9d,0x67,0x05,0x91, + /* a2 */ + 0x6b,0x8c,0xf0,0x7d,0x4c,0xa7,0x5c,0x88, + 0x95,0x7d,0x9d,0x67,0x05,0x91, + /* b2 */ + 0x01,0x24,0x3a,0xe1,0xb4,0xd7,0x16,0x13, + 0xbc,0x9f,0x78,0x0a,0x03,0x69,0x0e +}; + +static const unsigned char glv_constants_secp256k1[] = { + /* beta */ + 0x85,0x16,0x95,0xd4,0x9a,0x83,0xf8,0xef, + 0x91,0x9b,0xb8,0x61,0x53,0xcb,0xcb,0x16, + 0x63,0x0f,0xb6,0x8a,0xed,0x0a,0x76,0x6a, + 0x3e,0xc6,0x93,0xd6,0x8e,0x6a,0xfa,0x40, + /* a1 */ + 0xe4,0x43,0x7e,0xd6,0x01,0x0e,0x88,0x28, + 0x6f,0x54,0x7f,0xa9,0x0a,0xbf,0xe4,0xc3, + /* b1 */ + 0x30,0x86,0xd2,0x21,0xa7,0xd4,0x6b,0xcd, + 0xe8,0x6c,0x90,0xe4,0x92,0x84,0xeb,0x15, + /* a2 */ + 0x30,0x86,0xd2,0x21,0xa7,0xd4,0x6b,0xcd, + 0xe8,0x6c,0x90,0xe4,0x92,0x84,0xeb,0x15, + /* b2 */ + 0x01,0x14,0xca,0x50,0xf7,0xa8,0xe2,0xf3, + 0xf6,0x57,0xc1,0x10,0x8d,0x9d,0x44,0xcf, + 0xd8 +}; + +/** + * Integer decomposition. + * See 3.5 in "Guide to Elliptic Curve Cryptography" + * + * The alg is slightly re-arranged to keep all constants positive + * + * n = constants[0] + * a1 = constants[2] + * b1 = constants[3] + * a2 = constants[4] + * b2 = constants[5] + */ +int ec_GFp_glv_decompose(BIGNUM *k1, BIGNUM *k2, const BIGNUM *scalar, const BIGNUM **constants, BN_CTX *ctx) { + + int ret = 0; + + BIGNUM *twok, *c1, *c2; + + BN_CTX_start(ctx); + + do { + twok = BN_CTX_get(ctx); + c1 = BN_CTX_get(ctx); + if ((c2 = BN_CTX_get(ctx)) == NULL) break; + + if (!BN_lshift1(twok, scalar)) break; + + /* weird computation is for closest int rounding */ + /* c1 = (2*b2*k+r[0])/(2*r[0]) */ + /* c2 = (2*b1*k+r[0])/(2*r[0]) */ + if (!BN_mul(c1, twok, constants[5], ctx)) break; + if (!BN_add(c1, c1, constants[0])) break; + if (!BN_div(c1, NULL, c1, constants[0], ctx)) break; + if (!BN_rshift1(c1, c1)) break; + if (!BN_mul(c2, twok, constants[3], ctx)) break; + if (!BN_add(c2, c2, constants[0])) break; + if (!BN_div(c2, NULL, c2, constants[0], ctx)) break; + if (!BN_rshift1(c2, c2)) break; + + /* k1 = k - (c1*a1 + c2*a2) */ + /* k2 = c1*b1 - c2*b2 */ + if (!BN_mul(k1, constants[2], c1, ctx)) break; + if (!BN_mul(k2, constants[4], c2, ctx)) break; + if (!BN_add(k1, k1, k2)) break; + if (!BN_sub(k1, scalar, k1)) break; + if (!BN_mul(c1, constants[3], c1, ctx)) break; + if (!BN_mul(c2, constants[5], c2, ctx)) break; + if (!BN_sub(k2, c1, c2)) break; + + ret = 1; + } while(0); + + BN_CTX_end(ctx); + + return ret; + +} + +/** + * Computes the sum + * scalar*group->generator + scalars[0]*points[0] + ... + scalars[num-1]*points[num-1] + */ +int ec_GFp_glv_mul(const EC_GROUP *group, EC_POINT *r, const BIGNUM *scalar, + size_t num, const EC_POINT *points[], const BIGNUM *scalars[], BN_CTX *ctx) + { + + /* use default stuff if we have precomp and it can help */ + if(num == 0 && EC_GROUP_have_precompute_mult(group)) + return ec_wNAF_mul(group, r, scalar, num, points, scalars, ctx); + + int i, ret = 0; + + BIGNUM *tscalar = NULL; + EC_POINT **tpoints = NULL; + BIGNUM **tscalars = NULL; + BIGNUM **constants = NULL; + + if ((constants = OPENSSL_malloc(6*sizeof(BIGNUM *))) == NULL) return 0; + + BN_CTX_start(ctx); + + /* fill in the constants */ + for(i=0; i<6; i++) { + constants[i] = BN_CTX_get(ctx); + } + + if(constants[5] == NULL) goto err; + + if (!EC_GROUP_get_order(group, constants[0], ctx)) goto err; + + switch(EC_GROUP_get_curve_name(group)) { + case NID_secp160k1: + BN_bin2bn(glv_constants_secp160k1 + 0, 20, constants[1]); + BN_bin2bn(glv_constants_secp160k1 + 20, 10, constants[2]); + BN_bin2bn(glv_constants_secp160k1 + 30, 10, constants[3]); + BN_bin2bn(glv_constants_secp160k1 + 40, 11, constants[4]); + BN_bin2bn(glv_constants_secp160k1 + 51, 10, constants[5]); + break; + case NID_secp192k1: + BN_bin2bn(glv_constants_secp192k1 + 0, 24, constants[1]); + BN_bin2bn(glv_constants_secp192k1 + 24, 12, constants[2]); + BN_bin2bn(glv_constants_secp192k1 + 36, 12, constants[3]); + BN_bin2bn(glv_constants_secp192k1 + 48, 13, constants[4]); + BN_bin2bn(glv_constants_secp192k1 + 61, 12, constants[5]); + break; + case NID_secp224k1: + BN_bin2bn(glv_constants_secp224k1 + 0, 28, constants[1]); + BN_bin2bn(glv_constants_secp224k1 + 28, 14, constants[2]); + BN_bin2bn(glv_constants_secp224k1 + 42, 14, constants[3]); + BN_bin2bn(glv_constants_secp224k1 + 56, 14, constants[4]); + BN_bin2bn(glv_constants_secp224k1 + 70, 15, constants[5]); + break; + case NID_secp256k1: + BN_bin2bn(glv_constants_secp256k1 + 0, 32, constants[1]); + BN_bin2bn(glv_constants_secp256k1 + 32, 16, constants[2]); + BN_bin2bn(glv_constants_secp256k1 + 48, 16, constants[3]); + BN_bin2bn(glv_constants_secp256k1 + 64, 16, constants[4]); + BN_bin2bn(glv_constants_secp256k1 + 80, 17, constants[5]); + break; + default: + goto err; + } + + /* encode beta parameter to curve's finite field */ + if (!group->meth->field_encode(group, constants[1], constants[1], ctx)) goto err; + + /* setup some arrays and decompose scalar if it's present and apply endomorphism */ + if(scalar == NULL) { + if ((tpoints = OPENSSL_malloc(2 * num * sizeof(EC_POINT *))) == NULL) goto err; + if ((tscalars = OPENSSL_malloc(2 * num * sizeof(BIGNUM *))) == NULL) goto err; + } + else { + if ((tpoints = OPENSSL_malloc((2 * num + 1) * sizeof(EC_POINT *))) == NULL) goto err; + if ((tscalars = OPENSSL_malloc((2 * num + 1) * sizeof(BIGNUM *))) == NULL) goto err; + tscalar = BN_CTX_get(ctx); + if ((tscalars[2*num] = BN_CTX_get(ctx)) == NULL) goto err; + if ((tpoints[2*num] = EC_POINT_new(group)) == NULL) goto err; + if (!EC_POINT_copy(tpoints[2*num], EC_GROUP_get0_generator(group))) goto err; + if (!group->meth->field_mul(group, &tpoints[2*num]->X, &tpoints[2*num]->X, constants[1], ctx)) goto err; + if (!ec_GFp_glv_decompose(tscalar, tscalars[2*num], scalar, (const BIGNUM **)constants, ctx)) goto err; + } + + /* decompose all the other scalars and apply the endomorphism */ + for(i=0; i < num; i++) { + tpoints[2*i ] = *((EC_POINT **)points + 2*i); + if ((tpoints[2*i+1] = EC_POINT_new(group)) == NULL) goto err; + if (!EC_POINT_copy(tpoints[2*i+1], tpoints[2*i])) goto err; + if (!group->meth->field_mul(group, &tpoints[2*i+1]->X, &tpoints[2*i+1]->X, constants[1], ctx)) goto err; + tscalars[2*i ] = BN_CTX_get(ctx); + if ((tscalars[2*i+1] = BN_CTX_get(ctx)) == NULL) goto err; + if (!ec_GFp_glv_decompose(tscalars[2*i], tscalars[2*i+1], scalars[i], (const BIGNUM **)constants, ctx)) goto err; + } + + /* call into the multi scalar mult routine with new parameters */ + if(scalar == NULL) { + ret = ec_wNAF_mul(group, r, scalar, 2*num, (const EC_POINT **)tpoints, (const BIGNUM **)tscalars, ctx); + } + else { + ret = ec_wNAF_mul(group, r, tscalar, 2*num+1, (const EC_POINT **)tpoints, (const BIGNUM **)tscalars, ctx); + } + +err: + + /* cleanup */ + if (tpoints != NULL) { + for(i=0; i < num; i++) { + EC_POINT_free(tpoints[2*i+1]); + } + if (scalar != NULL) { + EC_POINT_free(tpoints[2*num]); + } + } + + BN_CTX_end(ctx); + + OPENSSL_free(tpoints); + OPENSSL_free(tscalars); + OPENSSL_free(constants); + + return ret; + } + +int ec_GFp_glv_precompute_mult(EC_GROUP *group, BN_CTX *ctx) + { + return ec_wNAF_precompute_mult(group, ctx); + } + +int ec_GFp_glv_have_precompute_mult(const EC_GROUP *group) + { + return ec_wNAF_have_precompute_mult(group); + } + diff -ru --new-file openssl-1.0.1l-orig/crypto/ec/Makefile openssl-1.0.1l/crypto/ec/Makefile --- openssl-1.0.1l-orig/crypto/ec/Makefile 2015-01-15 16:45:04.000000000 +0200 +++ openssl-1.0.1l/crypto/ec/Makefile 2015-01-19 13:43:51.239965175 +0200 @@ -17,13 +17,13 @@ APPS= LIB=$(TOP)/libcrypto.a -LIBSRC= ec_lib.c ecp_smpl.c ecp_mont.c ecp_nist.c ec_cvt.c ec_mult.c\ +LIBSRC= ec_lib.c ecp_smpl.c ecp_mont.c ecp_glv.c ecp_nist.c ec_cvt.c ec_mult.c\ ec_err.c ec_curve.c ec_check.c ec_print.c ec_asn1.c ec_key.c\ ec2_smpl.c ec2_mult.c ec_ameth.c ec_pmeth.c eck_prn.c \ ecp_nistp224.c ecp_nistp256.c ecp_nistp521.c ecp_nistputil.c \ ecp_oct.c ec2_oct.c ec_oct.c -LIBOBJ= ec_lib.o ecp_smpl.o ecp_mont.o ecp_nist.o ec_cvt.o ec_mult.o\ +LIBOBJ= ec_lib.o ecp_smpl.o ecp_mont.o ecp_glv.o ecp_nist.o ec_cvt.o ec_mult.o\ ec_err.o ec_curve.o ec_check.o ec_print.o ec_asn1.o ec_key.o\ ec2_smpl.o ec2_mult.o ec_ameth.o ec_pmeth.o eck_prn.o \ ecp_nistp224.o ecp_nistp256.o ecp_nistp521.o ecp_nistputil.o \ @@ -233,6 +233,14 @@ ecp_mont.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h ecp_mont.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h ecp_mont.o: ../../include/openssl/symhacks.h ec_lcl.h ecp_mont.c +ecp_glv.o: ../../include/openssl/asn1.h ../../include/openssl/bio.h +ecp_glv.o: ../../include/openssl/bn.h ../../include/openssl/crypto.h +ecp_glv.o: ../../include/openssl/e_os2.h ../../include/openssl/ec.h +ecp_glv.o: ../../include/openssl/err.h ../../include/openssl/lhash.h +ecp_glv.o: ../../include/openssl/obj_mac.h ../../include/openssl/opensslconf.h +ecp_glv.o: ../../include/openssl/opensslv.h ../../include/openssl/ossl_typ.h +ecp_glv.o: ../../include/openssl/safestack.h ../../include/openssl/stack.h +ecp_glv.o: ../../include/openssl/symhacks.h ec_lcl.h ecp_glv.c ecp_nist.o: ../../include/openssl/asn1.h ../../include/openssl/bio.h ecp_nist.o: ../../include/openssl/bn.h ../../include/openssl/crypto.h ecp_nist.o: ../../include/openssl/e_os2.h ../../include/openssl/ec.h From rt at openssl.org Tue Jan 20 14:02:36 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Tue, 20 Jan 2015 15:02:36 +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: 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 Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-use-the-cert-list-embedded-in-the-OCSP-respons.patch Type: text/x-diff Size: 1052 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ocsp_test.c Type: text/x-csrc Size: 2160 bytes Desc: not available URL: From rt at openssl.org Tue Jan 20 14:42:36 2015 From: rt at openssl.org (Joe Bundley via RT) Date: Tue, 20 Jan 2015 15:42:36 +0100 Subject: [openssl-dev] [openssl.org #3669] Abandoning SSL sockets. In-Reply-To: <160833039.3153565.1421647905696.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> References: <160833039.3153565.1421647905696.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> Message-ID: Spam detection software, running on the system "butler.openssl.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see spam-abuse at openssl.net for details. Content preview: Hello OpenSSL staff. I was wondering if you guys were going to drop SSL and just use TSL or some other advance encryption methods, soon? The reason why I am asking is because SSL 3.0 was proven to be insecure and recommended not to be used anymore. I hope you guys have plans for better sockets.? Fight Malware. Join ClamWin. ClamWin is a free, open-source, anti-virus for Windows users. http://www.clamwin.com/ [...] Content analysis details: (5.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in digit (joe bundley ) 1.6 FORGED_YAHOO_RCVD 'From' yahoo.com does not match 'Received' headers 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4976] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 2.1 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- Hello OpenSSL staff. I was wondering if you guys were going to drop SSL and just use TSL or some other advance encryption methods, soon? The reason why I am asking is because SSL 3.0 was proven to be insecure and recommended not to be used anymore. I hope you guys have plans for better sockets.?---------------------- Fight Malware. Join ClamWin. ClamWin is a free, open-source, anti-virus for Windows users. http://www.clamwin.com/ For Linux and Mac users, join ClamAV to fight malware. http://www.clamav.net/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Jan 20 15:25:12 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 20 Jan 2015 16:25:12 +0100 Subject: [openssl-dev] [openssl.org #3669] Abandoning SSL sockets. In-Reply-To: <160833039.3153565.1421647905696.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> References: <160833039.3153565.1421647905696.JavaMail.yahoo@jws106108.mail.bf1.yahoo.com> Message-ID: We have no plans to completely drop SSLv3. It is possible to compile it out already. And the next version after 1.0.2 will make it easier to specify the protocol versions you want to support, at runtime. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Jan 20 18:55:16 2015 From: rt at openssl.org (Perrow, Graeme via RT) Date: Tue, 20 Jan 2015 19:55:16 +0100 Subject: [openssl-dev] [openssl.org #3670] Bug in str_copy in conf_def.c [PATCH] In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E56CAC584@DEWDFEMB16B.global.corp.sap> References: <6378BFFB8601BD438AD9AF3CA610548E56CAC584@DEWDFEMB16B.global.corp.sap> Message-ID: A scanning tool we use to scan our code for runtime problems such as buffer overruns, possible NULL pointer dereferencing, memory leaks, etc. has found a bug in the str_copy routine in conf_def.c. At line 621 (in 1.0.1k), there is a call to BUF_MEM_grow_clean but the return value is not checked. If that call fails, we continue to use the memory assuming the expansion succeeded and will either dereference NULL (if the buffer was empty to begin with) or likely write off the end of the buffer. I have attached a patch. Graeme Perrow -------------- next part -------------- A non-text attachment was scrubbed... Name: str_cpy.patch Type: application/octet-stream Size: 542 bytes Desc: not available URL: From rt at openssl.org Tue Jan 20 18:55:45 2015 From: rt at openssl.org (Perrow, Graeme via RT) Date: Tue, 20 Jan 2015 19:55:45 +0100 Subject: [openssl-dev] [openssl.org #3671] Bug in TS_check_status_info in ts_rsp_verify.c [PATCH] In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E56CAC667@DEWDFEMB16B.global.corp.sap> References: <6378BFFB8601BD438AD9AF3CA610548E56CAC667@DEWDFEMB16B.global.corp.sap> Message-ID: Our code-scanning tool has found another bug in OpenSSl 1.0.1k. In TS_check_status_info (in crypto/ts/ts_rsp_verify.c), if an error occurs we create a string which is intended to be a comma-separated list of error strings. However when adding the comma between error strings, strcpy is used rather than strcat. This means that if more than one error bit is set, the resulting string will be ",x" where x is the text associated with the LAST error; all other errors will be overwritten. My guess is that having multiple failures is very rare, so very few people have run into this problem. I have attached a patch. Graeme Perrow -------------- next part -------------- A non-text attachment was scrubbed... Name: ts_check_status_info.patch Type: application/octet-stream Size: 489 bytes Desc: not available URL: From rsalz at akamai.com Tue Jan 20 21:44:09 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Jan 2015 21:44:09 +0000 Subject: [openssl-dev] OPENSSL_NO_SHA is still useful? In-Reply-To: <54ABC583.1040406@teletu.it> References: <54ABC583.1040406@teletu.it> Message-ID: <48982302947e4bdca06e47911dfd3add@usma1ex-dag1mb2.msg.corp.akamai.com> > you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA > and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and > other similar) that compiling with -DOPENSSL_NO_SHA gives an endless > series of errors and warnings. Right, it's not useful. We're looking at cleaning up a whole bunch of OPENSSL_NO_xxx options that don't really work. Details to come. From richmoore44 at gmail.com Tue Jan 20 23:00:34 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 20 Jan 2015 23:00:34 +0000 Subject: [openssl-dev] OPENSSL_NO_SHA is still useful? In-Reply-To: <48982302947e4bdca06e47911dfd3add@usma1ex-dag1mb2.msg.corp.akamai.com> References: <54ABC583.1040406@teletu.it> <48982302947e4bdca06e47911dfd3add@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 20 January 2015 at 21:44, Salz, Rich wrote: > > you think is still necessary to leave in the code #ifndef OPENSSL_NO_SHA > > and #ifdef OPENSSL_NO_SHA are so many function calls EVP_sha1() (and > > other similar) that compiling with -DOPENSSL_NO_SHA gives an endless > > series of errors and warnings. > > Right, it's not useful. We're looking at cleaning up a whole bunch of > OPENSSL_NO_xxx options that don't really work. Details to come. > If you're going to change this, then perhaps at the same time as changing the API these could be inverted so we have defines that say what /is/ enabled since that's probably a better design overall. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Jan 20 23:05:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Jan 2015 23:05:46 +0000 Subject: [openssl-dev] OPENSSL_NO_SHA is still useful? In-Reply-To: References: <54ABC583.1040406@teletu.it> <48982302947e4bdca06e47911dfd3add@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <7652e5d7b91944c297751da89c8442ab@usma1ex-dag1mb2.msg.corp.akamai.com> > If you're going to change this, then perhaps at the same time as changing the API these could be inverted so we have defines that say what /is/ enabled since that's probably a better design overall. The key word being "probably" There is something to be said for the idea that new features are enabled by default. Not clear we'll change it, but it is under consideration. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From rt at openssl.org Wed Jan 21 04:18:09 2015 From: rt at openssl.org (Uri Blumenthal via RT) Date: Wed, 21 Jan 2015 05:18:09 +0100 Subject: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k) In-Reply-To: <787BC417-6D16-4AD3-9449-83859E56C1DD@mit.edu> References: <874mroxhbk.fsf@alice.fifthhorseman.net><20150118161613.GA12056@roeckx.be><6F06A414-7B04-4E9A-A453-047E84BDB549@mit.edu> <54BD1EFE.4050201@comodo.com> <787BC417-6D16-4AD3-9449-83859E56C1DD@mit.edu> Message-ID: Steve Henson correctly pointed out that to change ASN1_TYPE_cmp() may not be appropriate, as there could be cases when null pointer (absent list) means something different from list being NULL. To address that concern, I've made sure the workaround applies only to the case when two algorithms are compared, based on RFC 5754 and 5280 that state that AlgorithmIdentifier parameter list can be absent or represented as ASN.1 NULL - and implementations MUST accept both cases. This patch also addresses the case when ASN1_TYPE_cmp(a, b) is called with a == b == NULL. Current implementation thinks that 0 != 0, which is not correct. Please find attached my updated patch "patch-null-absent.diff?: --- crypto/asn1/a_type.c.~1~ 2015-01-15 09:43:14.000000000 -0500 +++ crypto/asn1/a_type.c 2015-01-20 22:57:48.000000000 -0500 @@ -117,6 +117,8 @@ { int result = -1; + if (!a && !b) return 0; /* both null-pointers => both absent/equal */ + if (!a || !b || a->type != b->type) return -1; switch (a->type) --- crypto/asn1/x_algor.c.~1~ 2015-01-15 09:43:14.000000000 -0500 +++ crypto/asn1/x_algor.c 2015-01-20 23:00:54.000000000 -0500 @@ -151,5 +151,12 @@ return rv; if (!a->parameter && !b->parameter) return 0; + if ((!a->parameter && b->parameter + && b->parameter->type == V_ASN1_NULL) + || + (!b->parameter && a->parameter + && a->parameter->type == V_ASN1_NULL) + ) + return 0; return ASN1_TYPE_cmp(a->parameter, b->parameter); } -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-null-absent.diff Type: application/octet-stream Size: 809 bytes Desc: not available URL: From rt at openssl.org Thu Jan 22 21:47:14 2015 From: rt at openssl.org (xxkkpp@foxmail.com via RT) Date: Thu, 22 Jan 2015 22:47:14 +0100 Subject: [openssl-dev] [openssl.org #3672] About bug processing talked in your article In-Reply-To: <332806168.48666.1421912397185.JavaMail.administrator@mtom.nabble.com> References: <332806168.48666.1421912397185.JavaMail.administrator@mtom.nabble.com> Message-ID: Hi , I am sorry to disturb you , but I do hope get some help from you ..... I read article in http://openssl.6102.n7.nabble.com/openssl-org-3592-bug-report-Crash-Critical-Security-bug-td55139i20.html And I hit the same problem with my Asterisk11+OpenSSL 1.0.1 .... If there any progress in your reseach and can share with me the solution? Thanks in advance. _____________________________________ Sent from http://openssl.6102.n7.nabble.com From rt at openssl.org Thu Jan 22 21:48:19 2015 From: rt at openssl.org (Shane Brewer via RT) Date: Thu, 22 Jan 2015 22:48:19 +0100 Subject: [openssl-dev] [openssl.org #3673] openssl-1.0.2 build error In-Reply-To: References: Message-ID: Checking compiler... Running make... make[1]: Entering directory '/tmp/openssl-1.0.2' making all in crypto... make[2]: Entering directory '/tmp/openssl-1.0.2/crypto' making all in crypto/objects... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/objects' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/objects' making all in crypto/md2... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/md2' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/md2' making all in crypto/md4... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/md4' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/md4' making all in crypto/md5... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/md5' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/md5' making all in crypto/sha... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/sha' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/sha' making all in crypto/mdc2... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/mdc2' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/mdc2' making all in crypto/hmac... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/hmac' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/hmac' making all in crypto/ripemd... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ripemd' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ripemd' making all in crypto/whrlpool... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/whrlpool' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/whrlpool' making all in crypto/des... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/des' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/des' making all in crypto/aes... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/aes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/aes' making all in crypto/rc2... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/rc2' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/rc2' making all in crypto/rc4... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/rc4' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/rc4' making all in crypto/idea... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/idea' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/idea' making all in crypto/bf... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/bf' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/bf' making all in crypto/cast... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/cast' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/cast' making all in crypto/camellia... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/camellia' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/camellia' making all in crypto/seed... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/seed' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/seed' making all in crypto/modes... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/modes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/modes' making all in crypto/bn... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/bn' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/bn' making all in crypto/ec... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ec' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ec' making all in crypto/rsa... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/rsa' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/rsa' making all in crypto/dsa... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/dsa' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/dsa' making all in crypto/ecdsa... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ecdsa' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ecdsa' making all in crypto/dh... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/dh' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/dh' making all in crypto/ecdh... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ecdh' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ecdh' making all in crypto/dso... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/dso' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/dso' making all in crypto/engine... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/engine' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/engine' making all in crypto/buffer... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/buffer' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/buffer' making all in crypto/bio... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/bio' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/bio' making all in crypto/stack... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/stack' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/stack' making all in crypto/lhash... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/lhash' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/lhash' making all in crypto/rand... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/rand' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/rand' making all in crypto/err... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/err' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/err' making all in crypto/evp... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/evp' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/evp' making all in crypto/asn1... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/asn1' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/asn1' making all in crypto/pem... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/pem' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/pem' making all in crypto/x509... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/x509' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/x509' making all in crypto/x509v3... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/x509v3' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/x509v3' making all in crypto/conf... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/conf' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/conf' making all in crypto/txt_db... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/txt_db' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/txt_db' making all in crypto/pkcs7... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/pkcs7' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/pkcs7' making all in crypto/pkcs12... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/pkcs12' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/pkcs12' making all in crypto/comp... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/comp' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/comp' making all in crypto/ocsp... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ocsp' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ocsp' making all in crypto/ui... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ui' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ui' making all in crypto/krb5... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/krb5' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/krb5' making all in crypto/cms... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/cms' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/cms' making all in crypto/pqueue... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/pqueue' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/pqueue' making all in crypto/ts... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/ts' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/ts' making all in crypto/srp... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/srp' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/srp' making all in crypto/cmac... make[3]: Entering directory '/tmp/openssl-1.0.2/crypto/cmac' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/tmp/openssl-1.0.2/crypto/cmac' if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \ (cd ..; make libcrypto.so.1.0.0); \ fi make[3]: Entering directory '/tmp/openssl-1.0.2' make[4]: Entering directory '/tmp/openssl-1.0.2' make[5]: Entering directory '/tmp/openssl-1.0.2' make[5]: Leaving directory '/tmp/openssl-1.0.2' make[5]: Entering directory '/tmp/openssl-1.0.2' make[5]: Leaving directory '/tmp/openssl-1.0.2' make[4]: Leaving directory '/tmp/openssl-1.0.2' make[3]: Leaving directory '/tmp/openssl-1.0.2' make[2]: Leaving directory '/tmp/openssl-1.0.2/crypto' making all in ssl... make[2]: Entering directory '/tmp/openssl-1.0.2/ssl' gcc -I../crypto -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/tmp/fips-build/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o t1_lib.o t1_lib.c t1_lib.c: In function ?tls1_get_curvelist?: t1_lib.c:473:17: error: invalid type argument of unary ?*? (have ?size_t?) *pcurveslen = sizeof(fips_curves_default); ^ : recipe for target 't1_lib.o' failed make[2]: *** [t1_lib.o] Error 1 make[2]: Leaving directory '/tmp/openssl-1.0.2/ssl' Makefile:281: recipe for target 'build_ssl' failed make[1]: *** [build_ssl] Error 1 make[1]: Leaving directory '/tmp/openssl-1.0.2' Running make test... make[1]: Entering directory '/tmp/openssl-1.0.2' testing... make[2]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' make[3]: Entering directory '/tmp/openssl-1.0.2/test' make[3]: Leaving directory '/tmp/openssl-1.0.2/test' (cd ..; make DIRS=ssl all) make[3]: Entering directory '/tmp/openssl-1.0.2' making all in ssl... make[4]: Entering directory '/tmp/openssl-1.0.2/ssl' gcc -I../crypto -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/tmp/fips-build/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o t1_lib.o t1_lib.c t1_lib.c: In function ?tls1_get_curvelist?: t1_lib.c:473:17: error: invalid type argument of unary ?*? (have ?size_t?) *pcurveslen = sizeof(fips_curves_default); ^ : recipe for target 't1_lib.o' failed make[4]: *** [t1_lib.o] Error 1 make[4]: Leaving directory '/tmp/openssl-1.0.2/ssl' Makefile:281: recipe for target 'build_ssl' failed make[3]: *** [build_ssl] Error 1 make[3]: Leaving directory '/tmp/openssl-1.0.2' Makefile:367: recipe for target '../libssl.a' failed make[2]: *** [../libssl.a] Error 2 make[2]: Leaving directory '/tmp/openssl-1.0.2/test' Makefile:455: recipe for target 'tests' failed make[1]: *** [tests] Error 2 make[1]: Leaving directory '/tmp/openssl-1.0.2' OpenSSL self-test report: OpenSSL version: 1.0.2 Last change: SRTP Memory Leak.... Options: enable-md2 enable-shared fips --with-fipsdir=/tmp/fips-build no-ec_nistp_64_gcc_128 no-gmp no-jpake no-krb5 no-libunbound no-rc5 no-rfc3779 no-rsax no-sctp no-ssl-trace no-store no-unit-test no-zlib no-zlib-dynamic no-static-engine OS (uname): Linux diplomate 3.17.7-gentoo #1 SMP Tue Jan 6 10:03:50 NZDT 2015 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux OS (config): x86_64-whatever-linux2 Target (default): linux-x86_64 Target: linux-x86_64 Compiler: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.3 p1.1, pie-0.5.9' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog --enable-libsanitizer Thread model: posix gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) Failure! [...] Test report in file testlog From sdaoden at yandex.com Thu Jan 22 22:34:35 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 22 Jan 2015 23:34:35 +0100 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150122163847.GA28965@openssl.org> References: <20150122163847.GA28965@openssl.org> Message-ID: <20150122223435.S19rpI1J%sdaoden@yandex.com> Since noone else seems to say a word. I personally didn't understand at all why v1.0.2 when its end-of-life is in sight already. Now you have to continue to track three active branches. But this is your problem of course. What i _really_ don't understand is why 1.0.2 is delivered with false documentation (not only "int SSL_CONF_finish(SSL_CONF_CTX *cctx);") etc., especially given that there are bug reports. Documentation is a vivid part of a software, especially when a completely new interface is introduced. From only the documentation you won't be able to get that stuff going. Is ALPN, a prominent member of the NEWS entry (you find it on the website), at all documented? Where can i find a word about it?? So why that hastiness, now that OpenSSL gains enough money to pay the bread of not only one, but indeed multiple fulltime developers. And then the sponsors seem to accept spending time for tree re-evaluation? Is the OpenSSL project at the Wall Street and needs to produce hyper-hyper quarterly reports? That is really strange. Ciao, --steffen From openssl-users at dukhovni.org Thu Jan 22 22:56:05 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 22 Jan 2015 22:56:05 +0000 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150122223435.S19rpI1J%sdaoden@yandex.com> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> Message-ID: <20150122225605.GM8034@mournblade.imrryr.org> On Thu, Jan 22, 2015 at 11:34:35PM +0100, Steffen Nurpmeso wrote: > Since noone else seems to say a word. > I personally didn't understand at all why v1.0.2 when its > end-of-life is in sight already. Now you have to continue to > track three active branches. But this is your problem of course. You're confused. EOL has been announced for 0.9.8 and 1.0.0. No EOL has been announced for 1.0.1 (IIRC) and definitely not for 1.0.2. > What i _really_ don't understand is why 1.0.2 is delivered with > false documentation (not only "int SSL_CONF_finish(SSL_CONF_CTX > *cctx);") etc., especially given that there are bug reports. I would avoid throwing around words like "false" in this context. However, there are likely still documentation bugs and ommisions, problem reports are welcome. Not all past documentation sins have as yet been corrected. -- Viktor. From rt at openssl.org Fri Jan 23 00:17:30 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 23 Jan 2015 01:17:30 +0100 Subject: [openssl-dev] [openssl.org #3673] openssl-1.0.2 build error In-Reply-To: References: Message-ID: On Thu Jan 22 22:48:19 2015, Shane.Brewer at securitease.com wrote: > t1_lib.o t1_lib.c > t1_lib.c: In function ?tls1_get_curvelist?: > t1_lib.c:473:17: error: invalid type argument of unary ?*? (have > ?size_t?) > *pcurveslen = sizeof(fips_curves_default); > ^ 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 no_spam_98 at yahoo.com Fri Jan 23 05:44:19 2015 From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com) Date: Fri, 23 Jan 2015 05:44:19 +0000 (UTC) Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150122225605.GM8034@mournblade.imrryr.org> References: <20150122225605.GM8034@mournblade.imrryr.org> Message-ID: <1738117154.38315.1421991859421.JavaMail.yahoo@mail.yahoo.com> http://www.openssl.org/about/releasestrat.html "Version 1.0.1 will be supported until 2016-12-31." Perhaps its a matter of semantics, but isn't that EOL? ----- Original Message ----- > From: Viktor Dukhovni > > [stuff deleted] > > You're confused. EOL has been announced for 0.9.8 and 1.0.0. No > EOL has been announced for 1.0.1 (IIRC) and definitely not for 1.0.2. > > [stuff deleted] > > -- > Viktor. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From openssl-users at dukhovni.org Fri Jan 23 05:53:26 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jan 2015 05:53:26 +0000 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <1738117154.38315.1421991859421.JavaMail.yahoo@mail.yahoo.com> References: <20150122225605.GM8034@mournblade.imrryr.org> <1738117154.38315.1421991859421.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20150123055326.GO8034@mournblade.imrryr.org> On Fri, Jan 23, 2015 at 05:44:19AM +0000, no_spam_98 at yahoo.com wrote: > http://www.openssl.org/about/releasestrat.html > > "Version 1.0.1 will be supported until 2016-12-31." > > Perhaps its a matter of semantics, but isn't that EOL? It will be in 2017. -- Viktor. From matt at openssl.org Fri Jan 23 10:00:28 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Jan 2015 10:00:28 +0000 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150122223435.S19rpI1J%sdaoden@yandex.com> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> Message-ID: <54C21BBC.2090804@openssl.org> On 22/01/15 22:34, Steffen Nurpmeso wrote: > Since noone else seems to say a word. > I personally didn't understand at all why v1.0.2 when its > end-of-life is in sight already. >From my personal point of view I would like all our releases to have defined up front lifetimes, so that it is clear how long you can expect to receive support for. With respect to 1.0.2 we're not actually quite there as we've only said: Version 1.0.2 will be supported until at least 2016-12-31. Note the "at least". There is a good chance that it will be supported for significantly longer than that. The reasons for that are discussed in my recent blog post: https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ > Now you have to continue to > track three active branches. But this is your problem of course. Actually its four :-( - 0.9.8, 1.0.0, 1.0.1 and 1.0.2 (and of course we have master as well). Again see my blog post for a discussion on the thinking that went into it. As ever these decisions are a compromise between many competing pressures. > What i _really_ don't understand is why 1.0.2 is delivered with > false documentation (not only "int SSL_CONF_finish(SSL_CONF_CTX > *cctx);") etc., especially given that there are bug reports. > Documentation is a vivid part of a software, especially when > a completely new interface is introduced. From only the > documentation you won't be able to get that stuff going. > Is ALPN, a prominent member of the NEWS entry (you find it on the > website), at all documented? Where can i find a word about it?? Well "false" documentation seems a bit harsh to me :-)...that kind of makes it sound like we are deliberately setting out to mislead you!! It is a valid criticism that the documentation is not up to scratch. That applies to all versions...1.0.2 is nothing special there. It is on our list of things to sort out (see https://www.openssl.org/about/roadmap.html). That list has quite a few things on it, many of which are quite significant. Actually looking at it now reminds me that it could do with an update...quite a few of those things can either be knocked off (because we have done them), or we have some good progress to report. But documentation hasn't quite made it to the top of the list yet. It will do though. > So why that hastiness, now that OpenSSL gains enough money to pay > the bread of not only one, but indeed multiple fulltime > developers. Well 1.0.2 was in beta for nearly a year, so I'm not sure I would describe its release as hasty! Most of its development (including any associated documentation) was done before the time that any additional resources were made available. Matt From sdaoden at yandex.com Fri Jan 23 11:19:14 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Fri, 23 Jan 2015 12:19:14 +0100 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <54C21BBC.2090804@openssl.org> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> <54C21BBC.2090804@openssl.org> Message-ID: <20150123111914.-Ir_Jzec%sdaoden@yandex.com> Hello, Thanks for OpenSSL first. And again when you can read this. Matt Caswell wrote: |On 22/01/15 22:34, Steffen Nurpmeso wrote: |> Since noone else seems to say a word. |> I personally didn't understand at all why v1.0.2 when its |> end-of-life is in sight already. | |From my personal point of view I would like all our releases to have |defined up front lifetimes, so that it is clear how long you can expect |to receive support for. With respect to 1.0.2 we're not actually quite |there as we've only said: |Version 1.0.2 will be supported until at least 2016-12-31. My bad! I would have sworn that i had read 2015-12-31 as EOL for v1.0.2 in some message, but apparantly no such statement was posted to @announce, @devel nor @user at all. |Note the "at least". There is a good chance that it will be supported |for significantly longer than that. The reasons for that are discussed |in my recent blog post: |https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ I personally would prefer such a posting on -dev@, but great that lynx(1) can be used to read this blog, that's not self-evident. |> Now you have to continue to |> track three active branches. But this is your problem of course. | |Actually its four :-( - 0.9.8, 1.0.0, 1.0.1 and 1.0.2 (and of course we |have master as well). Again see my blog post for a discussion on the |thinking that went into it. As ever these decisions are a compromise |between many competing pressures. Sympathy! After all you are now more with some support by the vcs. [.] |> So why that hastiness, now that OpenSSL gains enough money to pay [.] |Well 1.0.2 was in beta for nearly a year, so I'm not sure I would Of course. Of course. And i think we are all looking forward to see what the future brings. (Myself even starves for documentation [coverage] improvements.) --steffen From Stefan.Neis at t-online.de Fri Jan 23 14:38:07 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Fri, 23 Jan 2015 15:38:07 +0100 Subject: [openssl-dev] =?utf-8?b?V0c6IFJlOiAgW29wZW5zc2wub3JnICMzNjI4XSBb?= =?utf-8?q?PATCH=5D_NDEBUG_macro_and_redundant_strings?= Message-ID: <1YEfN9-26xxBY0@fwd08.aul.t-online.de> Hi, I tried to comment on the ticket via rt, but apparently there's more to it than just sending it to rt at openssl.org using a magic subject line (or maybe it doesn't like "subject:" being replaced by the localized "Betreff:" as the webmail-frontend I'm using apparently does? Anyway, let me retry via openssl-dev: First some comments on the original patch: > These strings undesirably reveal absolute paths to the source > files of libcrypto. 1. AFAIR not all versions of libc are happy with NULL being passed for a string in printf and related functions (IIRC, e.g. SUN libc crashes in such situations), so those NULLs should be replaced by something like "\0" or similar, shouldn't they? 2. Also, I wonder, if defining OPENSSL_assert(e) instead of calling OpenSSLDie without a filename really was intended. 3. Lastly, completely turning off MemChecks at the same time as removing these strings seems a bit dubious. Then I previously commented > Along the same line of reasoning, there are some strings that > reveal paths to your local installation directory (see > crypto/x509/x509_def.c). [...] For completeness, her is a trivial patch for that suggestion (reusing the same NDEBUG define). Regards, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_NDEBUG2.patch Type: application/x-patch Size: 396 bytes Desc: URL: From dkg at fifthhorseman.net Fri Jan 23 15:30:53 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Jan 2015 10:30:53 -0500 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150123111914.-Ir_Jzec%sdaoden@yandex.com> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> <54C21BBC.2090804@openssl.org> <20150123111914.-Ir_Jzec%sdaoden@yandex.com> Message-ID: <87iofxldjm.fsf@alice.fifthhorseman.net> On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote: > And i think we are all looking forward to see what the future > brings. (Myself even starves for documentation [coverage] > improvements.) fwiw, OpenSSL documentation is pretty easy to read and to edit. If you notice that things are missing, you can edit the docs, and submit patches either on this mailing list, on the rt bugtracker at https://rt.openssl.org/, or as a pull request via github: https://github.com/openssl/openssl the main documentation is in the doc/ directory, either under doc/crypto/ (for libcrypto documentation) or doc/ssl/ (for libssl documentation). It is in pod format, which is pretty easy to read and get the hang of if you've used other markup languages. If you have a proposed change but you aren't sure that you've got the syntax right, go ahead and post the change anyway (in any of the three forums i mentioned above) and indicate that you'd like an extra double-check on the syntax. Contributions to improve documentation are important contributions, and it's a great way to give back to the project. --dkg From KThirumal at inautix.co.in Fri Jan 23 16:21:00 2015 From: KThirumal at inautix.co.in (Thirumal, Karthikeyan) Date: Fri, 23 Jan 2015 16:21:00 +0000 Subject: [openssl-dev] Disabling SSLv3 in OpenSSL 0.9.8a Message-ID: <55A0598A7539EC4BAB296D8BBA5AC1228671CEA7@WTPCPMBMEM07.ams.bnymellon.net> Team, In order to fix the Poodle vulnerability on SSLv3, I tried to disable my SSLv3 cipher using the below cipher set, but did not even initiate SSL in 0.9.8a. SSL_CTX_set_cipher_list(ssl_ctx,"SHA1+HIGH:!SSLv2:!SSLv3:!aNULL:!eNULL:@STRENGTH"); Without "!SSLv3" - by SSL connection is working fine by blocking just SSLv2. Can you advise if the above cipher list is right ? Thanks & Regards ________________________ Karthikeyan Thirumal ****************************************************** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ****************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Jan 23 16:44:09 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 16:44:09 +0000 Subject: [openssl-dev] Disabling SSLv3 in OpenSSL 0.9.8a In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC1228671CEA7@WTPCPMBMEM07.ams.bnymellon.net> References: <55A0598A7539EC4BAB296D8BBA5AC1228671CEA7@WTPCPMBMEM07.ams.bnymellon.net> Message-ID: <785371f37be249ab8d2094e9511bb946@usma1ex-dag1mb2.msg.corp.akamai.com> > In order to fix the Poodle vulnerability on SSLv3, I tried to disable my SSLv3 cipher using the below cipher set, but did not even initiate SSL in 0.9.8a. If you are running 0.9.8a Poodle is probably the least of your worries. Looking at https://www.openssl.org/news/openssl-0.9.8-notes.html it appears there are around 50 CVE fixes you are missing. From steve at openssl.org Fri Jan 23 16:50:47 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 23 Jan 2015 16:50:47 +0000 Subject: [openssl-dev] Disabling SSLv3 in OpenSSL 0.9.8a In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC1228671CEA7@WTPCPMBMEM07.ams.bnymellon.net> References: <55A0598A7539EC4BAB296D8BBA5AC1228671CEA7@WTPCPMBMEM07.ams.bnymellon.net> Message-ID: <20150123165047.GA16471@openssl.org> On Fri, Jan 23, 2015, Thirumal, Karthikeyan wrote: > Team, > In order to fix the Poodle vulnerability on SSLv3, I tried to disable my SSLv3 cipher using the below cipher set, but did not even initiate SSL in 0.9.8a. > > SSL_CTX_set_cipher_list(ssl_ctx,"SHA1+HIGH:!SSLv2:!SSLv3:!aNULL:!eNULL:@STRENGTH"); > > Without "!SSLv3" - by SSL connection is working fine by blocking just SSLv2. > > Can you advise if the above cipher list is right ? > You can't disable SSL 3.0 using a cipher list. The string "SSLv3" indicates ciphers which require a minimum of SSL 3.0 and so includes ciphersuites which can be used for SSL 3.0 or TLS 1.0. There aren't any ciphersuites suitable for TLS 1.0 and not SSL 3.0 so when you use !SSLv3 you disable all TLS 1.0 and SSL v3.0 ciphersuites. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Fri Jan 23 19:11:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 19:11:35 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes Message-ID: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinschen at redhat.com Fri Jan 23 19:46:18 2015 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 23 Jan 2015 20:46:18 +0100 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: <20150123194618.GR19127@calimero.vinschen.de> On Jan 23 19:11, 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 For those of the flags controlling OS capabilities, it would be nice to have a brief description so the OS-specific maintainers can check removing some of them might be a problem. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Fri Jan 23 20:27:14 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 20:27:14 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <20150123194618.GR19127@calimero.vinschen.de> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <20150123194618.GR19127@calimero.vinschen.de> Message-ID: > For those of the flags controlling OS capabilities, it would be nice to have a > brief description so the OS-specific maintainers can check removing some of > them might be a problem. I don't think I understand what you mean, but the only OS related one is NO_BUF_FREELISTS, which has openssl create a cache of buffers for systems where malloc and free are too slow. From vinschen at redhat.com Fri Jan 23 20:34:47 2015 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 23 Jan 2015 21:34:47 +0100 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <20150123194618.GR19127@calimero.vinschen.de> Message-ID: <20150123203447.GV19127@calimero.vinschen.de> On Jan 23 20:27, Salz, Rich wrote: > > For those of the flags controlling OS capabilities, it would be nice to have a > > brief description so the OS-specific maintainers can check removing some of ^^^ there was an "if" missing > > them might be a problem. > > I don't think I understand what you mean, but the only OS related one > is NO_BUF_FREELISTS, which has openssl create a cache of buffers for > systems where malloc and free are too slow. I was just asking if some of the flags handle OS-specific differences and if so, it would be nice to know which ones and what they were doing. This way platform maintainers of OpenSSL (Cygwin in my case) would know if they might get into trouble. But you already answered my question and it sounds like there's nothing to worry about :) Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From sdaoden at yandex.com Fri Jan 23 21:04:15 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Fri, 23 Jan 2015 22:04:15 +0100 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <87iofxldjm.fsf@alice.fifthhorseman.net> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> <54C21BBC.2090804@openssl.org> <20150123111914.-Ir_Jzec%sdaoden@yandex.com> <87iofxldjm.fsf@alice.fifthhorseman.net> Message-ID: <20150123210415.p6uJsIZr%sdaoden@yandex.com> Daniel Kahn Gillmor wrote: |On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote: |> brings. (Myself even starves for documentation [coverage] |> improvements.) | |fwiw, OpenSSL documentation is pretty easy to read and to edit. If you |notice that things are missing, you can edit the docs, and submit |patches either on this mailing list, on the rt bugtracker at |https://rt.openssl.org/, or as a pull request via github: | | https://github.com/openssl/openssl And fwiw :) i don't have a github account -- i had one but wanted to pay (also because they paid a developer for git(1) development), yet they didn't accept cash. And i *completely* decline using credit cards. --steffen -------------- next part -------------- An embedded message was scrubbed... From: Daniel Kahn Gillmor Subject: Re: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released Date: Fri, 23 Jan 2015 10:30:53 -0500 Size: 2551 URL: From richmoore44 at gmail.com Fri Jan 23 21:39:38 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 23 Jan 2015 21:39:38 +0000 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: The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build with OPENSSL_NO_SSL_INTERN defined since there are fields used for NPN that we need (iirc). Cheers Rich. On 23 January 2015 at 19:11, 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 dkg at fifthhorseman.net Fri Jan 23 21:43:11 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 23 Jan 2015 16:43:11 -0500 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <20150123210415.p6uJsIZr%sdaoden@yandex.com> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> <54C21BBC.2090804@openssl.org> <20150123111914.-Ir_Jzec%sdaoden@yandex.com> <87iofxldjm.fsf@alice.fifthhorseman.net> <20150123210415.p6uJsIZr%sdaoden@yandex.com> Message-ID: <87sif1i368.fsf@alice.fifthhorseman.net> On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote: > Daniel Kahn Gillmor wrote: > |On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote: > > |> brings. (Myself even starves for documentation [coverage] > |> improvements.) > | > |fwiw, OpenSSL documentation is pretty easy to read and to edit. If you > |notice that things are missing, you can edit the docs, and submit > |patches either on this mailing list, on the rt bugtracker at > |https://rt.openssl.org/, or as a pull request via github: > | > | https://github.com/openssl/openssl > > And fwiw :) i don't have a github account -- i had one but wanted > to pay (also because they paid a developer for git(1) > development), yet they didn't accept cash. And i *completely* > decline using credit cards. Sure, you don't need a github account at all, and no credit cards are required :) I'm assuming you've got the git client installed on your computer ("apt-get install git" or "yum install git" or if you're on some platform without a package management system get it from http://git-scm.com/). Then, to get a copy of the development tree and see what documentation files are present, you'd do: git clone https://github.com/openssl/openssl cd openssl/doc ls crypto/ ssl/ edit the documentation you want to fix, generate a patch using "git diff" and send it to this list attached to an explanatory e-mail. Regards, --dkg From rsalz at akamai.com Fri Jan 23 21:57:27 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Jan 2015 21:57:27 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <048f53b5d1764d778efc50fe2022cbd0@usma1ex-dag1mb2.msg.corp.akamai.com> > The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build with OPENSSL_NO_SSL_INTERN defined since there are fields used for NPN that we need (iirc). I hadn't thought of it as being a "preview" for what we plan to do. I guess it makes sense to keep it, at least until we have a preview of some kind that lets folks start building in the New World Order. Thanks! -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From shinrich at ieee.org Fri Jan 23 22:20:06 2015 From: shinrich at ieee.org (Susan Hinrichs) Date: Fri, 23 Jan 2015 16:20:06 -0600 Subject: [openssl-dev] Pausing TLS negotiation after client hello Message-ID: <54C2C916.1080300@ieee.org> Hello All, I work with Apache Traffic Server. Many of our users use the SNI callback to select the certificate that the proxy will present to the client. This selection can take some time. Rather than blocking the callback thread, we would like to pause the negotiation from the SNI callback. After the certificate has been selected, SSL_accept can be called again to continue the processing. Looking at documentation and code, I did not see a way to do this, so I created a small patch on 1.0.1f. I'll say a few words about the patch below. But first, is there another way to achieve this in the existing 1.0.x API or the proposed 1.1 API? If not, is there broader interest in such an addition? The users within the Apache Traffic Server community would like to be able to use an un-patched openssl library. My patch is at https://issues.apache.org/jira/secure/attachment/12662757/openssl-sni.patch It adds SSL_TLSEXT_ERR_READ_AGAIN as another return value option for the SNI callback. On this return value, openssl stops the negotiation and marks the message to be reused. It does not signal an error to the client. The next time SSL_accept is called, the client hello message is processed again, and if the SNI callback returns the SSL_TLSEXT_ERR_OK, the negotiation will continue. Thanks for your attention, Susan Hinrichs From openssl-users at dukhovni.org Fri Jan 23 22:48:37 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 23 Jan 2015 22:48:37 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <048f53b5d1764d778efc50fe2022cbd0@usma1ex-dag1mb2.msg.corp.akamai.com> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <048f53b5d1764d778efc50fe2022cbd0@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150123224836.GB8034@mournblade.imrryr.org> On Fri, Jan 23, 2015 at 09:57:27PM +0000, Salz, Rich wrote: > I hadn't thought of it as being a "preview" for what we plan to > do. I guess it makes sense to keep it, at least until we have a > preview of some kind that lets folks start building in the New > World Order. I've used it to "future-proof" Postfix. It now builds with the NO_INTERN flag set. Keeping that flag makes sense. -- Viktor. From steve at openssl.org Fri Jan 23 23:16:04 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 23 Jan 2015 23:16:04 +0000 Subject: [openssl-dev] Pausing TLS negotiation after client hello In-Reply-To: <54C2C916.1080300@ieee.org> References: <54C2C916.1080300@ieee.org> Message-ID: <20150123231604.GA14884@openssl.org> On Fri, Jan 23, 2015, Susan Hinrichs wrote: > Hello All, > > I work with Apache Traffic Server. Many of our users use the SNI > callback to select the certificate that the proxy will present to > the client. This selection can take some time. Rather than > blocking the callback thread, we would like to pause the negotiation > from the SNI callback. After the certificate has been selected, > SSL_accept can be called again to continue the processing. > > Looking at documentation and code, I did not see a way to do this, > so I created a small patch on 1.0.1f. I'll say a few words about > the patch below. > > But first, is there another way to achieve this in the existing > 1.0.x API or the proposed 1.1 API? > OpenSSL 1.0.2 has a certificate callback which can be used for both client and server certificates. It also supports non-blocking I/O so you can "pause" in the manner you describe. See: https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From matt at openssl.org Fri Jan 23 23:16:27 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Jan 2015 23:16:27 +0000 Subject: [openssl-dev] [openssl-announce] OpenSSL version 1.0.2 released In-Reply-To: <87iofxldjm.fsf@alice.fifthhorseman.net> References: <20150122163847.GA28965@openssl.org> <20150122223435.S19rpI1J%sdaoden@yandex.com> <54C21BBC.2090804@openssl.org> <20150123111914.-Ir_Jzec%sdaoden@yandex.com> <87iofxldjm.fsf@alice.fifthhorseman.net> Message-ID: <54C2D64B.4010601@openssl.org> On 23/01/15 15:30, Daniel Kahn Gillmor wrote: > On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote: > >> And i think we are all looking forward to see what the future >> brings. (Myself even starves for documentation [coverage] >> improvements.) > > fwiw, OpenSSL documentation is pretty easy to read and to edit. If you > notice that things are missing, you can edit the docs, and submit > patches either on this mailing list, on the rt bugtracker at > https://rt.openssl.org/, or as a pull request via github: > > https://github.com/openssl/openssl Just to clarify: the correct way to submit patches is via rt (i.e. email rt at openssl.org). This will automatically get sent to the dev list. Don't send them direct to the dev list. You can also submit via github...but if you do, you should still send an email to rt with a link to the pull request. RT is considered our master list of tickets...if it's not in there its liable to be forgotten about. For minor tweaks to the documentation you can also make edits on the wiki: Changes on the wiki are periodically collected together and reviewed like any other patch: https://wiki.openssl.org/index.php/Main_Page See the "Reference" section on the wiki main page. Matt From shinrich at ieee.org Sat Jan 24 00:16:42 2015 From: shinrich at ieee.org (Susan Hinrichs) Date: Fri, 23 Jan 2015 18:16:42 -0600 Subject: [openssl-dev] Pausing TLS negotiation after client hello In-Reply-To: <20150123231604.GA14884@openssl.org> References: <54C2C916.1080300@ieee.org> <20150123231604.GA14884@openssl.org> Message-ID: <54C2E46A.5070904@ieee.org> On 1/23/2015 5:16 PM, Dr. Stephen Henson wrote: > On Fri, Jan 23, 2015, Susan Hinrichs wrote: > >> Hello All, >> >> I work with Apache Traffic Server. Many of our users use the SNI >> callback to select the certificate that the proxy will present to >> the client. This selection can take some time. Rather than >> blocking the callback thread, we would like to pause the negotiation >> from the SNI callback. After the certificate has been selected, >> SSL_accept can be called again to continue the processing. >> >> Looking at documentation and code, I did not see a way to do this, >> so I created a small patch on 1.0.1f. I'll say a few words about >> the patch below. >> >> But first, is there another way to achieve this in the existing >> 1.0.x API or the proposed 1.1 API? >> > OpenSSL 1.0.2 has a certificate callback which can be used for both client > and server certificates. It also supports non-blocking I/O so you can > "pause" in the manner you describe. > > See: > > https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_cb.html > > Steve. Splendid! That looks like exactly what we need. Thank you for the pointer. Susan > -- > 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 rt at openssl.org Mon Jan 26 02:53:04 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 26 Jan 2015 03:53:04 +0100 Subject: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit() In-Reply-To: References: Message-ID: After discussion, we decided to make the existing function REALLY ignore errors and not print anything and not exit. But it's still deprecated and don't use it :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Jan 26 02:55:47 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 26 Jan 2015 03:55:47 +0100 Subject: [openssl-dev] [openssl.org #786] 0.9.7: OPENSSL_NO_SHA flag In-Reply-To: References: Message-ID: We're going to remove the flag, it is not worth the time to make openssl build without SHA. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Jan 26 03:02:16 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 26 Jan 2015 04:02:16 +0100 Subject: [openssl-dev] [openssl.org #1353] memory leak in EVP sign and verification functions In-Reply-To: <4496D838.20508@barc.gov.in> References: <4496D838.20508@barc.gov.in> Message-ID: demo was probably7 fixed with these commits: commit 89f534e1d30ed40a03455b36cda7da13734e7238 Author: Dr. Stephen Henson Date: Fri Sep 28 00:47:36 2001 +0000 Make (ancient) sign.c demo compile again. commit 5f6d0ea21050fd8a801c6681002e76689a5993b6 Author: Dr. Stephen Henson Date: Wed Jun 9 23:33:48 1999 +0000 Reformat and "modernise" the sign.c demo. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From richmoore44 at gmail.com Mon Jan 26 11:37:39 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 26 Jan 2015 11:37:39 +0000 Subject: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit() In-Reply-To: References: Message-ID: On 26 January 2015 at 02:53, Rich Salz via RT wrote: > After discussion, we decided to make the existing function REALLY ignore > errors > and not print anything and not exit. But it's still deprecated and don't > use it > :) > That's great Rich. So, to be clear, we should be using something like: CONF_modules_load_file(NULL, NULL, CONF_MFLAGS_IGNORE_ERRORS|CONF_MFLAGS_SILENT|CONF_MFLAGS_IGNORE_MISSING_FILE) If we want roughly equivalent behaviour? Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 26 11:37:54 2015 From: rt at openssl.org (Richard Moore via RT) Date: Mon, 26 Jan 2015 12:37:54 +0100 Subject: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit() In-Reply-To: References: Message-ID: On 26 January 2015 at 02:53, Rich Salz via RT wrote: > After discussion, we decided to make the existing function REALLY ignore > errors > and not print anything and not exit. But it's still deprecated and don't > use it > :) > That's great Rich. So, to be clear, we should be using something like: CONF_modules_load_file(NULL, NULL, CONF_MFLAGS_IGNORE_ERRORS|CONF_MFLAGS_SILENT|CONF_MFLAGS_IGNORE_MISSING_FILE) If we want roughly equivalent behaviour? Cheers Rich. From interfere.work at gmail.com Mon Jan 26 12:13:17 2015 From: interfere.work at gmail.com (Alexey Komnin) Date: Mon, 26 Jan 2015 15:13:17 +0300 Subject: [openssl-dev] [openssl.org #3628] Re: [PATCH] NDEBUG macro and redundant strings Message-ID: Hi, I have prepared a new patch, which is supposed to work well with libc provided by SUN. It also contains additional changes for t1_enc.c file. The patch is in attachment. I have also pinned the patch, provided by Stefan, though I have not understood why it is necessary to patch the x509_def.c file. Also, I have removed changes related to MemChecks from the patch. Regards, Alex. On Fri, Jan 23, 2015 at 5:38 PM, Stefan.Neis at t-online.de wrote: > Hi, > > I tried to comment on the ticket via rt, but apparently there's more > to it than just sending it to rt at openssl.org using a magic subject line > (or maybe it doesn't like "subject:" being replaced by the localized > "Betreff:" as the webmail-frontend I'm using apparently does? > > Anyway, let me retry via openssl-dev: > > First some comments on the original patch: >> These strings undesirably reveal absolute paths to the source >> files of libcrypto. > > 1. AFAIR not all versions of libc are happy with NULL being passed > for a string in printf and related functions (IIRC, e.g. SUN libc crashes > in such situations), so those NULLs should be replaced by > something like "\0" or similar, shouldn't they? > 2. Also, I wonder, if defining OPENSSL_assert(e) instead of calling > OpenSSLDie without a filename really was intended. > 3. Lastly, completely turning off MemChecks at the same time as > removing these strings seems a bit dubious. > > Then I previously commented >> Along the same line of reasoning, there are some strings that >> reveal paths to your local installation directory (see >> crypto/x509/x509_def.c). [...] > > For completeness, her is a trivial patch for that suggestion (reusing the > same NDEBUG define). > > Regards, > Stefan > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_NDEBUG2.patch Type: application/x-patch Size: 396 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-ndebug.patch Type: application/x-patch Size: 14005 bytes Desc: not available URL: From rt at openssl.org Mon Jan 26 12:13:31 2015 From: rt at openssl.org (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JrQvtC80L3QuNC9?= via RT) Date: Mon, 26 Jan 2015 13:13:31 +0100 Subject: [openssl-dev] [openssl.org #3628] Re: [PATCH] NDEBUG macro and redundant strings In-Reply-To: References: Message-ID: Hi, I have prepared a new patch, which is supposed to work well with libc provided by SUN. It also contains additional changes for t1_enc.c file. The patch is in attachment. I have also pinned the patch, provided by Stefan, though I have not understood why it is necessary to patch the x509_def.c file. Also, I have removed changes related to MemChecks from the patch. Regards, Alex. On Fri, Jan 23, 2015 at 5:38 PM, Stefan.Neis at t-online.de wrote: > Hi, > > I tried to comment on the ticket via rt, but apparently there's more > to it than just sending it to rt at openssl.org using a magic subject line > (or maybe it doesn't like "subject:" being replaced by the localized > "Betreff:" as the webmail-frontend I'm using apparently does? > > Anyway, let me retry via openssl-dev: > > First some comments on the original patch: >> These strings undesirably reveal absolute paths to the source >> files of libcrypto. > > 1. AFAIR not all versions of libc are happy with NULL being passed > for a string in printf and related functions (IIRC, e.g. SUN libc crashes > in such situations), so those NULLs should be replaced by > something like "\0" or similar, shouldn't they? > 2. Also, I wonder, if defining OPENSSL_assert(e) instead of calling > OpenSSLDie without a filename really was intended. > 3. Lastly, completely turning off MemChecks at the same time as > removing these strings seems a bit dubious. > > Then I previously commented >> Along the same line of reasoning, there are some strings that >> reveal paths to your local installation directory (see >> crypto/x509/x509_def.c). [...] > > For completeness, her is a trivial patch for that suggestion (reusing the > same NDEBUG define). > > Regards, > Stefan > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_NDEBUG2.patch Type: application/x-patch Size: 396 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-ndebug.patch Type: application/x-patch Size: 14005 bytes Desc: not available URL: From lars.laven at columbitech.com Mon Jan 26 13:18:34 2015 From: lars.laven at columbitech.com (=?iso-8859-1?Q?Lars_Lav=E9n?=) Date: Mon, 26 Jan 2015 13:18:34 +0000 Subject: [openssl-dev] Compile 1.0.2 release in FIPS mode Message-ID: Hi, I just tried to compile 1.0.2 in FIPS mode and unfortunately I get a compilation error. The function tls1_get_curvelist in ssl/t1_lib.c (line 437) still looks like it did in beta 3: #ifdef OPENSSL_FIPS if (FIPS_mode()) { *pcurves = fips_curves_default; *pcurveslen = sizeof(fips_curves_default); return; } #endif It should rather be: #ifdef OPENSSL_FIPS if (FIPS_mode()) { *pcurves = fips_curves_default; pcurveslen = sizeof(fips_curves_default); return; } #endif -- Kind regards, Lars Lav?n -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Jan 26 13:45:05 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Jan 2015 13:45:05 +0000 Subject: [openssl-dev] Compile 1.0.2 release in FIPS mode In-Reply-To: References: Message-ID: <54C644E1.5030907@openssl.org> On 26/01/15 13:18, Lars Lav?n wrote: > Hi, > > I just tried to compile 1.0.2 in FIPS mode and unfortunately I get a > compilation error. The function tls1_get_curvelist in ssl/t1_lib.c (line > 437) still looks like it did in beta 3: Hi Lars, This is fixed already in git. Please see commit 6fa805f516. Matt From rsalz at akamai.com Mon Jan 26 15:31:46 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Jan 2015 15:31:46 +0000 Subject: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit() In-Reply-To: References: Message-ID: Yes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Jan 26 15:32:38 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 26 Jan 2015 16:32:38 +0100 Subject: [openssl-dev] [openssl.org #3488] OPENSSL_config shouldn't exit() In-Reply-To: References: Message-ID: Yes. From rt at openssl.org Mon Jan 26 16:22:45 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 26 Jan 2015 17:22:45 +0100 Subject: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions In-Reply-To: <27355527.1T4quQhoAp@pintsize.usersys.redhat.com> References: <1427858765.11155705.1417276883241.JavaMail.zimbra@redhat.com> <27355527.1T4quQhoAp@pintsize.usersys.redhat.com> Message-ID: New pull request based on top of current master with minor fixes: https://github.com/openssl/openssl/pull/215 -- Regards, Hubert Kario From rt at openssl.org Mon Jan 26 18:02:51 2015 From: rt at openssl.org (David Bar via RT) Date: Mon, 26 Jan 2015 19:02:51 +0100 Subject: [openssl-dev] [openssl.org #3674] Bug report - cannot compile 1.0.2 with no-cms In-Reply-To: References: Message-ID: If running ./config no-cms make then there's multiple problems with new code that adds new CMS functionality that was not properly protected by #ifndef OPENSSL_NO_CMS I've attaching a patch file that I've done over 1.0.2. It compiles with the patch. The changes are fairly simple in all files except dh_pmeth.c which you should probably reconsider. In dh_pmeth.c, pkey_dh_ctrl(), the change is a bit ugly, especially if there's a plan to make more types of kdf_type in addition to the two existing ones. I've done it like so to minimize the change. Perhaps changes this to a switch would make it more elegant and future-proof. In dh_pmeth.c, pkey_dh_derive - apart from the reasonable change of putting the whole "else if" under a #ifndef, I've also changed the default return value of the function to 0. If the "if" and the "else if" don't recognize the kdf_type, I think it's much more reasonable for the function to indicate a failure, instead of the original code. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_no_cms.patch Type: application/octet-stream Size: 4853 bytes Desc: not available URL: From rt at openssl.org Mon Jan 26 18:03:01 2015 From: rt at openssl.org (Petr Spacek via RT) Date: Mon, 26 Jan 2015 19:03:01 +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: Hello, I'm attaching patch which fixes key wrapping mode with padding to conform to RFC 5649. According to RFC 5649 section 4.1 step 1) we should not add padding if plaintext length is multiple of 8 ockets. This matches pseudo-code in http://dx.doi.org/10.6028/NIST.SP.800-38F on page 15, section 6.3 KWP, algorithm 5 KWP-AE, step 2. Alternatively the same patch can be pulled from branch rfc5649_fix on Github: https://github.com/spacekpe/openssl/commit/69a37391f4a82855246fd86ddfb0c6bb47c36855 Have a nice day! -- Petr Spacek @ Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-key-wrapping-mode-with-padding-to-conform-to-RFC.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: From brian at briansmith.org Mon Jan 26 18:03:30 2015 From: brian at briansmith.org (Brian Smith) Date: Mon, 26 Jan 2015 10:03:30 -0800 Subject: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions In-Reply-To: <1811803.InTNV7kXGL@pintsize.usersys.redhat.com> References: <1811803.InTNV7kXGL@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > Actually it does not introduce it as OpenSSL does send the notification as > TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension. > > On Sunday 30 November 2014 20:36:20 Richard Moore wrote: >> That would introduce security issues such as the TLS renegotiation flaw. >> Surely a better solution is to make servers that pretend to support TLS but >> actually only support SSL3 die a horrible death? I agree with Richard that this seems . In particular, the session hash / extended master secret [1] specification requires an extension to work securely. Not having the SNI extension is likely to cause security issues (using a different and perhaps though-of-as-unused certificate). Many servers use the values in the signature_algorithms extension to determine whether to use a SHA-2 or SHA-1 certificate, so not sending signature_algorithms is likely to cause problems for any client that disables support for SHA-1 certificates. Resolving these TLS (extension) intolerance issues requires collective action, and it would be great if OpenSSL could do its part by not adding features like this that exist purely to avoid participating in the collective action, especially when the added feature disables other important security features. Cheers, Brian [1] https://tools.ietf.org/html/draft-bhargavan-tls-session-hash-00 From rt at openssl.org Mon Jan 26 21:01:10 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 26 Jan 2015 22:01:10 +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: <20150126210058.GA15575@kronk.local> References: <20150120133114.GA13866@kronk.local> <20150126210058.GA15575@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 Ping? This is actually pretty important since OpenSSL can't verify OCSP responses from a whole bunch of servers. Cheers From crrodriguez at opensuse.org Mon Jan 26 22:47:41 2015 From: crrodriguez at opensuse.org (=?UTF-8?q?Cristian=20Rodr=C3=ADguez?=) Date: Mon, 26 Jan 2015 19:47:41 -0300 Subject: [openssl-dev] [PATCH] libssl: scsv variable must be const Message-ID: <1422312461-16364-1-git-send-email-crrodriguez@opensuse.org> --- ssl/ssl_lib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c index d777935..90d1082 100644 --- a/ssl/ssl_lib.c +++ b/ssl/ssl_lib.c @@ -1481,7 +1481,7 @@ int ssl_cipher_list_to_bytes(SSL *s, STACK_OF(SSL_CIPHER) *sk, */ if (p != q) { if (empty_reneg_info_scsv) { - static SSL_CIPHER scsv = { + static const SSL_CIPHER scsv = { 0, NULL, SSL3_CK_SCSV, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; j = put_cb(&scsv, p); @@ -1492,7 +1492,7 @@ int ssl_cipher_list_to_bytes(SSL *s, STACK_OF(SSL_CIPHER) *sk, #endif } if (s->mode & SSL_MODE_SEND_FALLBACK_SCSV) { - static SSL_CIPHER scsv = { + static const SSL_CIPHER scsv = { 0, NULL, SSL3_CK_FALLBACK_SCSV, 0, 0, 0, 0, 0, 0, 0, 0, 0 }; j = put_cb(&scsv, p); -- 2.2.2 From openssl-users at dukhovni.org Mon Jan 26 22:59:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Jan 2015 22:59:54 +0000 Subject: [openssl-dev] [PATCH] libssl: scsv variable must be const In-Reply-To: <1422312461-16364-1-git-send-email-crrodriguez@opensuse.org> References: <1422312461-16364-1-git-send-email-crrodriguez@opensuse.org> Message-ID: <20150126225954.GE8034@mournblade.imrryr.org> On Mon, Jan 26, 2015 at 07:47:41PM -0300, Cristian Rodr?guez wrote: You say "scsv variable must be const". I agree it *should* be declared constant as a matter of hygiene, and so we should adopt the patch. Still I am puzzled why you use the word "must". Did some compiler object? If so, which one? > --- a/ssl/ssl_lib.c > +++ b/ssl/ssl_lib.c > @@ -1481,7 +1481,7 @@ int ssl_cipher_list_to_bytes(SSL *s, STACK_OF(SSL_CIPHER) *sk, > */ > if (p != q) { > if (empty_reneg_info_scsv) { > - static SSL_CIPHER scsv = { > + static const SSL_CIPHER scsv = { > 0, NULL, SSL3_CK_SCSV, 0, 0, 0, 0, 0, 0, 0, 0, 0 > }; > j = put_cb(&scsv, p); > @@ -1492,7 +1492,7 @@ int ssl_cipher_list_to_bytes(SSL *s, STACK_OF(SSL_CIPHER) *sk, > #endif > } > if (s->mode & SSL_MODE_SEND_FALLBACK_SCSV) { > - static SSL_CIPHER scsv = { > + static const SSL_CIPHER scsv = { > 0, NULL, SSL3_CK_FALLBACK_SCSV, 0, 0, 0, 0, 0, 0, 0, 0, 0 > }; > j = put_cb(&scsv, p); The put_cb() callback takes a "const SSL_CIPHER *" as its first argument, passing a non-const argument is AFAIK acceptable. -- Viktor. From crrodriguez at opensuse.org Mon Jan 26 23:37:32 2015 From: crrodriguez at opensuse.org (=?windows-1252?Q?Cristian_Rodr=EDguez?=) Date: Mon, 26 Jan 2015 20:37:32 -0300 Subject: [openssl-dev] [PATCH] libssl: scsv variable must be const In-Reply-To: <20150126225954.GE8034@mournblade.imrryr.org> References: <1422312461-16364-1-git-send-email-crrodriguez@opensuse.org> <20150126225954.GE8034@mournblade.imrryr.org> Message-ID: <54C6CFBC.50807@opensuse.org> El 26/01/15 a las 19:59, Viktor Dukhovni escribi?: > On Mon, Jan 26, 2015 at 07:47:41PM -0300, Cristian Rodr?guez wrote: > > You say "scsv variable must be const". I agree it *should* be > declared constant as a matter of hygiene, and so we should adopt > the patch. Still I am puzzled why you use the word "must". Did > some compiler object? If so, which one? Language mistake, I intented to write "should".. no compiler complains.. I was just checking what variables shouldn't be writable. ;-) From hanno at hboeck.de Tue Jan 27 11:30:45 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 27 Jan 2015 12:30:45 +0100 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: <20150127123045.4585a4e6@pc> Hello, On Fri, 23 Jan 2015 19:11:35 +0000 "Salz, Rich" wrote: > OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with "standard" memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From hkario at redhat.com Tue Jan 27 11:33:21 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 27 Jan 2015 12:33:21 +0100 Subject: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions In-Reply-To: References: <1811803.InTNV7kXGL@pintsize.usersys.redhat.com> Message-ID: <2382373.AFM677yIAI@pintsize.usersys.redhat.com> On Monday 26 January 2015 10:03:30 Brian Smith wrote: > Hubert Kario wrote: > > Actually it does not introduce it as OpenSSL does send the notification as > > TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension. > > > > On Sunday 30 November 2014 20:36:20 Richard Moore wrote: > >> That would introduce security issues such as the TLS renegotiation flaw. > >> Surely a better solution is to make servers that pretend to support TLS > >> but > >> actually only support SSL3 die a horrible death? > > I agree with Richard that this seems . In particular, the session hash > / extended master secret [1] specification requires an extension to > work securely. which is not used by openssl by default... > Not having the SNI extension is likely to cause > security issues (using a different and perhaps though-of-as-unused > certificate). SNI needs to be set manually on a connection, many openssl consumers still don't do it... and if you don't verify server certificate no amount of extensions will help you > Many servers use the values in the signature_algorithms > extension to determine whether to use a SHA-2 or SHA-1 certificate, Interesting, haven't seen such ones. Can you give examples? Still, how can you test if the server does the sane thing if the client doesn't provide signature_algorithms if you have such a server? > so > not sending signature_algorithms is likely to cause problems for any > client that disables support for SHA-1 certificates. exactly what every piece of documentation surrounding this option says > Resolving these TLS (extension) intolerance issues requires collective > action, and it would be great if OpenSSL could do its part by not > adding features like this that exist purely to avoid participating in > the collective action, especially when the added feature disables > other important security features. It's implemented not so that you can interoperate with them, I implemented it so that you can detect *if* this is the reason why you can't interoperate with them. Unfortunately it's rather hard to test interoperability without actually being interoperable... There are broken clients and there are broken servers and there are broken middle boxes out there. The library already has stuff like SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which is *really* dangerous. SSL_OP_NO_TLSEXT is less of an issue than export grade ciphers. SSL_OP_NO_TLSEXT is the default mode of operation for 0.9.8, and I think we can agree that while 0.9.8 is old it's still secure. -- Regards, Hubert Kario From david.lloyd at fsmail.net Tue Jan 27 12:02:44 2015 From: david.lloyd at fsmail.net (david.lloyd at fsmail.net) Date: Tue, 27 Jan 2015 13:02:44 +0100 Subject: [openssl-dev] OCB patent stuff Message-ID: <6320437.7351422360164576.JavaMail.www@wwinf3717> Hi, Quick note about this (or could you refer me to the discussion that I missed). Although I have no problems with explicitly patented code being included with OpenSSL, shouldn't the default for such code be "off" with an explicit "enable-ocb"? Added support for OCB mode. OpenSSL has been granted a patent license compatible with the OpenSSL license for use of OCB. Details are available at https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf. Support for OCB can be removed by calling config with no-ocb. [Matt Caswell] Thanks! From matt at openssl.org Tue Jan 27 12:14:37 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jan 2015 12:14:37 +0000 Subject: [openssl-dev] OCB patent stuff In-Reply-To: <6320437.7351422360164576.JavaMail.www@wwinf3717> References: <6320437.7351422360164576.JavaMail.www@wwinf3717> Message-ID: <54C7812D.4080403@openssl.org> On 27/01/15 12:02, david.lloyd at fsmail.net wrote: > Hi, > > Quick note about this (or could you refer me to the discussion that I missed). Although I have no problems with explicitly patented code being included with OpenSSL, shouldn't the default for such code be "off" with an explicit "enable-ocb"? Why? We have an explicit licence enabling its use - so why shouldn't it be on? Matt From david.lloyd at fsmail.net Tue Jan 27 13:12:23 2015 From: david.lloyd at fsmail.net (david.lloyd at fsmail.net) Date: Tue, 27 Jan 2015 14:12:23 +0100 Subject: [openssl-dev] OCB patent stuff Message-ID: <27693383.9041422364343795.JavaMail.www@wwinf3722> > Why? We have an explicit licence enabling its use - so why shouldn't it > be on? > > Matt You do, but I don't, and other users of OpenSSL don't either. According to my legal advice at least - your Lawyer may disagree. The linked pdf doesn't solve the problem apparently. That there is an *issued* patent on the algorithm at all immediately makes it "controversial", and probably doomed to die. Compare what the BBC did with the Dirac patents - the patent was publicly filed and then they explicitly let the application lapse without getting the patent issued within the timeframe. Once a patent is actually issued, there is the always someone who is going to have a problem. So the question is: Why did they pay for the Patent unless there is an intention to require Royalties? Are you or OpenSSL going to going to pay my royalty fees and/or legal costs if I am found to be infringing on this known patent? If you are not happy to be responsible for legal costs, then I recommend you disable it by default to avoid any such confusion... From matt at openssl.org Tue Jan 27 13:32:36 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jan 2015 13:32:36 +0000 Subject: [openssl-dev] OCB patent stuff In-Reply-To: <27693383.9041422364343795.JavaMail.www@wwinf3722> References: <27693383.9041422364343795.JavaMail.www@wwinf3722> Message-ID: <54C79374.9060206@openssl.org> On 27/01/15 13:12, david.lloyd at fsmail.net wrote: > > >> Why? We have an explicit licence enabling its use - so why shouldn't it >> be on? >> >> Matt > > > You do, but I don't, and other users of OpenSSL don't either. According to my legal advice at least - your Lawyer may disagree. The linked pdf doesn't solve the problem apparently. > > That there is an *issued* patent on the algorithm at all immediately makes it "controversial", and probably doomed to die. Compare what the BBC did with the Dirac patents - the patent was publicly filed and then they explicitly let the application lapse without getting the patent issued within the timeframe. Once a patent is actually issued, there is the always someone who is going to have a problem. > > So the question is: Why did they pay for the Patent unless there is an intention to require Royalties? Are you or OpenSSL going to going to pay my royalty fees and/or legal costs if I am found to be infringing on this known patent? > > If you are not happy to be responsible for legal costs, then I recommend you disable it by default to avoid any such confusion... The answer to that is in the OpenSSL licence: * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. and is also covered by the OpenSSL FAQ: https://www.openssl.org/support/faq.html#LEGAL1 However, it is not the first time that there are things within OpenSSL with patents, and it is not without precedent to have these things switched on (e.g. some distributions have disabled EC stuff because of patent concerns, which is on by default in standard OpenSSL). We did get our own legal advice before including it and those lawyers advised us that we were ok with the patent licence we have been granted. Your mileage may vary with your own legal advice (and of course that may vary depending on where in the world you are located)...hence the FAQ link I provided above. The option to disable OCB has been provided for the cautious. Matt From david.lloyd at fsmail.net Tue Jan 27 13:50:36 2015 From: david.lloyd at fsmail.net (david.lloyd at fsmail.net) Date: Tue, 27 Jan 2015 14:50:36 +0100 Subject: [openssl-dev] OCB patent stuff Message-ID: <6868426.10131422366636518.JavaMail.www@wwinf3722> > The answer to that is in the OpenSSL licence: > * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY > * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR > * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED > * OF THE POSSIBILITY OF SUCH DAMAGE. > > and is also covered by the OpenSSL FAQ: > https://www.openssl.org/support/faq.html#LEGAL1 Thanks, that matches exactly what my Legal advice said about the pdf. I will be specifying no-ocb for my customers. From rsalz at akamai.com Tue Jan 27 14:37:04 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 14:37:04 +0000 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <20150127123045.4585a4e6@pc> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <20150127123045.4585a4e6@pc> Message-ID: <9cea7b8fa8414708bca16d585da3d2c1@ustx2ex-dag1mb2.msg.corp.akamai.com> > What's the plan here? Replace openssl's own memory management by > default with "standard" memory management calls or is the plan to disable > the possibility to have standard memory management at all? > If the latter I'd vote against removing that flag. We use using only malloc and free. We are no longer keeping our own "freelist" management. From rt at openssl.org Tue Jan 27 14:48:25 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 27 Jan 2015 15:48:25 +0100 Subject: [openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works In-Reply-To: References: <9B578300-3D9D-45BE-810E-03D2FD97BE59@gmail.com> Message-ID: On Thu Jan 15 17:21:35 2015, matt wrote: > In response to your previous documentation question it is > (unfortunately) > undocumented. :-( > The best I can offer you is the source code: > int read_ahead; /* Read as many input bytes as possible * (for non- > blocking > reads) */ > With regards to your second point, I consider it a bug that this is > not the > default for DTLS. Unfortunately that bug has remained dormant until > the fix for > CVE-2014-0206 exposed it. > > I'm keeping this ticket open, until we have a proper fix. For now > though the > workaround is to use the SSL_CTX_set_read_ahead function directly. A slight correction to the notes above. The reference should be to CVE-2014-3571 (not CVE-2014-0206 as stated). I have now committed the fix for this problem. See commit 8dd4ad0ff in master (for 1.0.1 see 1895583). This fix makes read_ahead the default for DTLS...and in fact you can't turn it off now for DTLS either (calls to the read_ahead functions are ignored). I've also added some documentation for the read_ahead functions in commit 85074745. These are now irrelevant for DTLS (since you can't turn read_ahead off), but still relevant for TLS. Closing this ticket. Matt From crrodriguez at opensuse.org Tue Jan 27 14:54:00 2015 From: crrodriguez at opensuse.org (=?UTF-8?B?Q3Jpc3RpYW4gUm9kcsOtZ3Vleg==?=) Date: Tue, 27 Jan 2015 11:54:00 -0300 Subject: [openssl-dev] Seeking feedback on some #ifdef changes In-Reply-To: <20150127123045.4585a4e6@pc> References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com> <20150127123045.4585a4e6@pc> Message-ID: <54C7A688.2070308@opensuse.org> El 27/01/15 a las 08:30, Hanno B?ck escribi?: > Hello, > > On Fri, 23 Jan 2015 19:11:35 +0000 > "Salz, Rich" wrote: > >> OPENSSL_NO_BUF_FREELISTS > > As far as I remember the post-heartbleed discussions this disables an > openssl-own memory management which in the case of heartbleed > circumvented memory protection measures like address sanitizer. > > What's the plan here? Replace openssl's own memory management by > default with "standard" memory management calls or is the plan to > disable the possibility to have standard memory management at all? > If the latter I'd vote against removing that flag. I think It needs be replaced by standard memory managment, whoever wants to do something special like using a different/tweaked allocator for whatever reason should use the operating system facilities to do so. Inordinate amounts of time have been spent improving things at this level, at least in linux BUF_FREELISTS functionality makes no sense whatsover. From matt at openssl.org Tue Jan 27 15:02:24 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jan 2015 15:02:24 +0000 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 In-Reply-To: References: <54B7CCD2.108@openssl.org> <54B7CD3B.8040706@openssl.org> Message-ID: <54C7A880.9080803@openssl.org> On 15/01/15 17:06, Fedor Indutny wrote: > Matt, > > Thank you for reply. > > May I ask you when do you think your patch may land in 1.0.2 or whatever? > > If this is something of your long term goals and not going to land > anywhere soon. Could you please tell me about issues in my patch (either > privately or in publi?)? My apologies for the delayed response. Things went a bit mad for a while with releases and the source code reformat, and I completely forgot about this email :-( I am hoping my patch will land in master (which means 1.1.0...aiming for an end of year release). I will add some notes to your RT ticket regarding your patch. You can see my draft patch here: https://github.com/mattcaswell/openssl/commits/late-check-trusted-v2 This is still going through review so may change. Matt From rt at openssl.org Tue Jan 27 15:14:32 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 27 Jan 2015 16:14:32 +0100 Subject: [openssl-dev] [openssl.org #3637] [PATCH] x509: skip certs if in alternative cert chain In-Reply-To: References: Message-ID: On Thu Dec 18 15:31:48 2014, fedor at indutny.com wrote: > In situations like [0] the server may provide alternative certificate > chain, which is no longer valid in the current certificate store. In > fact the issuer of the leaf (or some intermediate) cert is known and > trusted, but the alternative chain certs that are sent by server are > not trusted, thus leading to `ctx->get_issuer(...)` return 0. > > This patch changes the default behavior from "borking out the whole sent > chain" to "pop as much certs as needed to make it work". > > Basically, it pops the last cert and checks if the previous has known > issuer. > > [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 Hi Fedor As per my email on openssl-dev here are some notes on the patch submitted with this ticket: The patch changes the state that the chain is left in within ctx in the event of an error. As this is a public API function this is a problem as it could break applications that depend on the behaviour. This function is actually called from server code when constructing the cert chain. The behaviour change above breaks the cert chain construction. Also the value of "num" is incorrectly handled so that error messages are incorrect...usually returning X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. Finally the code goes into a loop in the event that it encounters an orphaned non-root cert in the cert store. The loop would be infinite except that the incorrect handling of num above means that it eventually escapes when the max depth is reached. As mentioned on openssl-dev I have an alternative patch with the same goal that addresses this issue. I am going to leave this ticket open until such time as that patch is in master. Matt From fedor at indutny.com Tue Jan 27 15:18:54 2015 From: fedor at indutny.com (Fedor Indutny) Date: Tue, 27 Jan 2015 19:18:54 +0400 Subject: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1 In-Reply-To: <54C7A880.9080803@openssl.org> References: <54B7CCD2.108@openssl.org> <54B7CD3B.8040706@openssl.org> <54C7A880.9080803@openssl.org> Message-ID: Thank you! On Tue, Jan 27, 2015 at 6:02 PM, Matt Caswell wrote: > > > On 15/01/15 17:06, Fedor Indutny wrote: > > Matt, > > > > Thank you for reply. > > > > May I ask you when do you think your patch may land in 1.0.2 or whatever? > > > > If this is something of your long term goals and not going to land > > anywhere soon. Could you please tell me about issues in my patch (either > > privately or in publi?)? > > My apologies for the delayed response. Things went a bit mad for a while > with releases and the source code reformat, and I completely forgot > about this email :-( > > I am hoping my patch will land in master (which means 1.1.0...aiming for > an end of year release). > > I will add some notes to your RT ticket regarding your patch. > > You can see my draft patch here: > https://github.com/mattcaswell/openssl/commits/late-check-trusted-v2 > > This is still going through review so may change. > > Matt > _______________________________________________ > 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 Tue Jan 27 15:34:50 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 27 Jan 2015 10:34:50 -0500 Subject: [openssl-dev] Windows build broken? Message-ID: <54C7B01A.8050002@cisco.com> It looks like the Windows export symbols may need updating now that the rsax engine has been removed (yesterday). Here's the error from the log... link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\ADMINI~1\AppData\Local\Temp\1\nm3A91.tmp LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_rsax out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE"' : return code '0x460' Stop. The full log is located here: http://173.39.238.160:8080/job/1_0_1_windows/16/console From Matthias.St.Pierre at ncp-e.com Tue Jan 27 16:15:37 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 27 Jan 2015 17:15:37 +0100 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups Message-ID: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> From: "Dr. Matthias St. Pierre" Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). Signed-off-by: Dr. Matthias St. Pierre --- crypto/ec/ec.h | 38 ++++++++++++++++++++++++++++++++++++++ crypto/ec/ec_asn1.c | 30 ++++++++++++++++++++++++++---- util/libeay.num | 10 ++++++++++ 3 files changed, 74 insertions(+), 4 deletions(-) This patch makes the ASN1 templates used internally by OpenSSL for serializing DH and ECDH group parameters publicly available for reuse. For example, if one wants to save a set of [EC]DH Groups together with application defined data (e.g, group-name, group-id) to a file, it is much easier to define a small set of ASN1 rules extending the existing ones and let OpenSSL do the serialization, than fiddling around with i2d_DHparams, i2d_ECParameters, etc. to embed the curve data as an opaque blob into an OCTET_STREAM. The patch was created against the OpenSSL_1_0_2-stable branch. If possible, it would be nice if it could be merged into the next 1.0.2 release. diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h index 98edfdf..97ccee8 100644 --- a/crypto/ec/ec.h +++ b/crypto/ec/ec.h @@ -128,6 +128,9 @@ typedef struct ec_group_st typedef struct ec_point_st EC_POINT; +typedef struct ecpk_parameters_st ECPKPARAMETERS; +typedef struct ec_parameters_st ECPARAMETERS; + /********************************************************************/ /* EC_METHODs for curves over GF(p) */ /********************************************************************/ @@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, */ EC_GROUP *EC_GROUP_new_by_curve_name(int nid); +/** Creates a new EC_GROUP object from an ECPARAMETERS object + * \param params pointer to the ECPARAMETERS object + * \return newly created EC_GROUP object with specified curve or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params); + +/** Creates an ECPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPARAMETERS object or NULL + * \return pointer to the new ECPARAMETERS object or NULL + * if an error occurred. + */ +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params); + +/** Creates a new EC_GROUP object from an ECPKPARAMETERS object + * \param params pointer to an existing ECPKPARAMETERS object, or NULL + * \return newly created EC_GROUP object with specified curve, or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params); + +/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPKPARAMETERS object or NULL + * \return pointer to the new ECPKPARAMETERS object or NULL + * if an error occurred. + */ +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params); + /********************************************************************/ /* handling of internal curves */ /********************************************************************/ @@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group); /* ASN1 stuff */ /********************************************************************/ +DECLARE_ASN1_ITEM(ECPKPARAMETERS) +DECLARE_ASN1_ITEM(ECPARAMETERS) + /* * EC_GROUP_get_basis_type() returns the NID of the basis type used to * represent the field elements diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c index 2924374..d84c6d2 100644 --- a/crypto/ec/ec_asn1.c +++ b/crypto/ec/ec_asn1.c @@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const ECPKPARAMETERS *); static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *, ECPKPARAMETERS *); +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params) +{ + return ec_asn1_parameters2group(params); +} + +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params) +{ + return ec_asn1_group2parameters(group, params); +} + +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params) +{ + return ec_asn1_pkparameters2group(params); +} + +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params) +{ + return ec_asn1_group2pkparameters(group, params); +} + /* the function definitions */ static int ec_asn1_group2fieldid(const EC_GROUP *group, X9_62_FIELDID *field) @@ -540,7 +562,7 @@ static int ec_asn1_group2curve(const EC_GROUP *group, X9_62_CURVE *curve) } static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, - ECPARAMETERS *param) + ECPARAMETERS *params) { int ok = 0; size_t len = 0; @@ -555,13 +577,13 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, goto err; } - if (param == NULL) { + if (params == NULL) { if ((ret = ECPARAMETERS_new()) == NULL) { ECerr(EC_F_EC_ASN1_GROUP2PARAMETERS, ERR_R_MALLOC_FAILURE); goto err; } } else - ret = param; + ret = params; /* set the version (always one) */ ret->version = (long)0x1; @@ -631,7 +653,7 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, ok = 1; err:if (!ok) { - if (ret && !param) + if (ret && !params) ECPARAMETERS_free(ret); ret = NULL; } diff --git a/util/libeay.num b/util/libeay.num index 4a11d78..bf0adc5 100755 --- a/util/libeay.num +++ b/util/libeay.num @@ -4412,3 +4412,13 @@ ECDSA_METHOD_get_app_data 4770 EXIST::FUNCTION:ECDSA X509_VERIFY_PARAM_add1_host 4771 EXIST::FUNCTION: EC_GROUP_get_mont_data 4772 EXIST::FUNCTION:EC i2d_re_X509_tbs 4773 EXIST::FUNCTION: +DHparams_it 4774 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH +DHparams_it 4774 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH +ECPARAMETERS_it 4775 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPARAMETERS_it 4775 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +ECPKPARAMETERS_it 4776 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPKPARAMETERS_it 4776 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +EC_GROUP_new_from_ecparameters 4777 EXIST::FUNCTION:EC +EC_GROUP_get_ecparameters 4778 EXIST::FUNCTION:EC +EC_GROUP_new_from_ecpkparameters 4779 EXIST::FUNCTION:EC +EC_GROUP_get_ecpkparameters 4780 EXIST::FUNCTION:EC -- 2.0.5 From rt at openssl.org Tue Jan 27 17:42:52 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 27 Jan 2015 18:42:52 +0100 Subject: [openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1 In-Reply-To: <3ad3e323f53cc208961c50eaa3e2bc29.squirrel@mailhost.ut.ee> References: <3ad3e323f53cc208961c50eaa3e2bc29.squirrel@mailhost.ut.ee> Message-ID: It is no longer an option to build OpenSSL without SHA, so closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rsalz at akamai.com Tue Jan 27 17:54:15 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 17:54:15 +0000 Subject: [openssl-dev] Windows build broken? In-Reply-To: <54C7B01A.8050002@cisco.com> References: <54C7B01A.8050002@cisco.com> Message-ID: <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> > It looks like the Windows export symbols may need updating now that the > rsax engine has been removed (yesterday). Here's the error from the log... If you remove the reference to it from util/libeay.num does that fix the build? -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From foleyj at cisco.com Tue Jan 27 17:59:13 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 27 Jan 2015 12:59:13 -0500 Subject: [openssl-dev] Windows build broken? In-Reply-To: <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <54C7D1F1.30108@cisco.com> I'm sure this would resolve the issue. The problem exists in 1.0.1, but not 1.0.2. Here's the entry in the 1.0.1 libeay.num: ENGINE_load_rsax 4652 EXIST::FUNCTION:ENGINE And here's the entry in the 1.0.2 flavor of libeay.num: ENGINE_load_rsax 4652 NOEXIST::FUNCTION: You just need to to "make util/libeay.num" in the 1.0.1-stable branch. FYI, I have not checked master. On 01/27/2015 12:54 PM, Salz, Rich wrote: >> It looks like the Windows export symbols may need updating now that the >> rsax engine has been removed (yesterday). Here's the error from the log... > If you remove the reference to it from util/libeay.num does that fix the build? > > -- > 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 > From rsalz at akamai.com Tue Jan 27 18:06:08 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 18:06:08 +0000 Subject: [openssl-dev] Windows build broken? In-Reply-To: <54C7D1F1.30108@cisco.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> Message-ID: <5f55f172d72f49d7ae5fc00682960f9b@ustx2ex-dag1mb2.msg.corp.akamai.com> Oh, I thought it was in master! In 1.0.1 it was a mistake to remove eng_rsax. And a commit to fix that will be submitted shortl. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From foleyj at cisco.com Tue Jan 27 18:57:01 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 27 Jan 2015 13:57:01 -0500 Subject: [openssl-dev] Windows build broken? In-Reply-To: <5f55f172d72f49d7ae5fc00682960f9b@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> <5f55f172d72f49d7ae5fc00682960f9b@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <54C7DF7D.9060505@cisco.com> Thanks for the update. I was curious why it was removed from 1.0.1. It seemed to be beyond the scope of a bug fix. Given 1.0.2 has now been released, should eng_rsax been removed there too? On 01/27/2015 01:06 PM, Salz, Rich wrote: > Oh, I thought it was in master! > > In 1.0.1 it was a mistake to remove eng_rsax. And a commit to fix that will be submitted shortl. > > > -- > 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 > From rsalz at akamai.com Tue Jan 27 19:48:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 19:48:06 +0000 Subject: [openssl-dev] TSLEXT_TYPE_opaque_prf_input Message-ID: <12fb575d38d74fd5ae5ef191f7b4c1d7@ustx2ex-dag1mb2.msg.corp.akamai.com> This is an implementation of an IETF draft that expired seven years ago. Is anyone using it? -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at zacarias.com.ar Tue Jan 27 21:30:52 2015 From: gustavo at zacarias.com.ar (Gustavo Zacarias) Date: Tue, 27 Jan 2015 18:30:52 -0300 Subject: [openssl-dev] [PATCH] Make c_rehash match commands starting with - (minus) instead of minus in any starting position, otherwise a directory named a-b breaks it Message-ID: <1422394252-27640-1-git-send-email-gustavo@zacarias.com.ar> Signed-off-by: Gustavo Zacarias --- tools/c_rehash.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/c_rehash.in b/tools/c_rehash.in index 887e927..1df2fab 100644 --- a/tools/c_rehash.in +++ b/tools/c_rehash.in @@ -15,7 +15,7 @@ my $symlink_exists=eval {symlink("",""); 1}; my $removelinks = 1; ## Parse flags. -while ( $ARGV[0] =~ '-.*' ) { +while ( $ARGV[0] =~ '^-.*' ) { my $flag = shift @ARGV; last if ( $flag eq '--'); if ( $flag =~ /-old/) { -- 2.0.5 From rsalz at akamai.com Tue Jan 27 22:05:52 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Jan 2015 22:05:52 +0000 Subject: [openssl-dev] Windows build broken? In-Reply-To: <54C7D1F1.30108@cisco.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> Message-ID: <5652dc176d34406a9e4b0b452f2805cf@ustx2ex-dag1mb2.msg.corp.akamai.com> > I'm sure this would resolve the issue. The problem exists in 1.0.1, but not > 1.0.2. Here's the entry in the 1.0.1 libeay.num: Fixed. It was a mistake to remove engine_rsax, and I just reverted that. Should show up in the snapshots within an hour From matt at openssl.org Tue Jan 27 23:52:01 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Jan 2015 23:52:01 +0000 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: <54C824A1.30604@openssl.org> Please submit patches to rt at openssl.org. Matt On 27/01/15 16:15, Dr. Matthias St. Pierre wrote: > From: "Dr. Matthias St. Pierre" > > Add missing forward declarations and export declarations for DHparams > and EC[PK]PARAMETERS. > > Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS > objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). > > Signed-off-by: Dr. Matthias St. Pierre > --- > crypto/ec/ec.h | 38 ++++++++++++++++++++++++++++++++++++++ > crypto/ec/ec_asn1.c | 30 ++++++++++++++++++++++++++---- > util/libeay.num | 10 ++++++++++ > 3 files changed, 74 insertions(+), 4 deletions(-) > > This patch makes the ASN1 templates used internally by OpenSSL for > serializing DH and ECDH group parameters publicly available for reuse. > > For example, if one wants to save a set of [EC]DH Groups together with > application defined data (e.g, group-name, group-id) to a file, it > is much easier to define a small set of ASN1 rules extending the existing > ones and let OpenSSL do the serialization, than fiddling around with > i2d_DHparams, i2d_ECParameters, etc. to embed the curve data as an > opaque blob into an OCTET_STREAM. > > The patch was created against the OpenSSL_1_0_2-stable branch. If possible, > it would be nice if it could be merged into the next 1.0.2 release. > > diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h > index 98edfdf..97ccee8 100644 > --- a/crypto/ec/ec.h > +++ b/crypto/ec/ec.h > @@ -128,6 +128,9 @@ typedef struct ec_group_st > > typedef struct ec_point_st EC_POINT; > > +typedef struct ecpk_parameters_st ECPKPARAMETERS; > +typedef struct ec_parameters_st ECPARAMETERS; > + > /********************************************************************/ > /* EC_METHODs for curves over GF(p) */ > /********************************************************************/ > @@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, > */ > EC_GROUP *EC_GROUP_new_by_curve_name(int nid); > > +/** Creates a new EC_GROUP object from an ECPARAMETERS object > + * \param params pointer to the ECPARAMETERS object > + * \return newly created EC_GROUP object with specified curve or NULL > + * if an error occurred > + */ > +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params); > + > +/** Creates an ECPARAMETERS object for the the given EC_GROUP object. > + * \param group pointer to the EC_GROUP object > + * \param params pointer to an existing ECPARAMETERS object or NULL > + * \return pointer to the new ECPARAMETERS object or NULL > + * if an error occurred. > + */ > +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, > + ECPARAMETERS *params); > + > +/** Creates a new EC_GROUP object from an ECPKPARAMETERS object > + * \param params pointer to an existing ECPKPARAMETERS object, or NULL > + * \return newly created EC_GROUP object with specified curve, or NULL > + * if an error occurred > + */ > +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params); > + > +/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object. > + * \param group pointer to the EC_GROUP object > + * \param params pointer to an existing ECPKPARAMETERS object or NULL > + * \return pointer to the new ECPKPARAMETERS object or NULL > + * if an error occurred. > + */ > +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, > + ECPKPARAMETERS *params); > + > /********************************************************************/ > /* handling of internal curves */ > /********************************************************************/ > @@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group); > /* ASN1 stuff */ > /********************************************************************/ > > +DECLARE_ASN1_ITEM(ECPKPARAMETERS) > +DECLARE_ASN1_ITEM(ECPARAMETERS) > + > /* > * EC_GROUP_get_basis_type() returns the NID of the basis type used to > * represent the field elements > diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c > index 2924374..d84c6d2 100644 > --- a/crypto/ec/ec_asn1.c > +++ b/crypto/ec/ec_asn1.c > @@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const ECPKPARAMETERS *); > static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *, > ECPKPARAMETERS *); > > +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params) > +{ > + return ec_asn1_parameters2group(params); > +} > + > +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, > + ECPARAMETERS *params) > +{ > + return ec_asn1_group2parameters(group, params); > +} > + > +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params) > +{ > + return ec_asn1_pkparameters2group(params); > +} > + > +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, > + ECPKPARAMETERS *params) > +{ > + return ec_asn1_group2pkparameters(group, params); > +} > + > /* the function definitions */ > > static int ec_asn1_group2fieldid(const EC_GROUP *group, X9_62_FIELDID *field) > @@ -540,7 +562,7 @@ static int ec_asn1_group2curve(const EC_GROUP *group, X9_62_CURVE *curve) > } > > static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, > - ECPARAMETERS *param) > + ECPARAMETERS *params) > { > int ok = 0; > size_t len = 0; > @@ -555,13 +577,13 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, > goto err; > } > > - if (param == NULL) { > + if (params == NULL) { > if ((ret = ECPARAMETERS_new()) == NULL) { > ECerr(EC_F_EC_ASN1_GROUP2PARAMETERS, ERR_R_MALLOC_FAILURE); > goto err; > } > } else > - ret = param; > + ret = params; > > /* set the version (always one) */ > ret->version = (long)0x1; > @@ -631,7 +653,7 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, > ok = 1; > > err:if (!ok) { > - if (ret && !param) > + if (ret && !params) > ECPARAMETERS_free(ret); > ret = NULL; > } > diff --git a/util/libeay.num b/util/libeay.num > index 4a11d78..bf0adc5 100755 > --- a/util/libeay.num > +++ b/util/libeay.num > @@ -4412,3 +4412,13 @@ ECDSA_METHOD_get_app_data 4770 EXIST::FUNCTION:ECDSA > X509_VERIFY_PARAM_add1_host 4771 EXIST::FUNCTION: > EC_GROUP_get_mont_data 4772 EXIST::FUNCTION:EC > i2d_re_X509_tbs 4773 EXIST::FUNCTION: > +DHparams_it 4774 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH > +DHparams_it 4774 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH > +ECPARAMETERS_it 4775 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC > +ECPARAMETERS_it 4775 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC > +ECPKPARAMETERS_it 4776 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC > +ECPKPARAMETERS_it 4776 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC > +EC_GROUP_new_from_ecparameters 4777 EXIST::FUNCTION:EC > +EC_GROUP_get_ecparameters 4778 EXIST::FUNCTION:EC > +EC_GROUP_new_from_ecpkparameters 4779 EXIST::FUNCTION:EC > +EC_GROUP_get_ecpkparameters 4780 EXIST::FUNCTION:EC > From dkg at fifthhorseman.net Wed Jan 28 05:02:16 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Jan 2015 00:02:16 -0500 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: <87d25zh50n.fsf@alice.fifthhorseman.net> On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: > Add missing forward declarations and export declarations for DHparams > and EC[PK]PARAMETERS. > > Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS > objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). fwiw, the IETF TLS WG is moving away from the possibility of arbitrary EC groups, and toward the requirement of specified and vetted EC groups. I'm not sure how much extra work should be done to maintain that as a public-facing interface. --dkg From Satish.KumarYarru at cognizant.com Wed Jan 28 05:07:58 2015 From: Satish.KumarYarru at cognizant.com (Satish.KumarYarru at cognizant.com) Date: Wed, 28 Jan 2015 05:07:58 +0000 Subject: [openssl-dev] Loading of different Server CA certificates Message-ID: Hi, I want to connect with different SSL servers. So I need to load different Server CA certs into SSL Context. Is it possible to load different server CA certs of different SSL servers in a single SSL Context? If yes, when I am connecting with SSL server, SSL client can traverse all the CA certificates in the SSL context, and can find the CA certificate that is fit for the Server URL? If not, can you please help me how to address this issue? 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 dthompson at prinpay.com Wed Jan 28 07:49:34 2015 From: dthompson at prinpay.com (Dave Thompson) Date: Wed, 28 Jan 2015 02:49:34 -0500 Subject: [openssl-dev] Loading of different Server CA certificates In-Reply-To: References: Message-ID: <005701d03ace$f7d94630$e78bd290$@prinpay.com> > From: openssl-dev On Behalf Of Satish.KumarYarru at cognizant.com > Sent: Wednesday, January 28, 2015 00:08 This is a basic user question, not dev. > I want to connect with different SSL servers. So I need to load different Server CA certs into SSL Context. If the servers are (or may be) using different CAs, yes. > Is it possible to load different server CA certs of different SSL servers in a single SSL Context? > If yes, when I am connecting with SSL server, SSL client can traverse all the CA certificates > in the SSL context, and can find the CA certificate that is fit for the Server URL? ? Yes. There are actually two mechanisms. For CAfile, all the certs are loaded into memory, and the lookup just searches them. For CApath, the certs are left on disk, with filenames using hashes of the canonical subject names; lookup takes the hash of the needed CA, and reads the file(s) if any for that hash to find it. See the manpage on your system or at https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html . Also https://www.openssl.org/docs/apps/verify.html for some more details. From Matthias.St.Pierre at ncp-e.com Wed Jan 28 08:43:49 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 28 Jan 2015 09:43:49 +0100 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <54C824A1.30604@openssl.org> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> <54C824A1.30604@openssl.org> Message-ID: <54C8A145.4040700@ncp-e.com> Hello, On 01/28/2015 12:52 AM, Matt Caswell wrote: > Please submit patches to rt at openssl.org. Sorry about that, I will repost it. I overlooked . Instead, I followed the FAQ which sent me to the README file, and there was no mention of the request tracker. Maybe you could update the FAQ and the README accordingly? Matthias see From Matthias.St.Pierre at ncp-e.com Wed Jan 28 08:44:10 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 28 Jan 2015 09:44:10 +0100 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <87d25zh50n.fsf@alice.fifthhorseman.net> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> <87d25zh50n.fsf@alice.fifthhorseman.net> Message-ID: <54C8A15A.5060707@ncp-e.com> On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote: > On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: >> Add missing forward declarations and export declarations for DHparams >> and EC[PK]PARAMETERS. >> >> Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS >> objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). > > fwiw, the IETF TLS WG is moving away from the possibility of arbitrary > EC groups, and toward the requirement of specified and vetted EC > groups. I'm not sure how much extra work should be done to maintain > that as a public-facing interface. As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but for the 'low level' libcrypto library, which is in my opinion a general purpose crypto library. As such, it should not make assumptions on or impose restrictions to possible use cases of the library. Neither should it enforce standards, but provide algorithms. My patch does not introduce new features or change existing ones. It just makes functionality available for reuse. I needed this particular functionality and I had the choice between 1) copy & paste the code 2) patch OpenSSL privately, or 3) submit a patch. So I chose the latter. Regards, Matthias From rt at openssl.org Wed Jan 28 09:42:02 2015 From: rt at openssl.org (Dr. Matthias St. Pierre via RT) Date: Wed, 28 Jan 2015 10:42:02 +0100 Subject: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <1422347341-5962-1-git-send-email-msp@ncp-e.com> References: <1422347341-5962-1-git-send-email-msp@ncp-e.com> Message-ID: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). Signed-off-by: Dr. Matthias St. Pierre --- crypto/ec/ec.h | 38 ++++++++++++++++++++++++++++++++++++++ crypto/ec/ec_asn1.c | 30 ++++++++++++++++++++++++++---- util/libeay.num | 10 ++++++++++ 3 files changed, 74 insertions(+), 4 deletions(-) This patch makes the ASN1 templates used internally by OpenSSL for serializing DH and ECDH group parameters publicly available for reuse. For example, if one wants to save a set of [EC]DH Groups together with application defined data (like, group-name, group-id) to a file, it is much easier to define a small set of ASN1 rules extending the existing ones and let OpenSSL do the serialization, than having to fiddle around with i2d_DHparams(), i2d_ECParameters(), etc., to embed the curve data as a blob into an opaque ASN1 octet string. diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h index 98edfdf..97ccee8 100644 --- a/crypto/ec/ec.h +++ b/crypto/ec/ec.h @@ -128,6 +128,9 @@ typedef struct ec_group_st typedef struct ec_point_st EC_POINT; +typedef struct ecpk_parameters_st ECPKPARAMETERS; +typedef struct ec_parameters_st ECPARAMETERS; + /********************************************************************/ /* EC_METHODs for curves over GF(p) */ /********************************************************************/ @@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, */ EC_GROUP *EC_GROUP_new_by_curve_name(int nid); +/** Creates a new EC_GROUP object from an ECPARAMETERS object + * \param params pointer to the ECPARAMETERS object + * \return newly created EC_GROUP object with specified curve or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params); + +/** Creates an ECPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPARAMETERS object or NULL + * \return pointer to the new ECPARAMETERS object or NULL + * if an error occurred. + */ +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params); + +/** Creates a new EC_GROUP object from an ECPKPARAMETERS object + * \param params pointer to an existing ECPKPARAMETERS object, or NULL + * \return newly created EC_GROUP object with specified curve, or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params); + +/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPKPARAMETERS object or NULL + * \return pointer to the new ECPKPARAMETERS object or NULL + * if an error occurred. + */ +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params); + /********************************************************************/ /* handling of internal curves */ /********************************************************************/ @@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group); /* ASN1 stuff */ /********************************************************************/ +DECLARE_ASN1_ITEM(ECPKPARAMETERS) +DECLARE_ASN1_ITEM(ECPARAMETERS) + /* * EC_GROUP_get_basis_type() returns the NID of the basis type used to * represent the field elements diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c index 2924374..d84c6d2 100644 --- a/crypto/ec/ec_asn1.c +++ b/crypto/ec/ec_asn1.c @@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const ECPKPARAMETERS *); static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *, ECPKPARAMETERS *); +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params) +{ + return ec_asn1_parameters2group(params); +} + +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params) +{ + return ec_asn1_group2parameters(group, params); +} + +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params) +{ + return ec_asn1_pkparameters2group(params); +} + +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params) +{ + return ec_asn1_group2pkparameters(group, params); +} + /* the function definitions */ static int ec_asn1_group2fieldid(const EC_GROUP *group, X9_62_FIELDID *field) @@ -540,7 +562,7 @@ static int ec_asn1_group2curve(const EC_GROUP *group, X9_62_CURVE *curve) } static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, - ECPARAMETERS *param) + ECPARAMETERS *params) { int ok = 0; size_t len = 0; @@ -555,13 +577,13 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, goto err; } - if (param == NULL) { + if (params == NULL) { if ((ret = ECPARAMETERS_new()) == NULL) { ECerr(EC_F_EC_ASN1_GROUP2PARAMETERS, ERR_R_MALLOC_FAILURE); goto err; } } else - ret = param; + ret = params; /* set the version (always one) */ ret->version = (long)0x1; @@ -631,7 +653,7 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, ok = 1; err:if (!ok) { - if (ret && !param) + if (ret && !params) ECPARAMETERS_free(ret); ret = NULL; } diff --git a/util/libeay.num b/util/libeay.num index 4a11d78..bf0adc5 100755 --- a/util/libeay.num +++ b/util/libeay.num @@ -4412,3 +4412,13 @@ ECDSA_METHOD_get_app_data 4770 EXIST::FUNCTION:ECDSA X509_VERIFY_PARAM_add1_host 4771 EXIST::FUNCTION: EC_GROUP_get_mont_data 4772 EXIST::FUNCTION:EC i2d_re_X509_tbs 4773 EXIST::FUNCTION: +DHparams_it 4774 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH +DHparams_it 4774 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH +ECPARAMETERS_it 4775 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPARAMETERS_it 4775 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +ECPKPARAMETERS_it 4776 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPKPARAMETERS_it 4776 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +EC_GROUP_new_from_ecparameters 4777 EXIST::FUNCTION:EC +EC_GROUP_get_ecparameters 4778 EXIST::FUNCTION:EC +EC_GROUP_new_from_ecpkparameters 4779 EXIST::FUNCTION:EC +EC_GROUP_get_ecpkparameters 4780 EXIST::FUNCTION:EC -- 2.0.5 From rt at openssl.org Wed Jan 28 09:42:45 2015 From: rt at openssl.org (Jerabek, Petr via RT) Date: Wed, 28 Jan 2015 10:42:45 +0100 Subject: [openssl-dev] [openssl.org #3677] bug report - open ssl interactive command interface In-Reply-To: <09DED2AD0503184390C12250C5676819136C2063@SKDAMBXM03.mb.skoda.vwg> References: <09DED2AD0503184390C12250C5676819136C2063@SKDAMBXM03.mb.skoda.vwg> Message-ID: Hello, I found bug in interactive command inteface of openssl. I did not check whether it is related only to specific windows build of openssl. Please do test of behavior in other builds first. Used openssl version: OpenSSL 1.0.1h 5 Jun 2014; Windows build Bug description: By mistake pressed tab key in command interface to expand path for enter path (tab path expansion is working in common windows command prompt) to certificate for verification (command x509). Tab expansion is of course not working in openssl. Problem is that using tab,backspace key sequence corrupts command buffer and some way memory of open ssl is corrupted. See attachment for content of corupted session. First command in file was the one where I used tab, backspace key sequence. Characters xw at the end of first command line were not possible to delete. Regards, Petr Jerabek -------------- next part -------------- OpenSSL> OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp xw Error opening Certificate c:\temp\cx ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cx 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp\cxwi.cer Error opening Certificate c:\temp\cxwi.cer ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cxwi.cer 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp\cxwi.cer Error opening Certificate c:\temp\cxwi.cer ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cxwi.cer 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp\cxwi.cer Error opening Certificate c:\temp\cxwi.cer ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cxwi.cer 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp\cxwi.cer Error opening Certificate c:\temp\cxwi.cer ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cxwi.cer 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> x509 -noout -dates -fingerprint -text -checkend 1209600 -certopt no_issuer,no_validity,no_serial,no_signame,no_sigdump,no_pubkey,no_aux,no_version,ext_default -in c:\temp\cxwi.cer Error opening Certificate c:\temp\cxwi.cer ','rb')ror:0200107B:system library:fopen:Unknown error:.\crypto\bio\bss_file.c:398:fopen('c:\temp\cxwi.cer 1916:error:20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.c:400: unable to load certificate error in x509 OpenSSL> ? ' is an invalid command. Standard commands asn1parse ca ciphers cms crl crl2pkcs7 dgst dh dhparam dsa dsaparam ec ecparam enc engine errstr gendh gendsa genpkey genrsa nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp ts verify version x509 Message Digest commands (see the `dgst' command for more details) md4 md5 mdc2 rmd160 sha sha1 Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 seed seed-cbc seed-cfb seed-ecb seed-ofb OpenSSL> version ' is an invalid command. Standard commands asn1parse ca ciphers cms crl crl2pkcs7 dgst dh dhparam dsa dsaparam ec ecparam enc engine errstr gendh gendsa genpkey genrsa nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp ts verify version x509 Message Digest commands (see the `dgst' command for more details) md4 md5 mdc2 rmd160 sha sha1 Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 seed seed-cbc seed-cfb seed-ecb seed-ofb From rt at openssl.org Wed Jan 28 09:43:11 2015 From: rt at openssl.org (Devchandra L Meetei via RT) Date: Wed, 28 Jan 2015 10:43:11 +0100 Subject: [openssl-dev] [openssl.org #3678] [PATCH] Correct the BIO_new_bio_pair example in man page In-Reply-To: References: Message-ID: Hi all Please check if the man page correction for BIO_new_bio_pair. The earlier one was hard to understand and had to scratch hair for a long time Also it corrects syntax error in BIO_new_bio_pair. -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did," Steve Jobs -------------- next part -------------- diff --git a/doc/crypto/BIO_s_bio.pod b/doc/crypto/BIO_s_bio.pod index 8d0a55a..51179d1 100644 --- a/doc/crypto/BIO_s_bio.pod +++ b/doc/crypto/BIO_s_bio.pod @@ -136,9 +136,9 @@ without having to go through the SSL-interface. BIO *internal_bio, *network_bio; ... - BIO_new_bio_pair(internal_bio, 0, network_bio, 0); + BIO_new_bio_pair(&internal_bio, 0, &network_bio, 0); SSL_set_bio(ssl, internal_bio, internal_bio); - SSL_operations(); + SSL_operations(); //e.g SSL_read and SSL_write ... application | TLS-engine @@ -147,9 +147,13 @@ without having to go through the SSL-interface. | /\ || | || \/ | BIO-pair (internal_bio) - +----------< BIO-pair (network_bio) + | BIO-pair (network_bio) + | || /\ + | \/ || + +-----------< BIO_operations() | | - socket | + | | + socket ... SSL_free(ssl); /* implicitly frees internal_bio */ From rt at openssl.org Wed Jan 28 09:49:06 2015 From: rt at openssl.org (David Ramos via RT) Date: Wed, 28 Jan 2015 10:49:06 +0100 Subject: [openssl-dev] [openssl.org #3679] Memory leak in ssl_cert_dup (ssl/ssl_cert.c) In-Reply-To: <6E80F533-783E-4670-9F08-258D2A427DE3@stanford.edu> References: <6E80F533-783E-4670-9F08-258D2A427DE3@stanford.edu> Message-ID: Hello, Our UC-KLEE tool found a memory leak in ssl_cert_dup (ssl/ssl_cert.c). The bug affects commit 43257b9f51de749262258668c77c2f0f99d7a15b from the 1.0.2 branch, but it appears to date back many years. On line 222 of ssl/ssl_cert.c, ssl_cert_dup() allocates a new CERT: ret = (CERT *)OPENSSL_malloc(sizeof(CERT)); If any of the subsequent allocations or _dup()?s fail, we jump to ?err?, which frees many of the fields within ?ret?, but forgets to free ?ret? itself (leaking 728 bytes on my x86_64 Linux build). I believe there needs to be a call to: OPENSSL_free(ret); before the 'return NULL' at line 440. Please let me know if you have any questions. Thanks, -David From foleyj at cisco.com Wed Jan 28 14:23:19 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 28 Jan 2015 09:23:19 -0500 Subject: [openssl-dev] Windows build broken? In-Reply-To: <5652dc176d34406a9e4b0b452f2805cf@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> <5652dc176d34406a9e4b0b452f2805cf@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <54C8F0D7.6010407@cisco.com> Thanks for fixing this. Windows is now building on 1_0_1-stable. Having said that, you inspired me to add another job on my jenkins server to to a sanity build on master for Windows. I'm seeing the following error when trying to build on master using the identical build process. Should I dig deeper, or is this a known issue? c:\nightly\workspace\master_windows>ms\do_nasm.bat c:\nightly\workspace\master_windows>perl util\mkfiles.pl 1>MINFO c:\nightly\workspace\master_windows>perl util\mk1mf.pl nasm VC-WIN32 1>ms\nt.mak no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. c:\nightly\workspace\master_windows>perl util\mk1mf.pl dll nasm VC-WIN32 1>ms\ntdll.mak no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. c:\nightly\workspace\master_windows>perl util\mk1mf.pl nasm BC-NT 1>ms\bcb.mak no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 libeay 1>ms\libeay32.def No such class my at util\mkdef.pl line 143, near "my my" Execution of util\mkdef.pl aborted due to compilation errors. c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def No such class my at util\mkdef.pl line 143, near "my my" Execution of util\mkdef.pl aborted due to compilation errors. Build step 'Execute Windows batch command' marked build as failure Sending e-mails to: foleyj at cisco.com Finished: FAILURE On 01/27/2015 05:05 PM, Salz, Rich wrote: >> I'm sure this would resolve the issue. The problem exists in 1.0.1, but not >> 1.0.2. Here's the entry in the 1.0.1 libeay.num: > Fixed. It was a mistake to remove engine_rsax, and I just reverted that. Should show up in the snapshots within an hour > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From matt at openssl.org Wed Jan 28 14:27:02 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Jan 2015 14:27:02 +0000 Subject: [openssl-dev] Windows build broken? In-Reply-To: <54C8F0D7.6010407@cisco.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> <5652dc176d34406a9e4b0b452f2805cf@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C8F0D7.6010407@cisco.com> Message-ID: <54C8F1B6.9050806@openssl.org> On 28/01/15 14:23, John Foley wrote: > Thanks for fixing this. Windows is now building on 1_0_1-stable. > Having said that, you inspired me to add another job on my jenkins > server to to a sanity build on master for Windows. I'm seeing the > following error when trying to build on master using the identical build > process. Should I dig deeper, or is this a known issue? > > c:\nightly\workspace\master_windows>ms\do_nasm.bat > > c:\nightly\workspace\master_windows>perl util\mkfiles.pl 1>MINFO > > c:\nightly\workspace\master_windows>perl util\mk1mf.pl nasm VC-WIN32 1>ms\nt.mak > no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. > > c:\nightly\workspace\master_windows>perl util\mk1mf.pl dll nasm VC-WIN32 1>ms\ntdll.mak > no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. > > c:\nightly\workspace\master_windows>perl util\mk1mf.pl nasm BC-NT 1>ms\bcb.mak > no rule for crypto\sha\shatest at util\mk1mf.pl line 1253. > > c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 libeay 1>ms\libeay32.def > No such class my at util\mkdef.pl line 143, near "my my" > Execution of util\mkdef.pl aborted due to compilation errors. > > c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def > No such class my at util\mkdef.pl line 143, near "my my" > Execution of util\mkdef.pl aborted due to compilation errors. > Build step 'Execute Windows batch command' marked build as failure > Sending e-mails to: foleyj at cisco.com > Finished: FAILURE Yes, its a known issue. There is a fix on the way for this too. Matt From rsalz at akamai.com Wed Jan 28 16:41:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Jan 2015 16:41:18 +0000 Subject: [openssl-dev] Windows build broken? In-Reply-To: <54C7DF7D.9060505@cisco.com> References: <54C7B01A.8050002@cisco.com> <1cbd490bf1b04887a89ddbed7a555fde@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7D1F1.30108@cisco.com> <5f55f172d72f49d7ae5fc00682960f9b@ustx2ex-dag1mb2.msg.corp.akamai.com> <54C7DF7D.9060505@cisco.com> Message-ID: <65177416813e42ac90821f2615f7d5fd@ustx2ex-dag1mb2.msg.corp.akamai.com> > Thanks for the update. I was curious why it was removed from 1.0.1. It > seemed to be beyond the scope of a bug fix. Given 1.0.2 has now been > released, should eng_rsax been removed there too? I goofed removing it from 1.0.1 For 1.0.2 it wasn't compiled so it's just an OCD kinda thing :) From dkg at fifthhorseman.net Wed Jan 28 17:16:05 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Jan 2015 12:16:05 -0500 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <54C8A15A.5060707@ncp-e.com> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> <87d25zh50n.fsf@alice.fifthhorseman.net> <54C8A15A.5060707@ncp-e.com> Message-ID: <87fvaug71m.fsf@alice.fifthhorseman.net> On Wed 2015-01-28 03:44:10 -0500, Dr. Matthias St. Pierre wrote: > On 01/28/2015 06:02 AM, Daniel Kahn Gillmor wrote: >> On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: >>> Add missing forward declarations and export declarations for DHparams >>> and EC[PK]PARAMETERS. >>> >>> Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS >>> objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). >> >> fwiw, the IETF TLS WG is moving away from the possibility of arbitrary >> EC groups, and toward the requirement of specified and vetted EC >> groups. I'm not sure how much extra work should be done to maintain >> that as a public-facing interface. > > As for TLS, you maybe right. However, the use of Diffie-Hellman is not limited > to TLS (in my case, it's IKEv2). The proposed changes are not for libssl, but for > the 'low level' libcrypto library, which is in my opinion a general purpose crypto > library. As such, it should not make assumptions on or impose restrictions to possible > use cases of the library. Neither should it enforce standards, but provide algorithms. > > My patch does not introduce new features or change existing ones. It just makes > functionality available for reuse. I needed this particular functionality and I > had the choice between 1) copy & paste the code 2) patch OpenSSL privately, or > 3) submit a patch. So I chose the latter. Your choice of action makes sense to me, thanks! --dkg From rsalz at akamai.com Wed Jan 28 17:18:21 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Jan 2015 17:18:21 +0000 Subject: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <87fvaug71m.fsf@alice.fifthhorseman.net> References: <1422375337-31999-1-git-send-email-Matthias.St.Pierre@ncp-e.com> <87d25zh50n.fsf@alice.fifthhorseman.net> <54C8A15A.5060707@ncp-e.com> <87fvaug71m.fsf@alice.fifthhorseman.net> Message-ID: <3bcb337432a4459ab9f08a7410fda2a7@ustx2ex-dag1mb2.msg.corp.akamai.com> > > 3) submit a patch. So I chose the latter. > > Your choice of action makes sense to me, thanks! Thanks for the patch, it seems useful and makes sense. From kannanar at cisco.com Thu Jan 29 06:33:13 2015 From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco)) Date: Thu, 29 Jan 2015 06:33:13 +0000 Subject: [openssl-dev] Poodle Vulnerable Message-ID: Hi, For poodle vulnerability we have upgraded the openssl to 0.9.8zc version. But still result shows as vulnerable. (downloaded poodle.sh script from the link https://access.redhat.com/articles/1232123 to verify) Thanks, Kannan Narayanasamy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gvanem at yahoo.no Thu Jan 29 12:09:09 2015 From: gvanem at yahoo.no (Gisle Vanem) Date: Thu, 29 Jan 2015 12:09:09 +0000 Subject: [openssl-dev] crypto/threads/th-lock.c error Message-ID: <54CA22E5.70705@yahoo.no> I'm truly amazed that this error has been in there so long. From MingW's gcc: crypto/threads/th-lock.c:130:13: error: static declaration of 'CRYPTO_thread_cleanup' follows non-static declaration crypto/threads/th-lock.c:89:6: note: previous declaration of 'CRYPTO_thread_cleanup' was here Patch: --- a/crypto/threads/th-lock.c 2015-01-28 22:47:16 +0000 +++ b/crypto/threads/th-lock.c 2015-01-29 13:05:34 +0000 @@ -127,7 +127,7 @@ return (1); } -static void CRYPTO_thread_cleanup(void) +void CRYPTO_thread_cleanup(void) { int i; ---------- -- --gv From thoger at redhat.com Thu Jan 29 15:01:27 2015 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 29 Jan 2015 16:01:27 +0100 Subject: [openssl-dev] Poodle Vulnerable In-Reply-To: References: Message-ID: <20150129160127.2bc194a0@redhat.com> On Thu, 29 Jan 2015 06:33:13 +0000 Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > For poodle vulnerability we have upgraded the openssl to 0.9.8zc > version. But still result shows as vulnerable. (downloaded poodle.sh > script from the link https://access.redhat.com/articles/1232123 to > verify) The script checks if a target server has SSL 3.0 enabled, i.e. the PO part of POODLE. OpenSSL 0.9.8zc does not address that, it adds a feature (TLS_FALLBACK_SCSV) to help mitigate/block the DLE part. The script does not attempt to check if the server implements this fallback protection. -- Tomas Hoger From kannanar at cisco.com Thu Jan 29 19:25:43 2015 From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco)) Date: Thu, 29 Jan 2015 19:25:43 +0000 Subject: [openssl-dev] Poodle Vulnerable In-Reply-To: <20150129160127.2bc194a0@redhat.com> References: <20150129160127.2bc194a0@redhat.com> Message-ID: Hi Thomas, Thanks for the details. Is there any openssl version has the fix for this? Seems from openssl site they have pointed that the fix was in 0.9.8zc version. How to overcome this issue. Thanks, Kannan Narayanasamy. -----Original Message----- From: Tomas Hoger [mailto:thoger at redhat.com] Sent: Thursday, January 29, 2015 8:31 PM To: Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] Poodle Vulnerable On Thu, 29 Jan 2015 06:33:13 +0000 Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > For poodle vulnerability we have upgraded the openssl to 0.9.8zc > version. But still result shows as vulnerable. (downloaded poodle.sh > script from the link https://access.redhat.com/articles/1232123 to > verify) The script checks if a target server has SSL 3.0 enabled, i.e. the PO part of POODLE. OpenSSL 0.9.8zc does not address that, it adds a feature (TLS_FALLBACK_SCSV) to help mitigate/block the DLE part. The script does not attempt to check if the server implements this fallback protection. -- Tomas Hoger From rsalz at akamai.com Thu Jan 29 19:28:45 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Jan 2015 19:28:45 +0000 Subject: [openssl-dev] Poodle Vulnerable In-Reply-To: References: <20150129160127.2bc194a0@redhat.com> Message-ID: <56b8f8999b464b7db197bf19e071315c@ustx2ex-dag1mb2.msg.corp.akamai.com> You are misunderstanding him. The version you have is patched. The "poodle detection" script you are using is buggy. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From rt at openssl.org Thu Jan 29 19:33:59 2015 From: rt at openssl.org (David Ramos via RT) Date: Thu, 29 Jan 2015 20:33:59 +0100 Subject: [openssl-dev] [openssl.org #3680] NULL pointer dereference in tls1_check_chain (ssl/t1_lib.c) In-Reply-To: References: Message-ID: Hello, Our UC-KLEE tool found a NULL pointer dereference bug in tls1_check_chain (ssl/t1_lib.c) affecting OpenSSL 1.0.2. The bug appears to have been introduced in commit 6660baee66e474058229911950e26e56f31fb0bf (12/26/2012). The bug is triggered if either of the ?goto end? statements are taken on lines (w.r.t. commit 4ac03295) 4125 or 4128, as these jumps bypass the assignment pf ?cpk? on line 4129. The code then triggers a NULL pointer dereference when it dereferences ?cpk? on lines 4316 or 4332. Please let me know if you have any questions. Thanks, -David From kurt at roeckx.be Thu Jan 29 20:26:33 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 29 Jan 2015 21:26:33 +0100 Subject: [openssl-dev] Poodle Vulnerable In-Reply-To: <56b8f8999b464b7db197bf19e071315c@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150129160127.2bc194a0@redhat.com> <56b8f8999b464b7db197bf19e071315c@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150129202632.GA14790@roeckx.be> On Thu, Jan 29, 2015 at 07:28:45PM +0000, Salz, Rich wrote: > You are misunderstanding him. > > The version you have is patched. The "poodle detection" script you are using is buggy. Just to clarify, poodle is something that can not be fixed in SSLv3. If you allow SSLv3 you are affected by poodle. The only way to really fix the poodle problem is by not allowing SSLv3. The patch in the various branches does not fix the poodle problem, it just tries to prevent it. It adds a way to detect a downgrade attack. The most likely way poolde would be exploited is by doing a downgrade attack from TLS to SSLv3. There is a mitigation added in case of a fallback from a higher to a lower SSL/TLS version by the client. If both sides support this mitigation you can detect a downgrade attack and prevent the poodle attack. If the client does not support this mitigation you're still vulnerable. Just disable SSLv3. Kurt From rt at openssl.org Fri Jan 30 02:50:57 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 30 Jan 2015 03:50:57 +0100 Subject: [openssl-dev] [openssl.org #3681] function pointers in BIO set_callback References: Message-ID: set_callback takes a void*, not a function pointer. Strictly speaking that's not portable. And there are other some other issues. See bio/bio_conn.c the #if0 section, and and the FIXME comment in ssl_callback_ctrl in ssl/ssl_bio.c There is also internal commentary at https://gitlab.openssl.org/openssl/openssl/merge_requests/245 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Jan 30 08:02:08 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Fri, 30 Jan 2015 09:02:08 +0100 Subject: [openssl-dev] [openssl.org #3682] [PATCH] Fix double free in ocsp_main() In-Reply-To: References: Message-ID: There is a double free in ocsp_main() the attached patch fixes the issue. The user provides the -url argument to the ocsp utility and if OCSP_parse_url fails it frees the variable host then the variable host is assigned to thost and then the function goes on and goes to end and then the variable thost is freed causing a double free. --- Kurt Cancemi https://www.x64architecture.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-double-free-in-ocsp_main.patch Type: text/x-patch Size: 924 bytes Desc: not available URL: From rt at openssl.org Fri Jan 30 13:42:14 2015 From: rt at openssl.org (Dr. Matthias St. Pierre via RT) Date: Fri, 30 Jan 2015 14:42:14 +0100 Subject: [openssl-dev] [openssl.org #3676] [PATCH] Export ASN1 templates for DH and ECDH groups In-Reply-To: <1422610796-4644-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1422610796-4644-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: From: "Dr. Matthias St. Pierre" Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). Signed-off-by: Dr. Matthias St. Pierre --- crypto/dh/dh.h | 4 ++++ crypto/ec/ec.h | 38 ++++++++++++++++++++++++++++++++++++++ crypto/ec/ec_asn1.c | 30 ++++++++++++++++++++++++++---- util/libeay.num | 10 ++++++++++ 4 files changed, 78 insertions(+), 4 deletions(-) This patch amends my previous one and fixes a minor issue which affects only windows: The 'DHparams_it' symbol was not exported from the libeay32.dll library. The cause was a missing 'DECLARE_ASN1_ITEM(DHparams)' statement in the header file, which is required by the mkdef.pl perl script in order operate correctly when generating the linker definition file. Matthias diff --git a/crypto/dh/dh.h b/crypto/dh/dh.h index 0502f1a..9123276 100644 --- a/crypto/dh/dh.h +++ b/crypto/dh/dh.h @@ -65,6 +65,8 @@ # error DH is disabled. # endif +# include + # ifndef OPENSSL_NO_BIO # include # endif @@ -181,6 +183,8 @@ struct dh_st { */ # define DH_CHECK_P_NOT_STRONG_PRIME DH_CHECK_P_NOT_SAFE_PRIME +DECLARE_ASN1_ITEM(DHparams) + # define d2i_DHparams_fp(fp,x) (DH *)ASN1_d2i_fp((char *(*)())DH_new, \ (char *(*)())d2i_DHparams,(fp),(unsigned char **)(x)) # define i2d_DHparams_fp(fp,x) ASN1_i2d_fp(i2d_DHparams,(fp), \ diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h index 98edfdf..97ccee8 100644 --- a/crypto/ec/ec.h +++ b/crypto/ec/ec.h @@ -128,6 +128,9 @@ typedef struct ec_group_st typedef struct ec_point_st EC_POINT; +typedef struct ecpk_parameters_st ECPKPARAMETERS; +typedef struct ec_parameters_st ECPARAMETERS; + /********************************************************************/ /* EC_METHODs for curves over GF(p) */ /********************************************************************/ @@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const BIGNUM *a, */ EC_GROUP *EC_GROUP_new_by_curve_name(int nid); +/** Creates a new EC_GROUP object from an ECPARAMETERS object + * \param params pointer to the ECPARAMETERS object + * \return newly created EC_GROUP object with specified curve or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params); + +/** Creates an ECPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPARAMETERS object or NULL + * \return pointer to the new ECPARAMETERS object or NULL + * if an error occurred. + */ +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params); + +/** Creates a new EC_GROUP object from an ECPKPARAMETERS object + * \param params pointer to an existing ECPKPARAMETERS object, or NULL + * \return newly created EC_GROUP object with specified curve, or NULL + * if an error occurred + */ +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params); + +/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object. + * \param group pointer to the EC_GROUP object + * \param params pointer to an existing ECPKPARAMETERS object or NULL + * \return pointer to the new ECPKPARAMETERS object or NULL + * if an error occurred. + */ +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params); + /********************************************************************/ /* handling of internal curves */ /********************************************************************/ @@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group); /* ASN1 stuff */ /********************************************************************/ +DECLARE_ASN1_ITEM(ECPKPARAMETERS) +DECLARE_ASN1_ITEM(ECPARAMETERS) + /* * EC_GROUP_get_basis_type() returns the NID of the basis type used to * represent the field elements diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c index 2924374..d84c6d2 100644 --- a/crypto/ec/ec_asn1.c +++ b/crypto/ec/ec_asn1.c @@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const ECPKPARAMETERS *); static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *, ECPKPARAMETERS *); +EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params) +{ + return ec_asn1_parameters2group(params); +} + +ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group, + ECPARAMETERS *params) +{ + return ec_asn1_group2parameters(group, params); +} + +EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params) +{ + return ec_asn1_pkparameters2group(params); +} + +ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group, + ECPKPARAMETERS *params) +{ + return ec_asn1_group2pkparameters(group, params); +} + /* the function definitions */ static int ec_asn1_group2fieldid(const EC_GROUP *group, X9_62_FIELDID *field) @@ -540,7 +562,7 @@ static int ec_asn1_group2curve(const EC_GROUP *group, X9_62_CURVE *curve) } static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, - ECPARAMETERS *param) + ECPARAMETERS *params) { int ok = 0; size_t len = 0; @@ -555,13 +577,13 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, goto err; } - if (param == NULL) { + if (params == NULL) { if ((ret = ECPARAMETERS_new()) == NULL) { ECerr(EC_F_EC_ASN1_GROUP2PARAMETERS, ERR_R_MALLOC_FAILURE); goto err; } } else - ret = param; + ret = params; /* set the version (always one) */ ret->version = (long)0x1; @@ -631,7 +653,7 @@ static ECPARAMETERS *ec_asn1_group2parameters(const EC_GROUP *group, ok = 1; err:if (!ok) { - if (ret && !param) + if (ret && !params) ECPARAMETERS_free(ret); ret = NULL; } diff --git a/util/libeay.num b/util/libeay.num index 4a11d78..bf0adc5 100755 --- a/util/libeay.num +++ b/util/libeay.num @@ -4412,3 +4412,13 @@ ECDSA_METHOD_get_app_data 4770 EXIST::FUNCTION:ECDSA X509_VERIFY_PARAM_add1_host 4771 EXIST::FUNCTION: EC_GROUP_get_mont_data 4772 EXIST::FUNCTION:EC i2d_re_X509_tbs 4773 EXIST::FUNCTION: +DHparams_it 4774 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:DH +DHparams_it 4774 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:DH +ECPARAMETERS_it 4775 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPARAMETERS_it 4775 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +ECPKPARAMETERS_it 4776 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:EC +ECPKPARAMETERS_it 4776 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:EC +EC_GROUP_new_from_ecparameters 4777 EXIST::FUNCTION:EC +EC_GROUP_get_ecparameters 4778 EXIST::FUNCTION:EC +EC_GROUP_new_from_ecpkparameters 4779 EXIST::FUNCTION:EC +EC_GROUP_get_ecpkparameters 4780 EXIST::FUNCTION:EC -- 2.0.5 From rt at openssl.org Fri Jan 30 15:32:05 2015 From: rt at openssl.org (Giuseppe D'Angelo via RT) Date: Fri, 30 Jan 2015 16:32:05 +0100 Subject: [openssl-dev] [openssl.org #2464] TLS-RSA-PSK support In-Reply-To: <54CBA24A.2020802@kdab.com> References: <54CBA24A.2020802@kdab.com> Message-ID: 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-patch Size: 32648 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4048 bytes Desc: not available URL: From de.techno at gmail.com Sat Jan 31 07:37:22 2015 From: de.techno at gmail.com (dE) Date: Sat, 31 Jan 2015 13:07:22 +0530 Subject: [openssl-dev] sftp buggy put command Message-ID: <54CC8632.1010602@gmail.com> Hi! I was tying out the put command with version 6.7_p1 of OpenSSH. If I use recursive copying, sftp expects the last directory in the exists in the destination (on the server), otherwise ?Couldn't canonicalize: No such file or directory?. I would've taken this to be the expected behavior, but get command does not have this problem. It makes the destination directory in the client like with cp. So kindly take a look at this. From aaronmdjones at gmail.com Sat Jan 31 08:36:53 2015 From: aaronmdjones at gmail.com (Aaron Jones) Date: Sat, 31 Jan 2015 08:36:53 +0000 Subject: [openssl-dev] sftp buggy put command In-Reply-To: <54CC8632.1010602@gmail.com> References: <54CC8632.1010602@gmail.com> Message-ID: <54CC9425.2090100@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 31/01/15 07:37, dE wrote: > Hi! > > I was tying out the put command with version 6.7_p1 of OpenSSH. > > If I use recursive copying, sftp expects the last directory in the > exists in the destination (on the server), otherwise > ?Couldn't canonicalize: No such file or directory?. > > I would've taken this to be the expected behavior, but get command > does not have this problem. It makes the destination directory in > the client like with cp. > > So kindly take a look at this. This is the OpenSSL development mailing list. OpenSSL and OpenSSH are unrelated. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJUzJQXAAoJEG6FTA+q1M6k548P+wfb5N2im7E1hMwzT7FNxjIr brLmhqp7ImxvyIBkOyOUFA9ECTlRyNK9scVzR5pBq3Arwgc1lAe8krBqS6jkXZJG k6pTvHmxGqfYYHn+LiUvamS73YwaitdOltuCy83d1v/VSVMqCbSFij+nOcbhIA5M lG9PoG1ow0BXQep0i9O42ZG20oaPAqyt9NjC9MlN0BK4wyBCJF75T8eAHQl8WCBC RfFG8y9O5CAET7jP4AOavejIzCRMzm8apoMtoYZPnXjeBMHD0JJKSO1mEEL5JxLL tdKhT7VRev99rF+zCWUJysCJdNCh/OpqQv8qIJE1Vphx9hg/QWa8OaOHIZzTyAWC PuaFdh4FEnA7lF3a7XfbcoujcKW9XxSyxeKfZKWopGrps7fo2YAkT3VpkQPe4W66 CrUF0HgPnMy7yiNXkg4jxRjiZulnLGovInlHEcWOmdAzkh9fQCv+dQJN8DTz74Gs YAndLV1vxzly/+P3RFb+g4xv2P7tDZCh8+IP29yEwdbxATP0q06LyAgT1VjAI/SG rbKco7NkMn35LjNgPuuAfnuJ/vyN3f+08yBbziu9Hdrhdxwlml3pGLeAFgamqDYR MLAs5S89akjhCJh11gpa2Q/tbswgr9iX7ERQhO889gzGhUFsvdsqlda835aozivw qt58eFvqWu+afVP9lca2 =dBBe -----END PGP SIGNATURE----- From rt at openssl.org Sat Jan 31 16:06:34 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Jan 2015 17:06:34 +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: <20150131160610.GA15582@kronk.local> References: <20150120133114.GA13866@kronk.local> <20150131160610.GA15582@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 I updated the patch so that it applies cleanly after the reformatting of ocsp_vfy.c in commit 0f113f3. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-use-the-cert-list-embedded-in-the-OCSP-respons.patch Type: text/x-diff Size: 1163 bytes Desc: not available URL: