From gmaheshwari24.6 at gmail.com Tue Sep 1 08:46:08 2015 From: gmaheshwari24.6 at gmail.com (gaurav maheshwari) Date: Tue, 1 Sep 2015 14:16:08 +0530 Subject: [openssl-dev] Intel function stichting support for DTLS In-Reply-To: References: Message-ID: TLS has AES-SHA1 stitch and AES-SHA256 stitch support but this is not there for DTLS. Is there any fundamental issue for not implementing Intel function stitching for DTLS ciphers. I am looking in to adding the it in DTLS as I didn't find a reason for stitch not working in DTLS case. Thanks On Tue, Aug 25, 2015 at 7:31 PM, gaurav maheshwari < gmaheshwari24.6 at gmail.com> wrote: > Hello, > > Function stitching support (only for x86 processors) is there for some of > the TLS ciphers but same support is not there for DTLS. So, What was the > reason for not adding function stitching support for DTLS. > > Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Sep 1 11:32:14 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 11:32:14 +0000 Subject: [openssl-dev] [openssl.org #3977] bug report : Ubutu 12.0.4 : Openssl 1.0.1p : allowing connections with EXP cipher In-Reply-To: References: Message-ID: Everything seems to be working as intended; closing this ticket. From rt at openssl.org Tue Sep 1 11:48:51 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 11:48:51 +0000 Subject: [openssl-dev] [openssl.org #4007] Segmantation fault in OpenSSL 1.0.2a In-Reply-To: References: Message-ID: Please see https://rt.openssl.org/Ticket/Display.html?id=3439 Your symptoms match, so it looks like unfortunately you were relying on an OpenSSL bug to get the desired application behaviour. From rt at openssl.org Tue Sep 1 13:02:19 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 13:02:19 +0000 Subject: [openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing In-Reply-To: References: Message-ID: Resolving - this was fixed in 1.0.1k. From rt at openssl.org Tue Sep 1 13:51:43 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 13:51:43 +0000 Subject: [openssl-dev] [openssl.org #3926] [PATCH] Fix -evp option in openssl speed command In-Reply-To: References: Message-ID: Resolving: seems that this was fixed in dfba17b4f3b2f87b50f2251a608d1911bfd202bc From rt at openssl.org Tue Sep 1 14:21:51 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 14:21:51 +0000 Subject: [openssl-dev] [openssl.org #3815] Issue with X509_NAME_hash in 0.9.8zb In-Reply-To: <1084634388.1090583.1429589210899.JavaMail.yahoo@mail.yahoo.com> References: <1084634388.1090583.1429589210899.JavaMail.yahoo@mail.yahoo.com> Message-ID: Yes, this is intentional. See also the issuer_hash_old and subject_hash_old options in the x509 utility: https://www.openssl.org/docs/manmaster/apps/x509.html From rt at openssl.org Tue Sep 1 15:02:43 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 15:02:43 +0000 Subject: [openssl-dev] [openssl.org #3911] 1.0.2c: some kind of regression - fails to connect to server where 1.0.2a works fine In-Reply-To: <201506151308.08131.arekm@maven.pl> References: <201506151308.08131.arekm@maven.pl> Message-ID: Working as intended on the OpenSSL side. Marking resolved. From rt at openssl.org Tue Sep 1 18:04:40 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 18:04:40 +0000 Subject: [openssl-dev] [openssl.org #3493] Fix rsa_test In-Reply-To: References: Message-ID: Fixed in 25d6b3401ca40c9a2cbe5080449c1c2a37037777. From rt at openssl.org Tue Sep 1 18:11:16 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 18:11:16 +0000 Subject: [openssl-dev] [openssl.org #4002] Bug in branch master, file evp_pbe.c In-Reply-To: <9872E68DAF3EF5498FBA2777898A9D5F656454@pwsvl-excmbx-05.internal.cacheflow.com> References: <9872E68DAF3EF5498FBA2777898A9D5F656454@pwsvl-excmbx-05.internal.cacheflow.com> Message-ID: I believe this can't happen, but addressed in 394f7b6fcc38132b8ccff0a3253b9dd15640cfc0 anyway. From rt at openssl.org Tue Sep 1 18:21:24 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 01 Sep 2015 18:21:24 +0000 Subject: [openssl-dev] [openssl.org #3984] [PATCH] Fix clang compiler warning where %ld is used for uint64_t on Mac OS X In-Reply-To: References: Message-ID: Committed in fb029cebaeb6b0dbdb05a26a515e38a52a3c0fa1. From emilia at openssl.org Tue Sep 1 21:50:59 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 1 Sep 2015 23:50:59 +0200 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: References: Message-ID: On Fri, Aug 28, 2015 at 2:21 AM, Bill Cox wrote: > On Thu, Aug 27, 2015 at 5:00 PM, Emilia K?sper wrote: > >> A client should (SHOULD) always repeat extensions on resumption though, >> as it can't know whether the resumption will be accepted. >> >> Do you have a specific example where you need to save custom extension >> state? We can think about extending the API, even though I imagine that >> anything that does need to keep state will be too complex and hairy to be >> handled by the generic extension mechanism. >> >> Cheers, >> Emilia >> >> > Yes, I need it for the Token Binding Negotiation > > extension. We negotiate acceptable Token Binding key parameters in this > TLS extension. On resumption, the negotiation fails because the server > does not include the custom extension in it's server hello. At this point, > the client loses the ability to use channel bound tokens. > It's not quite clear to me why you'd have to resend parameters on resumption. After all, they are definitive for the session. Best if the draft explicitly specifies resumption behaviour. It's also not clear to me that the serialized TLS session is the place to store the parameters. Shouldn't they rather be stored at the application level, alongside with the eventual token? But setting that aside, the interaction with extended master secret makes using custom extensions for this purpose tricky anyway. Custom extensions don't really support interaction with other extensions; there's no guarantee that you'll end up processing them in the right order. (But I've only skimmed the docs so it's possible I got it all wrong.) Cheers, Emilia > Thanks, > Bill > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Sep 1 22:59:31 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 01 Sep 2015 22:59:31 +0000 Subject: [openssl-dev] [openssl.org #3838] [PATCH] Fix the comment for POINT_CONVERSION_UNCOMPRESSED, the z should be 0x04 but not 0x02. In-Reply-To: References: Message-ID: On Thu May 07 10:46:48 2015, tim.zhang at irdeto.com wrote: > Fix the comment for POINT_CONVERSION_UNCOMPRESSED, the z should be > 0x04 but not 0x02. Patch applied. Many thanks. Matt From rt at openssl.org Tue Sep 1 23:22:07 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 01 Sep 2015 23:22:07 +0000 Subject: [openssl-dev] [openssl.org #3924] Unable to compile OpenSSL 1.0.0s with no-tlsext option In-Reply-To: References: Message-ID: Thanks for your report. This issue has now been fixed in git. Matt From waywardgeek at google.com Wed Sep 2 01:00:19 2015 From: waywardgeek at google.com (Bill Cox) Date: Tue, 1 Sep 2015 18:00:19 -0700 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: References: Message-ID: On Tue, Sep 1, 2015 at 2:50 PM, Emilia K?sper wrote: > It's not quite clear to me why you'd have to resend parameters on > resumption. After all, they are definitive for the session. Best if the > draft explicitly specifies resumption behaviour. > I agree the draft should be enhanced to address resumption. I'll ping the ietf list. > It's also not clear to me that the serialized TLS session is the place to > store the parameters. Shouldn't they rather be stored at the application > level, alongside with the eventual token? > I think everyone is opposed to storing state from the Token Binding extension in the TLS session state. I agree it could be saved higher in the application stack in the client, but what if the resumption is with a server that does not support Token Binding for some reason? In that case the server ignores the extension and the client knows to disable Token Binding because it did not receive the extension from the server. This is how I implemented it locally, but I think this behavior should be clarified in the spec. > But setting that aside, the interaction with extended master secret makes > using custom extensions for this purpose tricky anyway. Custom extensions > don't really support interaction with other extensions; there's no > guarantee that you'll end up processing them in the right order. > > (But I've only skimmed the docs so it's possible I got it all wrong.) > In this case I am lucky. EMS is baked-in with native support, and all native extensions are parsed before all custom extensions. However, I realize this is not gaurenteed behavior. I should add a test for it... I do think this is a good candidate for custom extensions. Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Sep 2 01:39:56 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 02 Sep 2015 01:39:56 +0000 Subject: [openssl-dev] [openssl.org #3767] Enhancement: Use PNG instead of GIF In-Reply-To: References: Message-ID: in master and 1.0.2; updated doc/README and remove the gif and html "button" files. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From ikonta at yandex.ru Wed Sep 2 08:24:04 2015 From: ikonta at yandex.ru (Ikonta) Date: Wed, 02 Sep 2015 11:24:04 +0300 Subject: [openssl-dev] =?utf-8?q?1=2E0=2E2d_=E2=80=94_obsolete_directives_?= =?utf-8?q?in_openssl=2Ecnf=3F?= Message-ID: <400801441182244@web29j.yandex.ru> Hi, everybody. Yesterday I've re-read some openssl (1.0.2d version installed) docs (man x509v3_config) and find the following note: > Netscape Certificate Type > This is a multi-valued extensions which consists of a list of flags to be included. It was used to indicate the purposes > for which a certificate could be used. The basicConstraints, keyUsage and extended key usage extensions are now used > instead. > > Acceptable values for nsCertType are: client, server, email, objsign, reserved, sslCA, emailCA, objCA. But default config still contains obsolete directives, with no reference to valid ones: /etc/ssl/openssl.cnf ? # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. # nsCertType = server # For an object signing certificate this would be used. # nsCertType = objsign # For normal client use this is typical # nsCertType = client, email # and for everything including object signing: # nsCertType = client, email, objsign # This is typical in keyUsage for a client certificate. # keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "OpenSSL Generated Certificate" Maybe it's a time to update the config? From emilia at openssl.org Wed Sep 2 10:01:20 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Wed, 2 Sep 2015 12:01:20 +0200 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: References: Message-ID: On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox wrote: > On Tue, Sep 1, 2015 at 2:50 PM, Emilia K?sper wrote: > >> It's not quite clear to me why you'd have to resend parameters on >> resumption. After all, they are definitive for the session. Best if the >> draft explicitly specifies resumption behaviour. >> > > I agree the draft should be enhanced to address resumption. I'll ping the > ietf list. > > >> It's also not clear to me that the serialized TLS session is the place to >> store the parameters. Shouldn't they rather be stored at the application >> level, alongside with the eventual token? >> > > I think everyone is opposed to storing state from the Token Binding > extension in the TLS session state. I agree it could be saved higher in > the application stack in the client, but what if the resumption is with a > server that does not support Token Binding for some reason? In that case > the server ignores the extension and the client knows to disable Token > Binding because it did not receive the extension from the server. This is > how I implemented it locally, but I think this behavior should be clarified > in the spec. > Ah right. Yes, the spec should spell that out. > > >> But setting that aside, the interaction with extended master secret makes >> using custom extensions for this purpose tricky anyway. Custom extensions >> don't really support interaction with other extensions; there's no >> guarantee that you'll end up processing them in the right order. >> >> (But I've only skimmed the docs so it's possible I got it all wrong.) >> > > In this case I am lucky. EMS is baked-in with native support, and all > native extensions are parsed before all custom extensions. However, I > realize this is not gaurenteed behavior. I should add a test for it... > As far as I can see, the OpenSSL client processes extensions in the order they come in. But nothing is guaranteed. > > I do think this is a good candidate for custom extensions. > > Thanks, > Bill > > _______________________________________________ > 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 Wed Sep 2 12:27:49 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 02 Sep 2015 12:27:49 +0000 Subject: [openssl-dev] [openssl.org #3781] Possible bug In-Reply-To: References: Message-ID: I am afraid that there is not enough information here to diagnose the problem. We'd need to see a more detailed trace and/or the ClientHello contents. This could be https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0291, which was fixed in 1.0.2b, but I can't tell. From waywardgeek at google.com Wed Sep 2 14:50:31 2015 From: waywardgeek at google.com (Bill Cox) Date: Wed, 2 Sep 2015 07:50:31 -0700 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: References: Message-ID: On Wed, Sep 2, 2015 at 3:01 AM, Emilia K?sper wrote: > > As far as I can see, the OpenSSL client processes extensions in the order > they come in. But nothing is guaranteed. > I checked with the ietf tokbind list, and they say the server should not send the TB header on session resume, so I'll change my code accordingly. It looks like I have no need for this change to custom extensions after all. Thanks for the help! As for the order issue, we parse headers before creating any, so I'll just not add the header in the AddCallback if s->hit is set on the server side. This should behave well long term, I think. Again, thank you for all the help so far. I owe you a virtual beer :) Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 2 14:55:00 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 2 Sep 2015 15:55:00 +0100 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: References: Message-ID: <55E70DC4.4060201@openssl.org> On 02/09/15 15:50, Bill Cox wrote: > As for the order issue, we parse headers before creating any, so I'll > just not add the header in the AddCallback if s->hit is set on the > server side. This should behave well long term, I think. Except that in master (i.e. version 1.1.0) you will not be able to access s->hit. You should use SSL_cache_hit instead. Matt From waywardgeek at google.com Wed Sep 2 15:00:52 2015 From: waywardgeek at google.com (Bill Cox) Date: Wed, 2 Sep 2015 08:00:52 -0700 Subject: [openssl-dev] Minor bug in custom TLS extensions In-Reply-To: <55E70DC4.4060201@openssl.org> References: <55E70DC4.4060201@openssl.org> Message-ID: On Wed, Sep 2, 2015 at 7:55 AM, Matt Caswell wrote: > > > On 02/09/15 15:50, Bill Cox wrote: > > As for the order issue, we parse headers before creating any, so I'll > > just not add the header in the AddCallback if s->hit is set on the > > server side. This should behave well long term, I think. > > Except that in master (i.e. version 1.1.0) you will not be able to > access s->hit. You should use SSL_cache_hit instead. > Yes, I already had that pointed out :) Thanks, though! You can't be too careful in this code base. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Sep 3 02:38:10 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 02:38:10 +0000 Subject: [openssl-dev] Cleanup and changing the malloc routines Message-ID: We are considering a big cleanup to the memory-allocation API's in the next release. Please take a look at the attached documentation, which describes *ALL* of the public functions, and let us know if it will cause a problem. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OPENSSL_malloc.pod Type: application/octet-stream Size: 5598 bytes Desc: OPENSSL_malloc.pod URL: From rt at openssl.org Thu Sep 3 03:35:10 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 03 Sep 2015 03:35:10 +0000 Subject: [openssl-dev] [openssl.org #3938] Website ciphers.html specifies DHE-RSA-DES-CBC3-SHA, OpenSSL needs EDH-RSA-DES-CBC3-SHA In-Reply-To: References: Message-ID: We do now publish all manpage versions. If there's an error in a specific manpage, please create a new ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 3 03:41:18 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 03 Sep 2015 03:41:18 +0000 Subject: [openssl-dev] [openssl.org #3927] regression in 1.0.2c spotted by Net-SSLeay In-Reply-To: <20150629125258.GB21786@suse.de> References: <20150629125258.GB21786@suse.de> Message-ID: Not a bug, incorrect usage. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 3 09:23:06 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 03 Sep 2015 09:23:06 +0000 Subject: [openssl-dev] [openssl.org #3985] [PATCH] Fix potential memory leaks In-Reply-To: <20150903092251.GA4094@kronk.local> References: <20150903092251.GA4094@kronk.local> Message-ID: The corresponding GitHub pull request was merged, so this can be closed now. Cheers From alessandro at ghedini.me Thu Sep 3 10:17:53 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Thu, 3 Sep 2015 12:17:53 +0200 Subject: [openssl-dev] FW: Website changing this weekend In-Reply-To: References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150820192652.GA6425@kronk.local> <584881f1592c4447bd59887facfb5c62@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150821085532.GA16795@kronk.local> Message-ID: <20150903101753.GB4351@kronk.local> On Mon, Aug 24, 2015 at 07:05:26pm +0000, Salz, Rich wrote: > > https://www.openssl.org/docs/fipsvalidation.html (the UserGuide links lead > > to nowhere, and a few others as well). > > I fixed the two that I found, thanks. FWIW there are a bunch of other broken references to the user guide pdf in https://www.openssl.org/docs/fipsnotes.html > > On a related note, can we get the new logo in image format (ideally svg)? So > > Funny, others asked for a font/css solution. That makes sense for openssl.org, but for external websites (like the ones I mentioned) an image is usually required. > > images on https://github.com/openssl and > > https://www.openhub.net/p/openssl can be replaced with something less > > ugly (and ideally the favicon on the main site as well). > > Shrug, whatever people volunteer we'll look at. So, I made a thing [0] (note that I'm not sure if I'm using the correct font, it can be easily corrected if not). From that I made a 64x64 image [1] to be used on OpenHUB and a 100x100 one for GitHub [2]. I also tried to make a favicon out of it (16x16), but due to the size it was unreadable (if that's even a problem...). Cheers [0] https://www.ghedini.me/openssl.svg [1] https://www.ghedini.me/openssl-64.png [2] https://www.ghedini.me/openssl-100.png -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From rt at openssl.org Thu Sep 3 18:44:12 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 03 Sep 2015 18:44:12 +0000 Subject: [openssl-dev] [openssl.org #4027] Return value in dh_pmeth.c In-Reply-To: References: Message-ID: A non-matching kdf_type moves from return 1 to return 0 if NO_CMS compiles out the KDF_X9_42 change - that is a different error return and that seems incorrect to be making that change as part of handling conditional compilation additions. Although it looks like that change is one that should be made - and attention drawn to it - in that returning 1 == success for this function and not deriving anything because you don't know or support the kdf type should return an error condition (<= 0 for this function). _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 3 18:46:35 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 03 Sep 2015 18:46:35 +0000 Subject: [openssl-dev] [openssl.org #3674] Bug report - cannot compile 1.0.2 with no-cms In-Reply-To: References: Message-ID: Done in master-only. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 3 19:42:53 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 03 Sep 2015 19:42:53 +0000 Subject: [openssl-dev] [openssl.org #3952] [PATCH] Introduce OPENSSL_SYS_UEFI for rand configuration In-Reply-To: <1437582629.3905.125.camel@infradead.org> References: <1437582629.3905.125.camel@infradead.org> Message-ID: done, for master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From bkaduk at akamai.com Thu Sep 3 20:34:38 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 03 Sep 2015 15:34:38 -0500 Subject: [openssl-dev] [openssl-commits] [openssl] memset(0, ...) and NULL assignment In-Reply-To: <1441312003.206850.21793.nullmailer@dev.openssl.org> References: <1441312003.206850.21793.nullmailer@dev.openssl.org> Message-ID: <55E8AEDE.9020604@akamai.com> On 09/03/2015 03:26 PM, Rich Salz wrote: > The branch master has been updated > via 64b25758edca688a30f02c260262150f7ad0bc7d (commit) > from fb4844bbc62fb014c115cd8fd2fc4304cba6eb89 (commit) > > > - Log ----------------------------------------------------------------- > commit 64b25758edca688a30f02c260262150f7ad0bc7d > Author: Rich Salz > Date: Thu Sep 3 09:15:26 2015 -0400 > > remove 0 assignments. > > After openssl_zalloc, cleanup more "set to 0/NULL" assignments. > Many are from github feedback. Interestingly, Viktor had just added some explicit NULL assignments after memset-to-zero a few days ago in a0724ef1c9b9e2090bdd96b784f492b6a3952957. It is permitted for the NULL pointer to have a representation other than all-zeros, but such platforms are rare, and are explicitly excluded from the supported platforms list for, e.g., MIT krb5. Does openssl want to try to support such platforms? -Ben From rt at openssl.org Thu Sep 3 20:36:52 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 03 Sep 2015 20:36:52 +0000 Subject: [openssl-dev] [openssl.org #3965] Restore OPENSSL_NO_RFC3779 In-Reply-To: <1438175976.26511.50.camel@infradead.org> References: <1438175976.26511.50.camel@infradead.org> Message-ID: done in master. Nice work on updating the default to be 'yes' not 'no' :) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From openssl-users at dukhovni.org Thu Sep 3 20:40:54 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 20:40:54 +0000 Subject: [openssl-dev] [openssl-commits] [openssl] memset(0, ...) and NULL assignment In-Reply-To: <55E8AEDE.9020604@akamai.com> References: <1441312003.206850.21793.nullmailer@dev.openssl.org> <55E8AEDE.9020604@akamai.com> Message-ID: <20150903204053.GT9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 03:34:38PM -0500, Benjamin Kaduk wrote: > Interestingly, Viktor had just added some explicit NULL assignments > after memset-to-zero a few days ago in > a0724ef1c9b9e2090bdd96b784f492b6a3952957. It is permitted for the NULL > pointer to have a representation other than all-zeros, but such > platforms are rare, and are explicitly excluded from the supported > platforms list for, e.g., MIT krb5. Does openssl want to try to support > such platforms? In Postfix, Wietse and I doggedly avoid relying on NULL being stored as zero, whether or not any of our supported platforms violate that. Thus all pointers in malloced structures are initialized to NULL explicitly. So I tend to support the "general" case in other code I write. I would not have removed explicit NULL assignments, but if the project explicitly disavows the exotic platorms, and we decide to optimize out the redundant NULL assigments, I can live with that. -- Viktor. From rsalz at akamai.com Thu Sep 3 20:45:12 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 20:45:12 +0000 Subject: [openssl-dev] [openssl-commits] [openssl] memset(0, ...) and NULL assignment In-Reply-To: <20150903204053.GT9021@mournblade.imrryr.org> References: <1441312003.206850.21793.nullmailer@dev.openssl.org> <55E8AEDE.9020604@akamai.com> <20150903204053.GT9021@mournblade.imrryr.org> Message-ID: <7b0e0d1633a847b8be4cac1149108377@ustx2ex-dag1mb3.msg.corp.akamai.com> > So I tend to support the "general" case in other code I write. I would not > have removed explicit NULL assignments, but if the project explicitly > disavows the exotic platorms, and we decide to optimize out the redundant > NULL assigments, I can live with that. I'm going to add a test for this. So at least such bizarre wonderments will know they're failing :) From rt at openssl.org Fri Sep 4 02:00:01 2015 From: rt at openssl.org (=?UTF-8?B?5p6X5Lmm5biG?= via RT) Date: Fri, 04 Sep 2015 02:00:01 +0000 Subject: [openssl-dev] [openssl.org #4028] about the chipersuite for CoAP In-Reply-To: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> References: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> Message-ID: Constrained Application Protocol (CoAP) [RFC7252] currently specifies TLS_PSK_WITH_AES_128_CCM_8/TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as the mandatory to implement cipher suite for use with shared secrets. REF URL:http://datatracker.ietf.org/doc/draft-ietf-dice-profile/?include_text=1 So, is there any plan about it for openssl? or there is some other consideration? I extremely hope it will be implemented in next version 1.0.2e, thanks! -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 4 02:04:28 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 04 Sep 2015 02:04:28 +0000 Subject: [openssl-dev] [openssl.org #4028] about the chipersuite for CoAP In-Reply-To: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> References: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> Message-ID: It's a new feature, not a bug-fix, so it would not appear in 1.0.2 It is already implemented in master, which will become version 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Sep 4 07:30:43 2015 From: rt at openssl.org (=?UTF-8?B?5p6X5Lmm5biG?= via RT) Date: Fri, 04 Sep 2015 07:30:43 +0000 Subject: [openssl-dev] [openssl.org #4028] about the chipersuite for CoAP In-Reply-To: <457cd645.1682.14f97359b13.Coremail.linshufan0707@163.com> References: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> <457cd645.1682.14f97359b13.Coremail.linshufan0707@163.com> Message-ID: so will v1.1 be released in this year? ????????? On 2015-09-04 10:04 , Rich Salz via RT Wrote: It's a new feature, not a bug-fix, so it would not appear in 1.0.2 It is already implemented in master, which will become version 1.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Sep 4 12:03:35 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 04 Sep 2015 12:03:35 +0000 Subject: [openssl-dev] [openssl.org #4028] about the chipersuite for CoAP In-Reply-To: <49bde6f16e0444f5bff3c014315290ba@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <312F73E3-EC1B-49C9-94EF-0B89F93A00F5@163.com> <457cd645.1682.14f97359b13.Coremail.linshufan0707@163.com> <49bde6f16e0444f5bff3c014315290ba@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: > so will v1.1 be released in this year? More likely early 2016. From ming.sa at outlook.com Fri Sep 4 16:25:28 2015 From: ming.sa at outlook.com (Tantaryu MING) Date: Sat, 5 Sep 2015 00:25:28 +0800 Subject: [openssl-dev] Possible PBKDF2-params bug Message-ID: Hi guys, I read up the standards for PKCS#5 v2.0 and I think when we are using openssl pkcs8 command to generate a pkcs#5 private key, the format returned is not according to the specification. According to https://tools.ietf.org/html/rfc2898#appendix-A.2: PBKDF2-params ::= SEQUENCE { salt CHOICE { specified OCTET STRING, otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}} }, iterationCount INTEGER (1..MAX), keyLength INTEGER (1..MAX) OPTIONAL, prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT algid-hmacWithSHA1 } It seems like after iterationCount, both keyLength and prf is group under a new ASN1.Sequence, instead of all 4 under the same ASN1.sequence. This is the command I used: openssl pkcs8 -in key.pem -outform pem -topk8 -v2 aes256 -v2prf hmacWithSHA256 I'm wondering is this a bug or it needs to reference another specification? I can help fix it if it's a bug. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 4 18:28:25 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 4 Sep 2015 18:28:25 +0000 Subject: [openssl-dev] FW: Website changing this weekend In-Reply-To: <20150903101753.GB4351@kronk.local> References: <68b20d461e3844cda6918348abf00dc8@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150820192652.GA6425@kronk.local> <584881f1592c4447bd59887facfb5c62@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150821085532.GA16795@kronk.local> <20150903101753.GB4351@kronk.local> Message-ID: <66333c47fb8d4fa1a18d1cdd81f7cb70@ustx2ex-dag1mb3.msg.corp.akamai.com> > FWIW there are a bunch of other broken references to the user guide pdf in > https://www.openssl.org/docs/fipsnotes.html Fixed. > From that I made a 64x64 image [1] to be used on OpenHUB and a 100x100 > one for GitHub [2]. Installed your PNG images. Thanks! From rt at openssl.org Fri Sep 4 19:15:31 2015 From: rt at openssl.org (Roumen Petrov via RT) Date: Fri, 04 Sep 2015 19:15:31 +0000 Subject: [openssl-dev] [openssl.org #4029] incomplete get methods for X509_VERIFY_PARAM In-Reply-To: <55E9E3F3.2040809@roumenpetrov.info> References: <55E9E3F3.2040809@roumenpetrov.info> Message-ID: Hello, In master branch structure X509_VERIFY_PARAM is declared as opaque. For following attributes "get"-method is not defined: - check_time : applicable if flag X509_V_FLAG_USE_CHECK_TIME is set - inh_flags - purpose - trust - policies: stack of opaques ASN1 objects - id : opaque structure, may require own set of "get"-methods It seems to me for attributes name, flags and depth access is complete. Please finish declaration of X509_VERIFY_PARAM as opaque structure with definition of "get"-methods. Regards, Roumen Petrov _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Sep 5 13:49:23 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:49:23 +0000 Subject: [openssl-dev] [openssl.org #4030] Re: [openssl-dev #1542] others quick patches for memory leaks in pk7_smime.c and pk7_mime.c In-Reply-To: <20150905134909.GA19379@kronk.local> References: <20150905134909.GA19379@kronk.local> Message-ID: The proposed patch is mangled and very hard to read, but I think all proposed changes have already been committed, or the code has been removed. So I think this can be closed now. Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Sep 5 13:49:52 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:49:52 +0000 Subject: [openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c In-Reply-To: <20150905134941.GB19379@kronk.local> References: <20150905134941.GB19379@kronk.local> Message-ID: Same as #1542, the patch is mangled but I think everything is already fixed so this can be closed. Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Sep 5 13:52:13 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:52:13 +0000 Subject: [openssl-dev] [openssl.org #4030] Re: [openssl-dev #1542] others quick patches for memory leaks in pk7_smime.c and pk7_mime.c In-Reply-To: <20150905135205.GA19488@kronk.local> References: <20150905134909.GA19379@kronk.local> <20150905135205.GA19488@kronk.local> Message-ID: On Sat, Sep 05, 2015 at 01:49:23pm +0000, Alessandro Ghedini via RT wrote: > The proposed patch is mangled and very hard to read, but I think all proposed > changes have already been committed, or the code has been removed. > > So I think this can be closed now. Ugh, wrong subject... this was supposed to be a reply to RT#1542 and can be closed. Sorry for the noise. Cheers From rt at openssl.org Sat Sep 5 13:53:12 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:53:12 +0000 Subject: [openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c In-Reply-To: <20150905135304.GB19488@kronk.local> References: <20150905134941.GB19379@kronk.local> <20150905135304.GB19488@kronk.local> Message-ID: On Sat, Sep 05, 2015 at 01:49:52pm +0000, Alessandro Ghedini via RT wrote: > Same as #1542, the patch is mangled but I think everything is already fixed so > this can be closed. Same as #4031. It was supposed to be a reply to #1543 and can be closed. Cheers From rt at openssl.org Sat Sep 5 13:55:24 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:55:24 +0000 Subject: [openssl-dev] [openssl.org #1542] others quick patches for memory leaks in pk7_smime.c and pk7_mime.c In-Reply-To: <20150905135515.GC19488@kronk.local> References: <20150905135515.GC19488@kronk.local> Message-ID: The proposed patch is mangled and very hard to read, but I think all proposed changes have already been committed, or the code has been removed. So I think this can be closed now. Cheers From rt at openssl.org Sat Sep 5 13:56:25 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 05 Sep 2015 13:56:25 +0000 Subject: [openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c In-Reply-To: <20150905135616.GA20116@kronk.local> References: <20150905135616.GA20116@kronk.local> Message-ID: Same as #1542, the patch is mangled but I think everything is already fixed so this can be closed. Cheers From rt at openssl.org Sat Sep 5 15:02:23 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 15:02:23 +0000 Subject: [openssl-dev] [openssl.org #1542] others quick patches for memory leaks in pk7_smime.c and pk7_mime.c In-Reply-To: <148C743DBF70354A9E62CAB431C7F6EE0538E313@CORPUSMX30A.corp.emc.com> References: <148C743DBF70354A9E62CAB431C7F6EE0538E313@CORPUSMX30A.corp.emc.com> Message-ID: Yes, it looks like these have been fixed; closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 15:02:49 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 15:02:49 +0000 Subject: [openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c In-Reply-To: <148C743DBF70354A9E62CAB431C7F6EE0538E3AF@CORPUSMX30A.corp.emc.com> References: <148C743DBF70354A9E62CAB431C7F6EE0538E3AF@CORPUSMX30A.corp.emc.com> Message-ID: yes, it looks like these have been fixed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 19:54:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 19:54:01 +0000 Subject: [openssl-dev] [openssl.org #4030] others quick patches for memory leaks in pk7_smime.c and pk7_mime.c In-Reply-To: <20150905134909.GA19379@kronk.local> References: <20150905134909.GA19379@kronk.local> Message-ID: created by mistake. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 19:55:03 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 19:55:03 +0000 Subject: [openssl-dev] [openssl.org #4031] memory leak in crypto/asn1/x_x509a.c In-Reply-To: <20150905134941.GB19379@kronk.local> References: <20150905134941.GB19379@kronk.local> Message-ID: create by mistake. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 20:18:18 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 20:18:18 +0000 Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled In-Reply-To: <1437569859.3905.87.camel@intel.com> References: <1437569859.3905.87.camel@intel.com> Message-ID: checked into master; thanks! (and thanks for updating the docs as well) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 21:45:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 21:45:44 +0000 Subject: [openssl-dev] [openssl.org #3955] [PATCH] Reduce stack usage in PKCS7_verify() In-Reply-To: <1437655510.27621.29.camel@infradead.org> References: <1437655510.27621.29.camel@infradead.org> Message-ID: fixed in master; allocate space dynamically. we're not going to do a "stack use audit" platforms that need this are better equipped to do that, and can share the results with us. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Sep 5 21:50:09 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 05 Sep 2015 21:50:09 +0000 Subject: [openssl-dev] [openssl.org #3901] [PATCH] ts_rsp_print.c: fix TS_RESP_get_tst_info double call In-Reply-To: References: Message-ID: this is fixed in master, only. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Sep 8 01:36:58 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 08 Sep 2015 01:36:58 +0000 Subject: [openssl-dev] [openssl.org #3505] rewrite c_rehash in C In-Reply-To: <20140826080238.3ff27321@vostro> References: <20140826080238.3ff27321@vostro> Message-ID: delivered in main -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From openssl-users at dukhovni.org Tue Sep 8 01:46:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Sep 2015 01:46:49 +0000 Subject: [openssl-dev] [openssl.org #3505] rewrite c_rehash in C In-Reply-To: References: <20140826080238.3ff27321@vostro> Message-ID: <20150908014649.GF21942@mournblade.imrryr.org> On Tue, Sep 08, 2015 at 01:36:58AM +0000, Rich Salz via RT wrote: > delivered in main The documentation looks a bit out of date relative to the code. The program uses the B program to compute the hashes and fingerprints. If not found in the user's B, then set the B environment variable to the full pathname. Any program can be used, it will be invoked as follows for either a certificate or CRL: $OPENSSL x509 -hash -fingerprint -noout -in FILENAME $OPENSSL crl -hash -fingerprint -noout -in FILENAME where B is the filename. It must output the hash of the file on the first line, and the fingerprint on the second, optionally prefixed with some text and an equals sign. In fact no such silliness seems to take place, as far as I can tell, hashes are computed internally via the relevant C APIs. There may be other inaccuracies, it is likely worth comparing the documentation and code more thoroughly. -- Viktor. From rsalz at akamai.com Tue Sep 8 02:00:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 8 Sep 2015 02:00:30 +0000 Subject: [openssl-dev] [openssl.org #3505] rewrite c_rehash in C In-Reply-To: <20150908014649.GF21942@mournblade.imrryr.org> References: <20140826080238.3ff27321@vostro> <20150908014649.GF21942@mournblade.imrryr.org> Message-ID: > In fact no such silliness seems to take place, as far as I can tell, hashes are > computed internally via the relevant C APIs. > There may be other inaccuracies, it is likely worth comparing the > documentation and code more thoroughly. Yeah, I'll move the script stuff to a separate subsection. From rt at openssl.org Tue Sep 8 18:38:55 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 08 Sep 2015 18:38:55 +0000 Subject: [openssl-dev] [openssl.org #4011] OpenSSL: Hanging up with facebook protocol in MirandaNG In-Reply-To: References: Message-ID: Hi Pavel, I'm closing this ticket because there isn't sufficient detail to conclude that it's an OpenSSL bug, and not a problem with the plugin, or your environment. You can try asking for help on openssl-users@, though it looks more like a question for the Miranda NG community. Emilia From rt at openssl.org Tue Sep 8 18:47:38 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 08 Sep 2015 18:47:38 +0000 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141205220511.FmMVpf0B%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> Message-ID: The fix was committed in 995207bedcc58f2fa1bd7c460ee530b92c7dfbfe, so I think we can resolve this ticket. From rt at openssl.org Tue Sep 8 19:04:01 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 08 Sep 2015 19:04:01 +0000 Subject: [openssl-dev] [openssl.org #4021] Openssl. Responding to request tracker: "#502: TXT_DB error number 2" http://rt.openssl.org/Ticket/Display.html?id=502#txn-42752 In-Reply-To: <000e01d0dfc6$0cd24590$2676d0b0$@gmail.com> References: <000e01d0dfc6$0cd24590$2676d0b0$@gmail.com> Message-ID: There doesn't seem to be an open action item for OpenSSL here, so resolving this ticket. From rt at openssl.org Tue Sep 8 19:18:28 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Tue, 08 Sep 2015 19:18:28 +0000 Subject: [openssl-dev] [openssl.org #3942] Patch to fix issue with HMAC_init_ex in 1.0.1 In-Reply-To: <55A52AE6.5030809@cisco.com> References: <55A52AE6.5030809@cisco.com> Message-ID: Hm. You pass in a NULL key. The docs say that a NULL key indicates that we should reuse the existing key. With a new CTX, there is nothing to reuse, so it seems reasonable that the call should fail. If you actually wanted to set up the context with an empty key, you'd have to pass in a dummy key buffer with a 0 length. This is awkward, otoh, I'm not really sure why you'd want to do that in practice, so perhaps it's not terribly important? It's not a great API but we're bound by the documented contract. So I'm closing this as Working As Intended. If you think I got it wrong, please reopen. Cheers, Emilia From rt at openssl.org Wed Sep 9 03:21:14 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 09 Sep 2015 03:21:14 +0000 Subject: [openssl-dev] [openssl.org #3969] [PATCH] Add OPENSSL_SYS_UEFI In-Reply-To: <1438255199.26511.151.camel@infradead.org> References: <1438255199.26511.151.camel@infradead.org> Message-ID: done in master -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 9 03:22:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 09 Sep 2015 03:22:44 +0000 Subject: [openssl-dev] [openssl.org #3998] [PATCH] Allow scrypt to be disabled In-Reply-To: <1438963122.3098.1.camel@infradead.org> References: <1438963122.3098.1.camel@infradead.org> Message-ID: done in master sep 3 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 9 03:33:56 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 09 Sep 2015 03:33:56 +0000 Subject: [openssl-dev] [openssl.org #3993] [PATCH] Fix VS2008 "result still unsigned" build warning In-Reply-To: <1438866987.9814.125.camel@infradead.org> References: <1438866987.9814.125.camel@infradead.org> Message-ID: done in master -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 9 18:55:50 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 09 Sep 2015 18:55:50 +0000 Subject: [openssl-dev] [openssl.org #3995] [PATCH] Fix VS2008 "implicitly converted to 64 bits" build warning In-Reply-To: <1438867429.9814.132.camel@infradead.org> References: <1438867429.9814.132.camel@infradead.org> Message-ID: fixed in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 9 20:49:34 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 20:49:34 +0000 Subject: [openssl-dev] [openssl.org #3936] Bug (maybe) report In-Reply-To: <0525DE5B0D26F54C8D514CE0EFA18F6FA17273EE@NHPDAG005.dt.inc> References: <0525DE5B0D26F54C8D514CE0EFA18F6FA17273EE@NHPDAG005.dt.inc> Message-ID: OpenSSL attempts to load the master/default conf before diving into the subcommand and overriding the conf with the config in -config. It'll bail when it can't read the file, but only warn if the file does not exist. This seems wrong, and is a regression compared to 0.9.8, so I'm going to leave this ticket open. Meanwhile, you can work around it by setting the OPENSSL_CONF environment variable. Cheers, Emilia From rt at openssl.org Wed Sep 9 20:59:22 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 20:59:22 +0000 Subject: [openssl-dev] [openssl.org #955] Implementation of SSL_SESSION_get_session_id In-Reply-To: <200410111351.18645.jschneid@netilla.com> References: <200410111351.18645.jschneid@netilla.com> Message-ID: OpenSSL has SSL_SESSION_get_id since 0.9.8, so resolving this ticket just before its 11th anniversary. From rt at openssl.org Wed Sep 9 21:18:38 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 21:18:38 +0000 Subject: [openssl-dev] [openssl.org #2327] bug report In-Reply-To: <201008312028563295d0a3e5@en.lan-aces.com> References: <201008312028563295d0a3e5@en.lan-aces.com> Message-ID: It's been 5 years and we never heard back with more details, so rejecting this ticket. I suppose it could be CVE-2014-3509, though I can't tell. From rt at openssl.org Wed Sep 9 21:42:10 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 21:42:10 +0000 Subject: [openssl-dev] [openssl.org #3727] Question about ECC Patent In-Reply-To: <1ef514a147a9a7afafed451b2ec7eb@cweb09.nm.nhnsystem.com> References: <372a454157db5589d315fdd3185e4d3@cweb26.nm.nhnsystem.com> <7DE5DB67BDFC5641AF67737FC9E91E1469C8AF58@XMB116CNC.rim.net> <1ef514a147a9a7afafed451b2ec7eb@cweb09.nm.nhnsystem.com> Message-ID: We can't help you with legal matters: https://www.openssl.org/docs/faq.html#LEGAL1 Please note that this tracker is for bug reports. From rt at openssl.org Wed Sep 9 22:29:17 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 09 Sep 2015 22:29:17 +0000 Subject: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled In-Reply-To: <1438866658.9814.123.camel@infradead.org> References: <1438866658.9814.123.camel@infradead.org> Message-ID: done in master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 9 22:59:08 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 22:59:08 +0000 Subject: [openssl-dev] [openssl.org #2487] Possible bug In-Reply-To: References: Message-ID: No evidence that it's an OpenSSL bug. You can try openssl-users@ though I'm afraid there's not enough detail to resolve the problem there either. From rt at openssl.org Wed Sep 9 23:21:07 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 23:21:07 +0000 Subject: [openssl-dev] [openssl.org #3164] [PATCH] require DH group of 1024 bits In-Reply-To: <1383755273-16434-1-git-send-email-dkg@fifthhorseman.net> References: <1383755273-16434-1-git-send-email-dkg@fifthhorseman.net> Message-ID: How prophetic! We now require 768 and will do another bump to 1024 in the near future, so I'm resolving this ticket. Cheers, Emilia From rt at openssl.org Wed Sep 9 23:45:13 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 23:45:13 +0000 Subject: [openssl-dev] [openssl.org #2968] Possible bug report In-Reply-To: References: Message-ID: Chain building is complicated, because the issuance graph is complicated: certs get recertified, cross-signed, etc. Different clients have different trust stores, and will build different paths. We recently improved OpenSSL chain building to try more paths: see https://rt.openssl.org/Ticket/Display.html?id=3621 From rt at openssl.org Wed Sep 9 23:48:00 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 23:48:00 +0000 Subject: [openssl-dev] [openssl.org #3404] Bug report In-Reply-To: References: Message-ID: We didn't hear back and there's not enough info to repro; closing. From rt at openssl.org Wed Sep 9 23:58:20 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 09 Sep 2015 23:58:20 +0000 Subject: [openssl-dev] [openssl.org #3494] Possible sign bit bug in openssl 1.0.1i handling of 128-bit serial numbers In-Reply-To: <53F23F46.3040305@levicki.net> References: <53F23F46.3040305@levicki.net> Message-ID: As Rich said, this is according to ASN.1 DER spec. Serial numbers are integral, and you need 17 bytes to represent this serial number in two's complement form. From rt at openssl.org Thu Sep 10 00:35:19 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 00:35:19 +0000 Subject: [openssl-dev] [openssl.org #3092] BUG: Verify return code: 20 (unable to get local issuer certificate) with openssl 1.0.1 In-Reply-To: <5288108.ZgxU7CRk7v@kuehlschrank> References: <5288108.ZgxU7CRk7v@kuehlschrank> Message-ID: Probably same as https://rt.openssl.org/Ticket/Display.html?id=2968. We improved this. From rt at openssl.org Thu Sep 10 10:42:40 2015 From: rt at openssl.org (yancm via RT) Date: Thu, 10 Sep 2015 10:42:40 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: Hi, I've been tracking the dev branch of openssl for several months. In the last 24-48 hours was a source change that broke the build on my box (NetBSD 6_Stable / i386 architecture). I have cleaned and re- ./config'd but still see the build fail at: gmake[2]: Entering directory '/usr/local/src/openssl/apps' ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto }"; LDCMD="${LDCMD:-cc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -Wall -O3 -fomit-frame-pointer -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o ${LIBDEPS} ) gmake[2]: Leaving directory '/usr/local/src/openssl/apps' gmake[2]: Entering directory '/usr/local/src/openssl' Not available; use c_rehash script Makefile:428: recipe for target 'rehash.time' failed gmake[2]: *** [rehash.time] Error 1 gmake[2]: Leaving directory '/usr/local/src/openssl' Makefile:139: recipe for target 'openssl' failed gmake[1]: *** [openssl] Error 2 gmake[1]: Leaving directory '/usr/local/src/openssl/apps' Makefile:290: recipe for target 'build_apps' failed gmake: *** [build_apps] Error 1 Looks like something is broken in or around c_rehash? best regards, gene _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 10 10:48:58 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 10 Sep 2015 10:48:58 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: yes it was broken for a bit. fixed now; re-sync. (one test still fails, but that will be fixed today) -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 10 15:09:18 2015 From: rt at openssl.org (ralf.vennemann@web.de via RT) Date: Thu, 10 Sep 2015 15:09:18 +0000 Subject: [openssl-dev] [openssl.org #4034] mkstack.pl does generate new safestack.h until release 1.0.1m In-Reply-To: References: Message-ID: Hello, since OpenSSL release 1.0.1m the mkstack.pl script does not generate a new safestack.h file if new DECLARE_STACK_OF macros are available. I found the following issues: 1. The format of the following comment in safestack.h has changed: Old style (required by mkstack.pl): /* This block of defines is updated by util/mkstack.pl, please do not touch! */ New style: /* * This block of defines is updated by util/mkstack.pl, please do not touch! */ 2. The following line is missing in safestack.h (but required by the mkstack.pl script): /* End of util/mkstack.pl block, you may now edit :-) */ Regards, Ralf _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 10 15:27:38 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 15:27:38 +0000 Subject: [openssl-dev] [openssl.org #3754] [OpenSSL bug-report] if malloc failed on EVP_PKEY_new_mac_key() ? In-Reply-To: References: Message-ID: Fixed now in OpenSSL 1.0.1+, thanks for the report! From a.yousar at informatik.hu-berlin.de Thu Sep 10 15:20:24 2015 From: a.yousar at informatik.hu-berlin.de (Annie) Date: Thu, 10 Sep 2015 17:20:24 +0200 Subject: [openssl-dev] [openssl.org #4034] mkstack.pl does generate new safestack.h until release 1.0.1m In-Reply-To: References: Message-ID: <55F19FB8.3000303@informatik.hu-berlin.de> Hello Ralf, I discovered that already in April, and I sent an e-mail to the list on 2015-04-14 20:46:15 For your convienence the e-mail (including a patch proposal) is attached. Regards, /Ann. Am 10.09.2015 um 17:09 schrieb ralf.vennemann at web.de via RT: > Hello, > > since OpenSSL release 1.0.1m the mkstack.pl script does not generate a new safestack.h file if new DECLARE_STACK_OF macros are available. > I found the following issues: > > 1. The format of the following comment in safestack.h has changed: > Old style (required by mkstack.pl): > /* This block of defines is updated by util/mkstack.pl, please do not touch! */ > > New style: > /* > * This block of defines is updated by util/mkstack.pl, please do not touch! > */ > > 2. The following line is missing in safestack.h (but required by the mkstack.pl script): > /* End of util/mkstack.pl block, you may now edit :-) */ > > Regards, > Ralf > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An embedded message was scrubbed... From: Annie Subject: [openssl-dev] [1.0.1m] strange behavior of make stacks Date: Tue, 14 Apr 2015 20:44:49 +0200 Size: 7743 URL: From rt at openssl.org Thu Sep 10 15:30:18 2015 From: rt at openssl.org (Annie Yousar via RT) Date: Thu, 10 Sep 2015 15:30:18 +0000 Subject: [openssl-dev] [openssl.org #4034] mkstack.pl does generate new safestack.h until release 1.0.1m In-Reply-To: <55F19FB8.3000303@informatik.hu-berlin.de> References: <55F19FB8.3000303@informatik.hu-berlin.de> Message-ID: Hello Ralf, I discovered that already in April, and I sent an e-mail to the list on 2015-04-14 20:46:15 For your convienence the e-mail (including a patch proposal) is attached. Regards, /Ann. Am 10.09.2015 um 17:09 schrieb ralf.vennemann at web.de via RT: > Hello, > > since OpenSSL release 1.0.1m the mkstack.pl script does not generate a new safestack.h file if new DECLARE_STACK_OF macros are available. > I found the following issues: > > 1. The format of the following comment in safestack.h has changed: > Old style (required by mkstack.pl): > /* This block of defines is updated by util/mkstack.pl, please do not touch! */ > > New style: > /* > * This block of defines is updated by util/mkstack.pl, please do not touch! > */ > > 2. The following line is missing in safestack.h (but required by the mkstack.pl script): > /* End of util/mkstack.pl block, you may now edit :-) */ > > Regards, > Ralf > > _______________________________________________ > openssl-bugs-mod mailing list > openssl-bugs-mod at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- Dear all, I discovered a very strange behavior after the 1.0.1l to 1.0.1m change. The "make stacks" aka the Perl script util/mkstack.pl was broken. But the script itself wasn't changed, you may see that e.g. looking for tab chars, surviving therein. The reason is the change in the comment structuring (!) in crypto/stack/safestack.h. I was faced with this problem working on an implementation for the (stack of) qcStatements, a v3 extension according to RFC 3739. Some explanations: The script util/mkstacks.pl looks for a line beginning with regex ^/\* This block of defines is updated by util/mkstack.pl, please do not touch! \*/ But this line doesn't appear anymore in crypto/stack/safestack.h. It is now transformed into / * * This block of defines is updated by util/mkstack.pl, please do not touch! */ despite the warning "do not touch". The attached patch solves the issue. Beside of this crypto/stack/safestack.h lost also the following line at the very end: /* End of util/mkstack.pl block, you may now edit :-) */ which is also expected by the util/mkstack.pl script. I'm not fully aware of the consequences so I propose to give this line back to safestack. It is also integrated in the patch. Regards, /Ann. -------------- next part -------------- --- openssl-1.0.1m/util/mkstack.pl 2015-03-19 14:37:10.000000000 +0100 +++ openssl-1.0.1m.patch/util/mkstack.pl 2015-04-14 11:52:06.765625000 +0200 @@ -60,8 +60,8 @@ $old_stackfile .= $_; - if (m|^/\* This block of defines is updated by util/mkstack.pl, please do not touch! \*/|) { + if (m|^ \* This block of defines is updated by util/mkstack.pl, please do not touch!|) { $inside_block = 1; } - if (m|^/\* End of util/mkstack.pl block, you may now edit :-\) \*/|) { + if (m|^ \* End of util/mkstack.pl block, you may now edit :-\)|) { $inside_block = 0; } elsif ($inside_block == 0) { @@ -69,5 +69,5 @@ } next if($inside_block != 1); - $new_stackfile .= "/* This block of defines is updated by util/mkstack.pl, please do not touch! */"; + $new_stackfile .= " * This block of defines is updated by util/mkstack.pl, please do not touch!\n */"; foreach $type_thing (sort @stacklst) { @@ -175,5 +175,5 @@ } - $new_stackfile .= "/* End of util/mkstack.pl block, you may now edit :-) */\n"; + $new_stackfile .= "/*\n * End of util/mkstack.pl block, you may now edit :-)\n"; $inside_block = 2; } --- openssl-1.0.1m/crypto/stack/safestack.h 2015-03-19 14:38:23.000000000 +0100 +++ openssl-1.0.1m.patch/crypto/stack/safestack.h 2015-04-14 11:52:56.468750000 +0200 @@ -2531,4 +2531,8 @@ LHM_lh_stats_bio(SSL_SESSION,lh,out) # define lh_SSL_SESSION_free(lh) LHM_lh_free(SSL_SESSION,lh) +/* + * End of util/mkstack.pl block, you may now edit :-) + */ + #ifdef __cplusplus } -------------- next part -------------- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Sep 10 20:52:14 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 20:52:14 +0000 Subject: [openssl-dev] [openssl.org #3496] report :CVE-2014-0224 security issue not fixed in openssl 1.0.1h In-Reply-To: <00ca01cfbd15$2800d5e0$780281a0$@com.cn> References: <00ca01cfbd15$2800d5e0$780281a0$@com.cn> Message-ID: CVE-2014-0224 was fixed in 1.0.1h. From rt at openssl.org Thu Sep 10 21:00:20 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 21:00:20 +0000 Subject: [openssl-dev] [openssl.org #3484] s3_pkt.c build failure for openssl-SNAP-20140804 In-Reply-To: References: Message-ID: It's been fixed. From rt at openssl.org Thu Sep 10 21:08:45 2015 From: rt at openssl.org (Ivo Raisr via RT) Date: Thu, 10 Sep 2015 21:08:45 +0000 Subject: [openssl-dev] [openssl.org #4035] bug and fix - warning about uninitialized variables in ssl_asn1.c, function i2d_SSL_SESSION() In-Reply-To: <55F1EF20.5020708@oracle.com> References: <55F1EF20.5020708@oracle.com> Message-ID: When OpenSSL 1.0.2 is built on Linux with "no-psk" config option, the following warnings are emitted by the compiler: ssl_asn1.c: In function ?i2d_SSL_SESSION?: ssl_asn1.c:124:57: warning: unused variable ?v8? [-Wunused-variable] int v1 = 0, v2 = 0, v3 = 0, v4 = 0, v5 = 0, v7 = 0, v8 = 0; ^ ssl_asn1.c:124:49: warning: unused variable ?v7? [-Wunused-variable] int v1 = 0, v2 = 0, v3 = 0, v4 = 0, v5 = 0, v7 = 0, v8 = 0; ^ This is because variables v7 and v8 are defined unconditionally, regardless whether OPENSSL_NO_PSK is defined or not. Similar to existing constructs with OPENSSL_NO_TLSEXT, OPENSSL_NO_COMP and OPENSSL_NO_SRP, also OPENSSL_NO_PSK needs the following: +#ifndef OPENSSL_NO_PSK + int v7 = 0, v8 = 0; +#endif See the attached patch. Tested by building with and without "no-psk". Builds are clean and successful. Kind regards, Ivo Raisr -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_asn1_no-psk.patch Type: text/x-patch Size: 694 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 10 21:17:05 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 21:17:05 +0000 Subject: [openssl-dev] [openssl.org #2524] openssl 1.0.0d bug report/ query In-Reply-To: References: Message-ID: Whatever it was, it's no longer reproducible. From rt at openssl.org Thu Sep 10 21:30:52 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 10 Sep 2015 21:30:52 +0000 Subject: [openssl-dev] [openssl.org #3124] potential bug in ssl/s3_cbc.c In-Reply-To: <20130909233013.GO1208@x96.org> References: <20130909233013.GO1208@x96.org> Message-ID: In the is_sslv3 case, the header length is recomputed to be large enough. I also note that we've recently added a sanity check to make this explicit, see commit 29b0a15a480626544dd0c803d5de671552544de6 Sorry that we didn't acknowledge your report! Cheers, Emilia From rt at openssl.org Fri Sep 11 01:37:25 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 11 Sep 2015 01:37:25 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: On 2015-09-10 06:48, Rich Salz via RT wrote: > yes it was broken for a bit. fixed now; re-sync. (one test still fails, > but > that will be fixed today) Hi Rich, indeed it builds now, but it takes two tries. The first pass stops with: gmake[2]: Entering directory '/usr/local/src/openssl' Not available; use c_rehash script Makefile:428: recipe for target 'rehash.time' failed gmake[2]: *** [rehash.time] Error 1 gmake[2]: Leaving directory '/usr/local/src/openssl' Makefile:139: recipe for target 'openssl' failed gmake[1]: *** [openssl] Error 2 gmake[1]: Leaving directory '/usr/local/src/openssl/apps' Makefile:290: recipe for target 'build_apps' failed gmake: *** [build_apps] Error 1 the second pass finishes cleanly but at present I am unable to make the test target at all: clarity 144 # gmake test Not available; use c_rehash script Makefile:428: recipe for target 'rehash.time' failed gmake: *** [rehash.time] Error 1 clarity 145 # date Thu Sep 10 21:23:31 EDT 2015 thanks, gene From rsalz at akamai.com Fri Sep 11 01:40:33 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 11 Sep 2015 01:40:33 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: Please do "grep rehash Makefile" at the toplevel. From rt at openssl.org Fri Sep 11 01:40:38 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 11 Sep 2015 01:40:38 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: Please do "grep rehash Makefile" at the toplevel. From rt at openssl.org Fri Sep 11 09:31:00 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 11 Sep 2015 09:31:00 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> Message-ID: On 2015-09-10 21:40, Salz, Rich via RT wrote: > Please do "grep rehash Makefile" at the toplevel. To which I get: clarity 153 # grep rehash Makefile rm -f */*/*.o */*.o *.o core a.out fluff rehash.time testlog make.log cctest cctest.c rehash: rehash.time rehash.time: certs apps $$OPENSSL rehash certs/demo) && \ touch rehash.time; \ tests: rehash From rt at openssl.org Fri Sep 11 11:31:50 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 11:31:50 +0000 Subject: [openssl-dev] [openssl.org #2464] [PATCH] Experimental TLS-RSA-PSK support for OpenSSL In-Reply-To: <4D6E25AA.30901@internet-sicherheit.de> References: <4D6E25AA.30901@internet-sicherheit.de> Message-ID: No problems reported, marking ticket as resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Sep 11 11:38:13 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 11:38:13 +0000 Subject: [openssl-dev] [openssl.org #1851] [PATCH] "openssl verify -CAfile mutil_ca.pem site.cert" fails even if mutil_ca.pem contains the chain for site.cert In-Reply-To: <18abdd280902271210h5f4b342cy619caa2af518b877@mail.gmail.com> References: <18abdd280902261601u743c43f5h196ea1b34b49189b@mail.gmail.com> <18abdd280902261641s2d84726es275994a27e885446@mail.gmail.com> <18abdd280902271210h5f4b342cy619caa2af518b877@mail.gmail.com> Message-ID: Ancient ticket, resolved long ago. Closing. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Sep 11 12:51:44 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 12:51:44 +0000 Subject: [openssl-dev] [openssl.org #4009] bug: Handling of SUITEB* ciphers does not match documentation In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428011BC29128@exch-01> References: <401084E5E73F4241A44F3C9E6FD79428011BC29128@exch-01> Message-ID: Fixed now to SUITEB* works at the beginning of cipher string. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Sep 11 13:07:21 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 13:07:21 +0000 Subject: [openssl-dev] [openssl.org #3975] The CMS encrypt command uses the wrong ASN.1 encoding for the AES-GCM algorithm parameter. In-Reply-To: References: Message-ID: GCM mode isn't currently supported in CMS, it was a bug that it attempted to use it and produced incorrect results. Resolved now to return an error for GCM. 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 Sep 11 14:34:15 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 11 Sep 2015 15:34:15 +0100 Subject: [openssl-dev] State machine rewrite Message-ID: <55F2E667.5000506@openssl.org> I've just opened a github pull request to show recent work I have been doing on rewriting the OpenSSL state machine (for version 1.1.0). See: https://github.com/openssl/openssl/pull/394 My objectives for the rewrite were: - Remove duplication of state code between client and server - Remove duplication of state code between TLS and DTLS - Simplify transitions and bring the logic together in a single location so that it is easier to validate - Remove duplication of code between each of the message handling functions - Receive a message first and then work out whether that is a valid transition - not the other way around (the other way causes lots of issues where we are expecting one type of message next but actually get something else) - Separate message flow state from handshake state (in order to better understand each) - message flow state = when to flush buffers; handling restarts in the event of NBIO events; handling the common flow of steps for reading a message and the common flow of steps for writing a message etc - handshake state = what handshake message are we working on now - Control complexity: only the state machine can change state: keep all the state changes local to the state machine component The message flow state machine is divided into a reading sub-state machine and a writing sub-state machine. See the source comments in ssl/statem/statem.c for a more detailed description of the various states and transitions possible. Also see ssl/statem/README for additional info. One issue is that the patch as it is currently removes support for DTLSv1_listen. I have another patch to add that back in (in a completely different way) - but it needs a bit more work yet. I am interested in hearing any feedback you may have on the code (ideally as comments in the pull request). I would also be keen to hear of any problems you might encounter whilst using this code. You can check it out from my github repo: https://github.com/mattcaswell/openssl See the state-machine-rewrite branch. Thanks Matt From rsalz at akamai.com Fri Sep 11 14:35:42 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 11 Sep 2015 14:35:42 +0000 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F2E667.5000506@openssl.org> References: <55F2E667.5000506@openssl.org> Message-ID: <5c0c0712bdf443c9939dd483d56efe39@ustx2ex-dag1mb3.msg.corp.akamai.com> > I've just opened a github pull request to show recent work I have been doing > on rewriting the OpenSSL state machine (for version 1.1.0). See: > https://github.com/openssl/openssl/pull/394 Extended discussion should probably happen on openssl-dev, as conversations don't work too well on GitHub PR's. Bsased on experience. From foleyj at cisco.com Fri Sep 11 15:07:27 2015 From: foleyj at cisco.com (John Foley) Date: Fri, 11 Sep 2015 11:07:27 -0400 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F2E667.5000506@openssl.org> References: <55F2E667.5000506@openssl.org> Message-ID: <55F2EE2F.3080704@cisco.com> +1 It's great to see improvements in the state machine along with consolidated handlers for TLS/DTLS. Having said that, have you considered using a state transition table instead of long switch statements to enforce the state transition rules? This would improve the maintainability of the code. Here's a trivial example: http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/ On 09/11/2015 10:34 AM, Matt Caswell wrote: > I've just opened a github pull request to show recent work I have been > doing on rewriting the OpenSSL state machine (for version 1.1.0). See: > https://github.com/openssl/openssl/pull/394 > > My objectives for the rewrite were: > > - Remove duplication of state code between client and server > - Remove duplication of state code between TLS and DTLS > - Simplify transitions and bring the logic together in a single location > so that it is easier to validate > - Remove duplication of code between each of the message handling functions > - Receive a message first and then work out whether that is a valid > transition - not the other way around (the other way causes lots of > issues where we are expecting one type of message next but actually get > something else) > - Separate message flow state from handshake state (in order to better > understand each) > - message flow state = when to flush buffers; handling restarts in the > event of NBIO events; handling the common flow of steps for reading a > message and the common flow of steps for writing a message etc > - handshake state = what handshake message are we working on now > - Control complexity: only the state machine can change state: keep all > the state changes local to the state machine component > > The message flow state machine is divided into a reading sub-state > machine and a writing sub-state machine. See the source comments in > ssl/statem/statem.c for a more detailed description of the various > states and transitions possible. Also see ssl/statem/README for > additional info. > > One issue is that the patch as it is currently removes support for > DTLSv1_listen. I have another patch to add that back in (in a completely > different way) - but it needs a bit more work yet. > > I am interested in hearing any feedback you may have on the code > (ideally as comments in the pull request). I would also be keen to hear > of any problems you might encounter whilst using this code. You can > check it out from my github repo: > https://github.com/mattcaswell/openssl > > See the state-machine-rewrite branch. > > Thanks > > Matt > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Fri Sep 11 17:34:28 2015 From: rt at openssl.org (John Foley via RT) Date: Fri, 11 Sep 2015 17:34:28 +0000 Subject: [openssl-dev] [openssl.org #4036] Invalid use of memcpy() causing decrypt failure In-Reply-To: <55F30E12.6090800@cisco.com> References: <55F30E12.6090800@cisco.com> Message-ID: We're seeing intermittent failures in the AES key wrap test cases in test/evp_test in the 1.0.2d release. We believe the problem is due to using memcpy() with overlapping src/dst memory regions. The following thread provides some insight into this memcpy() issue: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The documentation for memcpy() states to use memmove() when the memory regions overlap. The attached patch resolves the problem. Please consider accepting this patch in the 1.0.2 stable and master branches. Thank you. -------------- next part -------------- A non-text attachment was scrubbed... Name: aes_wrap_fix.patch Type: text/x-patch Size: 704 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 11 17:34:28 2015 From: rt at openssl.org (Andrew Felsher via RT) Date: Fri, 11 Sep 2015 17:34:28 +0000 Subject: [openssl-dev] [openssl.org #4037] IV-setting bug on AES/CCM decryption In-Reply-To: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> References: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> Message-ID: Hi, While running some tests on a module using OpenSSL, we noticed that when using EVP_CIPHER_CTX_ctrl(context, EVP_CTRL_CCM_SET_IVLEN, length, NULL) to set the IV length, AES/CCM decryption does not seem to detect a bad IV length. With encryption, it is detected and an appropriate error code is returned. And AES/GCM, for example, detects the bad IV length for both encryption and decryption. Regards, Andrew Felsher -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From bkaduk at akamai.com Fri Sep 11 17:37:19 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 11 Sep 2015 12:37:19 -0500 Subject: [openssl-dev] interaction between --strict-warnings and disabled features Message-ID: <55F3114F.1070000@akamai.com> Hi all, When I configure with --strict-warnings and, say, no-seed, my build fails due to an empty compilation unit e_seed.c. Is it just expected that if I'm going to use strict-warnings I will have most/all features enabled, or is this something that we would want to fix? Thanks, Ben From rsalz at akamai.com Fri Sep 11 17:46:13 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 11 Sep 2015 17:46:13 +0000 Subject: [openssl-dev] interaction between --strict-warnings and disabled features In-Reply-To: <55F3114F.1070000@akamai.com> References: <55F3114F.1070000@akamai.com> Message-ID: <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> > When I configure with --strict-warnings and, say, no-seed, my build fails due > to an empty compilation unit e_seed.c. Does just putting an extern declaration in the file work? Or do we need something like "#if PEDANTIC" in apps/dsa.c, for example. From uri at ll.mit.edu Fri Sep 11 18:08:34 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 11 Sep 2015 18:08:34 +0000 Subject: [openssl-dev] Strange problem with cms_cd.o? Message-ID: I am trying to build the current Github version of openssl on Ubuntu-14.04 LTS. Must add that this system has openssl-1.0.1f already installed (relict of Ubuntu software update process). Everything seems to compile fine, but linking of ?openssl? fails, complaining that it cannot find ?CMS_CompressedData_it? reference. This only happens when I configure openssl with ?zlib" ./config ?prefix=/usr/local threads zlib I observed that ?r CMS_CompressedData_it? is present in cms_asn1.o in libcrypto.a. This works fine and links everything correctly (and all the tests pass OK): ./config ?prefix=/usr/local threads Any help is appreciated. Thanks! ? making all in crypto/cms... make[2]: Entering directory `/media/uri/Src/openssl/crypto/cms' gcc -I.. -I../.. -I../modes -I../include -I../../include -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o cms_cd.o cms_cd.c ar r ../../libcrypto.a cms_lib.o cms_asn1.o cms_att.o cms_io.o cms_smime.o cms_err.o cms_sd.o cms_dd.o cms_cd.o cms_env.o cms_enc.o cms_ess.o cms_pwri.o cms_kari.o /usr/bin/ranlib ../../libcrypto.a || echo Never mind. make[2]: Leaving directory `/media/uri/Src/openssl/crypto/cms' making all in crypto/pqueue... make[2]: Entering directory `/media/uri/Src/openssl/crypto/pqueue' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/media/uri/Src/openssl/crypto/pqueue' making all in crypto/ts... make[2]: Entering directory `/media/uri/Src/openssl/crypto/ts' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/media/uri/Src/openssl/crypto/ts' making all in crypto/srp... make[2]: Entering directory `/media/uri/Src/openssl/crypto/srp' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/media/uri/Src/openssl/crypto/srp' making all in crypto/cmac... make[2]: Entering directory `/media/uri/Src/openssl/crypto/cmac' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/media/uri/Src/openssl/crypto/cmac' if [ -n "" ]; then \ (cd ..; make libcrypto.so.1.1); \ fi make[1]: Leaving directory `/media/uri/Src/openssl/crypto' making all in engines... make[1]: Entering directory `/media/uri/Src/openssl/engines' making all in engines/ccgost... make[2]: Entering directory `/media/uri/Src/openssl/engines/ccgost' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/media/uri/Src/openssl/engines/ccgost' make[1]: Leaving directory `/media/uri/Src/openssl/engines' making all in ssl... make[1]: Entering directory `/media/uri/Src/openssl/ssl' if [ -n "" ]; then \ (cd ..; make libssl.so.1.1); \ fi make[1]: Leaving directory `/media/uri/Src/openssl/ssl' making all in apps... make[1]: Entering directory `/media/uri/Src/openssl/apps' rm -f openssl shlib_target=; if [ -n "" ]; then \ shlib_target="linux-shared"; \ fi; \ LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \ make -f ../Makefile.shared -e \ APPNAME=openssl OBJECTS="openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o" \ LIBDEPS=" $LIBRARIES -ldl -lz" \ link_app.${shlib_target} make[2]: Entering directory `/media/uri/Src/openssl/apps' ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl -lz}"; LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o srp.o ts.o verify.o version.o x509.o rehash.o apps.o opt.o s_cb.o s_socket.o app_rand.o ${LIBDEPS} ) ../libcrypto.a(cms_cd.o): In function `cms_CompressedData_create': cms_cd.c:(.text+0x1d): undefined reference to `CMS_CompressedData_it' collect2: error: ld returned 1 exit status make[2]: *** [link_app.] Error 1 make[2]: Leaving directory `/media/uri/Src/openssl/apps' make[1]: *** [openssl] Error 2 make[1]: Leaving directory `/media/uri/Src/openssl/apps' make: *** [build_apps] Error 1 -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Fri Sep 11 19:47:24 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Fri, 11 Sep 2015 19:47:24 +0000 Subject: [openssl-dev] [openssl.org #4038] SSLv2 session reuse is broken on the 1.0.2 branch In-Reply-To: <55F32FC6.1030705@akamai.com> References: <55F32FC6.1030705@akamai.com> Message-ID: SSLv2 support has been removed from master, but is still present in 1.0.2. Adding a range check in ssl_get_prev_session() broke the SSLv2 codepath because it supplied NULL as the 'limit' parameter that had not previously been used for SSLv2 (or v3), so the fix is just to supply a non-NULL limit. Patch at https://github.com/openssl/openssl/pull/395 . _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 11 19:58:11 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 19:58:11 +0000 Subject: [openssl-dev] [openssl.org #2397] openssl x509 stops outputting just before printing Issuer when using nameopt dn_rev In-Reply-To: References: Message-ID: Fixed to use a default separator if none is specified. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From kurt at roeckx.be Fri Sep 11 20:36:00 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 11 Sep 2015 22:36:00 +0200 Subject: [openssl-dev] interaction between --strict-warnings and disabled features In-Reply-To: <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <55F3114F.1070000@akamai.com> <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20150911203600.GA26216@roeckx.be> On Fri, Sep 11, 2015 at 05:46:13PM +0000, Salz, Rich wrote: > > When I configure with --strict-warnings and, say, no-seed, my build fails due > > to an empty compilation unit e_seed.c. > > Does just putting an extern declaration in the file work? Or do we need something like "#if PEDANTIC" in apps/dsa.c, for example. I think the PEDANTIC thing is the way to go for that. Kurt From dkg at fifthhorseman.net Fri Sep 11 21:45:49 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Sep 2015 17:45:49 -0400 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F2EE2F.3080704@cisco.com> References: <55F2E667.5000506@openssl.org> <55F2EE2F.3080704@cisco.com> Message-ID: <87613geik2.fsf@alice.fifthhorseman.net> On Fri 2015-09-11 11:07:27 -0400, John Foley wrote: > It's great to see improvements in the state machine along with > consolidated handlers for TLS/DTLS. Agreed. Thanks for the work on this, Matt! > Having said that, have you considered using a state transition table > instead of long switch statements to enforce the state transition > rules? This would improve the maintainability of the code. Here's a > trivial example: > > http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/ I'm getting a 404 from this. do you have another link? --dkg From rt at openssl.org Fri Sep 11 21:58:00 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 21:58:00 +0000 Subject: [openssl-dev] [openssl.org #4037] IV-setting bug on AES/CCM decryption In-Reply-To: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> References: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> Message-ID: On Fri Sep 11 17:34:27 2015, afelsher at cisco.com wrote: > Hi, > > While running some tests on a module using OpenSSL, we noticed that > when using EVP_CIPHER_CTX_ctrl(context, EVP_CTRL_CCM_SET_IVLEN, > length, NULL) to set the IV length, AES/CCM decryption does not seem > to detect a bad IV length. With encryption, it is detected and an > appropriate error code is returned. And AES/GCM, for example, detects > the bad IV length for both encryption and decryption. > Can you give a few more details? What do you mean by a "bad IV length" do you have some sample code? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Fri Sep 11 22:48:07 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 11 Sep 2015 22:48:07 +0000 Subject: [openssl-dev] Strange problem with cms_cd.o? In-Reply-To: References: Message-ID: <20150911224807.GA30851@openssl.org> On Fri, Sep 11, 2015, Blumenthal, Uri - 0553 - MITLL wrote: > I am trying to build the current Github version of openssl on Ubuntu-14.04 > LTS. Must add that this system has openssl-1.0.1f already installed (relict > of Ubuntu software update process). > > Everything seems to compile fine, but linking of ???openssl??? fails, > complaining that it cannot find ???CMS_CompressedData_it??? reference. This only > happens when I configure openssl with ???zlib" > > ./config ???prefix=/usr/local threads zlib > > I observed that ???r CMS_CompressedData_it??? is present in cms_asn1.o in > libcrypto.a. > > This works fine and links everything correctly (and all the tests pass OK): > > ./config ???prefix=/usr/local threads > > Any help is appreciated. > Fixed in commit bc2a15cdfb5a5a9 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From foleyj at cisco.com Fri Sep 11 22:56:08 2015 From: foleyj at cisco.com (John Foley (foleyj)) Date: Fri, 11 Sep 2015 22:56:08 +0000 Subject: [openssl-dev] State machine rewrite In-Reply-To: <87613geik2.fsf@alice.fifthhorseman.net> References: <55F2E667.5000506@openssl.org> <55F2EE2F.3080704@cisco.com>,<87613geik2.fsf@alice.fifthhorseman.net> Message-ID: <652F5D58-93EB-44B2-BCCF-9FF671540D62@cisco.com> Here's another trivial example if that URL still isn't working for you: johnsantic.com/comp/state.html On Sep 11, 2015, at 5:46 PM, Daniel Kahn Gillmor > wrote: On Fri 2015-09-11 11:07:27 -0400, John Foley wrote: It's great to see improvements in the state machine along with consolidated handlers for TLS/DTLS. Agreed. Thanks for the work on this, Matt! Having said that, have you considered using a state transition table instead of long switch statements to enforce the state transition rules? This would improve the maintainability of the code. Here's a trivial example: http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/ I'm getting a 404 from this. do you have another link? --dkg -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 11 23:20:52 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 12 Sep 2015 00:20:52 +0100 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F2EE2F.3080704@cisco.com> References: <55F2E667.5000506@openssl.org> <55F2EE2F.3080704@cisco.com> Message-ID: <55F361D4.7020003@openssl.org> On 11/09/15 16:07, John Foley wrote: > +1 > > It's great to see improvements in the state machine along with > consolidated handlers for TLS/DTLS. Having said that, have you > considered using a state transition table instead of long switch > statements to enforce the state transition rules? This would improve > the maintainability of the code. Here's a trivial example: > > http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/ > Hi John, That's a really good question that's going to need quite a long answer (sorry!). To summarise: the article states that any finite state machine can be represented as a state transition table. The article shows such a table with states along one axis, and events along the other. The contents of each "cell" of the table are the new state to move to, and an action to perform. The argument is that such an approach is easier to maintain because changing the structure of the state machine does not change the structure of the underlying code (you just change the table), whereas traditional approaches do. The article presents a very simplified table structure (for understandable reasons). A real table approach (for SSL/TLS) would have to be a bit more complicated than that. In particular the "events" we are talking about here are the arrival of new messages (at least they are when we are reading rather than writing). However we are working in a security setting and we have to deal with the possibility of "illegal" events. e.g. if you are server and the last message you read was ClientKeyExchange and then you receive a ChangeCipherSpec - is that ok? Well the answer is "it depends". Dependant on the preceding messages we might need to have a CertificateVerify next. So transitions are actually "guarded" - there is logic which determines whether a particular event is "allowed" in the current scenario or not. This is still fine from a table driven approach - it just means that the contents of our "cells" have to include a transition guard entry as well. The other thing to think about here is why is it that a table driven approach is easier to maintain (assuming we accept the argument that it is)? I would argue the reason is that each entry in the cells conforms to a common interface. The logic that does all the hard work of moving around that state machine can be generic, and all the state specific work is contained within the functions implementing the individual cells - which all have the same interface that the generic code can understand. Therefore changing the state machine should not impact the generic code - its just about changing the states/events/cells. I would further argue that the mechanism that you use to implement the table itself is fairly irrelevant - what is important is the generic table "look up" code doing the work of moving around the state machine, and the common interface to the state specific cells. The article presents a fairly obvious table implementation: an array. In an array based approach you first scan the "rows" of the table until you find your current state, and then you scan the "columns" of the table until you find the event. Now you've found the right cell. This is not the only implementation approach however. You could implement this in code directly: switch(my_state) { case state1: if (event1) cell_1_1_action(); else if (event2) cell_1_2_action(); else error(); break; case state2: if (event1) cell_2_1_action(); else if (event2) cell_2_2_action(); else error(); break; /* etc */ } So why might you take this approach rather than an array based approach? Well one reason is that if you have a lot of states and a lot of possible events an array based approach ends up being quite large and difficult to read...particularly if the table is quite sparsely populated. In SSL/TLS (for reading messages) the current state will be the last state that we read, and the event will be the arrival of the next message. There are quite a large number of states (there are 37 entries in the HANSHAKE_STATE enum), so you're talking about a 37x37 array. That's going to get quite messy to maintain. Given that the table is going to be sparsely populated I think the code based approach is probably better. You could probably come up more complicated data driven approaches that can cope with sparse data, but I reckon the code based approach given above is equivalent, quite simple, and does the job equally well. There is another reason as well why the code based approach might be preferable. I mentioned earlier about the necessity for transition "guard" logic. This makes the code above look more like this: switch(my_state) { case state1: if (event1 && guard_1_1) cell_1_1_action(); else if (event2 && guard_1_2) cell_1_2_action(); else error(); break; case state2: if (event1 && guard_2_1) cell_2_1_action(); else if (event2 && guard_2_2) cell_2_2_action(); else error(); break; /* etc */ } In an array based approach the guard logic would have to go into the cell data. In practice this means that each guard would have to be a function. That's going to see quite an explosion in the number of functions required and will distribute the transition logic around the code to wherever the functions are defined. In reality the guards are often quite simple. There may be the odd occasion where the guards are complicated enough to be functions, but more often than not you can just inline the guards directly into the if statements. This has the *significant* advantage that you can keep all the transition logic *in one place*. This was actually one of my design goals for the whole rewrite. The old state machine code has transition logic everywhere. Its very difficult to reason about and verify its correctness. By keeping everything together in one place the job of sanity checking that the logic is correct is made much easier. I would also argue that code maintenance is also much easier than having the logic distributed around lots of different functions. I have simplified things quite considerably. The whole thing is further complicated by the need to handle non-blocking IO, and so the state machine needs to be able to stop at any point, return control back to the calling application in order to resume where it left off later. For that reason (amongst others) the actual code implementation is slightly more complicated than I have outlined. However I would argue that the approach that has been taken is: - still table driven (using a code based implementation approach) - exhibits the core features of the table based approach: generic code along with standard interfaces to the "cells" of the table - benefits from the advantages of such an approach, i.e. code maintainability It's not an array based table which is what I think you were looking for. But I think there are good reasons not to go down that path. Matt From rt at openssl.org Fri Sep 11 23:52:42 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 23:52:42 +0000 Subject: [openssl-dev] [openssl.org #4036] Invalid use of memcpy() causing decrypt failure In-Reply-To: <55F30E12.6090800@cisco.com> References: <55F30E12.6090800@cisco.com> Message-ID: Fixed now in 1.0.2, it was already fixed in master. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Fri Sep 11 23:54:57 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 11 Sep 2015 23:54:57 +0000 Subject: [openssl-dev] [openssl.org #3978] RE: Openssl 1.0.2c include the FIPS 140-2 Object Module In-Reply-To: <8878620CF8603E45BB794422B7899E9E115D23BF0E@INBLRK77M1MSX.in002.siemens.net> References: <8878620CF8603E45BB794422B7899E9E115D23BF0E@INBLRK77M1MSX.in002.siemens.net> Message-ID: Resolving ticket: not a bug. If you have any more problems use openssl-users. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Sep 12 00:44:35 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 12 Sep 2015 00:44:35 +0000 Subject: [openssl-dev] [openssl.org #3974] The IV used by the 'openssl cms -encrypt -aes-256-gcm' command is not random (all zeroes). In-Reply-To: References: Message-ID: GCM is not supported for CMS enveloped data. Attempting to use it now returns an error. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Sep 12 01:44:59 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 12 Sep 2015 01:44:59 +0000 Subject: [openssl-dev] [openssl.org #3958] [PATCH] pkcs12 application selects bad defaults in FIPS mode In-Reply-To: References: Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From kurt at roeckx.be Sat Sep 12 10:22:50 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 12 Sep 2015 12:22:50 +0200 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F361D4.7020003@openssl.org> References: <55F2E667.5000506@openssl.org> <55F2EE2F.3080704@cisco.com> <55F361D4.7020003@openssl.org> Message-ID: <20150912102250.GA20407@roeckx.be> On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote: > Dependant on the preceding messages we > might need to have a CertificateVerify next. So transitions are actually > "guarded" - there is logic which determines whether a particular event > is "allowed" in the current scenario or not. Does that just not mean you don't have all the states as real states, but that you're combining 1 state with something like a variable to determine between other states inside that state? Please note that I'm not suggesting you turn everything into a state. You might end up with so much states that it gets more complicated than it should, and that you'll end up duplicating more code than you want. Kurt From matt at openssl.org Sat Sep 12 14:25:10 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 12 Sep 2015 15:25:10 +0100 Subject: [openssl-dev] State machine rewrite In-Reply-To: <20150912102250.GA20407@roeckx.be> References: <55F2E667.5000506@openssl.org> <55F2EE2F.3080704@cisco.com> <55F361D4.7020003@openssl.org> <20150912102250.GA20407@roeckx.be> Message-ID: <55F435C6.3060906@openssl.org> On 12/09/15 11:22, Kurt Roeckx wrote: > On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote: >> Dependant on the preceding messages we >> might need to have a CertificateVerify next. So transitions are actually >> "guarded" - there is logic which determines whether a particular event >> is "allowed" in the current scenario or not. > > Does that just not mean you don't have all the states as real > states, but that you're combining 1 state with something like a > variable to determine between other states inside that state? Yes, that is an excellent point and is indeed correct. I am "cheating" a little by introducing guarded transitions. The implementation of these guards inevitably goes off and inspects state that is held outside of the state machine itself. The kind of state I'm talking about here are things like the current ciphersuite; what extensions have been sent/received; whether the client has sent a Certificate or not; etc. It would of course be entirely possible to build a state machine which did not rely on any of this external state - *all* of the state would be locked into our current position within the state machine. For example, this might mean that you need a different set of states and transitions for handling (say) PSK ciphersuites to the set of states and transitions that you need for other ciphersuites. As you can imagine (and as you pointed out) this could lead to a real explosion in the number of states that you need. There's more to it than just that though. In the state machine as I have designed it the events that trigger transitions are quite simple and the code can be generic for handling them (at least for reading messages): an event is simply the arrival of a message of a particular type. In this new extended state machine that we are imagining where there are many more states, the events are more complicated in order to distinguish between the many more different transitions that we can now make. So for example in my state machine an event might be "a ServerHello message has arrived", whereas in the extended state machine the event might be "a ServerHello with a PSK ciphersuite selected has arrived". This now means our event detection logic is much more complicated - and is state specific. All we have done is moved complexity out of the transition guards and into the state machine structure *and* the event detection code. On balance I think such an approach is not a good trade off. I much prefer the simplicity of a one-to-one correspondence between messages and states. Doing it the other way is much more likely to turn into a code maintenance nightmare IMO. Matt From matt at openssl.org Sun Sep 13 18:23:02 2015 From: matt at openssl.org (Matt Caswell) Date: Sun, 13 Sep 2015 19:23:02 +0100 Subject: [openssl-dev] State machine rewrite In-Reply-To: <1B31874D-9AEE-4610-82E7-668EBEBFB22E@gmail.com> References: <636b724b15744e329517054c45ca669b@ustx2ex-dag1mb2.msg.corp.akamai.com> <557EC4D8.3080409@openssl.org> <61535371-E37A-49DF-9559-2C04E8B2C2BD@gmail.com> <55F2E042.6080502@openssl.org> <64BC5E80-0043-4BCA-80A7-B6DD33AD72B6@gmail.com> <1B31874D-9AEE-4610-82E7-668EBEBFB22E@gmail.com> Message-ID: <55F5BF06.60101@openssl.org> Hi Karthik Moving this to openssl-dev as per your suggestion. See my responses below. On 13/09/15 11:18, Karthikeyan Bhargavan wrote: > Matt, > > I?ve been looking through the code and before we begin testing it, my main question is: > what protocol versions and ciphersuites are meant to be covered by this state machine? > > For example, did you intend for it to cover SSL2-TLS1.2? (Clearly, it does not cover TLS 1.3 yet). > How about extensions like NPN? Did you intend for it to cover all PSK modes (PSK, RSA-PSK, DHE-PSK)? *_EXPORT_*? > > Having a succinct list of versions, extensions, and ciphersuites that are meant to be covered would > be good documentation and quite useful. > > Best, > Karthik > The state-machine-rewrite branch covers all the same ciphersuites, protocol versions and extensions that the main master branch covers. Obviously it depends on compile time and run time configuration options as to exactly which ones you get at any one time. However the full list of all those available are as follows. For protocol versions we support: SSLv3 TLS1.0 TLS1.1 TLS1.2 DTLS1.0 DTLS1.2 Note that SSLv2 support has been completely removed from master (and my state-machine-rewrite branch). I'm not sure if your testing tools can cope with DTLS or not, but nonetheless we support it. The extensions we support are: # define TLSEXT_TYPE_server_name 0 # define TLSEXT_TYPE_status_request 5 # define TLSEXT_TYPE_elliptic_curves 10 # define TLSEXT_TYPE_ec_point_formats 11 # define TLSEXT_TYPE_srp 12 # define TLSEXT_TYPE_signature_algorithms 13 # define TLSEXT_TYPE_use_srtp 14 # define TLSEXT_TYPE_heartbeat 15 # define TLSEXT_TYPE_application_layer_protocol_negotiation 16 # define TLSEXT_TYPE_padding 21 # define TLSEXT_TYPE_encrypt_then_mac 22 # define TLSEXT_TYPE_extended_master_secret 23 # define TLSEXT_TYPE_session_ticket 35 # define TLSEXT_TYPE_renegotiate 0xff01 # define TLSEXT_TYPE_next_proto_neg 13172 Note "use srtp" above is a DTLS only extension. For ciphersuites we support: $ ./openssl ciphers -v ALL ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256) Mac=AEAD ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-PSK-AES256-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(256) Mac=AEAD DHE-PSK-AES256-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(256) Mac=AEAD DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256) Mac=AEAD DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD ECDHE-PSK-AES256-CBC-SHA384 SSLv3 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA384 ECDHE-PSK-AES256-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1 SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=AES(256) Mac=SHA1 SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SHA1 SRP-AES-256-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(256) Mac=SHA1 RSA-PSK-AES256-CBC-SHA384 SSLv3 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA384 DHE-PSK-AES256-CBC-SHA384 SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA384 RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(256) Mac=AEAD DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD RSA-PSK-AES256-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(256) Mac=SHA1 DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256 DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256 DH-DSS-AES256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1 DH-DSS-AES256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(256) Mac=SHA1 ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256) Mac=SHA384 ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256) Mac=SHA384 ECDHE-PSK-CAMELLIA256-SHA384 SSLv3 Kx=ECDHEPSK Au=PSK Enc=Camellia(256) Mac=SHA384 RSA-PSK-CAMELLIA256-SHA384 SSLv3 Kx=RSAPSK Au=RSA Enc=Camellia(256) Mac=SHA384 DHE-PSK-CAMELLIA256-SHA384 SSLv3 Kx=DHEPSK Au=PSK Enc=Camellia(256) Mac=SHA384 DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA256 DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA256 DH-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA256 DH-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA256 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1 DH-DSS-CAMELLIA256-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(256) Mac=SHA1 AECDH-AES256-SHA SSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 ADH-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(256) Mac=SHA256 ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA384 ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1 ECDH-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=Camellia(256) Mac=SHA384 ECDH-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=Camellia(256) Mac=SHA384 AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256) Mac=AEAD AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA256 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 PSK-AES256-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(256) Mac=AEAD PSK-AES256-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(256) Mac=AEAD PSK-AES256-CBC-SHA384 SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384 PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 PSK-CAMELLIA256-SHA384 SSLv3 Kx=PSK Au=PSK Enc=Camellia(256) Mac=SHA384 ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128) Mac=AEAD ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) Mac=AEAD ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-PSK-AES128-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(128) Mac=AEAD DHE-PSK-AES128-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(128) Mac=AEAD DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128) Mac=AEAD DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD ECDHE-PSK-AES128-CBC-SHA256 SSLv3 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA256 ECDHE-PSK-AES128-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1 SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=AES(128) Mac=SHA1 SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(128) Mac=SHA1 SRP-AES-128-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=AES(128) Mac=SHA1 RSA-PSK-AES128-CBC-SHA256 SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA256 DHE-PSK-AES128-CBC-SHA256 SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256 RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128) Mac=AEAD DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AESGCM(128) Mac=AEAD DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD RSA-PSK-AES128-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=AES(128) Mac=SHA1 DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256 DH-RSA-AES128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA256 DH-DSS-AES128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 DH-RSA-AES128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(128) Mac=SHA1 DH-DSS-AES128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=AES(128) Mac=SHA1 ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128) Mac=SHA256 ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(128) Mac=SHA256 ECDHE-PSK-CAMELLIA128-SHA256 SSLv3 Kx=ECDHEPSK Au=PSK Enc=Camellia(128) Mac=SHA256 RSA-PSK-CAMELLIA128-SHA256 SSLv3 Kx=RSAPSK Au=RSA Enc=Camellia(128) Mac=SHA256 DHE-PSK-CAMELLIA128-SHA256 SSLv3 Kx=DHEPSK Au=PSK Enc=Camellia(128) Mac=SHA256 DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA256 DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA256 DH-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA256 DH-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA256 DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 DH-RSA-SEED-SHA SSLv3 Kx=DH/RSA Au=DH Enc=SEED(128) Mac=SHA1 DH-DSS-SEED-SHA SSLv3 Kx=DH/DSS Au=DH Enc=SEED(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 DH-RSA-CAMELLIA128-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(128) Mac=SHA1 DH-DSS-CAMELLIA128-SHA SSLv3 Kx=DH/DSS Au=DH Enc=Camellia(128) Mac=SHA1 AECDH-AES128-SHA SSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ADH-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(128) Mac=SHA256 ADH-SEED-SHA SSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA256 ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128) Mac=SHA1 ECDH-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=Camellia(128) Mac=SHA256 ECDH-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=Camellia(128) Mac=SHA256 AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128) Mac=AEAD AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA256 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 PSK-AES128-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(128) Mac=AEAD PSK-AES128-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(128) Mac=AEAD PSK-AES128-CBC-SHA256 SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256 PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1 PSK-CAMELLIA128-SHA256 SSLv3 Kx=PSK Au=PSK Enc=Camellia(128) Mac=SHA256 ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDHE-PSK-RC4-SHA SSLv3 Kx=ECDHEPSK Au=PSK Enc=RC4(128) Mac=SHA1 RSA-PSK-RC4-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=RC4(128) Mac=SHA1 DHE-PSK-RC4-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=RC4(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 ECDHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK Enc=3DES(168) Mac=SHA1 SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=DSS Enc=3DES(168) Mac=SHA1 SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=3DES(168) Mac=SHA1 SRP-3DES-EDE-CBC-SHA SSLv3 Kx=SRP Au=SRP Enc=3DES(168) Mac=SHA1 RSA-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=RSAPSK Au=RSA Enc=3DES(168) Mac=SHA1 DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=3DES(168) Mac=SHA1 DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 DHE-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DH-RSA-DES-CBC3-SHA SSLv3 Kx=DH/RSA Au=DH Enc=3DES(168) Mac=SHA1 DH-DSS-DES-CBC3-SHA SSLv3 Kx=DH/DSS Au=DH Enc=3DES(168) Mac=SHA1 AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1 ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1 ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1 DHE-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DH-RSA-DES-CBC-SHA SSLv3 Kx=DH/RSA Au=DH Enc=DES(56) Mac=SHA1 DH-DSS-DES-CBC-SHA SSLv3 Kx=DH/DSS Au=DH Enc=DES(56) Mac=SHA1 ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 EXP-DHE-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-ADH-DES-CBC-SHA SSLv3 Kx=DH(512) Au=None Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-ADH-RC4-MD5 SSLv3 Kx=DH(512) Au=None Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export Matt From rt at openssl.org Mon Sep 14 01:09:14 2015 From: rt at openssl.org (Leif Thuresson via RT) Date: Mon, 14 Sep 2015 01:09:14 +0000 Subject: [openssl-dev] [openssl.org #4039] TLS-PSK - SSL_use_psk_identity_hint() In-Reply-To: <55F46407.3020403@foxt.com> References: <55F46407.3020403@foxt.com> Message-ID: I understand that there has been an overhaul of the TLS-PSK support. Is there any chance to get the SSL_use_psk_identity_hint() function fixed in the process? The current implementation of this function is useless at least in my use case. I want to set the a PSK hint based on the address etc. of incoming connections to a server. The current implementation stores the PSK hint set with SSL_use_psk_identity_hint() in the SSL_SESSION object and if the session is not created SSL_use_psk_identity_hint() returns OK and ignores the hint? Typically you would like to use this function in conjunction with creating the SSL object so storing the PSK hint in the SSL_SESSION object is a problem since the session is not yet created. Thanks, /Leif Thuresson _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Sep 14 01:09:16 2015 From: rt at openssl.org (Martin Nilsson via RT) Date: Mon, 14 Sep 2015 01:09:16 +0000 Subject: [openssl-dev] [openssl.org #4040] Fix for comment out of sync with code (t1_lib.c:ssl_check_for_safari) In-Reply-To: <1442190473.2380466.382611457.4C6C5DB8@webmail.messagingengine.com> References: <1442190473.2380466.382611457.4C6C5DB8@webmail.messagingengine.com> Message-ID: $ diff -c t1_lib.c t1_lib_2.c *** t1_lib.c 2015-09-14 02:23:04.180535915 +0200 --- t1_lib_2.c 2015-09-14 02:23:22.620374882 +0200 *************** *** 1827,1833 **** * ssl_check_for_safari attempts to fingerprint Safari using OS X * SecureTransport using the TLS extension block in |d|, of length |n|. * Safari, since 10.6, sends exactly these extensions, in this order: ! * SNI, * elliptic_curves * ec_point_formats * --- 1827,1834 ---- * ssl_check_for_safari attempts to fingerprint Safari using OS X * SecureTransport using the TLS extension block in |d|, of length |n|. * Safari, since 10.6, sends exactly these extensions, in this order: ! * SNI ! * signature_algorithms * elliptic_curves * ec_point_formats * -- Martin Nilsson nilsson at fastmail.se _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Mon Sep 14 12:27:02 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2015 13:27:02 +0100 Subject: [openssl-dev] State machine rewrite In-Reply-To: <027AA0CB-C13D-4912-A76F-6623056BA805@gmail.com> References: <636b724b15744e329517054c45ca669b@ustx2ex-dag1mb2.msg.corp.akamai.com> <557EC4D8.3080409@openssl.org> <61535371-E37A-49DF-9559-2C04E8B2C2BD@gmail.com> <55F2E042.6080502@openssl.org> <64BC5E80-0043-4BCA-80A7-B6DD33AD72B6@gmail.com> <1B31874D-9AEE-4610-82E7-668EBEBFB22E@gmail.com> <55F5BB8A.7070108@openssl.org> <027AA0CB-C13D-4912-A76F-6623056BA805@gmail.com> Message-ID: <55F6BD16.6080109@openssl.org> On 14/09/15 11:27, Karthikeyan Bhargavan wrote: > [Could you forward to openssl-dev? I don?t seem to have permissions to post over there :(] You need to be subscribed with the same email address that you are posting from otherwise your posts will be rejected. openssl-dev: email from Karthik below along with my response. > > From a superficial look at the new state machine code, it seems to be missing a few boolean conditions. > > E.g. in statem_clnt.c after receiving a server CERTIFICATE, the client uses the function key_exchange_skip_allowed > to check whether the next message must be a SERVER_KEY_EXCHANGE or not. > In particular, if the kex is DHE or ECDHE, skipping SKE is allowed, otherwise not. > > However, this means that > (a) If the kex is RSA or PSK, the peer is still allowed to send SKE > (b) if the kex is RSA_EXPORT, the peer is allowed to skip SKE > > Do I have this right? > > I will continue my code inspection before trying to set automated tests for this state machnine > > Best, > Karthik > Hmmm. There does seem to be a couple of problems here. 1) The logic around skipping SKE has changed very recently in master due to the introduction of new PSK ciphersuites. I think there is a merge error in reflecting these changes in the state-machine-rewrite branch. In particular I think the condition in key_exchange_skip_allowed should read: if (alg_k & (SSL_kDHE | SSL_kECDHE | SSL_kDHEPSK | SSL_kECDHEPSK)) { return 0; } In other words there are more ephemeral ciphersuites that must not skip SKE. 2) In tls_process_key_exchange there is a check to ensure that if an SKE has been sent for an RSA ciphersuite then it must be an export ciphersuite. This is inherited from the existing master code. However that check (whilst technically correct) is inconsistent with how the new state machine code works. It should be moved into key_exchange_skip_allowed. Similarly for checking non export RSA ciphersuites. I think it is correct that if PSK is selected that an SKE is allowed since this can contain the identity hint. I will add a new commit to address the above issues. Matt From rt at openssl.org Thu Sep 10 10:42:41 2015 From: rt at openssl.org (Gueron, Shay via RT) Date: Thu, 10 Sep 2015 10:42:41 +0000 Subject: [openssl-dev] [openssl.org #4032] [PATCH] Fast 1536-bit modular exponentiation with the new VPMADD52 instructions In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939C9CF3E@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939C9CF3E@hasmsx107.ger.corp.intel.com> Message-ID: Hello everyone, This patch is a contribution to OpenSSL. It extends the patch "Id 3590" (from Nov 04, 2014; by Gueron and Krasnov) entitled "Fast modular exponentiation with the new VPMADD52 instructions". This contribution includes 1536-bit modular exponentiation (constant time) with the RSA fix to use these functions. An efficient 1536-bit modular exponentiation is useful for speeding up RSA3072 (decrypt/sign). RSA3072 provides 128 bit equivalent security (compared to 112 bits offered by RSA2048). Significant performance gains can be expected on future processors that will support VPMADD52. Details: The underlying method is VNRMM which explained in [1]. VPMADD52 instructions (VPMADD52LUQ and VPMADD52HUQ) were announced in https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf (see also the Intel(r) Software Development Emulator at https://software.intel.com/en-us/articles/intel-software-development-emulator) (currently, building the patch requires "binutils" version 2.24 (at least)., which can be downloaded from http://ftp.gnu.org/gnu/binutils/) Reference: [1] S. Gueron, V. Krasnov: "New CPU instructions for speeding up modular exponentiation" (to be published) Developers and authors: *************************************************************************** Shay Gueron (1, 2), Nir Drucker (1) (1) Intel Corporation, Israel Development Center, Haifa, Israel (2) University of Haifa, Israel *************************************************************************** Copyright (c) 2015, Intel Corp. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: rsaz-1356-vpmadd.patch Type: application/octet-stream Size: 44842 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From afelsher at cisco.com Mon Sep 14 14:04:25 2015 From: afelsher at cisco.com (Andrew Felsher (afelsher)) Date: Mon, 14 Sep 2015 14:04:25 +0000 Subject: [openssl-dev] [openssl.org #4037] IV-setting bug on AES/CCM decryption In-Reply-To: References: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> Message-ID: <4A26CC88823F2141ADDABB49292DF506212A334F@xmb-aln-x13.cisco.com> Nevermind; there was a misunderstanding regarding some program flows. Thanks anyway, Andrew -----Original Message----- From: Stephen Henson via RT [mailto:rt at openssl.org] Sent: Friday, September 11, 2015 5:58 PM To: Andrew Felsher (afelsher) Cc: openssl-dev at openssl.org Subject: [openssl.org #4037] IV-setting bug on AES/CCM decryption On Fri Sep 11 17:34:27 2015, afelsher at cisco.com wrote: > Hi, > > While running some tests on a module using OpenSSL, we noticed that > when using EVP_CIPHER_CTX_ctrl(context, EVP_CTRL_CCM_SET_IVLEN, > length, NULL) to set the IV length, AES/CCM decryption does not seem > to detect a bad IV length. With encryption, it is detected and an > appropriate error code is returned. And AES/GCM, for example, detects > the bad IV length for both encryption and decryption. > Can you give a few more details? What do you mean by a "bad IV length" do you have some sample code? 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 Sep 14 14:14:26 2015 From: rt at openssl.org (Andrew Felsher via RT) Date: Mon, 14 Sep 2015 14:14:26 +0000 Subject: [openssl-dev] [openssl.org #4037] IV-setting bug on AES/CCM decryption In-Reply-To: <4A26CC88823F2141ADDABB49292DF506212A334F@xmb-aln-x13.cisco.com> References: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> <4A26CC88823F2141ADDABB49292DF506212A334F@xmb-aln-x13.cisco.com> Message-ID: Nevermind; there was a misunderstanding regarding some program flows. Thanks anyway, Andrew -----Original Message----- From: Stephen Henson via RT [mailto:rt at openssl.org] Sent: Friday, September 11, 2015 5:58 PM To: Andrew Felsher (afelsher) Cc: openssl-dev at openssl.org Subject: [openssl.org #4037] IV-setting bug on AES/CCM decryption On Fri Sep 11 17:34:27 2015, afelsher at cisco.com wrote: > Hi, > > While running some tests on a module using OpenSSL, we noticed that > when using EVP_CIPHER_CTX_ctrl(context, EVP_CTRL_CCM_SET_IVLEN, > length, NULL) to set the IV length, AES/CCM decryption does not seem > to detect a bad IV length. With encryption, it is detected and an > appropriate error code is returned. And AES/GCM, for example, detects > the bad IV length for both encryption and decryption. > Can you give a few more details? What do you mean by a "bad IV length" do you have some sample code? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From matt at openssl.org Mon Sep 14 14:28:08 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Sep 2015 15:28:08 +0100 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F6BD16.6080109@openssl.org> References: <636b724b15744e329517054c45ca669b@ustx2ex-dag1mb2.msg.corp.akamai.com> <557EC4D8.3080409@openssl.org> <61535371-E37A-49DF-9559-2C04E8B2C2BD@gmail.com> <55F2E042.6080502@openssl.org> <64BC5E80-0043-4BCA-80A7-B6DD33AD72B6@gmail.com> <1B31874D-9AEE-4610-82E7-668EBEBFB22E@gmail.com> <55F5BB8A.7070108@openssl.org> <027AA0CB-C13D-4912-A76F-6623056BA805@gmail.com> <55F6BD16.6080109@openssl.org> Message-ID: <55F6D978.8020804@openssl.org> On 14/09/15 13:27, Matt Caswell wrote: > Hmmm. There does seem to be a couple of problems here. > > 1) The logic around skipping SKE has changed very recently in master due > to the introduction of new PSK ciphersuites. I think there is a merge > error in reflecting these changes in the state-machine-rewrite branch. > In particular I think the condition in key_exchange_skip_allowed should > read: > > if (alg_k & (SSL_kDHE | SSL_kECDHE | SSL_kDHEPSK | SSL_kECDHEPSK)) { > return 0; > } > > In other words there are more ephemeral ciphersuites that must not skip SKE. > > 2) In tls_process_key_exchange there is a check to ensure that if an SKE > has been sent for an RSA ciphersuite then it must be an export > ciphersuite. This is inherited from the existing master code. However > that check (whilst technically correct) is inconsistent with how the new > state machine code works. It should be moved into > key_exchange_skip_allowed. Similarly for checking non export RSA > ciphersuites. > > I think it is correct that if PSK is selected that an SKE is allowed > since this can contain the identity hint. > > I will add a new commit to address the above issues. Right - new commit added. So hopefully this covers the following logic: An SKE is required if: - The ciphersuite is DHE, ECDHE, DHEPSK, ECDHEPSK or SRP based - We have an export ciphersuite (must be RSA) and the key length in the server certificate is greater than the maximum allowed. An SKE is optional if: - The ciphersuite is any PSK ciphersuite where the SKE is not mandatory An SKE must not be sent: - In any other circumstance Matt From rt at openssl.org Mon Sep 14 15:10:22 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 14 Sep 2015 15:10:22 +0000 Subject: [openssl-dev] [openssl.org #4037] IV-setting bug on AES/CCM decryption In-Reply-To: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> References: <4A26CC88823F2141ADDABB49292DF506212A1C88@xmb-aln-x13.cisco.com> Message-ID: submitter said it was their error. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From bkaduk at akamai.com Mon Sep 14 15:43:23 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 14 Sep 2015 10:43:23 -0500 Subject: [openssl-dev] interaction between --strict-warnings and disabled features In-Reply-To: <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <55F3114F.1070000@akamai.com> <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <55F6EB1B.1080602@akamai.com> On 09/11/2015 12:46 PM, Salz, Rich wrote: >> When I configure with --strict-warnings and, say, no-seed, my build fails due >> to an empty compilation unit e_seed.c. > Does just putting an extern declaration in the file work? Or do we need something like "#if PEDANTIC" in apps/dsa.c, for example. Duplicating the declaration of SEED_encrypt() (with or without an extern keyword) at the end of the file, outside the #ifndef, lets the build succeed. But I think I agree with Kurt; the PEDANTIC thing makes it more clear what is actually going on. Thanks for the suggestions, Ben From bkaduk at akamai.com Mon Sep 14 17:29:09 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 14 Sep 2015 12:29:09 -0500 Subject: [openssl-dev] interaction between --strict-warnings and disabled features In-Reply-To: <55F6EB1B.1080602@akamai.com> References: <55F3114F.1070000@akamai.com> <20917cf03e8640db9a5570a1989ac1fb@ustx2ex-dag1mb3.msg.corp.akamai.com> <55F6EB1B.1080602@akamai.com> Message-ID: <55F703E5.2010700@akamai.com> On 09/14/2015 10:43 AM, Benjamin Kaduk wrote: > Duplicating the declaration of SEED_encrypt() (with or without an extern > keyword) at the end of the file, outside the #ifndef, lets the build > succeed. Sorry, I was mistakenly testing with seed enabled; the quoted statement is false. -Ben From rt at openssl.org Mon Sep 14 17:30:38 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 14 Sep 2015 17:30:38 +0000 Subject: [openssl-dev] [openssl.org #4026] patches to eliminate some warnings from clang In-Reply-To: <0CC79531-6841-48A0-B144-097B62785FF3@akamai.com> References: <0CC79531-6841-48A0-B144-097B62785FF3@akamai.com> Message-ID: Ben's work on df2ee0e27d2db02660c1d15fe6a3e38be9df0a60 made a lot of this stuff redundant; I rebased the branch at https://github.com/kaduk/openssl/commits/warning-cleanup and generated a new warning-cleanup1.patch, attached. Of note: the move of x509v3/ext_dat.h to crypto/include/internal is gone, since it would now just be a lot of churn only to remove one ".." path in an include statement. I also dropped the x509_object_cmp() change -- as much as I would like to uncomment the abort(), I haven't done an analysis to convince myself that it would not be introducing a remote DoS vector. -Ben From rt at openssl.org Mon Sep 14 18:16:01 2015 From: rt at openssl.org (Adam Eijdenberg via RT) Date: Mon, 14 Sep 2015 18:16:01 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: Message-ID: First of a series of patches to add comprehensive Certificate Transparency support to OpenSSL. Splitting into chunks to help review process. The first sets of patches will add private API surface only. Later patches will add tests and public API surface. Many thanks to Rob Stradling and Dr. Stephen Henson for the code in these patches. https://github.com/openssl/openssl/pull/396 This first patch looks larger than it really is - much of it is boilerplate related to adding the new Makefile, new error codes, running "make update" etc. -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Mon Sep 14 18:28:48 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 14 Sep 2015 18:28:48 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: Message-ID: <20150914182848.GG21942@mournblade.imrryr.org> On Mon, Sep 14, 2015 at 06:16:01PM +0000, Adam Eijdenberg via RT wrote: > First of a series of patches to add comprehensive Certificate Transparency > support to OpenSSL. Splitting into chunks to help review process. > > The first sets of patches will add private API surface only. > Later patches will add tests and public API surface. Is there a document that describes the new functionality? All I see is new code, and it is fairly light on comments. Splitting it up into multiple patches is good, but adoption of a new feature really should require that all the patches be available together, so that the overall design can be assessed as well the individual components. So better would be a pull request with multiple commits, rather than separate pull requests for each one. It seems unlikely that we'll adopt just a subset of the functionality. -- Viktor. From eijdenberg at google.com Mon Sep 14 18:45:34 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Mon, 14 Sep 2015 18:45:34 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <20150914182848.GG21942@mournblade.imrryr.org> References: <20150914182848.GG21942@mournblade.imrryr.org> Message-ID: On Mon, Sep 14, 2015 at 11:29 AM Viktor Dukhovni wrote: > Is there a document that describes the new functionality? All I > see is new code, and it is fairly light on comments. > > Splitting it up into multiple patches is good, but adoption of a > new feature really should require that all the patches be available > together, so that the overall design can be assessed as well the > individual components. > Hi Viktor, Thanks for the feedback. This branch: https://github.com/aeijdenberg/openssl/tree/ct-on-steve-sct has a longer plausible series of commits. The PR submitted in this ticket helps form the base of that series. A README describing the proposed end state is here: https://github.com/aeijdenberg/openssl/blob/ct-on-steve-sct/crypto/ct/README.md I suspect the final public API surface will generate substantial discussion, however it felt like there is a good amount of plumbing we need to get in place first that is likely less interesting / controversial. Emilia suggested breaking the basics down into some initial PRs, so that's how I got here. I'm happy to resubmit the patches in any format/structure that the team finds best to work with. Cheers, Adam > So better would be a pull request with multiple commits, rather > than separate pull requests for each one. It seems unlikely that > we'll adopt just a subset of the functionality. > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 14 19:11:50 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 14 Sep 2015 19:11:50 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: <20150914182848.GG21942@mournblade.imrryr.org> Message-ID: <20150914191150.GH21942@mournblade.imrryr.org> On Mon, Sep 14, 2015 at 06:45:34PM +0000, Adam Eijdenberg wrote: > Thanks for the feedback. This branch: > https://github.com/aeijdenberg/openssl/tree/ct-on-steve-sct > > has a longer plausible series of commits. The PR submitted in this ticket > helps form the base of that series. > > A README describing the proposed end state is here: > https://github.com/aeijdenberg/openssl/blob/ct-on-steve-sct/crypto/ct/README.md Thanks, that is very helpful. It is much easier to understand the new code when one knows where it is heading... One question on the overall integration. What adjustments if any might need to be made to existing servers that are not "CT-aware"? If a CA starts issuing certificates with CT-related extensions, will a server need new code to interoperate with CT-aware clients? Basically, what does "openssl s_server -serverinfo ..." do, and does it become necessary to update server applications to do the same? The README talks about the client API, but not much about the server API. -- Viktor. From rsalz at akamai.com Mon Sep 14 20:05:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 14 Sep 2015 20:05:06 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <20150914191150.GH21942@mournblade.imrryr.org> References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> Message-ID: <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> > One question on the overall integration. What adjustments if any might > need to be made to existing servers that are not "CT-aware"? For now, absolutely nothing. At some point there might be the equivalent of an "OCSP Stapling" for CT data. It's all about the client being able to see if the cert is got is valid. From openssl-users at dukhovni.org Mon Sep 14 20:25:55 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 14 Sep 2015 20:25:55 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20150914202555.GN21942@mournblade.imrryr.org> On Mon, Sep 14, 2015 at 08:05:06PM +0000, Salz, Rich wrote: > > One question on the overall integration. What adjustments if any might > > need to be made to existing servers that are not "CT-aware"? > > For now, absolutely nothing. At some point there might be the equivalent > of an "OCSP Stapling" for CT data. It's all about the client being able > to see if the cert is got is valid. What is then the purpose of the new "-serverinfo" option of s_server? If CT works without it, why add it? -- Viktor. From rt at openssl.org Mon Sep 14 21:04:55 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Mon, 14 Sep 2015 21:04:55 +0000 Subject: [openssl-dev] [openssl.org #4039] TLS-PSK - SSL_use_psk_identity_hint() In-Reply-To: <55F46407.3020403@foxt.com> References: <55F46407.3020403@foxt.com> Message-ID: On Mon Sep 14 01:09:14 2015, leif.thuresson at foxt.com wrote: > I understand that there has been an overhaul of the TLS-PSK support. > Is there any chance to get the SSL_use_psk_identity_hint() function > fixed in the process? Yes the current implementaion is just plain broken. I've applied a fix to the master branch as commit df6da24bda457b72. Let me know of any problems. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From eijdenberg at google.com Mon Sep 14 21:19:32 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Mon, 14 Sep 2015 21:19:32 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <20150914202555.GN21942@mournblade.imrryr.org> References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> Message-ID: On Mon, Sep 14, 2015 at 1:26 PM Viktor Dukhovni wrote: > On Mon, Sep 14, 2015 at 08:05:06PM +0000, Salz, Rich wrote: > > > > One question on the overall integration. What adjustments if any might > > > need to be made to existing servers that are not "CT-aware"? > > > > For now, absolutely nothing. At some point there might be the equivalent > > of an "OCSP Stapling" for CT data. It's all about the client being able > > to see if the cert is got is valid. > > What is then the purpose of the new "-serverinfo" option of s_server? > If CT works without it, why add it? > There are 3 ways by which a server can deliver Signed Certificate Timestamps (SCTs) to clients: 1. SCTs embedded in the certificate itself. 2. SCTs embedded in an OCSP-stapled response. 3. SCTs sent in a TLS extension. (1) requires work only by the CA issuing the cert. (2) requires work by the CA in their OCSP responder, and work by the site operator to enable OCSP stapling in their server. (3) requires work by the site operator only to configure their server to send SCTs. The "-serverinfo" option to s_server is one way to achieve (3), and in fact the tests (in a later commit) for s_client use this flag to verify behavior. I believe "-serverinfo" is purposely generic so it can also be used for adding other TLS extension data that does not require dynamic processing. Rich is correct that a server does not need to do anything, that is, until clients begin to require CT support (as we expect them to do over time as CT proves its value). Chrome, for example, already actually requires SCTs be supplied during the handshake for EV certificates that have been issued after January 1 this year ( https://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Extended-Validation-Certificates ). > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 14 21:24:51 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 14 Sep 2015 21:24:51 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> Message-ID: <165ccca29cbc4b66bd74b57c71172f9a@ustx2ex-dag1mb3.msg.corp.akamai.com> > 1. SCTs embedded in the certificate itself. > 2. SCTs embedded in an OCSP-stapled response. > 3. SCTs sent in a TLS extension. And my guess it's gonna be like exponential fall-off in that order. But we'll have to see. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From sebastianbrestin at gmail.com Mon Sep 14 21:30:24 2015 From: sebastianbrestin at gmail.com (Sebastian Brestin) Date: Tue, 15 Sep 2015 00:30:24 +0300 Subject: [openssl-dev] testing framework Message-ID: Hi guys, I just joined your community over here. Quick question: why have you chosen Test:More as a testing framework rather than gtest or another framework? I would be interested over the unit testing area if there are any plans in this direction. -sebastian -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 14 21:55:55 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 14 Sep 2015 21:55:55 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> Message-ID: <20150914215555.GR21942@mournblade.imrryr.org> On Mon, Sep 14, 2015 at 09:19:32PM +0000, Adam Eijdenberg wrote: > > What is then the purpose of the new "-serverinfo" option of s_server? > > If CT works without it, why add it? > > There are 3 ways by which a server can deliver Signed Certificate > Timestamps (SCTs) to clients: > > 1. SCTs embedded in the certificate itself. Some certificates will have these, and some won't. The client-side API has clients setting CT policy prior to the start of the handshake, before the client knows the issuer of the server certificate, or whether the server's certificate is EV or not. Is that the right design? Or does it make more sense for the client to require (or not require) CT dynamically, based on certificate features, (and likely on whether it is doing tranditional WebPKI or DANE). > 2. SCTs embedded in an OCSP-stapled response. Some servers don't support OCSP stapling, will the introduction of CT "require" them to start doing that? > 3. SCTs sent in a TLS extension. Under what conditions should a server be configured to do that? > (1) requires work only by the CA issuing the cert. So entirely transparent to the server... Do we really need any of the other models? Why? > (2) requires work by the CA in their OCSP responder, and work by the site > operator to enable OCSP stapling in their server. What's the advantage of SCT via OCSP rather than in the certificate? > (3) requires work by the site operator only to configure their server to > send SCTs. When is this the right model? > The "-serverinfo" option to s_server is one way to achieve (3), and in fact > the tests (in a later commit) for s_client use this flag to verify > behavior. I believe "-serverinfo" is purposely generic so it can also be > used for adding other TLS extension data that does not require dynamic > processing. So it is required for (3) only? > Rich is correct that a server does not need to do anything, that is, until > clients begin to require CT support (as we expect them to do over time as > CT proves its value). The API at the moment seems to support "requiring" CT before any communication with the server. That seems to be a flag-day transtion. Should the policy not be based on particular issuing CAs (that commit to log everything they issue)? That would make for a more incremental transition. > Chrome, for example, already actually requires SCTs be supplied during > the handshake for EV certificates that have been issued after January 1 > this year > https://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Extended-Validation-Certificates Which one does not know until the ServerCertificateMessage is received. In that light, do CT policy settings made indepent of any input from the server make sense? Perhaps the right place for CT policy (which logs to use, whether CT is required, ...) is in auxiliary data stored with "TRUSTED CERTIFICATE" objects for root CAs? -- Viktor. From eijdenberg at google.com Mon Sep 14 23:38:28 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Mon, 14 Sep 2015 23:38:28 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <20150914215555.GR21942@mournblade.imrryr.org> References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> <20150914215555.GR21942@mournblade.imrryr.org> Message-ID: Viktor, thanks for the detailed feedback and questions. Comments inline below. On Mon, Sep 14, 2015 at 2:56 PM Viktor Dukhovni wrote: > On Mon, Sep 14, 2015 at 09:19:32PM +0000, Adam Eijdenberg wrote: > > > > What is then the purpose of the new "-serverinfo" option of s_server? > > > If CT works without it, why add it? > > > > There are 3 ways by which a server can deliver Signed Certificate > > Timestamps (SCTs) to clients: > > > > 1. SCTs embedded in the certificate itself. > > Some certificates will have these, and some won't. The client-side > API has clients setting CT policy prior to the start of the handshake, > before the client knows the issuer of the server certificate, or > whether the server's certificate is EV or not. > > Is that the right design? Or does it make more sense for the client > to require (or not require) CT dynamically, based on certificate > features, (and likely on whether it is doing tranditional WebPKI > or DANE). > The idea of CT is to make mis-issuance easily detectable by requiring all certs to be logged in order to be considered valid (and thus deter mis-issuance). It would not be good if one could deliberately mis-issue a cert that would make clients think they need didn't need CT, so in the fullness of time (when is CT widely adopted, required by browsers) I would expect most clients would just turn this on in the same manner they would turn on verifying a cert chains to a trusted root. That said, I agree the higher level API proposed in the later patch isn't flexible enough, for example, one couldn't implement the current Chrome EV policy with it, and likely should be replaced with a callback similar to how verify is currently done. I figured that it's still worth starting on the more basic patches first as I expect it'll take a while to get all the pieces through the pipeline, and I think will leave us open to try a variety of approaches there later. > > 2. SCTs embedded in an OCSP-stapled response. > > Some servers don't support OCSP stapling, will the introduction of > CT "require" them to start doing that? > No. A server can choose either of the option options (1) or (3) instead to support CT. > > 3. SCTs sent in a TLS extension. > > Under what conditions should a server be configured to do that? > Any time a server wishes to serve SCTs. I'll list some reasons in the similar question below as to why this is desirable. Note that these methods are additive, not mutually exclusive. SCTs may be provided by any combination of these 3 mechanisms. > > (1) requires work only by the CA issuing the cert. > > So entirely transparent to the server... Do we really need any of > the other models? Why? > Under both (2) and (3) (but not (1)) the set of SCTs returned for a certificate can vary over time. So, for example, if a CT log ceased to be trusted for any reason, servers that send SCTs via methods (2) or (3) can log the certificate to new logs and return SCTs from those. Servers configured with (1) alone will need to get and install a new certificate from their CA. This is reflected in Chrome's current EV policy, which guards against this by requiring more SCTs be present depending on certificate validity length when they are delivered by being embedded in the certificate. (3) has another desirable property in that no participation is required by the CA who issued the certificate. A server operator can log their own certificate, grab the latest version of Apache, nginx or haproxy and support CT. For examples of this see: http://www.certificate-transparency.org/resources-for-site-owners > > (2) requires work by the CA in their OCSP responder, and work by the site > > operator to enable OCSP stapling in their server. > > What's the advantage of SCT via OCSP rather than in the certificate? > The set of SCTs returned can be varied over time by the OCSP operator as logs come and go - and less SCTs (= less bandwidth) are required for longer-lived certificates (under Chrome's current EV policy). > > (3) requires work by the site operator only to configure their server to > > send SCTs. > > When is this the right model? > If your CA doesn't currently offer an option to issue a certificate with embedded SCTs, or an OCSP responder with embedded SCTs, then this is a great option. If those other options are available to you, you might still choose to serve via the TLS Extension if fidelity around which SCTs from which logs are returned is important to you. (As a data point, Google properties have recently started serving SCTs via this mechanism.) > > The "-serverinfo" option to s_server is one way to achieve (3), and in > fact > > the tests (in a later commit) for s_client use this flag to verify > > behavior. I believe "-serverinfo" is purposely generic so it can also be > > used for adding other TLS extension data that does not require dynamic > > processing. > > So it is required for (3) only? > Correct. > > Rich is correct that a server does not need to do anything, that is, > until > > clients begin to require CT support (as we expect them to do over time as > > CT proves its value). > > The API at the moment seems to support "requiring" CT before any > communication with the server. That seems to be a flag-day transtion. > Should the policy not be based on particular issuing CAs (that > commit to log everything they issue)? That would make for a more > incremental transition. > I think that when you want to require CT or not depends also on the context in which openssl is being used. For example if it's being used as part of a browser, there'll be one set of considerations (e.g. an incremental rollout like Chrome's current policy or perhaps one as you've described). However if you were using openssl in an application to make custom API over HTTPS calls back to a server that you control, you might want to require CT for all calls, as you know that your server supports it. I'm not a fan of enabling per CA as it means you can avoid detection of a mis-issued certificate by targeting a CA that doesn't indicate it supports CT yet. Again, CT is about providing assurance for site-owners that they can detect mis-issuance of certificates, so one other option that we're considering (in the context of Chrome) is a mechanism by which a site-owner can opt-in to requiring CT ahead of any scheduled requirement (inspired by what Tom Ritter proposes in: https://ritter.vg/blog-require_certificate_transparency.html) > Chrome, for example, already actually requires SCTs be supplied during > > the handshake for EV certificates that have been issued after January 1 > > this year > > > https://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Extended-Validation-Certificates > > Which one does not know until the ServerCertificateMessage is > received. In that light, do CT policy settings made indepent of > any input from the server make sense? > I think it does under some scenarios (e.g. own app talking to own server) but I agree it isn't flexible enough for others (such as anyone trying to duplicate the current Chrome EV policy). Perhaps a callback similar to how verify works would be a helpful replacement for that part of the API? > Perhaps the right place for CT policy (which logs to use, whether > CT is required, ...) is in auxiliary data stored with "TRUSTED > CERTIFICATE" objects for root CAs? > Trusted log metadata will need to be stored somewhere. For the reasons above, I don't think it makes sense in general to key this on a root CA though. One thing to consider though is whether the trusted certificate objects have any notion of whether they are real root CAs, or certs installed by local admins on machines (e.g. by an enterprise that wishes to MITM all outbound connections). For that case ("local" roots) it doesn't make a lot of sense to require CT. > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 15 01:53:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 15 Sep 2015 01:53:36 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> <20150914215555.GR21942@mournblade.imrryr.org> Message-ID: <20150915015336.GV21942@mournblade.imrryr.org> On Mon, Sep 14, 2015 at 11:38:28PM +0000, Adam Eijdenberg wrote: > > Is that the right design? Or does it make more sense for the client > > to require (or not require) CT dynamically, based on certificate > > features, (and likely on whether it is doing tranditional WebPKI > > or DANE). > > > > The idea of CT is to make mis-issuance easily detectable by requiring all > certs to be logged in order to be considered valid (and thus deter > mis-issuance). That's not going to happen at the same time for all issuers. With DANE whether CT applies or not will depend on which TLSA record matched. * If DANE-EE(3), then CT is out of scope. * If PKIX-TA(0) or PKIX-EE(1) than CT is in scope. * If DANE-TA(2) then it may depend whether the trust-anchor in question is in fact a public root (though the sensible thing is to treat just as with DANE-EE(3)). > It would not be good if one could deliberately mis-issue a > cert that would make clients think they need didn't need CT, Well, that would not be possible if the locally configured public CA root the certificate chains to indicates whether CT is required or not. > so in the fullness of time (when is CT widely adopted, required by browsers) Browsers are not the only TLS applications, and the Web PKI with CT is not the only relevant PKI. > I would expect most clients would just turn this on in the same manner > they would turn on verifying a cert chains to a trusted root. This is not sufficient for e.g. DANE verification with a mixture of DANE-?? and PKIX-?? certificate usages. Nor is it sufficient if some roots do CT, but others, say additional internal corporate roots, do not. > That said, I agree the higher level API proposed in the later patch isn't > flexible enough, for example, one couldn't implement the current Chrome > EV policy with it, and likely should be replaced with a callback similar > to how verify is currently done. That's the point I'm trying to make, the API likely still needs some thought. > I figured that it's still worth starting on the more basic patches first as > I expect it'll take a while to get all the pieces through the pipeline, and > I think will leave us open to try a variety of approaches there later. I am not a big fan of retro-active design. We should aim to get that right, document it, and then write and review code. Sometimes implementation uncovers design issues, then we might updatet the design, but we should start with something plausibly correct. > > > (1) requires work only by the CA issuing the cert. > > > > So entirely transparent to the server... Do we really need any of > > the other models? Why? > > Under both (2) and (3) (but not (1)) the set of SCTs returned for a > certificate can vary over time. So, for example, if a CT log ceased to be > trusted for any reason, servers that send SCTs via methods (2) or (3) can > log the certificate to new logs and return SCTs from those. Servers > configured with (1) alone will need to get and install a new certificate > from their CA. > > This is reflected in Chrome's current EV policy, which > guards against this by requiring more SCTs be present depending on > certificate validity length when they are delivered by being embedded in > the certificate. Getting a new certificate when enough of the logs are retired does not seem too onerous... > (3) has another desirable property in that no participation is required by > the CA who issued the certificate. A server operator can log their own > certificate, grab the latest version of Apache, nginx or haproxy and > support CT. For examples of this see: > http://www.certificate-transparency.org/resources-for-site-owners That's all well and good, but I don't forsee a way for clients to know whether servers should be doing that or not. After all we are trying to keep issuing CAs honest, and if the issuing CA is not participating in CT, than many (or most) of its certificates will not be logged. Outside the browser space, I don't forsee a flag day any time soon with the entire Internet suddenly turning on mandatory CT on the client side. A more realistic deployment model is one root CA at a time, in which case the CA may as well be the one doing the logging, simplifying the server deployments (just serve the CA's certificate). > > > (2) requires work by the CA in their OCSP responder, and work by the site > > > operator to enable OCSP stapling in their server. > > > > What's the advantage of SCT via OCSP rather than in the certificate? > > The set of SCTs returned can be varied over time by the OCSP operator as > logs come and go - and less SCTs (= less bandwidth) are required for > longer-lived certificates (under Chrome's current EV policy). How much "coming and going" of logs do we expect? > If your CA doesn't currently offer an option to issue a certificate with > embedded SCTs, or an OCSP responder with embedded SCTs, then this is a > great option. If those other options are available to you, you might still > choose to serve via the TLS Extension if fidelity around which SCTs from > which logs are returned is important to you. I think think this solves the wrong problems, but I now understand the server deployment models, and API requirements. Since my concerns are not OpenSSL-specific, but rather generic to CT, if I had cycles I'd discuss them on the relevant CT lists. Since cycles are scarce, I'll let it drop. My main concern is the client interface. I think that CT policy belongs in the root CA store (a property of suitably augmented root CA certs). Any alternative suggestions for how client policy is managed? Note, I am not even talking about the API yet, rather where the policy is set operationally. Applications might still have an interface to tweak the implicit policy from the root trust-anchor store. > > The API at the moment seems to support "requiring" CT before any > > communication with the server. That seems to be a flag-day transtion. > > Should the policy not be based on particular issuing CAs (that > > commit to log everything they issue)? That would make for a more > > incremental transition. > > I think that when you want to require CT or not depends also on the context > in which openssl is being used. For example if it's being used as part of > a browser, there'll be one set of considerations (e.g. an incremental > rollout like Chrome's current policy or perhaps one as you've described). Yes. > However if you were using openssl in an application to make custom API over > HTTPS calls back to a server that you control, you might want to require CT > for all calls, as you know that your server supports it. Yes, though one might simply create and use a root CA store in which the usual suspects have the right policies "attached" to the certificates. In practice the attached policy might be accessed via auxiliary files, because that might be easier than building custom "TRUSTED CERTIFICATE" objects. > I'm not a fan of enabling per CA as it means you can avoid detection of a > mis-issued certificate by targeting a CA that doesn't indicate it supports > CT yet. That's the only means to avoid a flag day. Clients might over time elect to only trust CAs that do CT, but initially and for some time we'll have a mixture of CT-capable and non CT-capable certificates and servers. > Again, CT is about providing assurance for site-owners that they can detect > mis-issuance of certificates, so one other option that we're considering > (in the context of Chrome) is a mechanism by which a site-owner can opt-in > to requiring CT ahead of any scheduled requirement (inspired by what Tom > Ritter proposes in: > https://ritter.vg/blog-require_certificate_transparency.html) Fine, though keep in mind that HSTS is a TOFU mechanism, if you are MiTMed on first contact, you don't benefit. > > Perhaps the right place for CT policy (which logs to use, whether > > CT is required, ...) is in auxiliary data stored with "TRUSTED > > CERTIFICATE" objects for root CAs? > > Trusted log metadata will need to be stored somewhere. For the reasons > above, I don't think it makes sense in general to key this on a root CA > though. One thing to consider though is whether the trusted certificate > objects have any notion of whether they are real root CAs, or certs > installed by local admins on machines (e.g. by an enterprise that wishes to > MITM all outbound connections). For that case ("local" roots) it doesn't > make a lot of sense to require CT. Well, as more CAs commit to using CT, deployment grows, until some day soon CAs MUST use CT or stop being public CAs for the "Web PKI". However, even then, for quite some time, internal non-public CAs in organizations may not elect to use CT. So a global policy hardcoded into applications will work poorly. There'll need to be a way to know which certificates or servers are in scope, and which are not. -- Viktor. From eijdenberg at google.com Tue Sep 15 03:42:14 2015 From: eijdenberg at google.com (Adam Eijdenberg) Date: Tue, 15 Sep 2015 03:42:14 +0000 Subject: [openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support In-Reply-To: <20150915015336.GV21942@mournblade.imrryr.org> References: <20150914182848.GG21942@mournblade.imrryr.org> <20150914191150.GH21942@mournblade.imrryr.org> <4f5336d7d15a4f0994e80c2b5a2670a3@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150914202555.GN21942@mournblade.imrryr.org> <20150914215555.GR21942@mournblade.imrryr.org> <20150915015336.GV21942@mournblade.imrryr.org> Message-ID: On Mon, Sep 14, 2015 at 6:53 PM Viktor Dukhovni wrote: > I figured that it's still worth starting on the more basic patches first > as > > I expect it'll take a while to get all the pieces through the pipeline, > and > > I think will leave us open to try a variety of approaches there later. > > I am not a big fan of retro-active design. We should aim to get > that right, document it, and then write and review code. Sometimes > implementation uncovers design issues, then we might updatet the > design, but we should start with something plausibly correct. > I agree - let's agree on a design before adding client surface that actually applies CT policy. That said there is a significant amount of code that needs to land first which basically follows RFC6962. Namely: - data structures for SCTs - code to read/write SCTs - code to verify SCTs against a certificate - data structures for metadata about CT logs - utilities for creating test data This initial patch starts on just the first 2 items listed above and doesn't add new public API surface. My feeling is there isn't likely to be much controversy on the work items above, as they pretty faithfully implement functions to perform tasks described in RFC6962. We will need to revisit and update when RFC6962-bis is complete. I do think there are at least 2 healthy discussions in front of us in terms of client API design: 1. File format / location / storage for CT log metadata (the strawman in my patches is the JSON format already published at http://www.certificate-transparency.org/known-logs, specified in the same manner as the root CA file) 2. What the client API look like for enabling / requesting / requiring CT for a given context or connection. I think these areas of concern match with your thinking: My main concern is the client interface. I think that CT policy > belongs in the root CA store (a property of suitably augmented root > CA certs). > > Any alternative suggestions for how client policy is managed? Note, > I am not even talking about the API yet, rather where the policy > is set operationally. Applications might still have an interface > to tweak the implicit policy from the root trust-anchor store. > I can see it being useful to have a piece of metadata on a trusted root that can be set by a local admin that says something like "this_root_is_local". This should only be set on internal CAs created by organizations and installed by local admins. During CT policy evaluation, if a cert is signed by a root annotated in this manner, do not require CT even if the client indicates that it normally does expect it (HPKP may benefit from similar). Can you give an example of a policy that you'd set on a root trust-anchor that would work well with CT? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Sep 15 14:33:34 2015 From: rt at openssl.org (Horatiu N via RT) Date: Tue, 15 Sep 2015 14:33:34 +0000 Subject: [openssl-dev] [openssl.org #4043] monitoring software depending on openssl not working on cloudflare ssl websites In-Reply-To: <55F7CF5C.2000609@ddhosted.com> References: <55F7CEFD.3000400@ddhosted.com> <55F7CF5C.2000609@ddhosted.com> Message-ID: Greetings, Using the nagios plugins (latest debian package for 8.1) to check availability of https websites using cloudflare gives errors > CRITICAL - Cannot make SSL connection. > 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770: same goes if i attempt to run > openssl s_client -connect :443 This basically makes monitoring impossible at this time, Any idea how to remedy this situation ? i attached a textfile with sample domains as extracted from the certificate's "Certificate Subject alt name" it's reproducible on any target as long as it's online openssl version > OpenSSL 1.0.1k 8 Jan 2015 dpkg -l openssl > ii openssl 1.0.1k-3+deb8u1 amd64 Secure Sockets Layer toolkit - cryptographic utility tried also to compile the newest one from openssl.org and use it, same problem. -------------- next part -------------- *.bluusun.com *.coridonculturevoyages.com *.filelist.ro *.flro.org *.footsy.ml *.futurete.pt *.howtowork.ru *.indiviser.ru *.jungs.ru *.linica.ru *.metafront.ru *.mightytravels.com *.segabite.ru *.shrine.moe *.soundgreat.ru *.supersadovod.ru *.tactum.ru *.theonlyjoy.ru *.wakarimasenlol.com bluusun.com coridonculturevoyages.com filelist.ro flro.org footsy.ml futurete.pt howtowork.ru indiviser.ru jungs.ru linica.ru metafront.ru mightytravels.com segabite.ru shrine.moe soundgreat.ru supersadovod.ru tactum.ru theonlyjoy.ru wakarimasenlol.com *.alvimu.ga *.bellowusersyp10.cf *.blankorientalvr40.ga *.carterjk.com *.dualmountingbg66.ml *.improverespectedml51.gq *.lovableshooterfm10.gq *.mutesnoutedof56.ml *.muztube.com *.oberonrarean96.gq *.paristravelbook.net *.prospectusnebulamj12.ml *.quarkrollesyp10.ga *.travelstokyo.net *.triple.ph *.triple.site *.vomeratomzj61.ga *.waxmanassociates.com *.werremeyer.com alvimu.ga bellowusersyp10.cf blankorientalvr40.ga carterjk.com dualmountingbg66.ml improverespectedml51.gq lovableshooterfm10.gq mutesnoutedof56.ml muztube.com oberonrarean96.gq paristravelbook.net prospectusnebulamj12.ml quarkrollesyp10.ga travelstokyo.net triple.ph triple.site vomeratomzj61.ga waxmanassociates.com werremeyer.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3709 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Sep 15 14:49:03 2015 From: rt at openssl.org (Rob Stradling via RT) Date: Tue, 15 Sep 2015 14:49:03 +0000 Subject: [openssl-dev] [openssl.org #4043] monitoring software depending onopenssl not working on cloudflare ssl websites In-Reply-To: <55F82E4B.7040504@comodo.com> References: <55F7CEFD.3000400@ddhosted.com> <55F7CF5C.2000609@ddhosted.com> <55F82E4B.7040504@comodo.com> Message-ID: Hi Horatiu. To connect to a site that uses CloudFlare Universal SSL [1], you need to specify the SNI (Server Name Indication) header. Modern browsers do this by default, but for s_client you need to do this... openssl s_client -connect :443 -servername This isn't an OpenSSL bug, so I suggest closing this ticket. [1] https://blog.cloudflare.com/introducing-universal-ssl/ On 15/09/15 15:33, Horatiu N via RT wrote: > Greetings, > > Using the nagios plugins (latest debian package for 8.1) to check > availability of https websites using cloudflare gives errors >> CRITICAL - Cannot make SSL connection. >> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770: > > same goes if i attempt to run >> openssl s_client -connect :443 > > This basically makes monitoring impossible at this time, > Any idea how to remedy this situation ? > > i attached a textfile with sample domains as extracted from the > certificate's "Certificate Subject alt name" > it's reproducible on any target as long as it's online > > openssl version >> OpenSSL 1.0.1k 8 Jan 2015 > > > dpkg -l openssl >> ii openssl 1.0.1k-3+deb8u1 amd64 Secure Sockets Layer toolkit - cryptographic utility > > tried also to compile the newest one from openssl.org and use it, same > problem. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From rt at openssl.org Tue Sep 15 14:51:37 2015 From: rt at openssl.org (Horatiu N via RT) Date: Tue, 15 Sep 2015 14:51:37 +0000 Subject: [openssl-dev] [openssl.org #4043] monitoring software depending onopenssl not working on cloudflare ssl websites In-Reply-To: <55F83075.8090309@ddhosted.com> References: <55F7CEFD.3000400@ddhosted.com> <55F7CF5C.2000609@ddhosted.com> <55F82E4B.7040504@comodo.com> <55F83075.8090309@ddhosted.com> Message-ID: Thank you very much. Have a lovely day :) On 15-Sep-15 5:49 PM, Rob Stradling via RT wrote: > Hi Horatiu. To connect to a site that uses CloudFlare Universal SSL > [1], you need to specify the SNI (Server Name Indication) header. > Modern browsers do this by default, but for s_client you need to do this... > > openssl s_client -connect :443 -servername > > This isn't an OpenSSL bug, so I suggest closing this ticket. > > > [1] https://blog.cloudflare.com/introducing-universal-ssl/ > > On 15/09/15 15:33, Horatiu N via RT wrote: >> Greetings, >> >> Using the nagios plugins (latest debian package for 8.1) to check >> availability of https websites using cloudflare gives errors >>> CRITICAL - Cannot make SSL connection. >>> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770: >> >> same goes if i attempt to run >>> openssl s_client -connect :443 >> >> This basically makes monitoring impossible at this time, >> Any idea how to remedy this situation ? >> >> i attached a textfile with sample domains as extracted from the >> certificate's "Certificate Subject alt name" >> it's reproducible on any target as long as it's online >> >> openssl version >>> OpenSSL 1.0.1k 8 Jan 2015 >> >> >> dpkg -l openssl >>> ii openssl 1.0.1k-3+deb8u1 amd64 Secure Sockets Layer toolkit - cryptographic utility >> >> tried also to compile the newest one from openssl.org and use it, same >> problem. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3709 bytes Desc: not available URL: From rt at openssl.org Tue Sep 15 15:15:25 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Tue, 15 Sep 2015 15:15:25 +0000 Subject: [openssl-dev] [openssl.org #4044] cvsignore files are obsolete In-Reply-To: <55F83609.3060705@akamai.com> References: <55F83609.3060705@akamai.com> Message-ID: Now that everything's in git, the .cvsignore files seem to serve no useful purpose, and should be removed. -Ben _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Sep 15 16:03:19 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 15 Sep 2015 16:03:19 +0000 Subject: [openssl-dev] [openssl.org #4044] cvsignore files are obsolete In-Reply-To: <55F83609.3060705@akamai.com> References: <55F83609.3060705@akamai.com> Message-ID: Fixed in 1.0.2 and 1.0.1; thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From richard at levitte.org Tue Sep 15 16:23:26 2015 From: richard at levitte.org (Richard Levitte) Date: Tue, 15 Sep 2015 18:23:26 +0200 (CEST) Subject: [openssl-dev] testing framework In-Reply-To: References: Message-ID: <20150915.182326.1692397234877837986.richard@levitte.org> In message on Tue, 15 Sep 2015 00:30:24 +0300, Sebastian Brestin said: sebastianbrestin> Hi guys, sebastianbrestin> sebastianbrestin> I just joined your community over here. Quick sebastianbrestin> question: why have you chosen Test:More as a testing sebastianbrestin> framework rather than gtest or another framework? I sebastianbrestin> would be interested over the unit testing area if sebastianbrestin> there are any plans in this direction. Considering I made the choice, I guess I should be able to answer. Choosing Perl as a basis for test scripts was among the earliest decisions I made in this effort. Perl is supported on a very wide range of platforms. In that sense, it's cooler than most other scripting languages. It's even cooler than python (although I understand that python is pretty widely supported). The next thing was to have a look at available and suitable frameworks, or possibly building my own, and factoring in that we need to have it work for versions of Perl that are possibly not super recent. A bit of research and I came back to Test::More and Test::Harness. They've been along for a very long time, and the feature set we do use has been around since Perl 5.12. That should be old enough to be available on most current platforms even if they aren't super fresh. Basically, of the factors that came into play, these are the most prominent: - I wanted to set up something that could work consistently on a very wide range of platforms. - I went along with a culture we've had with OpenSSL for a long time, to be quite careful with what we choose to depend on, and actually keep that to a minimum. The rationale behind that choice is that the things we depend on also have a tendency to limit the range of platforms we can support. - We already use Perl quite extensively. The choice was actually quite easy. Oh, and should you wonder, Unix like platforms and Windows isn't enough. I factored in VMS as well, and am hoping have tested this on Unix, Windows and VMS will be enough to cover most oddities possible. Cheers, Richard -- Richard Levitte richard at levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish From rt at openssl.org Wed Sep 16 00:13:49 2015 From: rt at openssl.org (yancm via RT) Date: Wed, 16 Sep 2015 00:13:49 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <709060dd33ea5643c0853a7031880d86@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> <709060dd33ea5643c0853a7031880d86@SDF.ORG> Message-ID: Hi Rich, I checked a couple of things.. apps/rehash.c is interesting (see below) - is it supposed to have two rehash_main() definitions? The second one is throwing the error? thanks, gene ******************** ** Error Message ** ******************** gmake[2]: Leaving directory '/usr/local/src/openssl/apps' gmake[2]: Entering directory '/usr/local/src/openssl' Not available; use c_rehash script Makefile:428: recipe for target 'rehash.time' failed gmake[2]: *** [rehash.time] Error 1 gmake[2]: Leaving directory '/usr/local/src/openssl' Makefile:139: recipe for target 'openssl' failed gmake[1]: *** [openssl] Error 2 gmake[1]: Leaving directory '/usr/local/src/openssl/apps' Makefile:290: recipe for target 'build_apps' failed gmake: *** [build_apps] Error 1 clarity 24 # ******************************* ** Makefile - rehash targets ** ******************************* rehash: rehash.time rehash.time: certs apps @if [ -z "$(CROSS_COMPILE)" ]; then \ (OPENSSL="`pwd`/util/opensslwrap.sh"; \ [ -x "apps/openssl.exe" ] && OPENSSL="apps/openssl.exe" || :; \ OPENSSL_DEBUG_MEMORY=on; OPENSSL_CONF=/dev/null ; \ export OPENSSL OPENSSL_DEBUG_MEMORY OPENSSL_CONF; \ $$OPENSSL rehash certs/demo) && \ touch rehash.time; \ else :; fi ******************* ** apps/rehash.c ** ******************* 426 int rehash_main(int argc, char **argv) 427 { 428 const char *env, *prog; 429 char *e, *m; 430 int errs = 0; 431 OPTION_CHOICE o; 432 enum Hash h = HASH_NEW; 433 434 prog = opt_init(argc, argv, rehash_options); 435 while ((o = opt_next()) != OPT_EOF) { 436 switch (o) { 437 case OPT_EOF: 438 case OPT_ERR: 439 BIO_printf(bio_err, "%s: Use -help for summary.\n", prog); .... 485 int rehash_main(int argc, char **argv) 486 { 487 BIO_printf(bio_err, "Not available; use c_rehash script\n"); 488 return (1); 489 } 490 From rsalz at akamai.com Wed Sep 16 01:17:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 16 Sep 2015 01:17:50 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> <709060dd33ea5643c0853a7031880d86@SDF.ORG> Message-ID: <9091e9b4f59940b2a69331765acda433@ustx2ex-dag1mb3.msg.corp.akamai.com> Yes, it has two main functions, based on #ifdef unix. Not sure why netBSD doesn't -Dunix. From rt at openssl.org Wed Sep 16 01:17:56 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 16 Sep 2015 01:17:56 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <9091e9b4f59940b2a69331765acda433@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> <709060dd33ea5643c0853a7031880d86@SDF.ORG> <9091e9b4f59940b2a69331765acda433@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: Yes, it has two main functions, based on #ifdef unix. Not sure why netBSD doesn't -Dunix. From leif.thuresson at foxt.com Wed Sep 16 07:54:08 2015 From: leif.thuresson at foxt.com (Leif Thuresson) Date: Wed, 16 Sep 2015 09:54:08 +0200 Subject: [openssl-dev] [openssl.org #4039] TLS-PSK - SSL_use_psk_identity_hint() In-Reply-To: References: <55F46407.3020403@foxt.com> Message-ID: <55F92020.3090701@foxt.com> Got it working with latest SNAP:-) Thanks, /Leif On 2015-09-14 23:04, Stephen Henson via RT wrote: > On Mon Sep 14 01:09:14 2015, leif.thuresson at foxt.com wrote: >> I understand that there has been an overhaul of the TLS-PSK support. >> Is there any chance to get the SSL_use_psk_identity_hint() function >> fixed in the process? > Yes the current implementaion is just plain broken. I've applied a fix to the > master branch as commit df6da24bda457b72. Let me know of any problems. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > From rt at openssl.org Wed Sep 16 07:54:21 2015 From: rt at openssl.org (Leif Thuresson via RT) Date: Wed, 16 Sep 2015 07:54:21 +0000 Subject: [openssl-dev] [openssl.org #4039] TLS-PSK - SSL_use_psk_identity_hint() In-Reply-To: <55F92020.3090701@foxt.com> References: <55F46407.3020403@foxt.com> <55F92020.3090701@foxt.com> Message-ID: Got it working with latest SNAP:-) Thanks, /Leif On 2015-09-14 23:04, Stephen Henson via RT wrote: > On Mon Sep 14 01:09:14 2015, leif.thuresson at foxt.com wrote: >> I understand that there has been an overhaul of the TLS-PSK support. >> Is there any chance to get the SSL_use_psk_identity_hint() function >> fixed in the process? > Yes the current implementaion is just plain broken. I've applied a fix to the > master branch as commit df6da24bda457b72. Let me know of any problems. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > From matt at openssl.org Wed Sep 16 10:16:18 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Sep 2015 11:16:18 +0100 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable Message-ID: <55F94172.4050706@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL Project team would like to announce the publication of our current plans for the OpenSSL 1.1.0 release timetable. This has been included in our release strategy available here: https://www.openssl.org/policies/releasestrat.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV+UFyAAoJENnE0m0OYESRZiIH/0oT1j9Ipizi/IVjMSuE6BHY wDdvGuobNSwVUOb61TMxJejI6VX2mowZNjZrc8IdULYIVNnHNyF+iDNBrYQR+KcN bdVE8b1T6nzkKn8e7paI7cqdTYll59vE/p1fJ6uiZb0Y7oOLJ46jWuoRjtQB5xbw bJt8XweO7zR34ungk/kNLb76D8ZSKxGeaJsgD68ymJgOJdFpWHv4/phpg4eLClmk g+8g90COCfwQh9BskhVpUr5fT1+zxo91FA4HgQp3WdRhtcmYAbgoScc6/MWc73MH jIXEGBDURKaR0M2/WLf0Ezz/666ZxltjUhHNtOrhdv6waHmlpjsnYn1M7bxNh+Q= =R/23 -----END PGP SIGNATURE----- From rt at openssl.org Wed Sep 16 10:19:47 2015 From: rt at openssl.org (BeomGeun Bae via RT) Date: Wed, 16 Sep 2015 10:19:47 +0000 Subject: [openssl-dev] [openssl.org #4045] RSA_generate_key() In-Reply-To: References: Message-ID: I don't know where i need to ask but have a question for RSA_generate_key(). Do you have minimum cpu performance to run RSA_generate_key() for 2048bits? When I tested it in our system (4,000mips), it task more than 10 seconds. Is this expected? -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Sep 16 10:19:48 2015 From: rt at openssl.org (Uwe Granzow via RT) Date: Wed, 16 Sep 2015 10:19:48 +0000 Subject: [openssl-dev] [openssl.org #4046] Fix xmm6 register clobbering in crypto/bn/asm/x86_64-mont5.pl:bn_power5() under Win64 In-Reply-To: <4C22BDED-F783-404A-BF1F-77E32F0C6470@celemony.com> References: <4C22BDED-F783-404A-BF1F-77E32F0C6470@celemony.com> Message-ID: Hi, i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a loop. The compiler optimizer placed a local variable value in the xmm6 register. The content of this register was destroyed after calling BIO_do_handshake. I debugged this and found that the xmm6/xmm7 registers were not restored. I fixed this with following diff for openssl-1.0.2d / x86_64-mont5.pl (bn_power5 and bn_from_mont8x): 1013a1014,1020 > ___ > $code.=<<___ if ($win64); > movaps -88(%rsi),%xmm6 > movaps -72(%rsi),%xmm7 > ___ > $code.=<<___; > 2005a2013,2019 > ___ > $code.=<<___ if ($win64); > movaps -88(%rsi),%xmm6 > movaps -72(%rsi),%xmm7 > ___ > $code.=<<___; > The fix in bn_from_mont8x was not necessary for me but i think the lines are also missing there. Best regards Uwe Granzow ________________________________________ Celemony Software GmbH Uwe Granzow ug at celemony.com ________________________________________ -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Sep 16 11:05:04 2015 From: rt at openssl.org (yancm via RT) Date: Wed, 16 Sep 2015 11:05:04 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <09bdc5fcda7919ef6304419373b92e01@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <532279eef60f30c9e2044dd2d7d108c1@SDF.ORG> <709060dd33ea5643c0853a7031880d86@SDF.ORG> <9091e9b4f59940b2a69331765acda433@ustx2ex-dag1mb3.msg.corp.akamai.com> <09bdc5fcda7919ef6304419373b92e01@SDF.ORG> Message-ID: On 2015-09-15 21:17, Salz, Rich via RT wrote: > Yes, it has two main functions, based on #ifdef unix. > Not sure why netBSD doesn't -Dunix. Hmmm. It used to build and test OK, did the check for -Dunix change recently? Is the -Dunix test in config script? For a quick fix I added -Dunix to CFLAGS in Makefile and I am able to make and run tests. I note that now the tests "look" different. I do not recall the tests being run from a perl script before? I do fail some tests now: [...] ../test/recipes/40-test_rehash.t .......... 4/4 # Failed test 'Testing rehash operations on readonly directory' # at ../test/recipes/40-test_rehash.t line 35. # got: '1' # expected: anything else # Looks like you failed 1 test of 4. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests [...] Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=63, Tests=314, 220 wallclock secs ( 1.22 usr 0.18 sys + 150.48 cusr 62.41 csys = 214.29 CPU) Result: FAIL Failed 1/63 test programs. 1/314 subtests failed. From rt at openssl.org Wed Sep 16 14:24:16 2015 From: rt at openssl.org (fdasilvaYY@gmail.com via RT) Date: Wed, 16 Sep 2015 14:24:16 +0000 Subject: [openssl-dev] [openssl.org #4047] [PATCH] early "references = 1" init In-Reply-To: References: Message-ID: Hi , While looking at this commit https://github.com/openssl/openssl/commit/64b25758edca688a30f02c260262150f7ad0bc7d I notice a code path that can triggera REF_CHECK error message "..., bad reference count\n" in some particular case. I see the same pattern in other code places. I have not check if this issue is present in any released branch, but I guess it is possible. Please find attached the fix related to the trunk/master code. Regards, Filipe DA SILVA -------------- next part -------------- A non-text attachment was scrubbed... Name: early_ref_init.patch Type: text/x-patch Size: 1833 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Sep 16 14:34:37 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 16 Sep 2015 14:34:37 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <44effc6c8365476eafab51b072c00690@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <9091e9b4f59940b2a69331765acda433@ustx2ex-dag1mb3.msg.corp.akamai.com> <09bdc5fcda7919ef6304419373b92e01@SDF.ORG> <44effc6c8365476eafab51b072c00690@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: > Hmmm. It used to build and test OK, did the check for -Dunix change > recently? No. > Is the -Dunix test in config script? No, it's in apps/rehash.c > For a quick fix I added -Dunix to CFLAGS in Makefile and I am able to make > and run tests. Sounds like the netBSD config needs to add that. > I note that now the tests "look" different. I do not recall the tests being run > from a perl script before? Yup. A big improvement. > # Looks like you failed 1 test of 4. > ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, > 0x100) Failed 1/4 subtests [...] Test Summary Report You haven't pull down master recently; this was fixed a few days ago. From alessandro at ghedini.me Wed Sep 16 14:38:10 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Wed, 16 Sep 2015 16:38:10 +0200 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <55F94172.4050706@openssl.org> References: <55F94172.4050706@openssl.org> Message-ID: <20150916143809.GA11277@kronk.local> On Wed, Sep 16, 2015 at 11:16:18AM +0100, Matt Caswell wrote: > The OpenSSL Project team would like to announce the publication of our > current plans for the OpenSSL 1.1.0 release timetable. This has been > included in our release strategy available here: > > https://www.openssl.org/policies/releasestrat.html Do you have any idea on what features are gonna be present in 1.1.0? I seem to remember someone mentioning that ChaCha20-Poly1305 support was being worked on by Andy Polyakov and is planned for the 1.1.0 release, is this still the case? Same goes for Curve25519/Curve448. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From matt at openssl.org Wed Sep 16 14:54:42 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Sep 2015 15:54:42 +0100 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <20150916143809.GA11277@kronk.local> References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> Message-ID: <55F982B2.9080608@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/09/15 15:38, Alessandro Ghedini wrote: > On Wed, Sep 16, 2015 at 11:16:18AM +0100, Matt Caswell wrote: >> The OpenSSL Project team would like to announce the publication >> of our current plans for the OpenSSL 1.1.0 release timetable. >> This has been included in our release strategy available here: >> >> https://www.openssl.org/policies/releasestrat.html > > Do you have any idea on what features are gonna be present in > 1.1.0? I seem to remember someone mentioning that ChaCha20-Poly1305 > support was being worked on by Andy Polyakov and is planned for the > 1.1.0 release, is this still the case? > > Same goes for Curve25519/Curve448. The best place to look for all the 1.1.0 changes that have taken place so far is the CHANGES file. This is available online here: https://www.openssl.org/news/changelog.html That only lists changes that have been committed so far. Off the top of my head other big changes that are coming include: - - State machine rewrite - - Async support - - IPv6 I've not heard anything from Andy in a while on his stuff so I'm not sure what the current state of play is with ChaCha/Poly. There's probably a ton of other stuff that I've forgotten and my colleagues will remind me about. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV+YKyAAoJENnE0m0OYESR7QEH/0o7G/zcMWOGBqmw/D4lLi3C +zztovzleUGUsuFDCrpQOuhlDfWixjholnjC8VugCHCYNo+e3Lbx6gYk+BH2Xpz+ Nk7lFqdhAhjwsb3VMklLgYjb1fI7pZTfPhf3giUNPxxs+AOMrYVDjf0UMZlP955d u22ywOZHmf3CHNulhZ5sObT69SR/issxL6aeu2UwNofkcAJ/Q1rhSJICJeKsUCNr Ki9RHpHm4fkG2+97+dZxT4hmGXTQN7d5fAXuTpGZnycWi3p8GWXNi9XrY1PVmiUy +UA6RhLWznswUbXNcGE29ckFnM5BJB8SDOJcUcndi9pTsfQvpcO2ApMTMjxsz2M= =yEk5 -----END PGP SIGNATURE----- From rsalz at akamai.com Wed Sep 16 15:02:55 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 16 Sep 2015 15:02:55 +0000 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <55F982B2.9080608@openssl.org> References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> <55F982B2.9080608@openssl.org> Message-ID: > the current state of play is with ChaCha/Poly. There's probably a ton of other > stuff that I've forgotten and my colleagues will remind me about. I am committing to do all the new crypto if someone better qualified (and there are a couple of folks on the team) don't do so. From foleyj at cisco.com Wed Sep 16 15:15:28 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 16 Sep 2015 11:15:28 -0400 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <55F982B2.9080608@openssl.org> References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> <55F982B2.9080608@openssl.org> Message-ID: <55F98790.6010706@cisco.com> Is the "Async support" you have listed the same code that Intel developed for Cave Creek? Or is the Intel contribution planned for a follow-on release? On 09/16/2015 10:54 AM, Matt Caswell wrote: > > > On 16/09/15 15:38, Alessandro Ghedini wrote: > > On Wed, Sep 16, 2015 at 11:16:18AM +0100, Matt Caswell wrote: > >> The OpenSSL Project team would like to announce the publication > >> of our current plans for the OpenSSL 1.1.0 release timetable. > >> This has been included in our release strategy available here: > >> > >> https://www.openssl.org/policies/releasestrat.html > > > Do you have any idea on what features are gonna be present in > > 1.1.0? I seem to remember someone mentioning that ChaCha20-Poly1305 > > support was being worked on by Andy Polyakov and is planned for the > > 1.1.0 release, is this still the case? > > > Same goes for Curve25519/Curve448. > > > The best place to look for all the 1.1.0 changes that have taken place > so far is the CHANGES file. This is available online here: > > https://www.openssl.org/news/changelog.html > > That only lists changes that have been committed so far. Off the top > of my head other big changes that are coming include: > - State machine rewrite > - Async support > - IPv6 > > I've not heard anything from Andy in a while on his stuff so I'm not > sure what the current state of play is with ChaCha/Poly. There's > probably a ton of other stuff that I've forgotten and my colleagues > will remind me about. > > 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 Wed Sep 16 15:33:29 2015 From: rt at openssl.org (yancm via RT) Date: Wed, 16 Sep 2015 15:33:29 +0000 Subject: [openssl-dev] Update RE: [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <3574ff0719a87568eda3c1980882892d.squirrel@wm.sdf.org> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <09bdc5fcda7919ef6304419373b92e01@SDF.ORG> <44effc6c8365476eafab51b072c00690@ustx2ex-dag1mb3.msg.corp.akamai.com> <3574ff0719a87568eda3c1980882892d.squirrel@wm.sdf.org> Message-ID: >> Is the -Dunix test in config script? > > No, it's in apps/rehash.c Actually, I meant where should system type "unix" be detected and set so that it is automatically set in the Makefile... > >> For a quick fix I added -Dunix to CFLAGS in Makefile and I am able to >> make >> and run tests. > > Sounds like the netBSD config needs to add that. I can run config with -Dunix flag as a temporary fix, but agree it would be good if config found and set this automagically. >> # Looks like you failed 1 test of 4. >> ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 >> (wstat 256, >> 0x100) Failed 1/4 subtests [...] Test Summary Report > > You haven't pull down master recently; this was fixed a few days ago. Actually, I have been updating from master regularly. I just updated again and still get this error. Even starting from a "gmake clean" and a "./config no-shared -Dunix" From rt at openssl.org Wed Sep 16 16:35:12 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 16 Sep 2015 16:35:12 +0000 Subject: [openssl-dev] [openssl.org #4048] [PATCH] Fix potential read buffer overflow in PACKET_strndup() In-Reply-To: <20150916163504.GA15338@kronk.local> References: <20150916163504.GA15338@kronk.local> Message-ID: Hello, see GitHub pull request at https://github.com/openssl/openssl/pull/399 It provides a short analysis of the problem and a fix. Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Sep 16 16:36:32 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 16 Sep 2015 16:36:32 +0000 Subject: [openssl-dev] [openssl.org #3986] [PATCH] Implement HKDF algorithm (RFC 5869) In-Reply-To: <20150916163625.GA15050@kronk.local> References: <20150916163625.GA15050@kronk.local> Message-ID: Hello, FYI I rebased the code [0] on master and updated it to use the new test suite framework. As mentioned in the GitHub PR, I kept the actual implementation and the tests on two separate commits for easier review, but if you prefer I can squash them together. Could someone please review this? Since this is gonna be needed to implement TLS 1.3 in the future, I don't think there's any objection against merging this functionality. Cheers [0] https://github.com/openssl/openssl/pull/355 From rt at openssl.org Wed Sep 16 17:05:17 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 16 Sep 2015 17:05:17 +0000 Subject: [openssl-dev] [openssl.org #4039] TLS-PSK - SSL_use_psk_identity_hint() In-Reply-To: <55F46407.3020403@foxt.com> References: <55F46407.3020403@foxt.com> Message-ID: OK, thanks for the update, ticket closed. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Sep 16 17:14:18 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 16 Sep 2015 17:14:18 +0000 Subject: [openssl-dev] [openssl.org #4035] bug and fix - warning about uninitialized variables in ssl_asn1.c, function i2d_SSL_SESSION() In-Reply-To: <55F1EF20.5020708@oracle.com> References: <55F1EF20.5020708@oracle.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 zooko at leastauthority.com Wed Sep 16 17:29:54 2015 From: zooko at leastauthority.com (Zooko Wilcox-OHearn) Date: Wed, 16 Sep 2015 17:29:54 +0000 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <55F982B2.9080608@openssl.org> References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> <55F982B2.9080608@openssl.org> Message-ID: > There's probably a ton of other stuff that I've forgotten and my > colleagues will remind me about. There's BLAKE2. It already has mature and widely-used source code, including multiple independently-written portable C implementations, and Bill Cox has offered to integrate those into openssl: https://mta.openssl.org/pipermail/openssl-dev/2015-June/001791.html In light of the previous conversation and the way it ground to a halt, I would ask that we do the simple, easy thing now and don't re-raise any of the bike shed questions, so: * Don't implement the parallelized versions (BLAKE2bp and BLAKE2sp). * Don't change the names of the algorithms from "BLAKE2b" and "BLAKE2s" (they are already widely known under those names). * Don't integrate any of the optimized asm implementations, just a single portable C implementation. There. That ought to do it! The previous thread ? in which I argued that BLAKE2 is worth supporting ? starts here: https://mta.openssl.org/pipermail/openssl-dev/2015-June/001688.html Since I wrote that post, BLAKE2 has been promoted from Internet Draft to RFC. It doesn't have its RFC number yet but should get one any day now: https://datatracker.ietf.org/doc/draft-saarinen-blake2/ Regards, Zooko Wilcox-O'Hearn Founder, CEO, and Customer Support Rep https://LeastAuthority.com ? Freedom matters. From rsalz at akamai.com Wed Sep 16 17:36:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 16 Sep 2015 17:36:03 +0000 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> <55F982B2.9080608@openssl.org> Message-ID: > * Don't implement the parallelized versions (BLAKE2bp and BLAKE2sp). > * Don't change the names of the algorithms from "BLAKE2b" and "BLAKE2s" > (they are already widely known under those names). > * Don't integrate any of the optimized asm implementations, just a single > portable C implementation. If Bill is willing to generate a GitHub PR (or RT with patch), we'll get that into the stream. From pwalten at au1.ibm.com Thu Sep 17 01:04:24 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Thu, 17 Sep 2015 11:04:24 +1000 Subject: [openssl-dev] [openssl.org #4045] RSA_generate_key() In-Reply-To: References: Message-ID: <201509170112.t8H1Cog0030618@d23av02.au.ibm.com> Depends on the CPU, if you have a slow CPU RSA key gen will be slow. It seems to take ~ 1/10th of a second here with current x86_64 hardware. Something less capable. (ARM7) ~ 5 seconds. Your mips hardware is slow but in the ballpark. Peter From: BeomGeun Bae via RT To: Cc: openssl-dev at openssl.org Date: 16/09/2015 08:24 PM Subject: [openssl-dev] [openssl.org #4045] RSA_generate_key() Sent by: "openssl-dev" I don't know where i need to ask but have a question for RSA_generate_key (). Do you have minimum cpu performance to run RSA_generate_key() for 2048bits? When I tested it in our system (4,000mips), it task more than 10 seconds. Is this expected? _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From rt at openssl.org Thu Sep 17 02:10:58 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 17 Sep 2015 02:10:58 +0000 Subject: [openssl-dev] [openssl.org #4045] RSA_generate_key() In-Reply-To: References: Message-ID: Ask this kind of thing on openssl-dev or -users; this is not a bug. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 17 12:46:39 2015 From: rt at openssl.org (Aaron Jones via RT) Date: Thu, 17 Sep 2015 12:46:39 +0000 Subject: [openssl-dev] [openssl.org #4049] Minor corrections to codingstyle.txt In-Reply-To: <55FA67C7.1040804@gmail.com> References: <55FA67C7.1040804@gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello. Please find attached a patch to codingstyle.txt to fix some minor grammatical errors and such trivialities. Regards, Aaron Jones -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJV+me2AAoJEG6FTA+q1M6k0uEP/Rl/p9J/KbysC6wxZt+t4/Z+ m8P2onGkIYEHzuDcGG9ff0EFVS5kaj2/40qbte+EX3XJpfZUs6IZoiG9ClqJULGC PueK2BgYD5vjOI8R4n1e5FlpaTWdeoJJEPK9znPzCpF/MU1LyCrBysN1+67c4gYF FoYZYdtXPqpS0u0SmpXWL5ZKUyS9ElPajCyfMDl048RaUw04rdXV5yFAb+jl2Hx/ 0YCfdxRFwqfQVwdgkCs31KX4dpZXLXCWOBwzFlHeeDQrD01XqDCylNNSkypG5RiJ ibWHGQwlR0183Bmn+IoU2+1nyKfy9a4AcNctQ78mLQuzsvs667bWxiYDstuApqo/ AeLvfCDp+eB6DPLrE+h+5bAtOOSst8UvfkC37t3+Lxo6nOCKEyblx+0jX6BAEotq Jv42ysau/f0DeF2+Ob2+YVyxlfJaet7aMdNebvYI1ozjZOFePnQffwgtafi4lQ+m wCTHG8t9DnJCdRLZX4esNq3VNJMINWOBxU7eLSxwyyVHkFaO9ELSp/9xhWJK2TkB TetTq92lFOfBEtFhIe6vKFgo06SavZ2fx2iFH8UNNarfP/V5KH10sUJzG+giwhO6 EMSaDwyr4O3oQlYo0NgfI4TVTaG/CK/6Ycu+G12Rd3R3MZqxq26LlsF/4civi25H GZ2LhDnwrq+RvtmudtzP =8HJK -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: codingstyle.txt.diff Type: text/x-patch Size: 4652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: codingstyle.txt.diff.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 17 12:46:39 2015 From: rt at openssl.org (Andrew Janke via RT) Date: Thu, 17 Sep 2015 12:46:39 +0000 Subject: [openssl-dev] [openssl.org #4050] PR: website spelling and grammar: strategiy etc In-Reply-To: <55FA62DE.4070305@apjanke.net> References: <55FA62DE.4070305@apjanke.net> Message-ID: Hi, OpenSSL folks, I found some typos and other errors while reading through the openssl.org web site. I've submitted suggested changes as a PR to the openssl/web repo on GitHub. https://github.com/openssl/web/pull/8 Cheers, Andrew Janke _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 17 12:52:48 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 17 Sep 2015 12:52:48 +0000 Subject: [openssl-dev] [openssl.org #4051] [Patch] Fix EECDHE typo in ciphers(1) In-Reply-To: <4780609.ZHMZU9bJPd@pintsize.usersys.redhat.com> References: <4780609.ZHMZU9bJPd@pintsize.usersys.redhat.com> Message-ID: OpenSSL 1.0.1 ciphers man page specifies "EECDHE" alias, the actual alias supported by ciphers command is "EECDH". https://github.com/openssl/openssl/pull/405 -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Thu Sep 17 14:57:39 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 17 Sep 2015 15:57:39 +0100 Subject: [openssl-dev] OpenSSL 1.1.0 Release Timetable In-Reply-To: <55F98790.6010706@cisco.com> References: <55F94172.4050706@openssl.org> <20150916143809.GA11277@kronk.local> <55F982B2.9080608@openssl.org> <55F98790.6010706@cisco.com> Message-ID: <55FAD4E3.7050603@openssl.org> On 16/09/15 16:15, John Foley wrote: > Is the "Async support" you have listed the same code that Intel > developed for Cave Creek? Or is the Intel contribution planned for a > follow-on release? It is all new code. However I have been developing it in collaboration with Intel. Matt From rt at openssl.org Thu Sep 17 15:59:17 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 17 Sep 2015 15:59:17 +0000 Subject: [openssl-dev] [openssl.org #4047] [PATCH] early "references = 1" init In-Reply-To: References: Message-ID: fixed in mater with commit 0e04674. thanks! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Sep 17 16:11:48 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 17 Sep 2015 16:11:48 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> Message-ID: the real fix is to use OPENSSL_SYS_UNIX as the test. Done in commit 568b80 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Sep 15 14:33:35 2015 From: rt at openssl.org (Christopher Berube via RT) Date: Tue, 15 Sep 2015 14:33:35 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: Hi, I'm trying to build the FIPS-140 compliant OpenSSL software on my Windows 7 system using the Visual Studio 2015 compiler. I am using OpenSSL-FIPS-2.0.10 and OpenSSL-1.0.2d. I'm getting the following build error when trying to build the 32-bit version of the OpenSSL libraries: link /nologo /subsystem:console /opt:ref /debug /dll /fixed /map /base:0xFB00000 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\username\AppData\Local \Temp\nm8E.tmp Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp out32dll\fips_premain_dso.exe out32dll\libeay32.dll OPENSSL_Uplink(01489000,08): no OPENSSL_Applink Get hash failure at \usr\local\ssl\fips-2.0\bin\fipslink.pl line 60. NMAKE : fatal error U1077: 'C:\Perl64\bin\perl.EXE' : return code '0x1' Stop. Here's how I went about building it: 0) Executed "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\vcvars32.bat" in a DOS command prompt window. 1) Extracted the files for OpenSSL-FIPS-2.0.10 2) cd OpenSSL-FIPS-2.0.10 3) Perl Configure VC-WIN32 no-asm fipscheck no-idea no-mdc2 no-rc5 4) ms\do_ms 5) nmake -f ms\ntdll.mak 6) nmake -f ms\ntdll.mak install 7) Extracted the files for OpenSSL-1.0.2.d 8) cd OpenSSL-1.0.2d 9) Perl Configure VC-WIN32 no-asm fips --with-fipslibdir=C:\usr\local\ssl\fips-2.0 no-idea no-mdc2 no-rc5 10) ms\do_ms 11) nmake -f ms\nt.mak 12) nmake -f ms\nt.mak install 13) nmake -f ms\ntdll.mak I get the build error near the end of step 13. Known problem? Any work-arounds? Is there a "no applink" option? Regards, Christopher J. (CHRISTOPHER) Berube Windows Engineer, Guardium IBM ------------------------------------------------------------------------------ E-mail:cberube at us.ibm.com 550 King St Littleton, MA 01460-1250 United States -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 34078 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 17 16:51:41 2015 From: rt at openssl.org (yancm via RT) Date: Thu, 17 Sep 2015 16:51:41 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> Message-ID: > the real fix is to use OPENSSL_SYS_UNIX as the test. > Done in commit 568b80 That seems to work! I am still failing the rehash.t test: ../test/recipes/40-test_rehash.t .......... 1/4 # Failed test 'Testing rehash operations on readonly directory' # at ../test/recipes/40-test_rehash.t line 35. # got: '1' # expected: anything else # Looks like you failed 1 test of 4. ../test/recipes/40-test_rehash.t .......... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Should I turn in a new ticket for that or is there an old ticket number I should be using? thanks, gene From imcfadri at cisco.com Thu Sep 17 18:34:38 2015 From: imcfadri at cisco.com (Ian McFadries (imcfadri)) Date: Thu, 17 Sep 2015 18:34:38 +0000 Subject: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method In-Reply-To: <55C20439.500@openssl.org> References: <522B816F59485D4FBCBAF2CE8015B891928AA6@xmb-rcd-x01.cisco.com> <20150723182204.GA3935@w1.fi> <20150723202111.GY4347@mournblade.imrryr.org> <20150723224636.GA3876@w1.fi> <20150723230939.GB4347@mournblade.imrryr.org> <20150724090409.GA8799@w1.fi> <522B816F59485D4FBCBAF2CE8015B8919A43C1@xmb-rcd-x01.cisco.com> <55C20439.500@openssl.org> Message-ID: <06f5bde4da33467aafb439aecd357f1d@XCH-ALN-010.cisco.com> I see this fix will be in 1.0.1q. Do you know when 1.0.1q will be released? Ian -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Wednesday, August 05, 2015 8:40 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method On 04/08/15 22:03, Ian McFadries (imcfadri) wrote: > Sorry for the delayed response, I was away for a week and was able to test the fix today. > > The fix did resolve the session ticket issue that I was encountering. However, now I get an error when I am not using the session tickets under the following conditions. I am continuing to investigate. > > Create an SSL Session using the context that negotiates the highest > available version Client hello requests TLS 1.2 Server responds with > server hello using TLS 1.0 Complete handshake with no problems > Disconnect session Start new session which attempts a fast session > resumption Client sends Alert 70 (SSL_AD_PROTOCOLVERSION) because SSL > struct version contains version 0x303 but message after first message > contains version 0x301 Oh. Try this additional patch. By moving the session creation earlier in the process the session protocol version gets fixed at that earlier point. Unfortunately we have moved it to a point *before* version negotiation has completed. This patch just updates the session version once version negotiation is finished. Matt From matt at openssl.org Thu Sep 17 18:57:09 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 17 Sep 2015 19:57:09 +0100 Subject: [openssl-dev] TLS session ticket extension problem when using the ssl23_client_hello method In-Reply-To: <06f5bde4da33467aafb439aecd357f1d@XCH-ALN-010.cisco.com> References: <522B816F59485D4FBCBAF2CE8015B891928AA6@xmb-rcd-x01.cisco.com> <20150723182204.GA3935@w1.fi> <20150723202111.GY4347@mournblade.imrryr.org> <20150723224636.GA3876@w1.fi> <20150723230939.GB4347@mournblade.imrryr.org> <20150724090409.GA8799@w1.fi> <522B816F59485D4FBCBAF2CE8015B8919A43C1@xmb-rcd-x01.cisco.com> <55C20439.500@openssl.org> <06f5bde4da33467aafb439aecd357f1d@XCH-ALN-010.cisco.com> Message-ID: <55FB0D05.3060704@openssl.org> On 17/09/15 19:34, Ian McFadries (imcfadri) wrote: > I see this fix will be in 1.0.1q. Do you know when 1.0.1q will be released? We don't have a fixed timetable for bug fix releases. It is normally driven by what ever security issues we have to respond to - so unfortunately I don't know when 1.0.1q will be released. Matt From uri at ll.mit.edu Thu Sep 17 19:15:36 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 17 Sep 2015 19:15:36 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP Message-ID: $ apps/openssl$ openssl version OpenSSL 1.1.0-dev xx XXX xxxx $ make test testing... make[1]: Entering directory `/media/uri/Src/openssl/test' make[2]: Entering directory `/media/uri/Src/openssl' making all in apps... make[3]: Entering directory `/media/uri/Src/openssl/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/media/uri/Src/openssl/apps' make[2]: Leaving directory `/media/uri/Src/openssl' TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. ok ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslextension.t .... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/1 subtests Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslsessiontick.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 5/5 subtests ../test/recipes/70-test_sslskewith0p.t .... ok Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslvertol.t ....... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/2 subtests ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok # Looks like you planned 11 tests but ran 20. # Failed test 'CMS <=> CMS consistency tests, modified key parameters # ' # at ../test/recipes/80-test_cms.t line 460. # Looks like you failed 1 test of 4. ../test/recipes/80-test_cms.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_gost2814789.t ..... ok ../test/recipes/90-test_heartbeat.t ....... ok ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 1 tests but ran 0. ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 5 tests but ran 0. ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 2 tests but ran 0. ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys + 18.40 cusr 8.32 csys = 27.09 CPU) Result: FAIL Failed 4/63 test programs. 1/324 subtests failed. make[1]: *** [tests] Error 255 make[1]: Leaving directory `/media/uri/Src/openssl/test' make: *** [tests] Error 2 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Thu Sep 17 19:49:40 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 17 Sep 2015 19:49:40 +0000 Subject: [openssl-dev] [openssl.org #3757] OpenSSL decodes malformed base64 encoded inputs In-Reply-To: <20150320110539.2037a909@redhat.com> References: <20150320110539.2037a909@redhat.com> Message-ID: Wow, thanks for the thorough report. This was so broken that I had to go for a pretty major rewrite. Please take a look at commits 3cdd1e94b1d71f2ce3002738f9506da91fe2af45 and b785504a10310cb2872270eb409b70971be5e76e. (Also cherry-picked to 1.0.2 and 1.0.1.) All your test cases now pass so I'm resolving this ticket; if you find anything else, responding to this ticket will reopen it. Cheers, Emilia From rt at openssl.org Thu Sep 17 20:49:44 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 17 Sep 2015 20:49:44 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: Since email re-opens the ticket, let's use this one :) What's the output of this command: HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test From rt at openssl.org Thu Sep 17 21:17:05 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 17 Sep 2015 21:17:05 +0000 Subject: [openssl-dev] [openssl.org #4043] monitoring software depending on openssl not working on cloudflare ssl websites In-Reply-To: <55F7CF5C.2000609@ddhosted.com> References: <55F7CEFD.3000400@ddhosted.com> <55F7CF5C.2000609@ddhosted.com> Message-ID: Thanks Rob! Resolving. From rt at openssl.org Thu Sep 17 21:20:18 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 17 Sep 2015 21:20:18 +0000 Subject: [openssl-dev] [openssl.org #4052] [PATCH] Print debug info for extended master secret extension In-Reply-To: <20150917212006.GA24360@kronk.local> References: <20150917212006.GA24360@kronk.local> Message-ID: Hello, see GitHub pull request at https://github.com/openssl/openssl/pull/404 This is like RT#4016, but for extended master secret. Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Thu Sep 17 21:55:01 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 17 Sep 2015 22:55:01 +0100 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: References: Message-ID: <55FB36B5.40105@openssl.org> Hmmm. I cannot reproduce this. Is anyone else seeing this? Matt On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: > $ apps/openssl$ openssl version > OpenSSL 1.1.0-dev xx XXX xxxx > $ make test > testing... > make[1]: Entering directory `/media/uri/Src/openssl/test' > make[2]: Entering directory `/media/uri/Src/openssl' > making all in apps... > make[3]: Entering directory `/media/uri/Src/openssl/apps' > make[3]: Nothing to be done for `all'. > make[3]: Leaving directory `/media/uri/Src/openssl/apps' > make[2]: Leaving directory `/media/uri/Src/openssl' > TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests > ../test/recipes/00-check_testexes.t ....... ok > ../test/recipes/05-test_bf.t .............. ok > ../test/recipes/05-test_cast.t ............ ok > ../test/recipes/05-test_des.t ............. ok > ../test/recipes/05-test_hmac.t ............ ok > ../test/recipes/05-test_idea.t ............ ok > ../test/recipes/05-test_md2.t ............. ok > ../test/recipes/05-test_md4.t ............. ok > ../test/recipes/05-test_md5.t ............. ok > ../test/recipes/05-test_mdc2.t ............ ok > ../test/recipes/05-test_rand.t ............ ok > ../test/recipes/05-test_rc2.t ............. ok > ../test/recipes/05-test_rc4.t ............. ok > ../test/recipes/05-test_rc5.t ............. ok > ../test/recipes/05-test_rmd.t ............. ok > ../test/recipes/05-test_sha1.t ............ ok > ../test/recipes/05-test_sha256.t .......... ok > ../test/recipes/05-test_sha512.t .......... ok > ../test/recipes/05-test_wp.t .............. ok > ../test/recipes/10-test_bn.t .............. ok > ../test/recipes/10-test_exp.t ............. ok > ../test/recipes/15-test_dh.t .............. ok > ../test/recipes/15-test_dsa.t ............. ok > ../test/recipes/15-test_ec.t .............. ok > ../test/recipes/15-test_ecdh.t ............ ok > ../test/recipes/15-test_ecdsa.t ........... ok > ../test/recipes/15-test_rsa.t ............. ok > ../test/recipes/20-test_enc.t ............. ok > ../test/recipes/25-test_crl.t ............. ok > ../test/recipes/25-test_gen.t ............. ok > ../test/recipes/25-test_pkcs7.t ........... ok > ../test/recipes/25-test_req.t ............. ok > ../test/recipes/25-test_sid.t ............. ok > ../test/recipes/25-test_verify.t .......... ok > ../test/recipes/25-test_x509.t ............ ok > ../test/recipes/30-test_engine.t .......... ok > ../test/recipes/30-test_evp.t ............. ok > ../test/recipes/30-test_evp_extra.t ....... ok > ../test/recipes/30-test_pbelu.t ........... ok > ../test/recipes/40-test_rehash.t .......... ok > ../test/recipes/70-test_clienthello.t ..... ok > ../test/recipes/70-test_packet.t .......... ok > Use of uninitialized value within %message_type in concatenation (.) or > string at ../util/TLSProxy/Message.pm line 202, <> line 751. > Changed peer, but we still have fragment data > # Looks like your test exited with 255 before it could output anything. > ../test/recipes/70-test_sslextension.t .... > Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 1/1 subtests > Use of uninitialized value within %message_type in concatenation (.) or > string at ../util/TLSProxy/Message.pm line 202, <> line 751. > Changed peer, but we still have fragment data > # Looks like your test exited with 255 before it could output anything. > ../test/recipes/70-test_sslsessiontick.t .. > Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 5/5 subtests > ../test/recipes/70-test_sslskewith0p.t .... ok > Use of uninitialized value within %message_type in concatenation (.) or > string at ../util/TLSProxy/Message.pm line 202, <> line 751. > Changed peer, but we still have fragment data > # Looks like your test exited with 255 before it could output anything. > ../test/recipes/70-test_sslvertol.t ....... > Dubious, test returned 255 (wstat 65280, 0xff00) > Failed 2/2 subtests > ../test/recipes/70-test_verify_extra.t .... ok > ../test/recipes/80-test_ca.t .............. ok > # Looks like you planned 11 tests but ran 20. > > # Failed test 'CMS <=> CMS consistency tests, modified key parameters > # ' > # at ../test/recipes/80-test_cms.t line 460. > # Looks like you failed 1 test of 4. > ../test/recipes/80-test_cms.t ............. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests > ../test/recipes/80-test_ocsp.t ............ ok > ../test/recipes/80-test_ssl.t ............. ok > ../test/recipes/80-test_tsa.t ............. ok > ../test/recipes/90-test_constant_time.t ... ok > ../test/recipes/90-test_gmdiff.t .......... ok > ../test/recipes/90-test_gost2814789.t ..... ok > ../test/recipes/90-test_heartbeat.t ....... ok > ../test/recipes/90-test_ige.t ............. ok > ../test/recipes/90-test_jpake.t ........... ok > ../test/recipes/90-test_np.t .............. ok > ../test/recipes/90-test_p5_crpt2.t ........ ok > ../test/recipes/90-test_secmem.t .......... ok > ../test/recipes/90-test_srp.t ............. ok > ../test/recipes/90-test_v3name.t .......... ok > > Test Summary Report > ------------------- > ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 1 tests but ran 0. > ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 5 tests but ran 0. > ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) > Non-zero exit status: 255 > Parse errors: Bad plan. You planned 2 tests but ran 0. > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys + 18.40 cusr > 8.32 csys = 27.09 CPU) > Result: FAIL > Failed 4/63 test programs. 1/324 subtests failed. > make[1]: *** [tests] Error 255 > make[1]: Leaving directory `/media/uri/Src/openssl/test' > make: *** [tests] Error 2 > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 4.8.4-2ubuntu1~14.04' > --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-4.8 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib > --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --enable-gnu-unique-object --disable-libmudflap --enable-plugin > --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk > --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre > --enable-java-home > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 > --with-arch-directory=amd64 > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc > --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > Thread model: posix > gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) > -- > Regards, > Uri Blumenthal > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From richard at levitte.org Fri Sep 18 06:27:41 2015 From: richard at levitte.org (Richard Levitte) Date: Fri, 18 Sep 2015 08:27:41 +0200 (CEST) Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <55FB36B5.40105@openssl.org> References: <55FB36B5.40105@openssl.org> Message-ID: <20150918.082741.828773768499895038.richard@levitte.org> I can't reproduce it either, but judging from the line number, it looks like a surprise unknown message type. Uri, the attached patch and the following command line might help clear this up: HARNESS_VERBOSE=yes make TESTS=test_sslextension test Cheers, Richard In message <55FB36B5.40105 at openssl.org> on Thu, 17 Sep 2015 22:55:01 +0100, Matt Caswell said: matt> Hmmm. I cannot reproduce this. Is anyone else seeing this? matt> matt> Matt matt> matt> On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: matt> > $ apps/openssl$ openssl version matt> > OpenSSL 1.1.0-dev xx XXX xxxx matt> > $ make test matt> > testing... matt> > make[1]: Entering directory `/media/uri/Src/openssl/test' matt> > make[2]: Entering directory `/media/uri/Src/openssl' matt> > making all in apps... matt> > make[3]: Entering directory `/media/uri/Src/openssl/apps' matt> > make[3]: Nothing to be done for `all'. matt> > make[3]: Leaving directory `/media/uri/Src/openssl/apps' matt> > make[2]: Leaving directory `/media/uri/Src/openssl' matt> > TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests matt> > ../test/recipes/00-check_testexes.t ....... ok matt> > ../test/recipes/05-test_bf.t .............. ok matt> > ../test/recipes/05-test_cast.t ............ ok matt> > ../test/recipes/05-test_des.t ............. ok matt> > ../test/recipes/05-test_hmac.t ............ ok matt> > ../test/recipes/05-test_idea.t ............ ok matt> > ../test/recipes/05-test_md2.t ............. ok matt> > ../test/recipes/05-test_md4.t ............. ok matt> > ../test/recipes/05-test_md5.t ............. ok matt> > ../test/recipes/05-test_mdc2.t ............ ok matt> > ../test/recipes/05-test_rand.t ............ ok matt> > ../test/recipes/05-test_rc2.t ............. ok matt> > ../test/recipes/05-test_rc4.t ............. ok matt> > ../test/recipes/05-test_rc5.t ............. ok matt> > ../test/recipes/05-test_rmd.t ............. ok matt> > ../test/recipes/05-test_sha1.t ............ ok matt> > ../test/recipes/05-test_sha256.t .......... ok matt> > ../test/recipes/05-test_sha512.t .......... ok matt> > ../test/recipes/05-test_wp.t .............. ok matt> > ../test/recipes/10-test_bn.t .............. ok matt> > ../test/recipes/10-test_exp.t ............. ok matt> > ../test/recipes/15-test_dh.t .............. ok matt> > ../test/recipes/15-test_dsa.t ............. ok matt> > ../test/recipes/15-test_ec.t .............. ok matt> > ../test/recipes/15-test_ecdh.t ............ ok matt> > ../test/recipes/15-test_ecdsa.t ........... ok matt> > ../test/recipes/15-test_rsa.t ............. ok matt> > ../test/recipes/20-test_enc.t ............. ok matt> > ../test/recipes/25-test_crl.t ............. ok matt> > ../test/recipes/25-test_gen.t ............. ok matt> > ../test/recipes/25-test_pkcs7.t ........... ok matt> > ../test/recipes/25-test_req.t ............. ok matt> > ../test/recipes/25-test_sid.t ............. ok matt> > ../test/recipes/25-test_verify.t .......... ok matt> > ../test/recipes/25-test_x509.t ............ ok matt> > ../test/recipes/30-test_engine.t .......... ok matt> > ../test/recipes/30-test_evp.t ............. ok matt> > ../test/recipes/30-test_evp_extra.t ....... ok matt> > ../test/recipes/30-test_pbelu.t ........... ok matt> > ../test/recipes/40-test_rehash.t .......... ok matt> > ../test/recipes/70-test_clienthello.t ..... ok matt> > ../test/recipes/70-test_packet.t .......... ok matt> > Use of uninitialized value within %message_type in concatenation (.) or matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. matt> > Changed peer, but we still have fragment data matt> > # Looks like your test exited with 255 before it could output anything. matt> > ../test/recipes/70-test_sslextension.t .... matt> > Dubious, test returned 255 (wstat 65280, 0xff00) matt> > Failed 1/1 subtests matt> > Use of uninitialized value within %message_type in concatenation (.) or matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. matt> > Changed peer, but we still have fragment data matt> > # Looks like your test exited with 255 before it could output anything. matt> > ../test/recipes/70-test_sslsessiontick.t .. matt> > Dubious, test returned 255 (wstat 65280, 0xff00) matt> > Failed 5/5 subtests matt> > ../test/recipes/70-test_sslskewith0p.t .... ok matt> > Use of uninitialized value within %message_type in concatenation (.) or matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. matt> > Changed peer, but we still have fragment data matt> > # Looks like your test exited with 255 before it could output anything. matt> > ../test/recipes/70-test_sslvertol.t ....... matt> > Dubious, test returned 255 (wstat 65280, 0xff00) matt> > Failed 2/2 subtests matt> > ../test/recipes/70-test_verify_extra.t .... ok matt> > ../test/recipes/80-test_ca.t .............. ok matt> > # Looks like you planned 11 tests but ran 20. matt> > matt> > # Failed test 'CMS <=> CMS consistency tests, modified key parameters matt> > # ' matt> > # at ../test/recipes/80-test_cms.t line 460. matt> > # Looks like you failed 1 test of 4. matt> > ../test/recipes/80-test_cms.t ............. matt> > Dubious, test returned 1 (wstat 256, 0x100) matt> > Failed 1/4 subtests matt> > ../test/recipes/80-test_ocsp.t ............ ok matt> > ../test/recipes/80-test_ssl.t ............. ok matt> > ../test/recipes/80-test_tsa.t ............. ok matt> > ../test/recipes/90-test_constant_time.t ... ok matt> > ../test/recipes/90-test_gmdiff.t .......... ok matt> > ../test/recipes/90-test_gost2814789.t ..... ok matt> > ../test/recipes/90-test_heartbeat.t ....... ok matt> > ../test/recipes/90-test_ige.t ............. ok matt> > ../test/recipes/90-test_jpake.t ........... ok matt> > ../test/recipes/90-test_np.t .............. ok matt> > ../test/recipes/90-test_p5_crpt2.t ........ ok matt> > ../test/recipes/90-test_secmem.t .......... ok matt> > ../test/recipes/90-test_srp.t ............. ok matt> > ../test/recipes/90-test_v3name.t .......... ok matt> > matt> > Test Summary Report matt> > ------------------- matt> > ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) matt> > Non-zero exit status: 255 matt> > Parse errors: Bad plan. You planned 1 tests but ran 0. matt> > ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) matt> > Non-zero exit status: 255 matt> > Parse errors: Bad plan. You planned 5 tests but ran 0. matt> > ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) matt> > Non-zero exit status: 255 matt> > Parse errors: Bad plan. You planned 2 tests but ran 0. matt> > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) matt> > Failed test: 4 matt> > Non-zero exit status: 1 matt> > Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys + 18.40 cusr matt> > 8.32 csys = 27.09 CPU) matt> > Result: FAIL matt> > Failed 4/63 test programs. 1/324 subtests failed. matt> > make[1]: *** [tests] Error 255 matt> > make[1]: Leaving directory `/media/uri/Src/openssl/test' matt> > make: *** [tests] Error 2 matt> > $ gcc -v matt> > Using built-in specs. matt> > COLLECT_GCC=gcc matt> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper matt> > Target: x86_64-linux-gnu matt> > Configured with: ../src/configure -v --with-pkgversion='Ubuntu matt> > 4.8.4-2ubuntu1~14.04' matt> > --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs matt> > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr matt> > --program-suffix=-4.8 --enable-shared --enable-linker-build-id matt> > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix matt> > --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib matt> > --enable-nls --with-sysroot=/ --enable-clocale=gnu matt> > --enable-libstdcxx-debug --enable-libstdcxx-time=yes matt> > --enable-gnu-unique-object --disable-libmudflap --enable-plugin matt> > --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk matt> > --enable-gtk-cairo matt> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre matt> > --enable-java-home matt> > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 matt> > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 matt> > --with-arch-directory=amd64 matt> > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc matt> > --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 matt> > --with-multilib-list=m32,m64,mx32 --with-tune=generic matt> > --enable-checking=release --build=x86_64-linux-gnu matt> > --host=x86_64-linux-gnu --target=x86_64-linux-gnu matt> > Thread model: posix matt> > gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) matt> > -- matt> > Regards, matt> > Uri Blumenthal matt> > matt> > matt> > _______________________________________________ matt> > openssl-dev mailing list matt> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev matt> > matt> _______________________________________________ matt> openssl-dev mailing list matt> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: sslextension_debug.patch Type: text/x-patch Size: 1118 bytes Desc: not available URL: From rt at openssl.org Fri Sep 18 09:54:40 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 18 Sep 2015 09:54:40 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <36c3bae1c00dec26df8bbd199ee888ad@SDF.ORG> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> <36c3bae1c00dec26df8bbd199ee888ad@SDF.ORG> Message-ID: On 2015-09-17 16:49, Salz, Rich via RT wrote: > Since email re-opens the ticket, let's use this one :) > > What's the output of this command: > HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test # HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test testing... making all in apps... TOP=.. PERL=/usr/pkg/bin/perl /usr/pkg/bin/perl run_tests.pl test_rehash ../test/recipes/40-test_rehash.t .. 1..4 ok 1 - Testing normal rehash operations ok 2 - Testing rehash operations on readonly files ok 3 - Testing rehash operations on empty directory not ok 4 - Testing rehash operations on readonly directory # Failed test 'Testing rehash operations on readonly directory' # at ../test/recipes/40-test_rehash.t line 35. # got: '1' # expected: anything else # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=1, Tests=4, 0 wallclock secs ( 0.08 usr 0.01 sys + 0.26 cusr 0.18 csys = 0.53 CPU) Result: FAIL Failed 1/1 test programs. 1/4 subtests failed. *** Error code 1 Stop. make: stopped in /usr/local/src/openssl/test *** Error code 1 Stop. make: stopped in /usr/local/src/openssl From rt at openssl.org Fri Sep 18 13:50:52 2015 From: rt at openssl.org (Michal Bozon via RT) Date: Fri, 18 Sep 2015 13:50:52 +0000 Subject: [openssl-dev] [openssl.org #4053] [PATCH] Fix typo in prime.c error message In-Reply-To: References: Message-ID: s/Specifiy/Specify/ regards, Michal Bozon -------------- next part -------------- --- apps/prime.c.0 +++ apps/prime.c @@ -121,7 +121,7 @@ char *s; if (!bits) { - BIO_printf(bio_err, "Specifiy the number of bits.\n"); + BIO_printf(bio_err, "Specify the number of bits.\n"); goto end; } bn = BN_new(); -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 18 14:20:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 18 Sep 2015 14:20:34 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> <36c3bae1c00dec26df8bbd199ee888ad@SDF.ORG> Message-ID: Hi, jumping in here... could you show us the content of test/test_rehash.log ? In the mean time, I'll have a go on a FreeBSD system to see if I can trigger this fault. Vid Fre, 18 Sep 2015 kl. 09.54.40, skrev yancm at SDF.ORG: > On 2015-09-17 16:49, Salz, Rich via RT wrote: > > Since email re-opens the ticket, let's use this one :) > > > > What's the output of this command: > > HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test > > # HARNESS_VERBOSE=yes make 'TESTS=test_rehash' test > testing... > making all in apps... > TOP=.. PERL=/usr/pkg/bin/perl /usr/pkg/bin/perl run_tests.pl test_rehash > ../test/recipes/40-test_rehash.t .. > 1..4 > ok 1 - Testing normal rehash operations > ok 2 - Testing rehash operations on readonly files > ok 3 - Testing rehash operations on empty directory > not ok 4 - Testing rehash operations on readonly directory > > # Failed test 'Testing rehash operations on readonly directory' > # at ../test/recipes/40-test_rehash.t line 35. > # got: '1' > # expected: anything else > # Looks like you failed 1 test of 4. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests > > Test Summary Report > ------------------- > ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=1, Tests=4, 0 wallclock secs ( 0.08 usr 0.01 sys + 0.26 cusr > 0.18 csys = 0.53 CPU) > Result: FAIL > Failed 1/1 test programs. 1/4 subtests failed. > *** Error code 1 > > Stop. > make: stopped in /usr/local/src/openssl/test > *** Error code 1 > > Stop. > make: stopped in /usr/local/src/openssl > -- Richard Levitte levitte at openssl.org From rt at openssl.org Fri Sep 18 15:21:14 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 18 Sep 2015 15:21:14 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <429ad8f70d3381a4f8a3cf4fffb0ad0b.squirrel@wm.sdf.org> References: <03afe488fc06b0b393a2101aef3ed213@SDF.ORG> <0fd90f91cefdb8ea83174d7b328ac964.squirrel@wm.sdf.org> <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> <36c3bae1c00dec26df8bbd199ee888ad@SDF.ORG> <429ad8f70d3381a4f8a3cf4fffb0ad0b.squirrel@wm.sdf.org> Message-ID: > jumping in here... could you show us the content of > test/test_rehash.log ? > > In the mean time, I'll have a go on a FreeBSD system to see if I can > trigger this fault. # more test_rehash.log ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 # From uri at ll.mit.edu Fri Sep 18 16:18:53 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Sep 2015 16:18:53 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150918.082741.828773768499895038.richard@levitte.org> References: <55FB36B5.40105@openssl.org> <20150918.082741.828773768499895038.richard@levitte.org> Message-ID: Richard, Thank you for your help! Unfortunately, the problem persists: testing... make[1]: Entering directory `/media/uri/Src/openssl/test' make[2]: Entering directory `/media/uri/Src/openssl' making all in apps... make[3]: Entering directory `/media/uri/Src/openssl/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/media/uri/Src/openssl/apps' make[2]: Leaving directory `/media/uri/Src/openssl' TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. ok ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslextension.t .... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/1 subtests Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslsessiontick.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 5/5 subtests ../test/recipes/70-test_sslskewith0p.t .... ok Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 202, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslvertol.t ....... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/2 subtests ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok # Looks like you planned 11 tests but ran 20. # Failed test 'CMS <=> CMS consistency tests, modified key parameters # ' # at ../test/recipes/80-test_cms.t line 460. # Looks like you failed 1 test of 4. ../test/recipes/80-test_cms.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_gost2814789.t ..... ok ../test/recipes/90-test_heartbeat.t ....... ok ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 1 tests but ran 0. ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 5 tests but ran 0. ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 2 tests but ran 0. ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=63, Tests=324, 30 wallclock secs ( 0.31 usr 0.08 sys + 19.13 cusr 8.61 csys = 28.13 CPU) Result: FAIL Failed 4/63 test programs. 1/324 subtests failed. make[1]: *** [tests] Error 255 make[1]: Leaving directory `/media/uri/Src/openssl/test' make: *** [tests] Error 2 What can we (I :) do to either remedy it, or provide you more info to find the cause? -- Regards, Uri Blumenthal On 9/18/15, 2:27 , "Richard Levitte" wrote: >I can't reproduce it either, but judging from the line number, it >looks like a surprise unknown message type. Uri, the attached patch >and the following command line might help clear this up: > > HARNESS_VERBOSE=yes make TESTS=test_sslextension test > >Cheers, >Richard > >In message <55FB36B5.40105 at openssl.org> on Thu, 17 Sep 2015 22:55:01 >+0100, Matt Caswell said: > >matt> Hmmm. I cannot reproduce this. Is anyone else seeing this? >matt> >matt> Matt >matt> >matt> On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: >matt> > $ apps/openssl$ openssl version >matt> > OpenSSL 1.1.0-dev xx XXX xxxx >matt> > $ make test >matt> > testing... >matt> > make[1]: Entering directory `/media/uri/Src/openssl/test' >matt> > make[2]: Entering directory `/media/uri/Src/openssl' >matt> > making all in apps... >matt> > make[3]: Entering directory `/media/uri/Src/openssl/apps' >matt> > make[3]: Nothing to be done for `all'. >matt> > make[3]: Leaving directory `/media/uri/Src/openssl/apps' >matt> > make[2]: Leaving directory `/media/uri/Src/openssl' >matt> > TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests >matt> > ../test/recipes/00-check_testexes.t ....... ok >matt> > ../test/recipes/05-test_bf.t .............. ok >matt> > ../test/recipes/05-test_cast.t ............ ok >matt> > ../test/recipes/05-test_des.t ............. ok >matt> > ../test/recipes/05-test_hmac.t ............ ok >matt> > ../test/recipes/05-test_idea.t ............ ok >matt> > ../test/recipes/05-test_md2.t ............. ok >matt> > ../test/recipes/05-test_md4.t ............. ok >matt> > ../test/recipes/05-test_md5.t ............. ok >matt> > ../test/recipes/05-test_mdc2.t ............ ok >matt> > ../test/recipes/05-test_rand.t ............ ok >matt> > ../test/recipes/05-test_rc2.t ............. ok >matt> > ../test/recipes/05-test_rc4.t ............. ok >matt> > ../test/recipes/05-test_rc5.t ............. ok >matt> > ../test/recipes/05-test_rmd.t ............. ok >matt> > ../test/recipes/05-test_sha1.t ............ ok >matt> > ../test/recipes/05-test_sha256.t .......... ok >matt> > ../test/recipes/05-test_sha512.t .......... ok >matt> > ../test/recipes/05-test_wp.t .............. ok >matt> > ../test/recipes/10-test_bn.t .............. ok >matt> > ../test/recipes/10-test_exp.t ............. ok >matt> > ../test/recipes/15-test_dh.t .............. ok >matt> > ../test/recipes/15-test_dsa.t ............. ok >matt> > ../test/recipes/15-test_ec.t .............. ok >matt> > ../test/recipes/15-test_ecdh.t ............ ok >matt> > ../test/recipes/15-test_ecdsa.t ........... ok >matt> > ../test/recipes/15-test_rsa.t ............. ok >matt> > ../test/recipes/20-test_enc.t ............. ok >matt> > ../test/recipes/25-test_crl.t ............. ok >matt> > ../test/recipes/25-test_gen.t ............. ok >matt> > ../test/recipes/25-test_pkcs7.t ........... ok >matt> > ../test/recipes/25-test_req.t ............. ok >matt> > ../test/recipes/25-test_sid.t ............. ok >matt> > ../test/recipes/25-test_verify.t .......... ok >matt> > ../test/recipes/25-test_x509.t ............ ok >matt> > ../test/recipes/30-test_engine.t .......... ok >matt> > ../test/recipes/30-test_evp.t ............. ok >matt> > ../test/recipes/30-test_evp_extra.t ....... ok >matt> > ../test/recipes/30-test_pbelu.t ........... ok >matt> > ../test/recipes/40-test_rehash.t .......... ok >matt> > ../test/recipes/70-test_clienthello.t ..... ok >matt> > ../test/recipes/70-test_packet.t .......... ok >matt> > Use of uninitialized value within %message_type in concatenation >(.) or >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >matt> > Changed peer, but we still have fragment data >matt> > # Looks like your test exited with 255 before it could output >anything. >matt> > ../test/recipes/70-test_sslextension.t .... >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >matt> > Failed 1/1 subtests >matt> > Use of uninitialized value within %message_type in concatenation >(.) or >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >matt> > Changed peer, but we still have fragment data >matt> > # Looks like your test exited with 255 before it could output >anything. >matt> > ../test/recipes/70-test_sslsessiontick.t .. >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >matt> > Failed 5/5 subtests >matt> > ../test/recipes/70-test_sslskewith0p.t .... ok >matt> > Use of uninitialized value within %message_type in concatenation >(.) or >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >matt> > Changed peer, but we still have fragment data >matt> > # Looks like your test exited with 255 before it could output >anything. >matt> > ../test/recipes/70-test_sslvertol.t ....... >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >matt> > Failed 2/2 subtests >matt> > ../test/recipes/70-test_verify_extra.t .... ok >matt> > ../test/recipes/80-test_ca.t .............. ok >matt> > # Looks like you planned 11 tests but ran 20. >matt> > >matt> > # Failed test 'CMS <=> CMS consistency tests, modified key >parameters >matt> > # ' >matt> > # at ../test/recipes/80-test_cms.t line 460. >matt> > # Looks like you failed 1 test of 4. >matt> > ../test/recipes/80-test_cms.t ............. >matt> > Dubious, test returned 1 (wstat 256, 0x100) >matt> > Failed 1/4 subtests >matt> > ../test/recipes/80-test_ocsp.t ............ ok >matt> > ../test/recipes/80-test_ssl.t ............. ok >matt> > ../test/recipes/80-test_tsa.t ............. ok >matt> > ../test/recipes/90-test_constant_time.t ... ok >matt> > ../test/recipes/90-test_gmdiff.t .......... ok >matt> > ../test/recipes/90-test_gost2814789.t ..... ok >matt> > ../test/recipes/90-test_heartbeat.t ....... ok >matt> > ../test/recipes/90-test_ige.t ............. ok >matt> > ../test/recipes/90-test_jpake.t ........... ok >matt> > ../test/recipes/90-test_np.t .............. ok >matt> > ../test/recipes/90-test_p5_crpt2.t ........ ok >matt> > ../test/recipes/90-test_secmem.t .......... ok >matt> > ../test/recipes/90-test_srp.t ............. ok >matt> > ../test/recipes/90-test_v3name.t .......... ok >matt> > >matt> > Test Summary Report >matt> > ------------------- >matt> > ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 >Failed: 0) >matt> > Non-zero exit status: 255 >matt> > Parse errors: Bad plan. You planned 1 tests but ran 0. >matt> > ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 >Failed: 0) >matt> > Non-zero exit status: 255 >matt> > Parse errors: Bad plan. You planned 5 tests but ran 0. >matt> > ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 >Failed: 0) >matt> > Non-zero exit status: 255 >matt> > Parse errors: Bad plan. You planned 2 tests but ran 0. >matt> > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 >Failed: 1) >matt> > Failed test: 4 >matt> > Non-zero exit status: 1 >matt> > Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys + >18.40 cusr >matt> > 8.32 csys = 27.09 CPU) >matt> > Result: FAIL >matt> > Failed 4/63 test programs. 1/324 subtests failed. >matt> > make[1]: *** [tests] Error 255 >matt> > make[1]: Leaving directory `/media/uri/Src/openssl/test' >matt> > make: *** [tests] Error 2 >matt> > $ gcc -v >matt> > Using built-in specs. >matt> > COLLECT_GCC=gcc >matt> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper >matt> > Target: x86_64-linux-gnu >matt> > Configured with: ../src/configure -v --with-pkgversion='Ubuntu >matt> > 4.8.4-2ubuntu1~14.04' >matt> > --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs >matt> > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ >--prefix=/usr >matt> > --program-suffix=-4.8 --enable-shared --enable-linker-build-id >matt> > --libexecdir=/usr/lib --without-included-gettext >--enable-threads=posix >matt> > --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib >matt> > --enable-nls --with-sysroot=/ --enable-clocale=gnu >matt> > --enable-libstdcxx-debug --enable-libstdcxx-time=yes >matt> > --enable-gnu-unique-object --disable-libmudflap --enable-plugin >matt> > --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk >matt> > --enable-gtk-cairo >matt> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre >matt> > --enable-java-home >matt> > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 >matt> > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 >matt> > --with-arch-directory=amd64 >matt> > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc >matt> > --enable-multiarch --disable-werror --with-arch-32=i686 >--with-abi=m64 >matt> > --with-multilib-list=m32,m64,mx32 --with-tune=generic >matt> > --enable-checking=release --build=x86_64-linux-gnu >matt> > --host=x86_64-linux-gnu --target=x86_64-linux-gnu >matt> > Thread model: posix >matt> > gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) >matt> > -- >matt> > Regards, >matt> > Uri Blumenthal >matt> > >matt> > >matt> > _______________________________________________ >matt> > openssl-dev mailing list >matt> > To unsubscribe: >https://mta.openssl.org/mailman/listinfo/openssl-dev >matt> > >matt> _______________________________________________ >matt> openssl-dev mailing list >matt> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Fri Sep 18 18:23:51 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 18 Sep 2015 18:23:51 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: Vid Fre, 18 Sep 2015 kl. 15.21.14, skrev yancm at SDF.ORG: > > jumping in here... could you show us the content of > > test/test_rehash.log ? > > > > In the mean time, I'll have a go on a FreeBSD system to see if I can > > trigger this fault. > > # more test_rehash.log > ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 > ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 > ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 > ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 > # Ok, I'm having trouble reproducing.... What that last test really does is the equivalent of this: mkdir rehash.$$; (cd rehash.$$; chmod 0500 . ; ../util/shlib_wrap.sh ../apps/openssl rehash . ; echo $?; chmod 0700 . ); rmdir rehash.$$ with the current source (I have assume you're pull is absolutely up to date), that should print an error message and the echo of $? should print 1. I cannot understand why that fails for you... -- Richard Levitte levitte at openssl.org From erik at efca.com Fri Sep 18 18:32:15 2015 From: erik at efca.com (Erik Forsberg) Date: Fri, 18 Sep 2015 11:32:15 -0700 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: >-- Original Message -- > >Vid Fre, 18 Sep 2015 kl. 15.21.14, skrev yancm at SDF.ORG: >> > jumping in here... could you show us the content of >> > test/test_rehash.log ? >> > >> > In the mean time, I'll have a go on a FreeBSD system to see if I can >> > trigger this fault. >> >> # more test_rehash.log >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> # > >Ok, I'm having trouble reproducing.... > >What that last test really does is the equivalent of this: > >mkdir rehash.$$; (cd rehash.$$; chmod 0500 . ; ../util/shlib_wrap.sh >../apps/openssl rehash . ; echo $?; chmod 0700 . ); rmdir rehash.$$ > >with the current source (I have assume you're pull is absolutely up to date), >that should print an error message and the echo of $? should print 1. I cannot >understand why that fails for you... Maybe running test as root ? From rt at openssl.org Fri Sep 18 18:52:28 2015 From: rt at openssl.org (Erik Forsberg via RT) Date: Fri, 18 Sep 2015 18:52:28 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: >-- Original Message -- > >Vid Fre, 18 Sep 2015 kl. 15.21.14, skrev yancm at SDF.ORG: >> > jumping in here... could you show us the content of >> > test/test_rehash.log ? >> > >> > In the mean time, I'll have a go on a FreeBSD system to see if I can >> > trigger this fault. >> >> # more test_rehash.log >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> ../../util/shlib_wrap.sh ../../apps/openssl rehash . => 0 >> # > >Ok, I'm having trouble reproducing.... > >What that last test really does is the equivalent of this: > >mkdir rehash.$$; (cd rehash.$$; chmod 0500 . ; ../util/shlib_wrap.sh >../apps/openssl rehash . ; echo $?; chmod 0700 . ); rmdir rehash.$$ > >with the current source (I have assume you're pull is absolutely up to date), >that should print an error message and the echo of $? should print 1. I cannot >understand why that fails for you... Maybe running test as root ? From rt at openssl.org Fri Sep 18 18:56:31 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 18 Sep 2015 18:56:31 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: <0838da8bff55d7ca4c4ab0d7684a04fd.squirrel@wm.sdf.org> References: <20731d3032b144ea81a2699694a68ca0@ustx2ex-dag1mb3.msg.corp.akamai.com> <0838da8bff55d7ca4c4ab0d7684a04fd.squirrel@wm.sdf.org> Message-ID: > Ok, I'm having trouble reproducing.... > > with the current source (I have assume you're pull is absolutely up to > date), Yes, to the best of my understanding I am fully in sync with the master branch. > that should print an error message and the echo of $? > should print 1. I cannot understand why that fails for you... Yes, this is odd since it returns *zero* if I execute this command string - no error message... maybe a problem with the test perl code? Here's my output: # mkdir rehash.$$ ; ( cd rehash.$$ ; chmod 0500 . ; ../util/shlib_wrap.sh ../apps/openssl rehash . ; echo $? ; chmod 0700 . ) ; rmdir rehash.$$ 0 # --gene From rt at openssl.org Fri Sep 18 19:07:55 2015 From: rt at openssl.org (yancm via RT) Date: Fri, 18 Sep 2015 19:07:55 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: >>Ok, I'm having trouble reproducing.... [...] >>that should print an error message and the echo of $? >>should print 1. I cannot understand why that fails for you... > > Maybe running test as root ? YES! It's a one user box that I regularly update and install on, so rarely run as reduced/un-privileged user. If I switch to non-root, this passes. Sorry to take your bandwidth. --gene From richard at levitte.org Fri Sep 18 19:15:00 2015 From: richard at levitte.org (Richard Levitte) Date: Fri, 18 Sep 2015 21:15:00 +0200 (CEST) Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: References: <55FB36B5.40105@openssl.org> <20150918.082741.828773768499895038.richard@levitte.org> Message-ID: <20150918.211500.152048296829238565.richard@levitte.org> Did you apply the full patch? The was a part for test/recipes/70-test_sslextension.t that should have had it generate debugging output... In message on Fri, 18 Sep 2015 16:18:53 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> Richard, uri> uri> Thank you for your help! Unfortunately, the problem persists: uri> uri> testing... uri> make[1]: Entering directory `/media/uri/Src/openssl/test' uri> make[2]: Entering directory `/media/uri/Src/openssl' uri> making all in apps... uri> make[3]: Entering directory `/media/uri/Src/openssl/apps' uri> make[3]: Nothing to be done for `all'. uri> make[3]: Leaving directory `/media/uri/Src/openssl/apps' uri> make[2]: Leaving directory `/media/uri/Src/openssl' uri> TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests uri> ../test/recipes/00-check_testexes.t ....... ok uri> ../test/recipes/05-test_bf.t .............. ok uri> ../test/recipes/05-test_cast.t ............ ok uri> ../test/recipes/05-test_des.t ............. ok uri> ../test/recipes/05-test_hmac.t ............ ok uri> ../test/recipes/05-test_idea.t ............ ok uri> ../test/recipes/05-test_md2.t ............. ok uri> ../test/recipes/05-test_md4.t ............. ok uri> ../test/recipes/05-test_md5.t ............. ok uri> ../test/recipes/05-test_mdc2.t ............ ok uri> ../test/recipes/05-test_rand.t ............ ok uri> ../test/recipes/05-test_rc2.t ............. ok uri> ../test/recipes/05-test_rc4.t ............. ok uri> ../test/recipes/05-test_rc5.t ............. ok uri> ../test/recipes/05-test_rmd.t ............. ok uri> ../test/recipes/05-test_sha1.t ............ ok uri> ../test/recipes/05-test_sha256.t .......... ok uri> ../test/recipes/05-test_sha512.t .......... ok uri> ../test/recipes/05-test_wp.t .............. ok uri> ../test/recipes/10-test_bn.t .............. ok uri> ../test/recipes/10-test_exp.t ............. ok uri> ../test/recipes/15-test_dh.t .............. ok uri> ../test/recipes/15-test_dsa.t ............. ok uri> ../test/recipes/15-test_ec.t .............. ok uri> ../test/recipes/15-test_ecdh.t ............ ok uri> ../test/recipes/15-test_ecdsa.t ........... ok uri> ../test/recipes/15-test_rsa.t ............. ok uri> ../test/recipes/20-test_enc.t ............. ok uri> ../test/recipes/25-test_crl.t ............. ok uri> ../test/recipes/25-test_gen.t ............. ok uri> ../test/recipes/25-test_pkcs7.t ........... ok uri> ../test/recipes/25-test_req.t ............. ok uri> ../test/recipes/25-test_sid.t ............. ok uri> ../test/recipes/25-test_verify.t .......... ok uri> ../test/recipes/25-test_x509.t ............ ok uri> ../test/recipes/30-test_engine.t .......... ok uri> ../test/recipes/30-test_evp.t ............. ok uri> ../test/recipes/30-test_evp_extra.t ....... ok uri> ../test/recipes/30-test_pbelu.t ........... ok uri> ../test/recipes/40-test_rehash.t .......... ok uri> ../test/recipes/70-test_clienthello.t ..... ok uri> ../test/recipes/70-test_packet.t .......... ok uri> Use of uninitialized value within %message_type in concatenation (.) or uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> Changed peer, but we still have fragment data uri> # Looks like your test exited with 255 before it could output anything. uri> ../test/recipes/70-test_sslextension.t .... uri> Dubious, test returned 255 (wstat 65280, 0xff00) uri> Failed 1/1 subtests uri> Use of uninitialized value within %message_type in concatenation (.) or uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> Changed peer, but we still have fragment data uri> # Looks like your test exited with 255 before it could output anything. uri> ../test/recipes/70-test_sslsessiontick.t .. uri> Dubious, test returned 255 (wstat 65280, 0xff00) uri> Failed 5/5 subtests uri> ../test/recipes/70-test_sslskewith0p.t .... ok uri> Use of uninitialized value within %message_type in concatenation (.) or uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> Changed peer, but we still have fragment data uri> # Looks like your test exited with 255 before it could output anything. uri> ../test/recipes/70-test_sslvertol.t ....... uri> Dubious, test returned 255 (wstat 65280, 0xff00) uri> Failed 2/2 subtests uri> ../test/recipes/70-test_verify_extra.t .... ok uri> ../test/recipes/80-test_ca.t .............. ok uri> # Looks like you planned 11 tests but ran 20. uri> uri> # Failed test 'CMS <=> CMS consistency tests, modified key parameters uri> # ' uri> # at ../test/recipes/80-test_cms.t line 460. uri> # Looks like you failed 1 test of 4. uri> ../test/recipes/80-test_cms.t ............. uri> Dubious, test returned 1 (wstat 256, 0x100) uri> Failed 1/4 subtests uri> ../test/recipes/80-test_ocsp.t ............ ok uri> ../test/recipes/80-test_ssl.t ............. ok uri> ../test/recipes/80-test_tsa.t ............. ok uri> ../test/recipes/90-test_constant_time.t ... ok uri> ../test/recipes/90-test_gmdiff.t .......... ok uri> ../test/recipes/90-test_gost2814789.t ..... ok uri> ../test/recipes/90-test_heartbeat.t ....... ok uri> ../test/recipes/90-test_ige.t ............. ok uri> ../test/recipes/90-test_jpake.t ........... ok uri> ../test/recipes/90-test_np.t .............. ok uri> ../test/recipes/90-test_p5_crpt2.t ........ ok uri> ../test/recipes/90-test_secmem.t .......... ok uri> ../test/recipes/90-test_srp.t ............. ok uri> ../test/recipes/90-test_v3name.t .......... ok uri> uri> Test Summary Report uri> ------------------- uri> ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) uri> Non-zero exit status: 255 uri> Parse errors: Bad plan. You planned 1 tests but ran 0. uri> ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) uri> Non-zero exit status: 255 uri> Parse errors: Bad plan. You planned 5 tests but ran 0. uri> ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) uri> Non-zero exit status: 255 uri> Parse errors: Bad plan. You planned 2 tests but ran 0. uri> ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) uri> Failed test: 4 uri> Non-zero exit status: 1 uri> Files=63, Tests=324, 30 wallclock secs ( 0.31 usr 0.08 sys + 19.13 cusr uri> 8.61 csys = 28.13 CPU) uri> Result: FAIL uri> Failed 4/63 test programs. 1/324 subtests failed. uri> make[1]: *** [tests] Error 255 uri> make[1]: Leaving directory `/media/uri/Src/openssl/test' uri> make: *** [tests] Error 2 uri> uri> uri> uri> What can we (I :) do to either remedy it, or provide you more info to find uri> the cause? uri> -- uri> Regards, uri> Uri Blumenthal uri> uri> uri> uri> uri> uri> On 9/18/15, 2:27 , "Richard Levitte" wrote: uri> uri> >I can't reproduce it either, but judging from the line number, it uri> >looks like a surprise unknown message type. Uri, the attached patch uri> >and the following command line might help clear this up: uri> > uri> > HARNESS_VERBOSE=yes make TESTS=test_sslextension test uri> > uri> >Cheers, uri> >Richard uri> > uri> >In message <55FB36B5.40105 at openssl.org> on Thu, 17 Sep 2015 22:55:01 uri> >+0100, Matt Caswell said: uri> > uri> >matt> Hmmm. I cannot reproduce this. Is anyone else seeing this? uri> >matt> uri> >matt> Matt uri> >matt> uri> >matt> On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: uri> >matt> > $ apps/openssl$ openssl version uri> >matt> > OpenSSL 1.1.0-dev xx XXX xxxx uri> >matt> > $ make test uri> >matt> > testing... uri> >matt> > make[1]: Entering directory `/media/uri/Src/openssl/test' uri> >matt> > make[2]: Entering directory `/media/uri/Src/openssl' uri> >matt> > making all in apps... uri> >matt> > make[3]: Entering directory `/media/uri/Src/openssl/apps' uri> >matt> > make[3]: Nothing to be done for `all'. uri> >matt> > make[3]: Leaving directory `/media/uri/Src/openssl/apps' uri> >matt> > make[2]: Leaving directory `/media/uri/Src/openssl' uri> >matt> > TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests uri> >matt> > ../test/recipes/00-check_testexes.t ....... ok uri> >matt> > ../test/recipes/05-test_bf.t .............. ok uri> >matt> > ../test/recipes/05-test_cast.t ............ ok uri> >matt> > ../test/recipes/05-test_des.t ............. ok uri> >matt> > ../test/recipes/05-test_hmac.t ............ ok uri> >matt> > ../test/recipes/05-test_idea.t ............ ok uri> >matt> > ../test/recipes/05-test_md2.t ............. ok uri> >matt> > ../test/recipes/05-test_md4.t ............. ok uri> >matt> > ../test/recipes/05-test_md5.t ............. ok uri> >matt> > ../test/recipes/05-test_mdc2.t ............ ok uri> >matt> > ../test/recipes/05-test_rand.t ............ ok uri> >matt> > ../test/recipes/05-test_rc2.t ............. ok uri> >matt> > ../test/recipes/05-test_rc4.t ............. ok uri> >matt> > ../test/recipes/05-test_rc5.t ............. ok uri> >matt> > ../test/recipes/05-test_rmd.t ............. ok uri> >matt> > ../test/recipes/05-test_sha1.t ............ ok uri> >matt> > ../test/recipes/05-test_sha256.t .......... ok uri> >matt> > ../test/recipes/05-test_sha512.t .......... ok uri> >matt> > ../test/recipes/05-test_wp.t .............. ok uri> >matt> > ../test/recipes/10-test_bn.t .............. ok uri> >matt> > ../test/recipes/10-test_exp.t ............. ok uri> >matt> > ../test/recipes/15-test_dh.t .............. ok uri> >matt> > ../test/recipes/15-test_dsa.t ............. ok uri> >matt> > ../test/recipes/15-test_ec.t .............. ok uri> >matt> > ../test/recipes/15-test_ecdh.t ............ ok uri> >matt> > ../test/recipes/15-test_ecdsa.t ........... ok uri> >matt> > ../test/recipes/15-test_rsa.t ............. ok uri> >matt> > ../test/recipes/20-test_enc.t ............. ok uri> >matt> > ../test/recipes/25-test_crl.t ............. ok uri> >matt> > ../test/recipes/25-test_gen.t ............. ok uri> >matt> > ../test/recipes/25-test_pkcs7.t ........... ok uri> >matt> > ../test/recipes/25-test_req.t ............. ok uri> >matt> > ../test/recipes/25-test_sid.t ............. ok uri> >matt> > ../test/recipes/25-test_verify.t .......... ok uri> >matt> > ../test/recipes/25-test_x509.t ............ ok uri> >matt> > ../test/recipes/30-test_engine.t .......... ok uri> >matt> > ../test/recipes/30-test_evp.t ............. ok uri> >matt> > ../test/recipes/30-test_evp_extra.t ....... ok uri> >matt> > ../test/recipes/30-test_pbelu.t ........... ok uri> >matt> > ../test/recipes/40-test_rehash.t .......... ok uri> >matt> > ../test/recipes/70-test_clienthello.t ..... ok uri> >matt> > ../test/recipes/70-test_packet.t .......... ok uri> >matt> > Use of uninitialized value within %message_type in concatenation uri> >(.) or uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> >matt> > Changed peer, but we still have fragment data uri> >matt> > # Looks like your test exited with 255 before it could output uri> >anything. uri> >matt> > ../test/recipes/70-test_sslextension.t .... uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) uri> >matt> > Failed 1/1 subtests uri> >matt> > Use of uninitialized value within %message_type in concatenation uri> >(.) or uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> >matt> > Changed peer, but we still have fragment data uri> >matt> > # Looks like your test exited with 255 before it could output uri> >anything. uri> >matt> > ../test/recipes/70-test_sslsessiontick.t .. uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) uri> >matt> > Failed 5/5 subtests uri> >matt> > ../test/recipes/70-test_sslskewith0p.t .... ok uri> >matt> > Use of uninitialized value within %message_type in concatenation uri> >(.) or uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. uri> >matt> > Changed peer, but we still have fragment data uri> >matt> > # Looks like your test exited with 255 before it could output uri> >anything. uri> >matt> > ../test/recipes/70-test_sslvertol.t ....... uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) uri> >matt> > Failed 2/2 subtests uri> >matt> > ../test/recipes/70-test_verify_extra.t .... ok uri> >matt> > ../test/recipes/80-test_ca.t .............. ok uri> >matt> > # Looks like you planned 11 tests but ran 20. uri> >matt> > uri> >matt> > # Failed test 'CMS <=> CMS consistency tests, modified key uri> >parameters uri> >matt> > # ' uri> >matt> > # at ../test/recipes/80-test_cms.t line 460. uri> >matt> > # Looks like you failed 1 test of 4. uri> >matt> > ../test/recipes/80-test_cms.t ............. uri> >matt> > Dubious, test returned 1 (wstat 256, 0x100) uri> >matt> > Failed 1/4 subtests uri> >matt> > ../test/recipes/80-test_ocsp.t ............ ok uri> >matt> > ../test/recipes/80-test_ssl.t ............. ok uri> >matt> > ../test/recipes/80-test_tsa.t ............. ok uri> >matt> > ../test/recipes/90-test_constant_time.t ... ok uri> >matt> > ../test/recipes/90-test_gmdiff.t .......... ok uri> >matt> > ../test/recipes/90-test_gost2814789.t ..... ok uri> >matt> > ../test/recipes/90-test_heartbeat.t ....... ok uri> >matt> > ../test/recipes/90-test_ige.t ............. ok uri> >matt> > ../test/recipes/90-test_jpake.t ........... ok uri> >matt> > ../test/recipes/90-test_np.t .............. ok uri> >matt> > ../test/recipes/90-test_p5_crpt2.t ........ ok uri> >matt> > ../test/recipes/90-test_secmem.t .......... ok uri> >matt> > ../test/recipes/90-test_srp.t ............. ok uri> >matt> > ../test/recipes/90-test_v3name.t .......... ok uri> >matt> > uri> >matt> > Test Summary Report uri> >matt> > ------------------- uri> >matt> > ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 uri> >Failed: 0) uri> >matt> > Non-zero exit status: 255 uri> >matt> > Parse errors: Bad plan. You planned 1 tests but ran 0. uri> >matt> > ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 uri> >Failed: 0) uri> >matt> > Non-zero exit status: 255 uri> >matt> > Parse errors: Bad plan. You planned 5 tests but ran 0. uri> >matt> > ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 uri> >Failed: 0) uri> >matt> > Non-zero exit status: 255 uri> >matt> > Parse errors: Bad plan. You planned 2 tests but ran 0. uri> >matt> > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 uri> >Failed: 1) uri> >matt> > Failed test: 4 uri> >matt> > Non-zero exit status: 1 uri> >matt> > Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys + uri> >18.40 cusr uri> >matt> > 8.32 csys = 27.09 CPU) uri> >matt> > Result: FAIL uri> >matt> > Failed 4/63 test programs. 1/324 subtests failed. uri> >matt> > make[1]: *** [tests] Error 255 uri> >matt> > make[1]: Leaving directory `/media/uri/Src/openssl/test' uri> >matt> > make: *** [tests] Error 2 uri> >matt> > $ gcc -v uri> >matt> > Using built-in specs. uri> >matt> > COLLECT_GCC=gcc uri> >matt> > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper uri> >matt> > Target: x86_64-linux-gnu uri> >matt> > Configured with: ../src/configure -v --with-pkgversion='Ubuntu uri> >matt> > 4.8.4-2ubuntu1~14.04' uri> >matt> > --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs uri> >matt> > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ uri> >--prefix=/usr uri> >matt> > --program-suffix=-4.8 --enable-shared --enable-linker-build-id uri> >matt> > --libexecdir=/usr/lib --without-included-gettext uri> >--enable-threads=posix uri> >matt> > --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib uri> >matt> > --enable-nls --with-sysroot=/ --enable-clocale=gnu uri> >matt> > --enable-libstdcxx-debug --enable-libstdcxx-time=yes uri> >matt> > --enable-gnu-unique-object --disable-libmudflap --enable-plugin uri> >matt> > --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk uri> >matt> > --enable-gtk-cairo uri> >matt> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre uri> >matt> > --enable-java-home uri> >matt> > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 uri> >matt> > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 uri> >matt> > --with-arch-directory=amd64 uri> >matt> > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc uri> >matt> > --enable-multiarch --disable-werror --with-arch-32=i686 uri> >--with-abi=m64 uri> >matt> > --with-multilib-list=m32,m64,mx32 --with-tune=generic uri> >matt> > --enable-checking=release --build=x86_64-linux-gnu uri> >matt> > --host=x86_64-linux-gnu --target=x86_64-linux-gnu uri> >matt> > Thread model: posix uri> >matt> > gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) uri> >matt> > -- uri> >matt> > Regards, uri> >matt> > Uri Blumenthal uri> >matt> > uri> >matt> > uri> >matt> > _______________________________________________ uri> >matt> > openssl-dev mailing list uri> >matt> > To unsubscribe: uri> >https://mta.openssl.org/mailman/listinfo/openssl-dev uri> >matt> > uri> >matt> _______________________________________________ uri> >matt> openssl-dev mailing list uri> >matt> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From uri at ll.mit.edu Fri Sep 18 19:23:09 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Sep 2015 19:23:09 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150918.211500.152048296829238565.richard@levitte.org> References: <55FB36B5.40105@openssl.org> <20150918.082741.828773768499895038.richard@levitte.org> <20150918.211500.152048296829238565.richard@levitte.org> Message-ID: On 9/18/15, 15:15 , "Richard Levitte" wrote: >Did you apply the full patch? The was a part for >test/recipes/70-test_sslextension.t that should have had it generate >debugging output... Yes I?m sure I did. And I?m as surprised as you are to not see the expected output from at least ?Message.pm?? In message on Fri, 18 Sep 2015 16:18:53 +0000, "Blumenthal, Uri - 0553 - MITLL" said: >uri> Richard, >uri> >uri> Thank you for your help! Unfortunately, the problem persists: >uri> >uri> testing... >uri> make[1]: Entering directory `/media/uri/Src/openssl/test' >uri> make[2]: Entering directory `/media/uri/Src/openssl' >uri> making all in apps... >uri> make[3]: Entering directory `/media/uri/Src/openssl/apps' >uri> make[3]: Nothing to be done for `all'. >uri> make[3]: Leaving directory `/media/uri/Src/openssl/apps' >uri> make[2]: Leaving directory `/media/uri/Src/openssl' >uri> TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests >uri> ../test/recipes/00-check_testexes.t ....... ok >uri> ../test/recipes/05-test_bf.t .............. ok >uri> ../test/recipes/05-test_cast.t ............ ok >uri> ../test/recipes/05-test_des.t ............. ok >uri> ../test/recipes/05-test_hmac.t ............ ok >uri> ../test/recipes/05-test_idea.t ............ ok >uri> ../test/recipes/05-test_md2.t ............. ok >uri> ../test/recipes/05-test_md4.t ............. ok >uri> ../test/recipes/05-test_md5.t ............. ok >uri> ../test/recipes/05-test_mdc2.t ............ ok >uri> ../test/recipes/05-test_rand.t ............ ok >uri> ../test/recipes/05-test_rc2.t ............. ok >uri> ../test/recipes/05-test_rc4.t ............. ok >uri> ../test/recipes/05-test_rc5.t ............. ok >uri> ../test/recipes/05-test_rmd.t ............. ok >uri> ../test/recipes/05-test_sha1.t ............ ok >uri> ../test/recipes/05-test_sha256.t .......... ok >uri> ../test/recipes/05-test_sha512.t .......... ok >uri> ../test/recipes/05-test_wp.t .............. ok >uri> ../test/recipes/10-test_bn.t .............. ok >uri> ../test/recipes/10-test_exp.t ............. ok >uri> ../test/recipes/15-test_dh.t .............. ok >uri> ../test/recipes/15-test_dsa.t ............. ok >uri> ../test/recipes/15-test_ec.t .............. ok >uri> ../test/recipes/15-test_ecdh.t ............ ok >uri> ../test/recipes/15-test_ecdsa.t ........... ok >uri> ../test/recipes/15-test_rsa.t ............. ok >uri> ../test/recipes/20-test_enc.t ............. ok >uri> ../test/recipes/25-test_crl.t ............. ok >uri> ../test/recipes/25-test_gen.t ............. ok >uri> ../test/recipes/25-test_pkcs7.t ........... ok >uri> ../test/recipes/25-test_req.t ............. ok >uri> ../test/recipes/25-test_sid.t ............. ok >uri> ../test/recipes/25-test_verify.t .......... ok >uri> ../test/recipes/25-test_x509.t ............ ok >uri> ../test/recipes/30-test_engine.t .......... ok >uri> ../test/recipes/30-test_evp.t ............. ok >uri> ../test/recipes/30-test_evp_extra.t ....... ok >uri> ../test/recipes/30-test_pbelu.t ........... ok >uri> ../test/recipes/40-test_rehash.t .......... ok >uri> ../test/recipes/70-test_clienthello.t ..... ok >uri> ../test/recipes/70-test_packet.t .......... ok >uri> Use of uninitialized value within %message_type in concatenation (.) >or >uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> Changed peer, but we still have fragment data >uri> # Looks like your test exited with 255 before it could output >anything. >uri> ../test/recipes/70-test_sslextension.t .... >uri> Dubious, test returned 255 (wstat 65280, 0xff00) >uri> Failed 1/1 subtests >uri> Use of uninitialized value within %message_type in concatenation (.) >or >uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> Changed peer, but we still have fragment data >uri> # Looks like your test exited with 255 before it could output >anything. >uri> ../test/recipes/70-test_sslsessiontick.t .. >uri> Dubious, test returned 255 (wstat 65280, 0xff00) >uri> Failed 5/5 subtests >uri> ../test/recipes/70-test_sslskewith0p.t .... ok >uri> Use of uninitialized value within %message_type in concatenation (.) >or >uri> string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> Changed peer, but we still have fragment data >uri> # Looks like your test exited with 255 before it could output >anything. >uri> ../test/recipes/70-test_sslvertol.t ....... >uri> Dubious, test returned 255 (wstat 65280, 0xff00) >uri> Failed 2/2 subtests >uri> ../test/recipes/70-test_verify_extra.t .... ok >uri> ../test/recipes/80-test_ca.t .............. ok >uri> # Looks like you planned 11 tests but ran 20. >uri> >uri> # Failed test 'CMS <=> CMS consistency tests, modified key >parameters >uri> # ' >uri> # at ../test/recipes/80-test_cms.t line 460. >uri> # Looks like you failed 1 test of 4. >uri> ../test/recipes/80-test_cms.t ............. >uri> Dubious, test returned 1 (wstat 256, 0x100) >uri> Failed 1/4 subtests >uri> ../test/recipes/80-test_ocsp.t ............ ok >uri> ../test/recipes/80-test_ssl.t ............. ok >uri> ../test/recipes/80-test_tsa.t ............. ok >uri> ../test/recipes/90-test_constant_time.t ... ok >uri> ../test/recipes/90-test_gmdiff.t .......... ok >uri> ../test/recipes/90-test_gost2814789.t ..... ok >uri> ../test/recipes/90-test_heartbeat.t ....... ok >uri> ../test/recipes/90-test_ige.t ............. ok >uri> ../test/recipes/90-test_jpake.t ........... ok >uri> ../test/recipes/90-test_np.t .............. ok >uri> ../test/recipes/90-test_p5_crpt2.t ........ ok >uri> ../test/recipes/90-test_secmem.t .......... ok >uri> ../test/recipes/90-test_srp.t ............. ok >uri> ../test/recipes/90-test_v3name.t .......... ok >uri> >uri> Test Summary Report >uri> ------------------- >uri> ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 >Failed: 0) >uri> Non-zero exit status: 255 >uri> Parse errors: Bad plan. You planned 1 tests but ran 0. >uri> ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 >Failed: 0) >uri> Non-zero exit status: 255 >uri> Parse errors: Bad plan. You planned 5 tests but ran 0. >uri> ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 >Failed: 0) >uri> Non-zero exit status: 255 >uri> Parse errors: Bad plan. You planned 2 tests but ran 0. >uri> ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: >1) >uri> Failed test: 4 >uri> Non-zero exit status: 1 >uri> Files=63, Tests=324, 30 wallclock secs ( 0.31 usr 0.08 sys + 19.13 >cusr >uri> 8.61 csys = 28.13 CPU) >uri> Result: FAIL >uri> Failed 4/63 test programs. 1/324 subtests failed. >uri> make[1]: *** [tests] Error 255 >uri> make[1]: Leaving directory `/media/uri/Src/openssl/test' >uri> make: *** [tests] Error 2 >uri> >uri> >uri> >uri> What can we (I :) do to either remedy it, or provide you more info >to find >uri> the cause? >uri> -- >uri> Regards, >uri> Uri Blumenthal >uri> >uri> >uri> >uri> >uri> >uri> On 9/18/15, 2:27 , "Richard Levitte" wrote: >uri> >uri> >I can't reproduce it either, but judging from the line number, it >uri> >looks like a surprise unknown message type. Uri, the attached patch >uri> >and the following command line might help clear this up: >uri> > >uri> > HARNESS_VERBOSE=yes make TESTS=test_sslextension test >uri> > >uri> >Cheers, >uri> >Richard >uri> > >uri> >In message <55FB36B5.40105 at openssl.org> on Thu, 17 Sep 2015 22:55:01 >uri> >+0100, Matt Caswell said: >uri> > >uri> >matt> Hmmm. I cannot reproduce this. Is anyone else seeing this? >uri> >matt> >uri> >matt> Matt >uri> >matt> >uri> >matt> On 17/09/15 20:15, Blumenthal, Uri - 0553 - MITLL wrote: >uri> >matt> > $ apps/openssl$ openssl version >uri> >matt> > OpenSSL 1.1.0-dev xx XXX xxxx >uri> >matt> > $ make test >uri> >matt> > testing... >uri> >matt> > make[1]: Entering directory `/media/uri/Src/openssl/test' >uri> >matt> > make[2]: Entering directory `/media/uri/Src/openssl' >uri> >matt> > making all in apps... >uri> >matt> > make[3]: Entering directory `/media/uri/Src/openssl/apps' >uri> >matt> > make[3]: Nothing to be done for `all'. >uri> >matt> > make[3]: Leaving directory `/media/uri/Src/openssl/apps' >uri> >matt> > make[2]: Leaving directory `/media/uri/Src/openssl' >uri> >matt> > TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl >alltests >uri> >matt> > ../test/recipes/00-check_testexes.t ....... ok >uri> >matt> > ../test/recipes/05-test_bf.t .............. ok >uri> >matt> > ../test/recipes/05-test_cast.t ............ ok >uri> >matt> > ../test/recipes/05-test_des.t ............. ok >uri> >matt> > ../test/recipes/05-test_hmac.t ............ ok >uri> >matt> > ../test/recipes/05-test_idea.t ............ ok >uri> >matt> > ../test/recipes/05-test_md2.t ............. ok >uri> >matt> > ../test/recipes/05-test_md4.t ............. ok >uri> >matt> > ../test/recipes/05-test_md5.t ............. ok >uri> >matt> > ../test/recipes/05-test_mdc2.t ............ ok >uri> >matt> > ../test/recipes/05-test_rand.t ............ ok >uri> >matt> > ../test/recipes/05-test_rc2.t ............. ok >uri> >matt> > ../test/recipes/05-test_rc4.t ............. ok >uri> >matt> > ../test/recipes/05-test_rc5.t ............. ok >uri> >matt> > ../test/recipes/05-test_rmd.t ............. ok >uri> >matt> > ../test/recipes/05-test_sha1.t ............ ok >uri> >matt> > ../test/recipes/05-test_sha256.t .......... ok >uri> >matt> > ../test/recipes/05-test_sha512.t .......... ok >uri> >matt> > ../test/recipes/05-test_wp.t .............. ok >uri> >matt> > ../test/recipes/10-test_bn.t .............. ok >uri> >matt> > ../test/recipes/10-test_exp.t ............. ok >uri> >matt> > ../test/recipes/15-test_dh.t .............. ok >uri> >matt> > ../test/recipes/15-test_dsa.t ............. ok >uri> >matt> > ../test/recipes/15-test_ec.t .............. ok >uri> >matt> > ../test/recipes/15-test_ecdh.t ............ ok >uri> >matt> > ../test/recipes/15-test_ecdsa.t ........... ok >uri> >matt> > ../test/recipes/15-test_rsa.t ............. ok >uri> >matt> > ../test/recipes/20-test_enc.t ............. ok >uri> >matt> > ../test/recipes/25-test_crl.t ............. ok >uri> >matt> > ../test/recipes/25-test_gen.t ............. ok >uri> >matt> > ../test/recipes/25-test_pkcs7.t ........... ok >uri> >matt> > ../test/recipes/25-test_req.t ............. ok >uri> >matt> > ../test/recipes/25-test_sid.t ............. ok >uri> >matt> > ../test/recipes/25-test_verify.t .......... ok >uri> >matt> > ../test/recipes/25-test_x509.t ............ ok >uri> >matt> > ../test/recipes/30-test_engine.t .......... ok >uri> >matt> > ../test/recipes/30-test_evp.t ............. ok >uri> >matt> > ../test/recipes/30-test_evp_extra.t ....... ok >uri> >matt> > ../test/recipes/30-test_pbelu.t ........... ok >uri> >matt> > ../test/recipes/40-test_rehash.t .......... ok >uri> >matt> > ../test/recipes/70-test_clienthello.t ..... ok >uri> >matt> > ../test/recipes/70-test_packet.t .......... ok >uri> >matt> > Use of uninitialized value within %message_type in >concatenation >uri> >(.) or >uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> >matt> > Changed peer, but we still have fragment data >uri> >matt> > # Looks like your test exited with 255 before it could >output >uri> >anything. >uri> >matt> > ../test/recipes/70-test_sslextension.t .... >uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >uri> >matt> > Failed 1/1 subtests >uri> >matt> > Use of uninitialized value within %message_type in >concatenation >uri> >(.) or >uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> >matt> > Changed peer, but we still have fragment data >uri> >matt> > # Looks like your test exited with 255 before it could >output >uri> >anything. >uri> >matt> > ../test/recipes/70-test_sslsessiontick.t .. >uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >uri> >matt> > Failed 5/5 subtests >uri> >matt> > ../test/recipes/70-test_sslskewith0p.t .... ok >uri> >matt> > Use of uninitialized value within %message_type in >concatenation >uri> >(.) or >uri> >matt> > string at ../util/TLSProxy/Message.pm line 202, <> line 751. >uri> >matt> > Changed peer, but we still have fragment data >uri> >matt> > # Looks like your test exited with 255 before it could >output >uri> >anything. >uri> >matt> > ../test/recipes/70-test_sslvertol.t ....... >uri> >matt> > Dubious, test returned 255 (wstat 65280, 0xff00) >uri> >matt> > Failed 2/2 subtests >uri> >matt> > ../test/recipes/70-test_verify_extra.t .... ok >uri> >matt> > ../test/recipes/80-test_ca.t .............. ok >uri> >matt> > # Looks like you planned 11 tests but ran 20. >uri> >matt> > >uri> >matt> > # Failed test 'CMS <=> CMS consistency tests, modified key >uri> >parameters >uri> >matt> > # ' >uri> >matt> > # at ../test/recipes/80-test_cms.t line 460. >uri> >matt> > # Looks like you failed 1 test of 4. >uri> >matt> > ../test/recipes/80-test_cms.t ............. >uri> >matt> > Dubious, test returned 1 (wstat 256, 0x100) >uri> >matt> > Failed 1/4 subtests >uri> >matt> > ../test/recipes/80-test_ocsp.t ............ ok >uri> >matt> > ../test/recipes/80-test_ssl.t ............. ok >uri> >matt> > ../test/recipes/80-test_tsa.t ............. ok >uri> >matt> > ../test/recipes/90-test_constant_time.t ... ok >uri> >matt> > ../test/recipes/90-test_gmdiff.t .......... ok >uri> >matt> > ../test/recipes/90-test_gost2814789.t ..... ok >uri> >matt> > ../test/recipes/90-test_heartbeat.t ....... ok >uri> >matt> > ../test/recipes/90-test_ige.t ............. ok >uri> >matt> > ../test/recipes/90-test_jpake.t ........... ok >uri> >matt> > ../test/recipes/90-test_np.t .............. ok >uri> >matt> > ../test/recipes/90-test_p5_crpt2.t ........ ok >uri> >matt> > ../test/recipes/90-test_secmem.t .......... ok >uri> >matt> > ../test/recipes/90-test_srp.t ............. ok >uri> >matt> > ../test/recipes/90-test_v3name.t .......... ok >uri> >matt> > >uri> >matt> > Test Summary Report >uri> >matt> > ------------------- >uri> >matt> > ../test/recipes/70-test_sslextension.t (Wstat: 65280 >Tests: 0 >uri> >Failed: 0) >uri> >matt> > Non-zero exit status: 255 >uri> >matt> > Parse errors: Bad plan. You planned 1 tests but ran 0. >uri> >matt> > ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 >Tests: 0 >uri> >Failed: 0) >uri> >matt> > Non-zero exit status: 255 >uri> >matt> > Parse errors: Bad plan. You planned 5 tests but ran 0. >uri> >matt> > ../test/recipes/70-test_sslvertol.t (Wstat: 65280 >Tests: 0 >uri> >Failed: 0) >uri> >matt> > Non-zero exit status: 255 >uri> >matt> > Parse errors: Bad plan. You planned 2 tests but ran 0. >uri> >matt> > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 >uri> >Failed: 1) >uri> >matt> > Failed test: 4 >uri> >matt> > Non-zero exit status: 1 >uri> >matt> > Files=63, Tests=324, 27 wallclock secs ( 0.32 usr 0.05 sys >+ >uri> >18.40 cusr >uri> >matt> > 8.32 csys = 27.09 CPU) >uri> >matt> > Result: FAIL >uri> >matt> > Failed 4/63 test programs. 1/324 subtests failed. >uri> >matt> > make[1]: *** [tests] Error 255 >uri> >matt> > make[1]: Leaving directory `/media/uri/Src/openssl/test' >uri> >matt> > make: *** [tests] Error 2 >uri> >matt> > $ gcc -v >uri> >matt> > Using built-in specs. >uri> >matt> > COLLECT_GCC=gcc >uri> >matt> > >COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper >uri> >matt> > Target: x86_64-linux-gnu >uri> >matt> > Configured with: ../src/configure -v >--with-pkgversion='Ubuntu >uri> >matt> > 4.8.4-2ubuntu1~14.04' >uri> >matt> > --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs >uri> >matt> > --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ >uri> >--prefix=/usr >uri> >matt> > --program-suffix=-4.8 --enable-shared >--enable-linker-build-id >uri> >matt> > --libexecdir=/usr/lib --without-included-gettext >uri> >--enable-threads=posix >uri> >matt> > --with-gxx-include-dir=/usr/include/c++/4.8 >--libdir=/usr/lib >uri> >matt> > --enable-nls --with-sysroot=/ --enable-clocale=gnu >uri> >matt> > --enable-libstdcxx-debug --enable-libstdcxx-time=yes >uri> >matt> > --enable-gnu-unique-object --disable-libmudflap >--enable-plugin >uri> >matt> > --with-system-zlib --disable-browser-plugin >--enable-java-awt=gtk >uri> >matt> > --enable-gtk-cairo >uri> >matt> > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre >uri> >matt> > --enable-java-home >uri> >matt> > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 >uri> >matt> > >--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 >uri> >matt> > --with-arch-directory=amd64 >uri> >matt> > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar >--enable-objc-gc >uri> >matt> > --enable-multiarch --disable-werror --with-arch-32=i686 >uri> >--with-abi=m64 >uri> >matt> > --with-multilib-list=m32,m64,mx32 --with-tune=generic >uri> >matt> > --enable-checking=release --build=x86_64-linux-gnu >uri> >matt> > --host=x86_64-linux-gnu --target=x86_64-linux-gnu >uri> >matt> > Thread model: posix >uri> >matt> > gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) >uri> >matt> > -- >uri> >matt> > Regards, >uri> >matt> > Uri Blumenthal >uri> >matt> > >uri> >matt> > >uri> >matt> > _______________________________________________ >uri> >matt> > openssl-dev mailing list >uri> >matt> > To unsubscribe: >uri> >https://mta.openssl.org/mailman/listinfo/openssl-dev >uri> >matt> > >uri> >matt> _______________________________________________ >uri> >matt> openssl-dev mailing list >uri> >matt> To unsubscribe: >https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rt at openssl.org Fri Sep 18 19:26:53 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 18 Sep 2015 19:26:53 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: > YES! It's a one user box that I regularly update and install on, so rarely run as > reduced/un-privileged user. > > If I switch to non-root, this passes. Glad we got it figured out. Perhaps we can add a warning to the test (running as root, expect to fail) or some such. From rt at openssl.org Fri Sep 18 19:31:05 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 18 Sep 2015 19:31:05 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: Vid Fre, 18 Sep 2015 kl. 19.07.55, skrev yancm at SDF.ORG: > >>Ok, I'm having trouble reproducing.... > [...] > >>that should print an error message and the echo of $? > >>should print 1. I cannot understand why that fails for you... > > > > Maybe running test as root ? > > YES! It's a one user box that I regularly update and install on, > so rarely run as reduced/un-privileged user. > > If I switch to non-root, this passes. > > Sorry to take your bandwidth. > > --gene > No problem. This will happen again, so I've prepared a commit that has test_rehash compalain loudly if being run as root. Will show up in not too long. -- Richard Levitte levitte at openssl.org From rt at openssl.org Fri Sep 18 19:34:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 18 Sep 2015 19:34:34 +0000 Subject: [openssl-dev] [openssl.org #4033] Unable to build openssl git master branch on NetBSD for > 24 hours In-Reply-To: References: Message-ID: Vid Fre, 18 Sep 2015 kl. 19.31.05, skrev levitte: > Vid Fre, 18 Sep 2015 kl. 19.07.55, skrev yancm at SDF.ORG: > > >>Ok, I'm having trouble reproducing.... > > [...] > > >>that should print an error message and the echo of $? > > >>should print 1. I cannot understand why that fails for you... > > > > > > Maybe running test as root ? > > > > YES! It's a one user box that I regularly update and install on, > > so rarely run as reduced/un-privileged user. > > > > If I switch to non-root, this passes. > > > > Sorry to take your bandwidth. > > > > --gene > > > > No problem. This will happen again, so I've prepared a commit that has > test_rehash compalain loudly if being run as root. Will show up in not too > long. > > -- > Richard Levitte > levitte at openssl.org Commit pushed, e008d1b2672f0ab6d64ab1afd20a903678bd8ed2 -- Richard Levitte levitte at openssl.org From richard at levitte.org Fri Sep 18 19:46:47 2015 From: richard at levitte.org (Richard Levitte) Date: Fri, 18 Sep 2015 21:46:47 +0200 (CEST) Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: References: <20150918.211500.152048296829238565.richard@levitte.org> Message-ID: <20150918.214647.1814237996141076555.richard@levitte.org> In message on Fri, 18 Sep 2015 19:23:09 +0000, "Blumenthal, Uri - 0553 - MITLL" said: uri> On 9/18/15, 15:15 , "Richard Levitte" wrote: uri> uri> >Did you apply the full patch? The was a part for uri> >test/recipes/70-test_sslextension.t that should have had it generate uri> >debugging output... uri> uri> Yes I?m sure I did. And I?m as surprised as you are to not see the uri> expected output from at least ?Message.pm?? You can look for yourself, $proxy should be assigned like this: my $proxy = TLSProxy::Proxy->new( \&extension_filter, cmdstr(app(["openssl"])), top_file("apps", "server.pem"), 1 # <========= This is what turns on the debugging output ); -- Richard Levitte richard at levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish From uri at ll.mit.edu Fri Sep 18 19:53:15 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Sep 2015 19:53:15 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150918.214647.1814237996141076555.richard@levitte.org> References: <20150918.211500.152048296829238565.richard@levitte.org> <20150918.214647.1814237996141076555.richard@levitte.org> Message-ID: Yes, it certainly is: ... $ENV{OPENSSL_ENGINES} = top_dir("engines"); $ENV{OPENSSL_ia32cap} = '~0x200000200000000'; my $proxy = TLSProxy::Proxy->new( \&extension_filter, cmdstr(app(["openssl"])), top_file("apps", "server.pem"), 1 ); plan tests => 1; ... -- Regards, Uri Blumenthal On 9/18/15, 15:46 , "Richard Levitte" wrote: >In message on Fri, 18 Sep 2015 19:23:09 >+0000, "Blumenthal, Uri - 0553 - MITLL" said: > >uri> On 9/18/15, 15:15 , "Richard Levitte" wrote: >uri> >uri> >Did you apply the full patch? The was a part for >uri> >test/recipes/70-test_sslextension.t that should have had it generate >uri> >debugging output... >uri> >uri> Yes I?m sure I did. And I?m as surprised as you are to not see the >uri> expected output from at least ?Message.pm?? > >You can look for yourself, $proxy should be assigned like this: > >my $proxy = TLSProxy::Proxy->new( > \&extension_filter, > cmdstr(app(["openssl"])), > top_file("apps", "server.pem"), > 1 # <========= This is what turns on the debugging output >); > >-- >Richard Levitte richard at levitte.org > http://richard.levitte.org/ > >"Life is a tremendous celebration - and I'm invited!" >-- from a friend's blog, translated from Swedish -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From matt at openssl.org Fri Sep 18 19:54:35 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2015 20:54:35 +0100 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150918.214647.1814237996141076555.richard@levitte.org> References: <20150918.211500.152048296829238565.richard@levitte.org> <20150918.214647.1814237996141076555.richard@levitte.org> Message-ID: <55FC6BFB.9060107@openssl.org> On 18/09/15 20:46, Richard Levitte wrote: > In message on Fri, 18 Sep 2015 19:23:09 +0000, "Blumenthal, Uri - 0553 - MITLL" said: > > uri> On 9/18/15, 15:15 , "Richard Levitte" wrote: > uri> > uri> >Did you apply the full patch? The was a part for > uri> >test/recipes/70-test_sslextension.t that should have had it generate > uri> >debugging output... > uri> > uri> Yes I?m sure I did. And I?m as surprised as you are to not see the > uri> expected output from at least ?Message.pm?? > > You can look for yourself, $proxy should be assigned like this: > > my $proxy = TLSProxy::Proxy->new( > \&extension_filter, > cmdstr(app(["openssl"])), > top_file("apps", "server.pem"), > 1 # <========= This is what turns on the debugging output > ); > I encountered a problem with this the other day. Something in the translation to the new test framework has borked debugging output. It only seems to have affected stdout. I had to additionally add this after the above line: open(STDOUT, ">&STDERR"); Matt From uri at ll.mit.edu Fri Sep 18 20:24:19 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Sep 2015 20:24:19 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <55FC6BFB.9060107@openssl.org> References: <20150918.211500.152048296829238565.richard@levitte.org> <20150918.214647.1814237996141076555.richard@levitte.org> <55FC6BFB.9060107@openssl.org> Message-ID: On 9/18/15, 15:54 , "Matt Caswell" wrote: >>You can look for yourself, $proxy should be assigned like this: >> >> my $proxy = TLSProxy::Proxy->new( >> \&extension_filter, >> cmdstr(app(["openssl"])), >> top_file("apps", "server.pem"), >> 1 # <========= This is what turns on the debugging output >> ); >> > >I encountered a problem with this the other day. Something in the >translation to the new test framework has borked debugging output. It >only seems to have affected stdout. > >I had to additionally add this after the above line: >open(STDOUT, ">&STDERR"); Yes! Adding this line got the debugging output. Log file is attached, and appended here (?About to run unpack()...? is my print/addition): testing... make[1]: Entering directory `/media/uri/Src/openssl/test' make[2]: Entering directory `/media/uri/Src/openssl' making all in apps... make[3]: Entering directory `/media/uri/Src/openssl/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/media/uri/Src/openssl/apps' make[2]: Leaving directory `/media/uri/Src/openssl' TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. ok ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok Proxy started on port 4453 Connection opened Received client packet Packet length = 374 Processing flight 0 Record 1 (client -> server) Content type: HANDSHAKE Version: TLS1.0 Length: 369 About to run unpack()... Message length: 365 Message type: ClientHello (1) Message Length: 365 Client Version:771 Session ID Len:0 Ciphersuite len:230 Compression Method Len:2 Extensions Len:93 Forwarded packet length = 281 Received server packet Packet length = 1113 Processing flight 1 Record 1 (server -> client) Content type: HANDSHAKE Version: TLS1.2 Length: 81 About to run unpack()... Message length: 77 Message type: ServerHello (2) Message Length: 77 Server Version:771 Session ID Len:32 Ciphersuite:47 Compression Method:1 Extensions Len:5 Record 2 (server -> client) Content type: HANDSHAKE Version: TLS1.2 Length: 1013 About to run unpack()... Message length: 1009 Message type: Certificate (11) Message Length: 1009 Record 3 (server -> client) Content type: HANDSHAKE Version: TLS1.2 Length: 4 About to run unpack()... Message length: 0 Message type: ServerHelloDone (14) Message Length: 0 Forwarded packet length = 1113 Received client packet Packet length = 342 Processing flight 2 Record 1 (client -> server) Content type: HANDSHAKE Version: TLS1.2 Length: 262 About to run unpack()... Message length: 258 Message type: ClientKeyExchange (16) Message Length: 258 Record 2 (client -> server) Content type: CCS Version: TLS1.2 Length: 1 Record 3 (client -> server) Content type: HANDSHAKE Version: TLS1.2 Length: 64 About to run unpack()... Message length: 10228321 Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 204, <> line 751. Message type: (120) Message Length: 10228321 Forwarded packet length = 342 Received server packet Packet length = 75 Processing flight 3 Record 1 (server -> client) Content type: CCS Version: TLS1.2 Length: 1 Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslextension.t .... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/1 subtests Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 204, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslsessiontick.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 5/5 subtests ../test/recipes/70-test_sslskewith0p.t .... ok Use of uninitialized value within %message_type in concatenation (.) or string at ../util/TLSProxy/Message.pm line 204, <> line 751. Changed peer, but we still have fragment data # Looks like your test exited with 255 before it could output anything. ../test/recipes/70-test_sslvertol.t ....... Dubious, test returned 255 (wstat 65280, 0xff00) Failed 2/2 subtests ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok # Looks like you planned 11 tests but ran 20. # Failed test 'CMS <=> CMS consistency tests, modified key parameters # ' # at ../test/recipes/80-test_cms.t line 460. # Looks like you failed 1 test of 4. ../test/recipes/80-test_cms.t ............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_gost2814789.t ..... ok ../test/recipes/90-test_heartbeat.t ....... ok ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok Test Summary Report ------------------- ../test/recipes/70-test_sslextension.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 1 tests but ran 0. ../test/recipes/70-test_sslsessiontick.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 5 tests but ran 0. ../test/recipes/70-test_sslvertol.t (Wstat: 65280 Tests: 0 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 2 tests but ran 0. ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=63, Tests=324, 26 wallclock secs ( 0.33 usr 0.03 sys + 18.44 cusr 8.46 csys = 27.26 CPU) Result: FAIL Failed 4/63 test programs. 1/324 subtests failed. make[1]: *** [tests] Error 255 make[1]: Leaving directory `/media/uri/Src/openssl/test' make: *** [tests] Error 2 Thanks! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: make-test-out.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From matt at openssl.org Fri Sep 18 22:00:57 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2015 23:00:57 +0100 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: References: <20150918.211500.152048296829238565.richard@levitte.org> <20150918.214647.1814237996141076555.richard@levitte.org> <55FC6BFB.9060107@openssl.org> Message-ID: <55FC8999.1050405@openssl.org> On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote: > On 9/18/15, 15:54 , "Matt Caswell" wrote: > Received server packet > Packet length = 1113 > Processing flight 1 > Record 1 (server -> client) > Content type: HANDSHAKE > Version: TLS1.2 > Length: 81 > About to run unpack()... > Message length: 77 > Message type: ServerHello (2) > Message Length: 77 > Server Version:771 > Session ID Len:32 > Ciphersuite:47 > Compression Method:1 You have compiled in compression support? Can you try it without? Thanks Matt From uri at ll.mit.edu Fri Sep 18 22:23:16 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 18 Sep 2015 22:23:16 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP Message-ID: <20150918222301.17789008.35794.23896@ll.mit.edu> I compiled with ? ./config threads shared zlib Should I drop zlib and try again...? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Matt Caswell Sent: Friday, September 18, 2015 18:01 To: Blumenthal, Uri - 0553 - MITLL; Richard Levitte Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] Some tests fail on the current/latest SNAP On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote: > On 9/18/15, 15:54 , "Matt Caswell" wrote: > Received server packet > Packet length = 1113 > Processing flight 1 > Record 1 (server -> client) > Content type: HANDSHAKE > Version: TLS1.2 > Length: 81 > About to run unpack()... > Message length: 77 > Message type: ServerHello (2) > Message Length: 77 > Server Version:771 > Session ID Len:32 > Ciphersuite:47 > Compression Method:1 You have compiled in compression support? Can you try it without? Thanks Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From matt at openssl.org Fri Sep 18 22:32:11 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Sep 2015 23:32:11 +0100 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150918222301.17789008.35794.23896@ll.mit.edu> References: <20150918222301.17789008.35794.23896@ll.mit.edu> Message-ID: <55FC90EB.2050605@openssl.org> On 18/09/15 23:23, Blumenthal, Uri - 0553 - MITLL wrote: > I compiled with > > ./config threads shared zlib > > Should I drop zlib and try again...? Yes please. Thanks Matt From rt at openssl.org Sat Sep 19 09:01:30 2015 From: rt at openssl.org (=?UTF-8?B?S2ltIEdyw6RzbWFu?= via RT) Date: Sat, 19 Sep 2015 09:01:30 +0000 Subject: [openssl-dev] [openssl.org #4010] AutoReply: [PATCH] Fix #include order in rand.h for Windows In-Reply-To: References: Message-ID: Ping? - Kim On Tue, Aug 18, 2015 at 4:16 PM, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "[PATCH] Fix #include order in rand.h for Windows", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4010]. > > Please include the string: > > [openssl.org #4010] > > 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 > > ------------------------------------------------------------------------- > Hi all, > > When using OpenSSL on Windows, we've seen compiler errors when we > #include after and then attempting > to use X509_NAME in our code. > > This is because engine.h pulls in rand.h, which in turn includes > windows.h. The Windows headers introduce conflicting #defines for > X509_NAME (among other names). Most of the OpenSSL headers counteract > this by #undef-ing the conflicting names. However, rand.h includes > windows.h *after* ossl_types.h, so Windows re-#defines the symbols and > wins again. > > The attached patch switches include order around so that ossl_types.h > is included after windows.h, and thereby fixing the namespace up > again. > > I've built on Windows and Linux and everything still appears to work. > > Please let me know if this is applicable to mainline OpenSSL. > > Thanks, > - Kim > From rt at openssl.org Sat Sep 19 11:14:06 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 19 Sep 2015 11:14:06 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: On Tue Sep 15 14:33:33 2015, cberube at us.ibm.com wrote: > Hi, > > I'm trying to build the FIPS-140 compliant OpenSSL software on my > Windows 7 > system using the Visual Studio 2015 compiler. I am using OpenSSL-FIPS- > 2.0.10 > and OpenSSL-1.0.2d. I'm getting the following build error when trying > to build > the 32-bit version of the OpenSSL libraries: > > link /nologo /subsystem:console /opt:ref /debug /dll /fixed /map > /base:0xFB00000 > /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def > @C:\Users\username\AppData\Local > \Temp\nm8E.tmp > Creating library out32dll\libeay32.lib and object > out32dll\libeay32.exp > out32dll\fips_premain_dso.exe out32dll\libeay32.dll > OPENSSL_Uplink(01489000,08): no OPENSSL_Applink > Get hash failure at \usr\local\ssl\fips-2.0\bin\fipslink.pl line 60. > NMAKE : fatal error U1077: 'C:\Perl64\bin\perl.EXE' : return code > '0x1' > Stop. > > Here's how I went about building it: > > 0) Executed "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\vcvars32.bat" in a DOS command prompt window. > 1) Extracted the files for OpenSSL-FIPS-2.0.10 > 2) cd OpenSSL-FIPS-2.0.10 > 3) Perl Configure VC-WIN32 no-asm fipscheck no-idea no-mdc2 no-rc5 > 4) ms\do_ms > 5) nmake -f ms\ntdll.mak > 6) nmake -f ms\ntdll.mak install You cannot use custom commands when building the FIPS module or the result is not compliant. You have to do: ms\do_fips Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From vitus at wagner.pp.ru Sat Sep 19 18:17:13 2015 From: vitus at wagner.pp.ru (Victor Wagner) Date: Sat, 19 Sep 2015 21:17:13 +0300 Subject: [openssl-dev] Block cipher padding modes Message-ID: <20150919181712.GB23274@wagner.pp.ru> Hi, There are several standards which define padding for block ciphers. OpenSSL currently implements only PKCS#7 padding mode. For some reasons I need to use ISO/IEC 7816-4 padding, and hope to get this patch accepted into OpenSSL. Now we have EVP_CIPHER_CTX_set_padding function which accepts integer argument and with zero it disables padding and with non-sero enables it. Obvois idea for more flexible interface is to define some integer constants #define PADDING_PKCS7 1 #define PADDING_ISO7816 2 #define PADDING_ANSI_X_923 3 etc etc and make EVP_CIPHER_CTX_set_padding recognize this constants and complain about any other values. Default should be left PKCS7_PADDING I doubt that there is some code around there that would be broken by this interface change. But to maintain stricter backward compatibility it is possible to define EVP_CIPHER_CTX_set_padding_ex function, which would set padding mode according to this constants and leave EVP_CIPHER_CTX_set_padding with current semantics - set PCKS7 padding on any non-zero argument. Which interface is better? From matt at openssl.org Sat Sep 19 19:35:13 2015 From: matt at openssl.org (Matt Caswell) Date: Sat, 19 Sep 2015 20:35:13 +0100 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: References: <20150918.211500.152048296829238565.richard@levitte.org> <20150918.214647.1814237996141076555.richard@levitte.org> <55FC6BFB.9060107@openssl.org> Message-ID: <55FDB8F1.1000507@openssl.org> I've just pushed a partial fix for this issue. The TLS tests should now pass for you in the latest master version in git. The new TLS test proxy we are using does not support compression, but was failing to switch it off if OpenSSL is configured for it. However, this one is a different problem: On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote > # Looks like you planned 11 tests but ran 20. > > > # Failed test 'CMS <=> CMS consistency tests, modified key parameters > # ' > # at ../test/recipes/80-test_cms.t line 460. > # Looks like you failed 1 test of 4. > ../test/recipes/80-test_cms.t ............. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/4 subtests This also seems to be related to Configuring with zlib in some way. Matt From rt at openssl.org Sat Sep 19 19:56:46 2015 From: rt at openssl.org (Victor Wagner via RT) Date: Sat, 19 Sep 2015 19:56:46 +0000 Subject: [openssl-dev] [openssl.org #4054] [BUG] engine-provided ciphers are unavailable for command-line utility In-Reply-To: <20150919100907.GA4766@wagner.pp.ru> References: <20150919100907.GA4766@wagner.pp.ru> Message-ID: In the branches 1.0.0, 1.0.1 and 1.0.2 of OpenSSL, some command line commands which accepts cipher argument (at least enc, cms and smime) delays engine initialization until all the command-line options are parsed. Thus, if user specifies cipher, which is available only from engine, such as -gost89, these commands report "Unknown cipher" if appropriate engine is not specified in the configuration file. I.e. it is not possible to run openssl enc -engine gost -gost89 -e or openssl cms -engine gost -encrypt -gost89 while openssl dgst -engine gost -md_gost94 works just fine. Also, it is not possible to get list of ciphers including engine-provided ones, using openssl enc -engine gost -help, because help is printed inside option-parsing loop before engine is initialized. Problem is already fixed in the master branch, where option parsing is completely reworked. FIX is quite trivial for the branches mentioned above too. Just move call of setup_engine up into the option parsing loop. This would also minimize need of #ifndef OPENSSL_NO_ENGINE conditional, because all engine initialization would go into one place _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Sep 20 13:45:33 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sun, 20 Sep 2015 13:45:33 +0000 Subject: [openssl-dev] [openssl.org #3817] bug report, command line SRP In-Reply-To: References: Message-ID: Fixed now: the SRP logic was missing from -www so it didn't work properly. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From richard at levitte.org Sun Sep 20 18:09:31 2015 From: richard at levitte.org (Richard Levitte) Date: Sun, 20 Sep 2015 20:09:31 +0200 (CEST) Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <55FDB8F1.1000507@openssl.org> References: <55FC6BFB.9060107@openssl.org> <55FDB8F1.1000507@openssl.org> Message-ID: <20150920.200931.1392613791272118129.richard@levitte.org> In message <55FDB8F1.1000507 at openssl.org> on Sat, 19 Sep 2015 20:35:13 +0100, Matt Caswell said: matt> On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote matt> > # Looks like you planned 11 tests but ran 20. matt> > matt> > matt> > # Failed test 'CMS <=> CMS consistency tests, modified key parameters matt> > # ' matt> > # at ../test/recipes/80-test_cms.t line 460. matt> > # Looks like you failed 1 test of 4. matt> > ../test/recipes/80-test_cms.t ............. matt> > Dubious, test returned 1 (wstat 256, 0x100) matt> > Failed 1/4 subtests matt> matt> This also seems to be related to Configuring with zlib in some way. FYI, problem fixed. It was a typo in the compression test, so it used the wrong array of parameters when trying to perform them. However, when OpenSSL is configured without zlib, that test is skipped, so the fault went undetected for quite some time. -- Richard Levitte richard at levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish From phpdev at ehrhardt.nl Sun Sep 20 21:48:17 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Sun, 20 Sep 2015 23:48:17 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Sat, 19 Sep 2015 11:14:06 +0000): >You cannot use custom commands when building the FIPS module or the result is >not compliant. You have to do: > >ms\do_fips And then it fails on a missing applink in fips_premain_dso.exe. This is the solution, but it is not compliant either: https://github.com/Jan-E/openssl-fips/commits/master Jan From phpdev at ehrhardt.nl Sun Sep 20 22:01:49 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Mon, 21 Sep 2015 00:01:49 +0200 Subject: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module References: <8878620CF8603E45BB794422B7899E9E112DF77932@INBLRK77M1MSX.in002.siemens.net> <5593F0CA.7070803@openssl.com> <55CD86EA.8060707@ncp-e.com> <6ltrsadoqbcgggh7n6ifrq1sr227l7pm06@4ax.com> <55D10615.9040609@ncp-e.com> Message-ID: Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16 Aug 2015 23:52:21 +0200): > >Am 14.08.2015 um 16:22 schrieb Jan Ehrhardt: >> I guess there was a change from optional (in VC9/VC11) to required in >> VC14, but only for the 1.0.2 branch. The PHP devs were the first to >> notice and included applink.c in the VS2015/VC14 builds of PHP7. >> Apachelounge followed by including applink.c in the VS2015/VC14 builds >> of Apache 2.4.16. Then I tried to compile OpenSSL 1.0.2c + FIPS 2.0.9 >> with VC14 and ran into the error. >Thank you once more for the detailed reply. I applied your patches >provisorily before going on vacation last friday to keep the builds >going. After my vacation we will have to decide what to do about the >FIPS problem. Surely, your holiday must be over by now ;-) Jan From rt at openssl.org Sun Sep 20 22:51:21 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sun, 20 Sep 2015 22:51:21 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: On Sat Sep 19 11:14:06 2015, steve wrote: > On Tue Sep 15 14:33:33 2015, cberube at us.ibm.com wrote: > > Hi, > > > > I'm trying to build the FIPS-140 compliant OpenSSL software on my > > Windows 7 > > system using the Visual Studio 2015 compiler. I am using OpenSSL- > > FIPS- > > 2.0.10 > > and OpenSSL-1.0.2d. I'm getting the following build error when trying > > to build > > the 32-bit version of the OpenSSL libraries: > > In more detail I just tried a build from sources. I did this: set FIPSDIR=X:\some\for\fips\module\installation cd ms\do_fips cd perl Configure VC-WIN32 fips nmake -f ms\ntdll.mak With no problems. I'd suggest you try that as a starting point and let me know of any errors you get. You will need to install nasm for that to work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From bhat.jayalakshmi at gmail.com Mon Sep 21 04:38:56 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Mon, 21 Sep 2015 10:08:56 +0530 Subject: [openssl-dev] CBC mode does not seems to work in OpenSSL 1.0.2d Message-ID: Hi All, I have ported OpenSSL 1.0.2d on our product. After that CBC mode is not working. Handshakes are failing with bad mac alert failure. When I checked the code mac retrieved from ssl3_cbc_copy_mac does not match with the calculated mac. Any help on this is appreciated. Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Mon Sep 21 16:15:39 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 21 Sep 2015 16:15:39 +0000 Subject: [openssl-dev] Some tests fail on the current/latest SNAP In-Reply-To: <20150920.200931.1392613791272118129.richard@levitte.org> References: <55FC6BFB.9060107@openssl.org> <55FDB8F1.1000507@openssl.org> <20150920.200931.1392613791272118129.richard@levitte.org> Message-ID: Richard and Matt, Thank you very much for your help. I confirm that the problems disappeared, and all the tests now succeed: $ make test testing... make[1]: Entering directory `/media/uri/Src/openssl/test' make[2]: Entering directory `/media/uri/Src/openssl' making all in apps... make[3]: Entering directory `/media/uri/Src/openssl/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/media/uri/Src/openssl/apps' make[2]: Leaving directory `/media/uri/Src/openssl' TOP=.. PERL=/usr/bin/perl /usr/bin/perl run_tests.pl alltests ../test/recipes/00-check_testexes.t ....... ok ../test/recipes/05-test_bf.t .............. ok ../test/recipes/05-test_cast.t ............ ok ../test/recipes/05-test_des.t ............. ok ../test/recipes/05-test_hmac.t ............ ok ../test/recipes/05-test_idea.t ............ ok ../test/recipes/05-test_md2.t ............. ok ../test/recipes/05-test_md4.t ............. ok ../test/recipes/05-test_md5.t ............. ok ../test/recipes/05-test_mdc2.t ............ ok ../test/recipes/05-test_rand.t ............ ok ../test/recipes/05-test_rc2.t ............. ok ../test/recipes/05-test_rc4.t ............. ok ../test/recipes/05-test_rc5.t ............. ok ../test/recipes/05-test_rmd.t ............. ok ../test/recipes/05-test_sha1.t ............ ok ../test/recipes/05-test_sha256.t .......... ok ../test/recipes/05-test_sha512.t .......... ok ../test/recipes/05-test_wp.t .............. ok ../test/recipes/10-test_bn.t .............. ok ../test/recipes/10-test_exp.t ............. ok ../test/recipes/15-test_dh.t .............. ok ../test/recipes/15-test_dsa.t ............. ok ../test/recipes/15-test_ec.t .............. ok ../test/recipes/15-test_ecdh.t ............ ok ../test/recipes/15-test_ecdsa.t ........... ok ../test/recipes/15-test_rsa.t ............. ok ../test/recipes/20-test_enc.t ............. ok ../test/recipes/25-test_crl.t ............. ok ../test/recipes/25-test_gen.t ............. ok ../test/recipes/25-test_pkcs7.t ........... ok ../test/recipes/25-test_req.t ............. ok ../test/recipes/25-test_sid.t ............. ok ../test/recipes/25-test_verify.t .......... ok ../test/recipes/25-test_x509.t ............ ok ../test/recipes/30-test_engine.t .......... ok ../test/recipes/30-test_evp.t ............. ok ../test/recipes/30-test_evp_extra.t ....... ok ../test/recipes/30-test_pbelu.t ........... ok ../test/recipes/40-test_rehash.t .......... ok ../test/recipes/70-test_clienthello.t ..... ok ../test/recipes/70-test_packet.t .......... ok ../test/recipes/70-test_sslextension.t .... ok ../test/recipes/70-test_sslsessiontick.t .. ok ../test/recipes/70-test_sslskewith0p.t .... ok ../test/recipes/70-test_sslvertol.t ....... ok ../test/recipes/70-test_verify_extra.t .... ok ../test/recipes/80-test_ca.t .............. ok ../test/recipes/80-test_cms.t ............. ok ../test/recipes/80-test_ocsp.t ............ ok ../test/recipes/80-test_ssl.t ............. ok ../test/recipes/80-test_tsa.t ............. ok ../test/recipes/90-test_constant_time.t ... ok ../test/recipes/90-test_gmdiff.t .......... ok ../test/recipes/90-test_gost2814789.t ..... ok ../test/recipes/90-test_heartbeat.t ....... ok ../test/recipes/90-test_ige.t ............. ok ../test/recipes/90-test_jpake.t ........... ok ../test/recipes/90-test_np.t .............. ok ../test/recipes/90-test_p5_crpt2.t ........ ok ../test/recipes/90-test_secmem.t .......... ok ../test/recipes/90-test_srp.t ............. ok ../test/recipes/90-test_v3name.t .......... ok All tests successful. Files=63, Tests=343, 29 wallclock secs ( 0.36 usr 0.05 sys + 19.63 cusr 8.62 csys = 28.66 CPU) Result: PASS make[1]: Leaving directory `/media/uri/Src/openssl/test' OPENSSL_CONF=apps/openssl.cnf util/opensslwrap.sh version -a OpenSSL 1.1.0-dev xx XXX xxxx built on: reproducible build, date unspecified platform: linux-x86_64 compiler: gcc -I. -I.. -I../include -Iinclude -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/usr/local/ssl" -- Regards, Uri Blumenthal On 9/20/15, 14:09 , "Richard Levitte" wrote: >In message <55FDB8F1.1000507 at openssl.org> on Sat, 19 Sep 2015 20:35:13 >+0100, Matt Caswell said: > >matt> On 18/09/15 21:24, Blumenthal, Uri - 0553 - MITLL wrote >matt> > # Looks like you planned 11 tests but ran 20. >matt> > >matt> > >matt> > # Failed test 'CMS <=> CMS consistency tests, modified key >parameters >matt> > # ' >matt> > # at ../test/recipes/80-test_cms.t line 460. >matt> > # Looks like you failed 1 test of 4. >matt> > ../test/recipes/80-test_cms.t ............. >matt> > Dubious, test returned 1 (wstat 256, 0x100) >matt> > Failed 1/4 subtests >matt> >matt> This also seems to be related to Configuring with zlib in some way. > >FYI, problem fixed. It was a typo in the compression test, so it used >the wrong array of parameters when trying to perform them. However, >when OpenSSL is configured without zlib, that test is skipped, so the >fault went undetected for quite some time. > >-- >Richard Levitte richard at levitte.org > http://richard.levitte.org/ > >"Life is a tremendous celebration - and I'm invited!" >-- from a friend's blog, translated from Swedish -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Mon Sep 21 16:34:55 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 21 Sep 2015 16:34:55 +0000 Subject: [openssl-dev] CBC mode does not seems to work in OpenSSL 1.0.2d In-Reply-To: References: Message-ID: > I have ported OpenSSL 1.0.2d on our product. After that CBC mode is not working. Handshakes are failing with bad mac alert failure. When I checked the code mac retrieved from?ssl3_cbc_copy_mac does not match with the calculated mac. Try using the openssl ciphers command to narrow down the differences. From rt at openssl.org Mon Sep 21 18:30:43 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 21 Sep 2015 18:30:43 +0000 Subject: [openssl-dev] [openssl.org #3823] [PATCH] Improve the robustness of event logging In-Reply-To: References: Message-ID: fixed on master, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Sep 21 18:37:51 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 21 Sep 2015 18:37:51 +0000 Subject: [openssl-dev] [openssl.org #3823] [PATCH] Improve the robustness of event logging In-Reply-To: References: Message-ID: also in 1.0.2 and 1.0.1, in addition to master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From phpdev at ehrhardt.nl Mon Sep 21 20:42:17 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Mon, 21 Sep 2015 22:42:17 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: <2nq00b51qlqh5t5iv706o0906omnt312v3@4ax.com> Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Sun, 20 Sep 2015 22:51:21 +0000): >In more detail I just tried a build from sources. I did this: > >set FIPSDIR=X:\some\for\fips\module\installation >cd >ms\do_fips >cd >perl Configure VC-WIN32 fips >nmake -f ms\ntdll.mak > >With no problems. I'd suggest you try that as a starting point and let me know >of any errors you get. You will need to install nasm for that to work. Did you do that with VS2015 aka VC14? The Apache and PHP world is moving to VC14. PHP7 will only be built with VC14. -- Jan From phpdev at ehrhardt.nl Mon Sep 21 21:20:40 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Mon, 21 Sep 2015 23:20:40 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> <2nq00b51qlqh5t5iv706o0906omnt312v3@4ax.com> Message-ID: Jan Ehrhardt in gmane.comp.encryption.openssl.devel (Mon, 21 Sep 2015 22:42:17 +0200): >Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Sun, 20 Sep >2015 22:51:21 +0000): >>In more detail I just tried a build from sources. I did this: >> >>set FIPSDIR=X:\some\for\fips\module\installation >>cd >>ms\do_fips >>cd >>perl Configure VC-WIN32 fips >>nmake -f ms\ntdll.mak >> >>With no problems. I'd suggest you try that as a starting point and let me know >>of any errors you get. You will need to install nasm for that to work. > >Did you do that with VS2015 aka VC14? The Apache and PHP world is moving >to VC14. PHP7 will only be built with VC14. The error message with VC14 is still the same as it was with FIPS 2.0.9: N:\openssl>nmake -f ms\ntdll.mak test Microsoft (R) Program Maintenance Utility Version 14.00.23026.0 Copyright (C) Microsoft Corporation. All rights reserved. SET FIPS_LINK=link SET FIPS_CC=cl SET FIPS_CC_ARGS=/Fotmp32dll\fips_premain.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I\usr\local\ssl\fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Fdtmp32dll/lib -D_WINDLL -c SET PREMAIN_DSO_EXE=out32dll\fips_premain_dso.exe SET FIPS_SHA1_EXE=\usr\local\ssl\fips-2.0\bin\fips_standalone_sha1.exe SET FIPS_TARGET=out32dll\libeay32.dll SET FIPSLIB_D=\usr\local\ssl\fips-2.0\lib perl \usr\local\ssl\fips-2.0\bin\fipslink.pl /nologo /subsystem:console /opt:ref /debug /dll /fixed /map /base:0xFB00000 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @d:\temp\nm50A8.tmp Invalid hash syntax in file at \usr\local\ssl\fips-2.0\bin\fipslink.pl line 90. NMAKE : fatal error U1077: 'C:\Perl64\bin\perl.EXE' : return code '0xff' Stop. N:\openssl>out32dll\fips_premain_dso.exe out32dll\libeay32.dll OPENSSL_Uplink(00DB5000,08): no OPENSSL_Applink Jan From rt at openssl.org Mon Sep 21 21:34:41 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 21 Sep 2015 21:34:41 +0000 Subject: [openssl-dev] [openssl.org #3479] BIO_read_filename() does not handle UTF-8 on Windows, as BIO_new_file() does. In-Reply-To: <1406758595.5726.41.camel@infradead.org> References: <1406758595.5726.41.camel@infradead.org> Message-ID: OpenSSL_1_0_1-stable 21d8f24 RT3479: Add UTF8 support to BIO_read_filename() OpenSSL_1_0_2-stable 0ea050e RT3479: Add UTF8 support to BIO_read_filename() master ff03599 RT3479: Add UTF8 support to BIO_read_filename() Author: David Woodhouse Date: Wed Sep 9 15:49:01 2015 -0400 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Sep 22 00:00:45 2015 From: rt at openssl.org (Gibbons, Lee D via RT) Date: Tue, 22 Sep 2015 00:00:45 +0000 Subject: [openssl-dev] [openssl.org #4055] FIPS Object Module User Guide corrections needed for (*get_entropy)() In-Reply-To: References: Message-ID: This is to highlight a bug in the FIPS Object Module 2.10 and corrective documentation in its User Guide. The User Guide for the FIPS Object Module 2.10 describes the (*get_entropy)() callback: size_t (*get_entropy)(DRBG_CTX *ctx, unsigned char **pout, int entropy, size_t min_len, size_t max_len) "A call to this function requests entropy bits of entropy in a buffer of between min_len and max_len size bytes inclusive. The values of these are mechanism specific and taken from SP800-90 tables. This callback should then return the amount of data in the buffer *pout and the length in the return value, or zero in case of being unable to retrieve sufficient entropy." The caller of (*get_entropy)() is the static function fips_get_entropy(). Notice how it constructs the value, which should be in bits: rv = dctx->get_entropy(dctx, &tout, entropy + bl, min_len + bl, max_len + bl); *pout = tout + bl; if (rv < (min_len + bl) || (rv % bl)) return 0; The "entropy + bl" expression is mixing types, adding bits and bytes together. Anyone defining a (*get_entropy)() callback had better ignore the parameter. What's more, the callback had better return rounded up to a dctx->entropy_blocklen boundary or face failure. The User Guide mentions none of this. I realize the FIPS Object Module is frozen. The documentation should be corrected to expose the real restrictions on the callback. Doug Gibbons | Consulting Engineer | Avaya Inc. | 12121 Grant St | 2S-237 | Thornton, CO 80241 | 303-538-3538 | ldgibbons at avaya.com -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Sep 22 00:39:37 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 22 Sep 2015 00:39:37 +0000 Subject: [openssl-dev] [openssl.org #4056] 1.0.2d and Configure issue under X32 (ARFLAGS is architecture name?) In-Reply-To: References: Message-ID: I experienced this issue under X32. X32 provides 32-bit integers, longs and pointers combined with the richness of x86_64 register set. Debian has a chroot environment for X32 at https://wiki.debian.org/X32Port. It appears ARFLAGS is set to the architecture when using RPATH options in Configure's $cflags and $ldflags. RPATHS are important (IMHO) because OpenSSL can get into a situation where /usr/local/bin/openssl uses /usr/local/lib/libssl.so, but libssl.so uses the system's /usr/lib/libcrypto.so. I added a Configure target that provides RPATH options to $cflags (field 2) and $ldflags (field 6): # ./Configure LIST | grep x32 linux-x32 linux-x32-rpath linux32-s390x Here's what it looks like (copy and paste from under emacs; ignore the back slashes): "linux-x32-rpath", "gcc:-mx32 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl\ /lib::-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib -ldl:SIXTY_FOUR_BIT RC4_CHUNK\ _LL DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC -mx32:.so.\$(\ SHLIB_MAJOR).\$(SHLIB_MINOR):::x32", And below is what it results in, which fails under `make` because `ARFLAGS=m32`. Jeff ********** # unset ARFLAGS # ./Configure linux-x32-rpath shared enable-ec_nistp_64_gcc_128 Configuring for linux-x32-rpath no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-fPIC -mx32 -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mx32 -DL_ENDIAN -O3 -Wall -Wl,-rpath=/usr/local/ssl/lib -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM EX_LIBS =-Wl,-rpath=/usr/local/ssl/lib -ldl CPUID_OBJ =x86_64cpuid.o BN_ASM =x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS =x32 PERL =/usr/bin/perl SIXTY_FOUR_BIT mode DES_UNROLL used DES_INT used RC4_CHUNK is unsigned long long created directory `include/openssl' ... _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Tue Sep 22 21:57:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 22 Sep 2015 21:57:54 +0000 Subject: [openssl-dev] who wants to fix travis builds? Message-ID: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> Please see https://travis-ci.org/openssl/openssl/jobs/81672180 Etc. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Wed Sep 23 08:06:24 2015 From: appro at openssl.org (Andy Polyakov) Date: Wed, 23 Sep 2015 10:06:24 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56025D80.7060802@openssl.org> > Please see https://travis-ci.org/openssl/openssl/jobs/81672180 --debug is not recognized by earlier ./Configures? BTW, nor is there mingw64 in 098. From rt at openssl.org Wed Sep 23 11:45:30 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 23 Sep 2015 11:45:30 +0000 Subject: [openssl-dev] [openssl.org #4048] [PATCH] Fix potential read buffer overflow in PACKET_strndup() In-Reply-To: <20150923114515.GA6782@kronk.local> References: <20150923114515.GA6782@kronk.local> Message-ID: The GitHub pull request was merged, so this can be closed. Cheers From alessandro at ghedini.me Wed Sep 23 11:46:07 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Wed, 23 Sep 2015 13:46:07 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <56025D80.7060802@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> Message-ID: <20150923114607.GA27612@kronk.local> On Wed, Sep 23, 2015 at 10:06:24AM +0200, Andy Polyakov wrote: > > Please see https://travis-ci.org/openssl/openssl/jobs/81672180 > > --debug is not recognized by earlier ./Configures? Yeah, it seems that earlier ./Configure only support the debug-$platform arguments. For general travis debug builds (which use ./config), we can simply change the $CONFIG_OPTS to use '-d' instead of '--debug', but that still leaves the mingw builds out (they use ./Configure directly). Another possibility is to backport '--debug' to older ./Configures. > BTW, nor is there mingw64 in 098. And the mingw build is broken anyway. Is this something worth fixing in a future 0.9.8 release? Otherwise the mingw builds could be simply removed from travis for 0.9.8. Other builds failing are: - linux-gcc and mingw debug builds in 1.0.2 (I haven't tried to reproduce these yet). - mingw debug and shared builds in master. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed Sep 23 11:48:36 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 23 Sep 2015 11:48:36 +0000 Subject: [openssl-dev] [openssl.org #4048] [PATCH] Fix potential read buffer overflow in PACKET_strndup() In-Reply-To: <20150916163504.GA15338@kronk.local> References: <20150916163504.GA15338@kronk.local> Message-ID: Marking this ticket as closed. Matt From appro at openssl.org Wed Sep 23 13:57:18 2015 From: appro at openssl.org (Andy Polyakov) Date: Wed, 23 Sep 2015 15:57:18 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20150923114607.GA27612@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> Message-ID: <5602AFBE.4090407@openssl.org> > And the mingw build is broken anyway. For the record, originally mingw was supported by itself, i.e. under MSYS, and under cygwin (which is why you'll notice -mno-cygwin). Then is was empirically confirmed that it works even with cross-compiler under Linux. But it more than likely happened with 1.0, so that assuming that 0.9.8 would work was in fact a stretch. > Is this something worth fixing in a future > 0.9.8 release? I'd vote against. > Otherwise the mingw builds could be simply removed from travis > for 0.9.8. > > Other builds failing are: > > - linux-gcc and mingw debug builds in 1.0.2 (I haven't tried to reproduce > these yet). No comment at this point. > - mingw debug and shared builds in master. While I can confirm problem with shared (fixable with attached patch, please double-check), I can't confirm problem with debug (please elaborate). -------------- next part -------------- A non-text attachment was scrubbed... Name: mingw-shared.diff Type: text/x-patch Size: 301 bytes Desc: not available URL: From alvherre at alvh.no-ip.org Wed Sep 23 18:28:01 2015 From: alvherre at alvh.no-ip.org (Alvaro Herrera) Date: Wed, 23 Sep 2015 15:28:01 -0300 Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: References: Message-ID: <20150923182801.GA295784@alvherre.pgsql> Harri Porten wrote: > Hi! > > In case you are interested in seeing the condition/decision source code > coverage as achieved through the OpenSSL test suite: > > http://www.opencoverage.net/projects/openssl/index_html/sources.html Is it just me, or are none of the files in ssl/ getting checked? -- ?lvaro Herrera PostgreSQL Expert, http://www.2ndQuadrant.com/ From alessandro at ghedini.me Thu Sep 24 10:44:24 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Thu, 24 Sep 2015 12:44:24 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <5602AFBE.4090407@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> Message-ID: <20150924104423.GA13584@kronk.local> On Wed, Sep 23, 2015 at 03:57:18pm +0200, Andy Polyakov wrote: > > - mingw debug and shared builds in master. > > While I can confirm problem with shared (fixable with attached patch, > please double-check), Can confirm that your patch works. > I can't confirm problem with debug (please elaborate). The travis debug builds now also use --strict-warnings, which enables all warnings and treats them as errors, and there's a bunch of warnings when building with mingw. I tried to fix some of them (see [0]) but it's kind of a lost battle. Cheers [0] https://github.com/ghedo/openssl/commit/0368a58 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu Sep 24 11:52:05 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 24 Sep 2015 11:52:05 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: On Sun Sep 20 22:51:21 2015, steve wrote: > > In more detail I just tried a build from sources. I did this: > > set FIPSDIR=X:\some\for\fips\module\installation > cd > ms\do_fips > cd > perl Configure VC-WIN32 fips > nmake -f ms\ntdll.mak > > With no problems. I'd suggest you try that as a starting point and let > me know > of any errors you get. You will need to install nasm for that to work. > I've tried a newer version of VC++ and I also get the "No Applink" error when it is trying to embed the fingerprint in libeay32.dll. I'll see if this can be fixed. There are a couple of workarounds. One is to use the msincore script. You do: set FIPS_SIG=perl X:\\util\msincore The wont affect the validation as you aren't modifying the FIPS module sources and the use of an alternative script to generate the fingerprint is permitted (it is normally used for cross compilation). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Sep 24 12:56:04 2015 From: rt at openssl.org (Vladimir Kotal via RT) Date: Thu, 24 Sep 2015 12:56:04 +0000 Subject: [openssl-dev] [openssl.org #4057] apps/rehash.c fails to compile on Solaris (+ fix) In-Reply-To: <56012334.5080802@oracle.com> References: <56012334.5080802@oracle.com> Message-ID: apps/rehash.c fails to compile on Solaris and other systems that do not define NAME_MAX in limits.h. Namely, Solaris has this comment in limits.h: /* * POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the * related text states: * * A definition of one of the values from Table 2-5 shall be omitted from the * on specific implementations where the corresponding value is * equal to or greater than the stated minimum, but where the value can vary * depending on the file to which it is applied. The actual value supported for * a specific pathname shall be provided by the pathconf() (5.7.1) function. * * This is clear that any machine supporting multiple file system types * and/or a network can not include this define, regardless of protection * by the _POSIX_SOURCE and _POSIX_C_SOURCE flags. * * #define NAME_MAX 14 */ See pull request https://github.com/openssl/openssl/pull/408 for the actual fix. Cheers, v. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 24 13:09:34 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 24 Sep 2015 13:09:34 +0000 Subject: [openssl-dev] [openssl.org #4056] 1.0.2d and Configure issue under X32 (ARFLAGS is architecture name?) In-Reply-To: <5603F61E.5050803@openssl.org> References: <5603F61E.5050803@openssl.org> Message-ID: > It appears ARFLAGS is set to the architecture when using RPATH options > in Configure's $cflags and $ldflags. RPATHS are important (IMHO) > because OpenSSL can get into a situation where /usr/local/bin/openssl > uses /usr/local/lib/libssl.so, but libssl.so uses the system's > /usr/lib/libcrypto.so. > > I added a Configure target that provides RPATH options to $cflags > (field 2) and $ldflags (field 6): > > # ./Configure LIST | grep x32 > linux-x32 > linux-x32-rpath > linux32-s390x > > Here's what it looks like (copy and paste from under emacs; ignore the > back slashes): > > "linux-x32-rpath", "gcc:-mx32 -DL_ENDIAN -O3 -Wall > -Wl,-rpath=/usr/local/ssl\ > /lib::-D_REENTRANT::-Wl,-rpath=/usr/local/ssl/lib > -ldl:SIXTY_FOUR_BIT RC4_CHUNK\ > _LL DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC > -mx32:.so.\$(\ > SHLIB_MAJOR).\$(SHLIB_MINOR):::x32", > > And below is what it results in, which fails under `make` because `ARFLAGS=m32`. This means only one thing, that there are not enough : in your config line. Or in other words your line -> your problem :-) :-) :-) 'make TABLE' and examine where it does wrong. And once again, what prevents you from passing custom -Wl,-rpath=/some/place as additional command line argument to Configure/config? Thing is that dedicated -rpath line actually works against own purpose. I mean it reflects somebody's overly particular need, and there is no guarantee that it coincides with everybody's need. Isn't it better to have freedom to *choose* depending on situation as opposite to *cementing* it in config line? From appro at openssl.org Thu Sep 24 14:23:52 2015 From: appro at openssl.org (Andy Polyakov) Date: Thu, 24 Sep 2015 16:23:52 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20150924104423.GA13584@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150924104423.GA13584@kronk.local> Message-ID: <56040778.5010101@openssl.org> >>> - mingw debug and shared builds in master. >> >> While I can confirm problem with shared (fixable with attached patch, >> please double-check), > > Can confirm that your patch works. > >> I can't confirm problem with debug (please elaborate). > > The travis debug builds now also use --strict-warnings, which enables all > warnings and treats them as errors, and there's a bunch of warnings when > building with mingw. I think it's appropriate to set pragmatic goals in this case. Fixing warnings for non-primary[!] platform such as mingw in master is arguably pragmatic, but not in all versions. So that in this case, i.e. travis-ci.org, I'd argue for limiting testing to current working de-facto status for all versions but master. Is it reasonable? > I tried to fix some of them (see [0]) but it's kind of a lost battle. What does "kind of a lost battle" mean in the context? From rsalz at akamai.com Thu Sep 24 14:34:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 24 Sep 2015 14:34:30 +0000 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <56040778.5010101@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150924104423.GA13584@kronk.local> <56040778.5010101@openssl.org> Message-ID: > So that in this case, i.e. > travis-ci.org, I'd argue for limiting testing to current working de-facto status > for all versions but master. Is it reasonable? Yes, this makes a lot of sense; let's do it. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From hkario at redhat.com Thu Sep 24 15:19:49 2015 From: hkario at redhat.com (Hubert Kario) Date: Thu, 24 Sep 2015 17:19:49 +0200 Subject: [openssl-dev] State machine rewrite In-Reply-To: <55F2E667.5000506@openssl.org> References: <55F2E667.5000506@openssl.org> Message-ID: <1641785.ZN87TdnGaB@pintsize.usersys.redhat.com> On Friday 11 September 2015 15:34:15 Matt Caswell wrote: > I've just opened a github pull request to show recent work I have been > doing on rewriting the OpenSSL state machine (for version 1.1.0). > See: https://github.com/openssl/openssl/pull/394 > > My objectives for the rewrite were: > - Separate message flow state from handshake state (in order to better > understand each) Unfortunately, it doesn't look like the rewrite fixed https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest I can still reproduce the issue: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ -nodes -batch ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ localhost.crt pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-openssl-3712.py The client reports Broken pipe While the server reports: 140584857466520:error:140940F5:SSL routines:ssl3_read_bytes:unexpected record:record/rec_layer_s3.c:1458: -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Thu Sep 24 15:24:03 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Thu, 24 Sep 2015 15:24:03 +0000 Subject: [openssl-dev] [openssl.org #4059] Error processing set_serial parameter of the req command In-Reply-To: References: Message-ID: Hello! Current master treats -set_serial as digest alg and expects -set-serial instead. It is the only place in apps, x509 and ca commands seem to accept -set_serial. -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Sep 24 15:26:23 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 24 Sep 2015 15:26:23 +0000 Subject: [openssl-dev] [openssl.org #4057] apps/rehash.c fails to compile on Solaris (+ fix) In-Reply-To: <56012334.5080802@oracle.com> References: <56012334.5080802@oracle.com> Message-ID: thanks, fixed! -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From alessandro at ghedini.me Thu Sep 24 15:39:12 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Thu, 24 Sep 2015 17:39:12 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <56040778.5010101@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150924104423.GA13584@kronk.local> <56040778.5010101@openssl.org> Message-ID: <20150924153912.GA5448@kronk.local> On Thu, Sep 24, 2015 at 04:23:52pm +0200, Andy Polyakov wrote: > >>> - mingw debug and shared builds in master. > >> > >> While I can confirm problem with shared (fixable with attached patch, > >> please double-check), > > > > Can confirm that your patch works. > > > >> I can't confirm problem with debug (please elaborate). > > > > The travis debug builds now also use --strict-warnings, which enables all > > warnings and treats them as errors, and there's a bunch of warnings when > > building with mingw. > > I think it's appropriate to set pragmatic goals in this case. Fixing > warnings for non-primary[!] platform such as mingw in master is arguably > pragmatic, but not in all versions. So that in this case, i.e. > travis-ci.org, I'd argue for limiting testing to current working > de-facto status for all versions but master. Is it reasonable? Sure, that seems like a sensible strategy. > > I tried to fix some of them (see [0]) but it's kind of a lost battle. > > What does "kind of a lost battle" mean in the context? Meaning that there actually are a lot of warnings and many of them are very difficult (if not impossible) to fix. Fixing all of them would require quite a bit of work and the result may be very ugly. As an aside, the patch I previously posted is broken, so just ignore it. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu Sep 24 16:08:27 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Thu, 24 Sep 2015 16:08:27 +0000 Subject: [openssl-dev] [openssl.org #4060] a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: Hi, I am a software developer who is struggling on an application development based on OpenSSL 1.0.1 (released on 2012-03-14) under Linux (32-bit Redhat). I used to use the SSL functions from OpenSSL 0.9.8, and my application worked fine. I applied the SSLv23_method() to setup the SSL context and communicate with customer's server over various SSL/TLS protocols. While, recently my customer required me to upgrade my OpenSSL library, because their server only support TLS1.2. So I downloaded OpenSSL 1.0.1 source package, then complied and installed successfully. I configured the OpenSSL as: #./config -prefix=/usr shared //I have to generate the shared library like libssl.so, libcrypto.so Then I found my SSL context, setup by SSLv23_method(), stopped working, I can't reach their server anymore. It looked like they didn't understand my handshake message when I called SSL_Connect(). So I switched to the TLSv1_2_method() to build SSL context. However, my program crashed every time when I called SSL_Connect(), I mean crash happened inside the SSL_Connect(), and it didn't return at all. Now I have tried 2 methods: 1. SSLv23_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = SSLv23_method(); ctx = SSL_CTX_new(meth); //Only allow TLSv1_1 or higher SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); ...... The SSL_Connect() resulted in: ConnectSSL [SSL_connect(ssl)] failed: 5 SSL_ERROR_SYSCALL: 5 2. TLSv1_2_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = TLSv1_2_method(); ctx = SSL_CTX_new(meth); then, the SSL_connect() crashed when I invoked it. Currently, I don't know how to attack this issue, all the code worked fine before. I just changed the SSLv23_method to TLSv1_2_method. Is there any difference between that 2 functions? What I should do if I want to use the TLSv1_2_method? I am very pleased if anyone of you have any idea to help me. Thanks, Tyler -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Thu Sep 24 16:29:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2015 16:29:43 +0000 Subject: [openssl-dev] [openssl.org #4060] a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: <20150924162942.GN21942@mournblade.imrryr.org> On Thu, Sep 24, 2015 at 04:08:27PM +0000, Tiantian Liu via RT wrote: > I used to use the SSL functions from OpenSSL 0.9.8, and my application > worked fine. I applied the SSLv23_method() to setup the SSL context and > communicate with customer's server over various SSL/TLS protocols. > > While, recently my customer required me to upgrade my OpenSSL library, > because their server only support TLS1.2. So I downloaded OpenSSL 1.0.1 > source package, then complied and installed successfully. > I configured the OpenSSL as: > #./config -prefix=/usr shared > > Then I found my SSL context, setup by SSLv23_method(), stopped working, > I can't reach their server anymore. It looked like they didn't understand > my handshake message when I called SSL_Connect(). Did you recompile your application code against the *headers* and libraries from OpenSSL 1.0.1? The 0.9.8 release is not binary-compatible with the 1.0.1 release. > 1. SSLv23_method() to build SSL context That's what you should use. You should not explicitly select a fixed protocol version in most cases. > SSL_METHOD *meth; > SSL_CTX *ctx; > ...... > meth = SSLv23_method(); > ctx = SSL_CTX_new(meth); > > SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); So far, so good. I assume that you also initialized the library before this via SSL_library_init() or similar. > The SSL_Connect() resulted in: > ConnectSSL [SSL_connect(ssl)] failed: 5 > SSL_ERROR_SYSCALL: 5 You should print the error stack, and examime "errno". Perhaps the connection to the server failed. Looking at the output of "strace" may also shed light on the reason for the failure. -- Viktor. From rt at openssl.org Thu Sep 24 19:17:34 2015 From: rt at openssl.org (Devchandra L Meetei via RT) Date: Thu, 24 Sep 2015 19:17:34 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: In a bid to use openssl's non blocking mode with bio pair, we are calling SSL_do_handshake to perform handshake and we would like to do callback based on role of SSL. and Seems that OpenSSL does not expose any APi for doing the same. The attached patch adds a new API, which returns the ```server``` member of ```ssl_st```. > int SSL_get_role(const SSL *s) It currently does not have any test included and Will be happy to update the patch with test case if openssl team is okay with the API change. -- 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 -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From dlmeetei at gmail.com Thu Sep 24 19:35:34 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Fri, 25 Sep 2015 01:05:34 +0530 Subject: [openssl-dev] Request for new API for getting role of SSL endpoint Message-ID: Hey all Just uploaded a patch at https://rt.openssl.org/Ticket/Display.html?id=4061 for adding a new API for getting role, client or server. Please let me know what do you think of it. -- 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 -------------- An HTML attachment was scrubbed... URL: From alessandro at ghedini.me Thu Sep 24 19:59:36 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Thu, 24 Sep 2015 21:59:36 +0200 Subject: [openssl-dev] Request for new API for getting role of SSL endpoint In-Reply-To: References: Message-ID: <20150924195936.GA10428@kronk.local> On Fri, Sep 25, 2015 at 01:05:34am +0530, Devchandra L Meetei wrote: > Hey all Hi, > Just uploaded a patch at https://rt.openssl.org/Ticket/Display.html?id=4061 > for adding a new API for getting role, client or server. > > Please let me know what do you think of it. There seems to be no patch there... (Also note that discussions on RT are automatically forwarded to the mailing list, so no need to announce it here). Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu Sep 24 20:00:57 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 24 Sep 2015 20:00:57 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: On Thu Sep 24 19:17:34 2015, dlmeetei at gmail.com wrote: > In a bid to use openssl's non blocking mode with bio pair, we are calling > SSL_do_handshake to perform handshake and we would like to do callback > based on role of SSL. > > and Seems that OpenSSL does not expose any APi for doing the same. > There is the function SSL_is_server(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mlist-openssl-dev at alt255.com Thu Sep 24 19:59:30 2015 From: mlist-openssl-dev at alt255.com (Justin Burke) Date: Thu, 24 Sep 2015 12:59:30 -0700 Subject: [openssl-dev] Support for TLS SHA2-512? Message-ID: <20150924195930.GC30993@alt255.com> Hello, Does OpenSSL support TLS with SHA2-512? I'm able to compile 1.0.1p with SHA2-256 and SHA2-384 support, but not with SHA2-512. `openssl ciphers` does not list any SHA512 cipher, while `openssl dgst` does support SHA512. Thanks, Justin From rt at openssl.org Thu Sep 24 20:40:53 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 24 Sep 2015 20:40:53 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> Message-ID: I have made the reproducer cleaner and it should use relatively stable API's of tlsfuzzer now. openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ -nodes -batch ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ localhost.crt pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-openssl-3712.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From phpdev at ehrhardt.nl Thu Sep 24 22:48:37 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Fri, 25 Sep 2015 00:48:37 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Thu, 24 Sep 2015 11:52:05 +0000): >I've tried a newer version of VC++ and I also get the "No Applink" error when >it is trying to embed the fingerprint in libeay32.dll. I'll see if this can be >fixed. For FIPS 2.0.9 I had some patches here: https://github.com/Jan-E/openssl-fips/commits/master -- Jan From Stefan.Neis at t-online.de Fri Sep 25 08:48:44 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Fri, 25 Sep 2015 10:48:44 +0200 Subject: [openssl-dev] =?utf-8?q?Support_for_TLS_SHA2-512=3F?= In-Reply-To: <20150924195930.GC30993@alt255.com> References: <20150924195930.GC30993@alt255.com> Message-ID: <176023579156050a6c647ad7.53072022@email.t-online.de> Hi, > Does OpenSSL support TLS with SHA2-512? No, since there is no such thing as a TLS cipher suite with SHA512. Cipher suites need to be registered and assigned IDs, so servers/clients can exchange those IDs to announce what cipher suites they support. And if you look at the probably most up-to-date list of currently registered cipher suites at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 you'll see that there simply is no cipher suite using SHA512. The rational for this is that SHA-384 already offers the same level of security as the 256 bit block ciphers do, so there's no point in using longer hashes. Regards, Stefan From Matthias.St.Pierre at ncp-e.com Fri Sep 25 08:52:04 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 25 Sep 2015 10:52:04 +0200 Subject: [openssl-dev] Openssl 1.0.2c include the FIPS 140-2 Object Module In-Reply-To: References: <8878620CF8603E45BB794422B7899E9E112DF77932@INBLRK77M1MSX.in002.siemens.net> <5593F0CA.7070803@openssl.com> <55CD86EA.8060707@ncp-e.com> <6ltrsadoqbcgggh7n6ifrq1sr227l7pm06@4ax.com> <55D10615.9040609@ncp-e.com> Message-ID: <56050B34.1070907@ncp-e.com> On 09/21/2015 12:01 AM, Jan Ehrhardt wrote: > Dr. Matthias St. Pierre in gmane.comp.encryption.openssl.devel (Sun, 16 > Aug 2015 23:52:21 +0200): >> >> Thank you once more for the detailed reply. I applied your patches >> provisorily before going on vacation last friday to keep the builds >> going. After my vacation we will have to decide what to do about the >> FIPS problem. > > Surely, your holiday must be over by now ;-) > > Jan > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > Sorry for not answering earlier, I overlooked your post. Not because of holidays, but because I was busy with other problems. As you might have guessed, my provisional arrangement is still in place ;-) I noticed there has been some movement on issue #4042 recently and hope there will be an official solution to the problem soon. Thanks for persisting on the subject, anyway. Regards, Matthias From erwann.abalea at opentrust.com Fri Sep 25 08:55:08 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Fri, 25 Sep 2015 10:55:08 +0200 Subject: [openssl-dev] Support for TLS SHA2-512? In-Reply-To: <20150924195930.GC30993@alt255.com> References: <20150924195930.GC30993@alt255.com> Message-ID: <9B3F9F7C-038B-4545-B109-320F32251A1B@opentrust.com> Bonjour, > Le 24 sept. 2015 ? 21:59, Justin Burke a ?crit : > > Hello, > > Does OpenSSL support TLS with SHA2-512? I'm able to compile 1.0.1p with > SHA2-256 and SHA2-384 support, but not with SHA2-512. `openssl ciphers` > does not list any SHA512 cipher, while `openssl dgst` does support > SHA512. The list of registered cipher suites can be found at https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 and there?s no standardized *SHA512 cipher suite, as you can see. Cordialement, Erwann Abalea -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 25 09:47:42 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Sep 2015 10:47:42 +0100 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> Message-ID: <5605183E.8070501@openssl.org> On 24/09/15 21:40, Hubert Kario via RT wrote: > I have made the reproducer cleaner and it should use relatively stable > API's of tlsfuzzer now. > > openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ > -nodes -batch > ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ > localhost.crt > > pip install --pre tlslite-ng > git clone https://github.com/tomato42/tlsfuzzer.git > > cd tlsfuzzer > PYTHONPATH=. python scripts/test-openssl-3712.py This is really nice! Thanks Hubert. I've been looking into this issue. The reason this fails is because at some point in the past there has been an explicit design decision to disallow it. The relevant code is here: /* * At this point, we were expecting handshake data, but have * application data. If the library was running inside ssl3_read() * (i.e. in_read_app_data is set) and it makes sense to read * application data at this point (session renegotiation not yet * started), we will indulge it. */ if (s->s3->in_read_app_data && (s->s3->total_renegotiations != 0) && (((s->state & SSL_ST_CONNECT) && (s->state >= SSL3_ST_CW_CLNT_HELLO_A) && (s->state <= SSL3_ST_CR_SRVR_HELLO_A) ) || ((s->state & SSL_ST_ACCEPT) && (s->state <= SSL3_ST_SW_HELLO_REQ_A) && (s->state >= SSL3_ST_SR_CLNT_HELLO_A) ) )) { s->s3->in_read_app_data = 2; return (-1); } else { al = SSL_AD_UNEXPECTED_MESSAGE; SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_UNEXPECTED_RECORD); goto f_err; } So to pull this conditional apart a bit: s->s3->in_read_app_data : we were originally called by SSL_read AND s->s3->total_renegotiations != 0 : we have started at least one renegotiation at some point (*see below) AND ( ((s->state & SSL_ST_CONNECT) && (s->state >= SSL3_ST_CW_CLNT_HELLO_A) && (s->state <= SSL3_ST_CR_SRVR_HELLO_A) : we are a client and are in a state where we have started to write/have finished writing a ClientHello out but have not yet received a ServerHello. OR (s->state & SSL_ST_ACCEPT) && (s->state <= SSL3_ST_SW_HELLO_REQ_A) && (s->state >= SSL3_ST_SR_CLNT_HELLO_A) : we are a server and are about to write a HelloVerifyRequest, or we are in the process of reading a ClientHello ) Aside from whether this is the correct logic or not I think there is a related bug here in the total_renegotiations value. I believe this is intended to count up the number of renegotiations that have occurred. As far as I can determine this is incremented when: - There is an explicit call to SSL_renegotiate() or SSL_renegotiate_abbreviated() OR - As a client we initiate a renegotiation following receipt of a HelloRequest So it does not seem to get incremented when, as a server and after the initial handshake has completed, we receive an unsolicited ClientHello, i.e. client initiated renegotiation as in your reproducer code. This alone is sufficient for your test case to fail, but even fixing it won't solve the problem due to the intent of the logic above. The above logic can be traced back to this commit: commit b35e9050f282c5ea2164bd5b08ed34d03accf45f Author: Bodo M?ller AuthorDate: Sun Feb 20 23:04:06 2000 +0000 Commit: Bodo M?ller CommitDate: Sun Feb 20 23:04:06 2000 +0000 Tolerate fragmentation and interleaving in the SSL 3/TLS record layer. Note the date of February 2000! The OP correctly cites RFC 5246 (TLS1.2) and RFC 4346 (TLS1.1) as follows: Note: Data of different TLS Record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. As the OP also observes: "The last sentence clearly puts the blame on OpenSSL. This seems to be an addition in TLS 1.1 since it cannot be found in RFC 2246." Clearly the code commit pre-dates the publication of TLS1.1 (April 2006) and is a carry over from the ambiguous situation as it is in TLS1.0. Therefore this does seem to be an OpenSSL bug. However, I have some concerns with the wording of the RFC. It seems to place no limits whatsoever on when it is valid to receive app data in the handshake. By the wording in the RFC it would be valid for app data to be received *after* the ChangeCipherSpec has been received but *before* the Finished has been processed. This seems dangerous to me because it is not until the Finished is processed that we verify the handshake data MAC - and yet we could already have acted upon app data received. I assume the intent was to allow the interleaved app data only up until the point that the CCS is received. I have attached a patch for 1.0.2 that implements that logic. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: interleave-data-102.patch Type: text/x-patch Size: 2086 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 09:47:49 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 09:47:49 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5605183E.8070501@openssl.org> References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> Message-ID: On 24/09/15 21:40, Hubert Kario via RT wrote: > I have made the reproducer cleaner and it should use relatively stable > API's of tlsfuzzer now. > > openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ > -nodes -batch > ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ > localhost.crt > > pip install --pre tlslite-ng > git clone https://github.com/tomato42/tlsfuzzer.git > > cd tlsfuzzer > PYTHONPATH=. python scripts/test-openssl-3712.py This is really nice! Thanks Hubert. I've been looking into this issue. The reason this fails is because at some point in the past there has been an explicit design decision to disallow it. The relevant code is here: /* * At this point, we were expecting handshake data, but have * application data. If the library was running inside ssl3_read() * (i.e. in_read_app_data is set) and it makes sense to read * application data at this point (session renegotiation not yet * started), we will indulge it. */ if (s->s3->in_read_app_data && (s->s3->total_renegotiations != 0) && (((s->state & SSL_ST_CONNECT) && (s->state >= SSL3_ST_CW_CLNT_HELLO_A) && (s->state <= SSL3_ST_CR_SRVR_HELLO_A) ) || ((s->state & SSL_ST_ACCEPT) && (s->state <= SSL3_ST_SW_HELLO_REQ_A) && (s->state >= SSL3_ST_SR_CLNT_HELLO_A) ) )) { s->s3->in_read_app_data = 2; return (-1); } else { al = SSL_AD_UNEXPECTED_MESSAGE; SSLerr(SSL_F_SSL3_READ_BYTES, SSL_R_UNEXPECTED_RECORD); goto f_err; } So to pull this conditional apart a bit: s->s3->in_read_app_data : we were originally called by SSL_read AND s->s3->total_renegotiations != 0 : we have started at least one renegotiation at some point (*see below) AND ( ((s->state & SSL_ST_CONNECT) && (s->state >= SSL3_ST_CW_CLNT_HELLO_A) && (s->state <= SSL3_ST_CR_SRVR_HELLO_A) : we are a client and are in a state where we have started to write/have finished writing a ClientHello out but have not yet received a ServerHello. OR (s->state & SSL_ST_ACCEPT) && (s->state <= SSL3_ST_SW_HELLO_REQ_A) && (s->state >= SSL3_ST_SR_CLNT_HELLO_A) : we are a server and are about to write a HelloVerifyRequest, or we are in the process of reading a ClientHello ) Aside from whether this is the correct logic or not I think there is a related bug here in the total_renegotiations value. I believe this is intended to count up the number of renegotiations that have occurred. As far as I can determine this is incremented when: - There is an explicit call to SSL_renegotiate() or SSL_renegotiate_abbreviated() OR - As a client we initiate a renegotiation following receipt of a HelloRequest So it does not seem to get incremented when, as a server and after the initial handshake has completed, we receive an unsolicited ClientHello, i.e. client initiated renegotiation as in your reproducer code. This alone is sufficient for your test case to fail, but even fixing it won't solve the problem due to the intent of the logic above. The above logic can be traced back to this commit: commit b35e9050f282c5ea2164bd5b08ed34d03accf45f Author: Bodo M?ller AuthorDate: Sun Feb 20 23:04:06 2000 +0000 Commit: Bodo M?ller CommitDate: Sun Feb 20 23:04:06 2000 +0000 Tolerate fragmentation and interleaving in the SSL 3/TLS record layer. Note the date of February 2000! The OP correctly cites RFC 5246 (TLS1.2) and RFC 4346 (TLS1.1) as follows: Note: Data of different TLS Record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. As the OP also observes: "The last sentence clearly puts the blame on OpenSSL. This seems to be an addition in TLS 1.1 since it cannot be found in RFC 2246." Clearly the code commit pre-dates the publication of TLS1.1 (April 2006) and is a carry over from the ambiguous situation as it is in TLS1.0. Therefore this does seem to be an OpenSSL bug. However, I have some concerns with the wording of the RFC. It seems to place no limits whatsoever on when it is valid to receive app data in the handshake. By the wording in the RFC it would be valid for app data to be received *after* the ChangeCipherSpec has been received but *before* the Finished has been processed. This seems dangerous to me because it is not until the Finished is processed that we verify the handshake data MAC - and yet we could already have acted upon app data received. I assume the intent was to allow the interleaved app data only up until the point that the CCS is received. I have attached a patch for 1.0.2 that implements that logic. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: interleave-data-102.patch Type: text/x-patch Size: 2087 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 10:25:34 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 10:25:34 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <27757549.yjyxRzWiBc@pintsize.usersys.redhat.com> References: <5605183E.8070501@openssl.org> <27757549.yjyxRzWiBc@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 10:47:42 Matt Caswell wrote: > However, I have some concerns with the wording of the RFC. It seems to > place no limits whatsoever on when it is valid to receive app data in > the handshake. By the wording in the RFC it would be valid for app > data to be received *after* the ChangeCipherSpec has been received > but *before* the Finished has been processed. This seems dangerous to > me because it is not until the Finished is processed that we verify > the handshake data MAC - and yet we could already have acted upon app > data received. I assume the intent was to allow the interleaved app > data only up until the point that the CCS is received. I have > attached a patch for 1.0.2 that implements that logic. yes, I think the only place in which the handshake protocol and application data _can't_ be interleaved is between the CCS and Finished. Or in other words, the following sections from RFC 5246 apply: Application data MUST NOT be sent prior to the completion of the first handshake (before a cipher suite other than TLS_NULL_WITH_NULL_NULL is established). and: A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. and: It is a fatal error if a Finished message is not preceded by a ChangeCipherSpec message at the appropriate point in the handshake. isn't overruled by: Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matt at openssl.org Fri Sep 25 10:37:47 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Sep 2015 11:37:47 +0100 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <5605183E.8070501@openssl.org> <27757549.yjyxRzWiBc@pintsize.usersys.redhat.com> Message-ID: <560523FB.4080908@openssl.org> On 25/09/15 11:25, Hubert Kario via RT wrote: > > A Finished message is always sent immediately after a change > cipher spec message to verify that the key exchange and > authentication processes were successful. This is perhaps the key statement. It could do with being more explicit if the intent here is to disallow interleaved app data. Matt From matt at openssl.org Fri Sep 25 10:40:27 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Sep 2015 11:40:27 +0100 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <5605183E.8070501@openssl.org> <27757549.yjyxRzWiBc@pintsize.usersys.redhat.com> Message-ID: <5605249B.1080605@openssl.org> On 25/09/15 11:25, Hubert Kario via RT wrote: > On Friday 25 September 2015 10:47:42 Matt Caswell wrote: >> However, I have some concerns with the wording of the RFC. It seems to >> place no limits whatsoever on when it is valid to receive app data in >> the handshake. By the wording in the RFC it would be valid for app >> data to be received *after* the ChangeCipherSpec has been received >> but *before* the Finished has been processed. This seems dangerous to >> me because it is not until the Finished is processed that we verify >> the handshake data MAC - and yet we could already have acted upon app >> data received. I assume the intent was to allow the interleaved app >> data only up until the point that the CCS is received. I have >> attached a patch for 1.0.2 that implements that logic. > > yes, I think the only place in which the handshake protocol and > application data _can't_ be interleaved is between the CCS and Finished. It would be nice to have a test for that wouldn't it ;-) Matt From karthik.bhargavan at gmail.com Fri Sep 25 10:42:14 2015 From: karthik.bhargavan at gmail.com (Karthikeyan Bhargavan) Date: Fri, 25 Sep 2015 12:42:14 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5605249B.1080605@openssl.org> References: <5605183E.8070501@openssl.org> <27757549.yjyxRzWiBc@pintsize.usersys.redhat.com> <5605249B.1080605@openssl.org> Message-ID: <9D5FF2F1-802A-4020-AD0E-4F9B202A1F61@gmail.com> During renegotiation, app data should not appear between CCS and finished, but some implementations (e.g. NSS) do allow this. I would consider it a state machine bug, although finding a serious exploit is not so easy. > On 25 Sep 2015, at 12:40, Matt Caswell wrote: > > > > On 25/09/15 11:25, Hubert Kario via RT wrote: >> On Friday 25 September 2015 10:47:42 Matt Caswell wrote: >>> However, I have some concerns with the wording of the RFC. It seems to >>> place no limits whatsoever on when it is valid to receive app data in >>> the handshake. By the wording in the RFC it would be valid for app >>> data to be received *after* the ChangeCipherSpec has been received >>> but *before* the Finished has been processed. This seems dangerous to >>> me because it is not until the Finished is processed that we verify >>> the handshake data MAC - and yet we could already have acted upon app >>> data received. I assume the intent was to allow the interleaved app >>> data only up until the point that the CCS is received. I have >>> attached a patch for 1.0.2 that implements that logic. >> >> yes, I think the only place in which the handshake protocol and >> application data _can't_ be interleaved is between the CCS and Finished. > > It would be nice to have a test for that wouldn't it ;-) > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From hkario at redhat.com Fri Sep 25 12:20:40 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 25 Sep 2015 14:20:40 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5605249B.1080605@openssl.org> References: <5605249B.1080605@openssl.org> Message-ID: <2902110.0tSk9Xvkbz@pintsize.usersys.redhat.com> On Friday 25 September 2015 11:40:27 Matt Caswell wrote: > On 25/09/15 11:25, Hubert Kario via RT wrote: > > On Friday 25 September 2015 10:47:42 Matt Caswell wrote: > >> However, I have some concerns with the wording of the RFC. It seems > >> to place no limits whatsoever on when it is valid to receive app > >> data in the handshake. By the wording in the RFC it would be valid > >> for app data to be received *after* the ChangeCipherSpec has been > >> received but *before* the Finished has been processed. This seems > >> dangerous to me because it is not until the Finished is processed > >> that we verify the handshake data MAC - and yet we could already > >> have acted upon app data received. I assume the intent was to > >> allow the interleaved app data only up until the point that the > >> CCS is received. I have attached a patch for 1.0.2 that implements > >> that logic. > > > > yes, I think the only place in which the handshake protocol and > > application data _can't_ be interleaved is between the CCS and > > Finished. > It would be nice to have a test for that wouldn't it ;-) yeah, but it will be hard to do, you know, with it requiring an TLS implementation to misbehave ;) I'll make one as soon as I'll finish the test cases for record layer fragmentation of initial Client Hello (there are few bugs there too) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From hkario at redhat.com Fri Sep 25 12:24:27 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 25 Sep 2015 14:24:27 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <9D5FF2F1-802A-4020-AD0E-4F9B202A1F61@gmail.com> References: <5605249B.1080605@openssl.org> <9D5FF2F1-802A-4020-AD0E-4F9B202A1F61@gmail.com> Message-ID: <5121824.Ecc9jBVlhN@pintsize.usersys.redhat.com> On Friday 25 September 2015 12:42:14 Karthikeyan Bhargavan wrote: > During renegotiation, app data should not appear between CCS and > finished, but some implementations (e.g. NSS) do allow this. I would > consider it a state machine bug, although finding a serious exploit > is not so easy. while it is not easy, patching it up before it is exploitable is a good idea. And besides, we already had enough issues with clients and servers incorrectly attaching data to wrong authentication info. Some implementations may think that stuff before Finished is from new connection while others that it is from old connection. I'll file that bug as soon as I have a reproducer for it (most likely today) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Fri Sep 25 13:16:17 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 13:16:17 +0000 Subject: [openssl-dev] [openssl.org #4062] [PATCH] Fix build failure In-Reply-To: <20150925131603.GA17219@kronk.local> References: <20150925131603.GA17219@kronk.local> Message-ID: Hello, due to commit a93d3e0 the ./config script currently fails with the error: > Operating system: x86_64-whatever-linux2 > This system (linux-x86_64) is not supported. See file INSTALL for details. see the following GitHub pull request for a fix: https://github.com/openssl/openssl/pull/412 Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 25 13:20:12 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 13:20:12 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> Message-ID: Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite branches reject Client Hello messages bigger than 2^14+4 bytes. RFC 5246 specifies maximum size of just the extensions field to be 2^16-1: struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello; reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\ -nodes -batch ~/dev/openssl/apps/openssl s_server -key localhost.key -cert\ localhost.crt -www pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-record-layer-fragmentation.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 25 13:55:56 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 13:55:56 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925135548.GA17952@kronk.local> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <20150925135548.GA17952@kronk.local> Message-ID: On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT wrote: > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite branches > reject Client Hello messages bigger than 2^14+4 bytes. IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think the problem is that OpenSSL only checks for that. AFAICT both SSLv3 and TLS implementations share the same ssl_accept() method (that is ssl3_accept()), which calls e.g. ssl3_get_client_key_exchange() which in turn calls the ssl_get_message() method (implemented by ssl3_get_message()) using SSL3_RT_MAX_PLAIN_LENGTH as maximum size. I think a proper fix would be to have all the ssl_get_message() calls changed to use the proper "max" parameter depending on the protocol version. The above applies to current master, I haven't checked the state machine rewrite branch yet. I can look into preparing a patch, if no one beats me to it. Cheers From rt at openssl.org Fri Sep 25 14:02:36 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 14:02:36 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <3023376.mUGYYq7pVs@pintsize.usersys.redhat.com> References: <20150925135548.GA17952@kronk.local> <3023376.mUGYYq7pVs@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think the > problem is that OpenSSL only checks for that. yes, it does place a limit of 2^14, but only on _records_, not handshake messages that travel in those records > I think a proper fix would be to have all the ssl_get_message() calls > changed to use the proper "max" parameter depending on the protocol > version. As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly the same as in they don't specify any upper size limit for the Handshake protocol messages or Client Hello specifically other than the limits enforced by the length fields themselves. Remember, the records are completely independent of messages that travel through them, record layer is just there to multiplex the different protocols that are required for TLS to work (handshake, CCS, application data, etc.) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 14:08:18 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 14:08:18 +0000 Subject: [openssl-dev] [openssl.org #4062] [PATCH] Fix build failure In-Reply-To: <20150925131603.GA17219@kronk.local> References: <20150925131603.GA17219@kronk.local> Message-ID: Patch applied. Thanks. Matt From rt at openssl.org Fri Sep 25 14:09:10 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 14:09:10 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: Closing this ticket. Please use the API suggested by Steve. Matt From hkario at redhat.com Fri Sep 25 14:14:46 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 25 Sep 2015 16:14:46 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <2902110.0tSk9Xvkbz@pintsize.usersys.redhat.com> References: <5605249B.1080605@openssl.org> <2902110.0tSk9Xvkbz@pintsize.usersys.redhat.com> Message-ID: <2036813.2p2IiB1MtJ@pintsize.usersys.redhat.com> On Friday 25 September 2015 14:20:40 Hubert Kario wrote: > On Friday 25 September 2015 11:40:27 Matt Caswell wrote: > > On 25/09/15 11:25, Hubert Kario via RT wrote: > > > On Friday 25 September 2015 10:47:42 Matt Caswell wrote: > > >> However, I have some concerns with the wording of the RFC. It > > >> seems > > >> to place no limits whatsoever on when it is valid to receive app > > >> data in the handshake. By the wording in the RFC it would be > > >> valid > > >> for app data to be received *after* the ChangeCipherSpec has been > > >> received but *before* the Finished has been processed. This seems > > >> dangerous to me because it is not until the Finished is processed > > >> that we verify the handshake data MAC - and yet we could already > > >> have acted upon app data received. I assume the intent was to > > >> allow the interleaved app data only up until the point that the > > >> CCS is received. I have attached a patch for 1.0.2 that > > >> implements > > >> that logic. > > > > > > yes, I think the only place in which the handshake protocol and > > > application data _can't_ be interleaved is between the CCS and > > > Finished. > > > > It would be nice to have a test for that wouldn't it ;-) > > yeah, but it will be hard to do, you know, with it requiring an TLS > implementation to misbehave ;) > > I'll make one as soon as I'll finish the test cases for record layer > fragmentation of initial Client Hello (there are few bugs there too) and done, in the same repo just run scripts/test-interleaved-application-data-in-renegotiation.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Fri Sep 25 14:51:17 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 14:51:17 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925145105.GA25726@kronk.local> References: <20150925135548.GA17952@kronk.local> <3023376.mUGYYq7pVs@pintsize.usersys.redhat.com> <20150925145105.GA25726@kronk.local> Message-ID: On Fri, Sep 25, 2015 at 02:02:36pm +0000, Hubert Kario via RT wrote: > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote: > > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT wrote: > > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > > > IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think the > > problem is that OpenSSL only checks for that. > > yes, it does place a limit of 2^14, but only on _records_, not handshake > messages that travel in those records > > > I think a proper fix would be to have all the ssl_get_message() calls > > changed to use the proper "max" parameter depending on the protocol > > version. > > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly the > same as in they don't specify any upper size limit for the Handshake > protocol messages or Client Hello specifically other than the limits > enforced by the length fields themselves. > > Remember, the records are completely independent of messages that travel > through them, record layer is just there to multiplex the different > protocols that are required for TLS to work (handshake, CCS, application > data, etc.) Right. Some of the handshake messages do have a maximum length though (e.g. ChangeCipherSpace), so the maximum length check shouldn't be removed (as a sanity check). In the case of ClientHello, the minimal fix for the problem then is just a matter of finding the absolute maximum it can hold (which may as well be whatever the Handshake length field maximum value is). As a matter of test I changed the ssl_get_message() in ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, and the tlsfuzzer failures went from 5 to 2, are all the tests supposed to pass? If so, then there's another problem as well. Cheers From rt at openssl.org Fri Sep 25 15:02:27 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 15:02:27 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> References: <20150925145105.GA25726@kronk.local> <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 02:02:36pm +0000, Hubert Kario via RT wrote: > > On Friday 25 September 2015 13:55:56 Alessandro Ghedini via RT wrote: > > > On Fri, Sep 25, 2015 at 01:20:12pm +0000, Hubert Kario via RT wrote: > > > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > > > > > IIRC SSLv3 does place the limit at 2^14 or so bytes, so I think > > > the > > > problem is that OpenSSL only checks for that. > > > > yes, it does place a limit of 2^14, but only on _records_, not > > handshake messages that travel in those records > > > > > I think a proper fix would be to have all the ssl_get_message() > > > calls > > > changed to use the proper "max" parameter depending on the > > > protocol > > > version. > > > > As far as I can tell, SSLv3, TLS1.0, TLS1.1 and TLS1.2 are exactly > > the same as in they don't specify any upper size limit for the > > Handshake protocol messages or Client Hello specifically other than > > the limits enforced by the length fields themselves. > > > > Remember, the records are completely independent of messages that > > travel through them, record layer is just there to multiplex the > > different protocols that are required for TLS to work (handshake, > > CCS, application data, etc.) > > Right. Some of the handshake messages do have a maximum length though > (e.g. ChangeCipherSpace), so the maximum length check shouldn't be > removed (as a sanity check). In the case of ClientHello, the minimal > fix for the problem then is just a matter of finding the absolute > maximum it can hold (which may as well be whatever the Handshake > length field maximum value is). the protocol states that the message must have all bytes accounted for if the implementation supports extensions, so if there is data trailing extensions array, its a protocol violation (I'm working on test cases for that right now) > As a matter of test I changed the ssl_get_message() in > ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, it doesn't have in theory, but it does in practice, as extensions can only be 2^16 long, same for cipher suites, and you can't have data trailing the messages, so the actual size is limited to something closer 2^18, so if the client hello parser is correct, it will be limited by it > and the tlsfuzzer failures went from 5 to 2, are all the tests > supposed to pass? If so, then there's another problem as well. yes, there are also tests for record layer carrying the data in 1 byte chunks. The specification disallows only empty record layer messages. But it is less severe, as it doesn't cause a de-facto TLS extension intolerance. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 15:37:40 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 15:37:40 +0000 Subject: [openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <56056954.1010002@openssl.org> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 25/09/15 14:19, Hubert Kario wrote: > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > branches reject Client Hello messages bigger than 2^14+4 bytes. Right. The reason for that is that there is an explicit (deliberate) check for it. Each message in its call to ssl_get_message specifies the max size. For ClientHello: n = s->method->ssl_get_message(s, SSL3_ST_SR_CLNT_HELLO_B, SSL3_ST_SR_CLNT_HELLO_C, SSL3_MT_CLIENT_HELLO, SSL3_RT_MAX_PLAIN_LENGTH, &ok); The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH (=16384, or the max possible size that can fit into a single record). Every message has one of these defined. Some of them are quite arbitrary values. E.g. for ServerHello n = s->method->ssl_get_message(s, SSL3_ST_CR_SRVR_HELLO_A, SSL3_ST_CR_SRVR_HELLO_B, -1, 20000, &ok); Why 20000? No idea. The same restriction exists in the state-machine-rewrite branches because I'm ultra-cautious. I am reluctant to remove an explicit check like that without understanding why it's there in the first place. Especially if its not breaking anything. Are we ever likely to encounter a ClientHello > 16384 bytes? Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWBWlUAAoJENnE0m0OYESR0GUIAKPpYctFSqG7RVtPI8mKdw75 Ml+18+fOh4QE6RoKVLoBB3FglAZujZ8RMXlOZ6bivF8KrLygoAT6ECF/a0ee3kpk UAlYOY9HEHistlY+BeAs0jx2VsAKb10mO+Z+C6jV+Uql2GSTFqzrdGSdS6pxOuL1 EJr4WFh32sj+ApvTpDw6XVuvNypVpoEY5KeDj+4ZPKnQdp/TcoErLEzIgzIsGm7b FNXkpgTy8Xamr+S6afQYgNi6MOlHIIRlOXkDqkOyRpjHfqLU748EympIUkWNq8EZ dw8Sxk6PRTe9BqgtjX10benF3K7N9yuli2sLHoHFZvwTVqWvNqMgA2jyJIoCgM8= =bEaO -----END PGP SIGNATURE----- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 25 15:39:13 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 15:39:13 +0000 Subject: [openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <56056954.1010002@openssl.org> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> Message-ID: Gahhh....didn't mean to open this as a new ticket. Closing. From appro at openssl.org Fri Sep 25 15:49:52 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 25 Sep 2015 17:49:52 +0200 Subject: [openssl-dev] Making assembly language optimizations working on Cortex-M3 In-Reply-To: <55C873B8.9060602@openssl.org> References: <55C4DC74.6060900@openssl.org> <55C873B8.9060602@openssl.org> Message-ID: <56056D20.9020806@openssl.org> >> > and recognize two new settings, >> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this. >> >> While NO_NEON might make sense, I really see no reason to introduce >> THUMB_ONLY. Because pre-defines set by the compiler driver are >> sufficient. >> >> >> You mean, using __thumb__ (predefined for both thumb1 and thumb2) >> and __thumb2__ (predefined for thumb2 only)? > > Yes. http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=11208dcfb9105e8afa37233185decefd45e89e17 made whole assembly pack Thumb2-friendly, so that now you should be able to compile all modules. Please, double-check. There is no option to disable NEON (yet?), because a) I want to expose it to more build cases to catch eventual bugs; b) would like to suggest idea of supporting Cortex-M with -march=armv6t2 -mthumb. Latter means that you'll loose some performance, because it won't utilize word load instruction's capability to handle misaligned access in ARMv7. But on the other hand it won't have ideas about compiling NEON, and you'll be excused to think about which particular Cortex-M is targeted, one will be able to cover all with single config/buid. Can it be viable compromise? One would still be able to tune for favorite Mx... From rt at openssl.org Fri Sep 25 16:05:09 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 16:05:09 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925160458.GA9339@kronk.local> References: <20150925145105.GA25726@kronk.local> <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> <20150925160458.GA9339@kronk.local> Message-ID: On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: > On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: > > As a matter of test I changed the ssl_get_message() in > > ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, > > it doesn't have in theory, but it does in practice, as extensions can > only be 2^16 long, same for cipher suites, and you can't have data > trailing the messages, so the actual size is limited to something closer > 2^18, so if the client hello parser is correct, it will be limited by it Yeah, but OpenSSL first tries to "get" the handshake body and its length before parsing it (this is done by ssl3_get_message()). So the "max" argument is intended to be used, I imagine, as a sanity check: if the message exceeds that, then it's obviously broken and an "illegal parameters" alert is sent. This is done regardless of the message type, so the ClientHello parser has to do this as well. This max length check is not exactly smart (e.g. the max size of the SSLv3 ClientHello is very different from that of TLS) and could probably be removed completely, but I don't really know what the consequences of this would be. So the best next fix would simply be to provide an approximation of an absolute maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull request [0] with just this minimal fix. Anyone is very welcome to propose a better fix for this though. How trailing data is then handled is orthogonal to this problem (the length check doesn't really affect this). It might be that OpenSSL handles it correctly or not, I don't really know (and having the tlsfuzzer test for this will be very useful). Cheers [0] https://github.com/openssl/openssl/pull/413 From matt at openssl.org Fri Sep 25 16:17:30 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Sep 2015 17:17:30 +0100 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: References: <20150925145105.GA25726@kronk.local> <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> <20150925160458.GA9339@kronk.local> Message-ID: <5605739A.6080206@openssl.org> On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: >>> As a matter of test I changed the ssl_get_message() in >>> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, >> >> it doesn't have in theory, but it does in practice, as extensions can >> only be 2^16 long, same for cipher suites, and you can't have data >> trailing the messages, so the actual size is limited to something closer >> 2^18, so if the client hello parser is correct, it will be limited by it > > Yeah, but OpenSSL first tries to "get" the handshake body and its length before > parsing it (this is done by ssl3_get_message()). So the "max" argument is > intended to be used, I imagine, as a sanity check: if the message exceeds that, > then it's obviously broken and an "illegal parameters" alert is sent. This is > done regardless of the message type, so the ClientHello parser has to do this > as well. > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > ClientHello is very different from that of TLS) and could probably be removed > completely, but I don't really know what the consequences of this would be. So > the best next fix would simply be to provide an approximation of an absolute > maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull > request [0] with just this minimal fix. Anyone is very welcome to propose a > better fix for this though. 0xffffff = 16777215 or 16Mb Allowing a ClientHello as big as this could enable a DoS attack. If I did my sums right I make the biggest possible valid ClientHello to be 131396. But should we allow something as big as this just because its theoretically possible? Matt From rt at openssl.org Fri Sep 25 16:17:33 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 25 Sep 2015 16:17:33 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <5605739A.6080206@openssl.org> References: <20150925145105.GA25726@kronk.local> <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> <20150925160458.GA9339@kronk.local> <5605739A.6080206@openssl.org> Message-ID: On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: >>> As a matter of test I changed the ssl_get_message() in >>> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, >> >> it doesn't have in theory, but it does in practice, as extensions can >> only be 2^16 long, same for cipher suites, and you can't have data >> trailing the messages, so the actual size is limited to something closer >> 2^18, so if the client hello parser is correct, it will be limited by it > > Yeah, but OpenSSL first tries to "get" the handshake body and its length before > parsing it (this is done by ssl3_get_message()). So the "max" argument is > intended to be used, I imagine, as a sanity check: if the message exceeds that, > then it's obviously broken and an "illegal parameters" alert is sent. This is > done regardless of the message type, so the ClientHello parser has to do this > as well. > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > ClientHello is very different from that of TLS) and could probably be removed > completely, but I don't really know what the consequences of this would be. So > the best next fix would simply be to provide an approximation of an absolute > maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull > request [0] with just this minimal fix. Anyone is very welcome to propose a > better fix for this though. 0xffffff = 16777215 or 16Mb Allowing a ClientHello as big as this could enable a DoS attack. If I did my sums right I make the biggest possible valid ClientHello to be 131396. But should we allow something as big as this just because its theoretically possible? Matt From rt at openssl.org Fri Sep 25 16:23:27 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 16:23:27 +0000 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 16:33:40 Matt Caswell wrote: > On 25/09/15 14:19, Hubert Kario wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > Right. The reason for that is that there is an explicit (deliberate) > check for it. Each message in its call to ssl_get_message specifies > the max size. For ClientHello: > > n = s->method->ssl_get_message(s, > SSL3_ST_SR_CLNT_HELLO_B, > SSL3_ST_SR_CLNT_HELLO_C, > SSL3_MT_CLIENT_HELLO, > SSL3_RT_MAX_PLAIN_LENGTH, &ok); > > The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH > (=16384, or the max possible size that can fit into a single record). well, except that this doesn't include the message type and message length fields, so the message (from the point of view of record layer) is actually 2^14+4 bytes so it won't fit into a single record :) the actual maximum size is: 4 + # handshake protocol header 2 + # client_version 32 + # only valid length for random 1 + # length of session_id 32 + # maximum size for session_id 2 + # length of cipher suites 2^16-2 + # maximum length of cipher suites array 1 + # length of compression_methods 2^8-1 + # maximum length of compression methods 2 + # length of extensions 2^16-1 # maximum length of extensions = 131400 or 131396 without header > Every message has one of these defined. Some of them are quite > arbitrary values. > > E.g. for ServerHello > n = s->method->ssl_get_message(s, > SSL3_ST_CR_SRVR_HELLO_A, > SSL3_ST_CR_SRVR_HELLO_B, -1, 20000, > &ok); > > Why 20000? No idea. > > The same restriction exists in the state-machine-rewrite branches > because I'm ultra-cautious. entirely understandable > I am reluctant to remove an explicit check > like that without understanding why it's there in the first place. > Especially if its not breaking anything. Are we ever likely to > encounter a ClientHello > 16384 bytes? with actual TLSv1.2? likely "nothing" and "never". But the same could have been said about version number not being anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how well this turned out to be... Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends up as an extension, possibly multiple ones), and that quantum computing resistant algorithms usually require fairly large key sizes (large enough that protocol limitations itself are problematic), we may see Client Hellos larger than 16k in not so far future. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Sep 25 16:25:01 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 16:25:01 +0000 Subject: [openssl-dev] [openssl.org #4063] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <7113502.DDnHN6Szt1@pintsize.usersys.redhat.com> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <7113502.DDnHN6Szt1@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 16:33:40 Matt Caswell wrote: > On 25/09/15 14:19, Hubert Kario wrote: > > Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite > > branches reject Client Hello messages bigger than 2^14+4 bytes. > > Right. The reason for that is that there is an explicit (deliberate) > check for it. Each message in its call to ssl_get_message specifies > the max size. For ClientHello: > > n = s->method->ssl_get_message(s, > SSL3_ST_SR_CLNT_HELLO_B, > SSL3_ST_SR_CLNT_HELLO_C, > SSL3_MT_CLIENT_HELLO, > SSL3_RT_MAX_PLAIN_LENGTH, &ok); > > The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH > (=16384, or the max possible size that can fit into a single record). well, except that this doesn't include the message type and message length fields, so the message (from the point of view of record layer) is actually 2^14+4 bytes so it won't fit into a single record :) the actual maximum size is: 4 + # handshake protocol header 2 + # client_version 32 + # only valid length for random 1 + # length of session_id 32 + # maximum size for session_id 2 + # length of cipher suites 2^16-2 + # maximum length of cipher suites array 1 + # length of compression_methods 2^8-1 + # maximum length of compression methods 2 + # length of extensions 2^16-1 # maximum length of extensions = 131400 or 131396 without header > Every message has one of these defined. Some of them are quite > arbitrary values. > > E.g. for ServerHello > n = s->method->ssl_get_message(s, > SSL3_ST_CR_SRVR_HELLO_A, > SSL3_ST_CR_SRVR_HELLO_B, -1, 20000, > &ok); > > Why 20000? No idea. > > The same restriction exists in the state-machine-rewrite branches > because I'm ultra-cautious. entirely understandable > I am reluctant to remove an explicit check > like that without understanding why it's there in the first place. > Especially if its not breaking anything. Are we ever likely to > encounter a ClientHello > 16384 bytes? with actual TLSv1.2? likely "nothing" and "never". But the same could have been said about version number not being anything but 3.0 or 3.1 when TLSv1.0 was published, and we all know how well this turned out to be... Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends up as an extension, possibly multiple ones), and that quantum computing resistant algorithms usually require fairly large key sizes (large enough that protocol limitations itself are problematic), we may see Client Hellos larger than 16k in not so far future. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 16:36:00 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 16:36:00 +0000 Subject: [openssl-dev] [openssl.org #4065] AutoReply: Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <2943455.quhynR1obn@pintsize.usersys.redhat.com> References: <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <2943455.quhynR1obn@pintsize.usersys.redhat.com> Message-ID: sorry, duplicate of #4063, please close -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 16:54:02 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 16:54:02 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925165353.GA32505@kronk.local> References: <20150925145105.GA25726@kronk.local> <1983840.ZyDZYCzqam@pintsize.usersys.redhat.com> <20150925160458.GA9339@kronk.local> <5605739A.6080206@openssl.org> <20150925165353.GA32505@kronk.local> Message-ID: On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote: > > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: > >>> As a matter of test I changed the ssl_get_message() in > >>> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum size, > >> > >> it doesn't have in theory, but it does in practice, as extensions can > >> only be 2^16 long, same for cipher suites, and you can't have data > >> trailing the messages, so the actual size is limited to something closer > >> 2^18, so if the client hello parser is correct, it will be limited by it > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its length before > > parsing it (this is done by ssl3_get_message()). So the "max" argument is > > intended to be used, I imagine, as a sanity check: if the message exceeds that, > > then it's obviously broken and an "illegal parameters" alert is sent. This is > > done regardless of the message type, so the ClientHello parser has to do this > > as well. > > > > This max length check is not exactly smart (e.g. the max size of the SSLv3 > > ClientHello is very different from that of TLS) and could probably be removed > > completely, but I don't really know what the consequences of this would be. So > > the best next fix would simply be to provide an approximation of an absolute > > maximum length for the ClientHello (or just use 0xFFFFFF). I opened a pull > > request [0] with just this minimal fix. Anyone is very welcome to propose a > > better fix for this though. > > 0xffffff = 16777215 or 16Mb > > Allowing a ClientHello as big as this could enable a DoS attack. > > If I did my sums right I make the biggest possible valid ClientHello to > be 131396. I updated my patch to use this value now. > But should we allow something as big as this just because its > theoretically possible? As a way of future-proofing OpenSSL (Hubert mentioned a few reasons) or just to be more standard-compliant I'd say yes, but it's obviously not an urgent problem. FWIW I checked a couple of TLS implementations I have around (GnuTLS and s2n), and AFAICT they don't check for a maximum size at all. Cheers From hkario at redhat.com Fri Sep 25 17:06:31 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 25 Sep 2015 19:06:31 +0200 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: References: <20150925165353.GA32505@kronk.local> Message-ID: <2302241.KavHYMYfUb@pintsize.usersys.redhat.com> (since we're not talking about OpenSSL any more, I'm dropping the RT) On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > FWIW I checked a couple of TLS implementations I have around (GnuTLS > and s2n), and AFAICT they don't check for a maximum size at all. what do you mean by that? As we've said with Matt, you can't create a valid Client Hello bigger than 131396 bytes... or do you mean that they accept malformed Client Hello messages? or that they do accept SSLv3 Client Hellos with arbitrary sized junk at the end? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Fri Sep 25 17:11:39 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 25 Sep 2015 17:11:39 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <1613070.baSY88TkD9@pintsize.usersys.redhat.com> References: <20150925165353.GA32505@kronk.local> <1613070.baSY88TkD9@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote: > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT wrote: > > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote: > > >>> As a matter of test I changed the ssl_get_message() in > > >>> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum > > >>> size, > > >> > > >> it doesn't have in theory, but it does in practice, as extensions > > >> can > > >> only be 2^16 long, same for cipher suites, and you can't have > > >> data > > >> trailing the messages, so the actual size is limited to something > > >> closer 2^18, so if the client hello parser is correct, it will > > >> be limited by it> > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its > > > length before parsing it (this is done by ssl3_get_message()). So > > > the "max" argument is intended to be used, I imagine, as a sanity > > > check: if the message exceeds that, then it's obviously broken > > > and an "illegal parameters" alert is sent. This is done > > > regardless of the message type, so the ClientHello parser has to > > > do this as well. > > > > > > This max length check is not exactly smart (e.g. the max size of > > > the SSLv3 ClientHello is very different from that of TLS) and > > > could probably be removed completely, but I don't really know > > > what the consequences of this would be. So the best next fix > > > would simply be to provide an approximation of an absolute > > > maximum length for the ClientHello (or just use 0xFFFFFF). I > > > opened a pull request [0] with just this minimal fix. Anyone is > > > very welcome to propose a better fix for this though. > > > > 0xffffff = 16777215 or 16Mb > > > > Allowing a ClientHello as big as this could enable a DoS attack. > > > > If I did my sums right I make the biggest possible valid ClientHello > > to be 131396. > > I updated my patch to use this value now. embedding magic values is rather bad form. A define with extended comment describing how we arrived at this value would be much better -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From alessandro at ghedini.me Fri Sep 25 17:29:41 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 25 Sep 2015 19:29:41 +0200 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <2302241.KavHYMYfUb@pintsize.usersys.redhat.com> References: <20150925165353.GA32505@kronk.local> <2302241.KavHYMYfUb@pintsize.usersys.redhat.com> Message-ID: <20150925172940.GA982@kronk.local> On Fri, Sep 25, 2015 at 07:06:31PM +0200, Hubert Kario wrote: > (since we're not talking about OpenSSL any more, I'm dropping the RT) > > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > > FWIW I checked a couple of TLS implementations I have around (GnuTLS > > and s2n), and AFAICT they don't check for a maximum size at all. > > what do you mean by that? As we've said with Matt, you can't create a > valid Client Hello bigger than 131396 bytes... > > or do you mean that they accept malformed Client Hello messages? > or that they do accept SSLv3 Client Hellos with arbitrary sized junk at > the end? No and no. I meant that OpenSSL seems to be the only implementation (among the ones that I checked) to perform maximum length checks on handshake messages. That is, checking that the message doesn't exceed a pre-defined maximum length by only looking at the message type and length fields, before even trying to parse the message body. The fact that the other libraries don't do this check at all suggests that increasing the limit in OpenSSL (or even removing the limit completely) shouldn't affect it negatively. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Sep 25 17:35:56 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 25 Sep 2015 17:35:56 +0000 Subject: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925173553.GA7811@kronk.local> References: <20150925165353.GA32505@kronk.local> <1613070.baSY88TkD9@pintsize.usersys.redhat.com> <20150925173553.GA7811@kronk.local> Message-ID: On Fri, Sep 25, 2015 at 05:11:39pm +0000, Hubert Kario via RT wrote: > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > > On Fri, Sep 25, 2015 at 04:17:33PM +0000, Matt Caswell via RT wrote: > > > On 25/09/15 17:05, Alessandro Ghedini via RT wrote: > > > > On Fri, Sep 25, 2015 at 03:02:27pm +0000, Hubert Kario via RT > wrote: > > > >> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT > wrote: > > > >>> As a matter of test I changed the ssl_get_message() in > > > >>> ssl3_get_client_hello() to use 0xFFFFFF (uint24 max) as maximum > > > >>> size, > > > >> > > > >> it doesn't have in theory, but it does in practice, as extensions > > > >> can > > > >> only be 2^16 long, same for cipher suites, and you can't have > > > >> data > > > >> trailing the messages, so the actual size is limited to something > > > >> closer 2^18, so if the client hello parser is correct, it will > > > >> be limited by it> > > > > > Yeah, but OpenSSL first tries to "get" the handshake body and its > > > > length before parsing it (this is done by ssl3_get_message()). So > > > > the "max" argument is intended to be used, I imagine, as a sanity > > > > check: if the message exceeds that, then it's obviously broken > > > > and an "illegal parameters" alert is sent. This is done > > > > regardless of the message type, so the ClientHello parser has to > > > > do this as well. > > > > > > > > This max length check is not exactly smart (e.g. the max size of > > > > the SSLv3 ClientHello is very different from that of TLS) and > > > > could probably be removed completely, but I don't really know > > > > what the consequences of this would be. So the best next fix > > > > would simply be to provide an approximation of an absolute > > > > maximum length for the ClientHello (or just use 0xFFFFFF). I > > > > opened a pull request [0] with just this minimal fix. Anyone is > > > > very welcome to propose a better fix for this though. > > > > > > 0xffffff = 16777215 or 16Mb > > > > > > Allowing a ClientHello as big as this could enable a DoS attack. > > > > > > If I did my sums right I make the biggest possible valid ClientHello > > > to be 131396. > > > > I updated my patch to use this value now. > > embedding magic values is rather bad form. > A define with extended comment describing how we arrived at this value > would be much better Fair enough. Updated the patch again to do this. Cheers From dnsands at sandia.gov Fri Sep 25 17:44:58 2015 From: dnsands at sandia.gov (Sands, Daniel) Date: Fri, 25 Sep 2015 17:44:58 +0000 Subject: [openssl-dev] [EXTERNAL] Re: [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925172940.GA982@kronk.local> References: <20150925165353.GA32505@kronk.local> <2302241.KavHYMYfUb@pintsize.usersys.redhat.com> <20150925172940.GA982@kronk.local> Message-ID: > > On Friday 25 September 2015 16:54:02 Alessandro Ghedini via RT wrote: > > > FWIW I checked a couple of TLS implementations I have around (GnuTLS > > > and s2n), and AFAICT they don't check for a maximum size at all. > > > > what do you mean by that? As we've said with Matt, you can't create a > > valid Client Hello bigger than 131396 bytes... > > The fact that the other libraries don't do this check at all suggests that > increasing the limit in OpenSSL (or even removing the limit completely) > shouldn't affect it negatively. Actually it suggests that they don't do their due diligence. If there is not a valid Hello message that is greater than 131396 bytes, then there is no reason to allow for one either. On the contrary, there is every reason to protect oneself from Godzillagrams. From rt at openssl.org Fri Sep 25 18:54:42 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 25 Sep 2015 18:54:42 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: On Thu Sep 24 11:52:05 2015, steve wrote: > > I've tried a newer version of VC++ and I also get the "No Applink" > error when > it is trying to embed the fingerprint in libeay32.dll. I'll see if > this can be > fixed. Please try the attached patch. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- A non-text attachment was scrubbed... Name: diffs.applink Type: application/octet-stream Size: 1046 bytes Desc: not available URL: From kurt at roeckx.be Fri Sep 25 19:19:02 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 25 Sep 2015 21:19:02 +0200 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> Message-ID: <20150925191902.GA22214@roeckx.be> On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote: > > Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends > up as an extension, possibly multiple ones), and that quantum computing > resistant algorithms usually require fairly large key sizes (large > enough that protocol limitations itself are problematic), we may see > Client Hellos larger than 16k in not so far future. Since we don't actually know how things are going to change in the future and that they can change the maximum size of a Client Hello, it makes sense to me to not enforce a limit for the Client Hello message just because that's what the current version only supports. For all other messages we should be able to tell what the maximum size is. Kurt From rt at openssl.org Fri Sep 25 19:19:12 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 25 Sep 2015 19:19:12 +0000 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925191902.GA22214@roeckx.be> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <20150925191902.GA22214@roeckx.be> Message-ID: On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote: > > Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends > up as an extension, possibly multiple ones), and that quantum computing > resistant algorithms usually require fairly large key sizes (large > enough that protocol limitations itself are problematic), we may see > Client Hellos larger than 16k in not so far future. Since we don't actually know how things are going to change in the future and that they can change the maximum size of a Client Hello, it makes sense to me to not enforce a limit for the Client Hello message just because that's what the current version only supports. For all other messages we should be able to tell what the maximum size is. Kurt From openssl-users at dukhovni.org Fri Sep 25 20:14:29 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 25 Sep 2015 20:14:29 +0000 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925191902.GA22214@roeckx.be> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <20150925191902.GA22214@roeckx.be> Message-ID: <20150925201428.GC21942@mournblade.imrryr.org> On Fri, Sep 25, 2015 at 09:19:02PM +0200, Kurt Roeckx wrote: > Since we don't actually know how things are going to change in the > future and that they can change the maximum size of a Client > Hello, it makes sense to me to not enforce a limit for the Client > Hello message just because that's what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. There's no such thing as "no limit". If the client HELLO retains its basic structure, it needs to retain the same limits. If the limits change, that's a new protocol message that is no longer an SSLv3/TLSv1.0 compatible client HELLO. The published limits from TLS 1.2 cannot change in TLS 1.3, if TLS 1.3 HELLO messages are to be understood by TLS 1.2 servers. -- Viktor. From matt at openssl.org Fri Sep 25 22:44:46 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Sep 2015 23:44:46 +0100 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150925191902.GA22214@roeckx.be> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <20150925191902.GA22214@roeckx.be> Message-ID: <5605CE5E.7040700@openssl.org> On 25/09/15 20:19, Kurt Roeckx wrote: > On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote: >> >> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends >> up as an extension, possibly multiple ones), and that quantum computing >> resistant algorithms usually require fairly large key sizes (large >> enough that protocol limitations itself are problematic), we may see >> Client Hellos larger than 16k in not so far future. > > Since we don't actually know how things are going to change in the > future and that they can change the maximum size of a Client > Hello, it makes sense to me to not enforce a limit for the Client > Hello message just because that's what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. If the ClientHello message is longer than 131396 bytes then either we are under some kind attack, or it is in some future format that we do not understand and is not backwards compatible (a requirement of backwards compatibility would be that it is under or equal to that limit). Either way we should drop the message. My concern is whether we should have a limit that is less than that. A default s_client ClientHello on master at the moment is 364 bytes. A default ClientHello with a ticket is 556 bytes. The biggest ClientHello I can induce from s_client is one including a ticket and a cipher string of "ALL:@SECLEVEL=0" which leads to 618 bytes. I recognise that we are talking about future proofing; but the current limit of 16384 already gives us the ability to accept ClientHello's 26 times bigger than the biggest s_client can create today. That is significant room for future growth. On the other side of the coin handling very large ClientHello's is not without cost and risk. There is bandwidth consumption, memory consumption, CPU consumption handling any operations required from the ClientHello (e.g. decrypting an enormous SessionTicket) etc. We also have to bear in mind the OpenSSL doesn't necessarily just run on big powerful servers in datacentres. It can also runs in very resource constrained environments. We potentially open up our users to DoS attacks by attempting to accept these "godzillagram" (as someone called them) ClientHellos. Right now, today, if a server starts receiving ClientHello's that big then it is almost certainly an attack. Increasing the maximum size over what we have today increases the risk of attacks right now. Of course we don't know what the future will bring. I'm struggling to foresee a scenario where we have a vast explosion in the ciphersuites available (which is where a significant proportion of the "allowed" ClientHello size is allocated) - but I guess it could happen. Possibly more likely is some new extension(s) requiring very large extension data blocks. Still, whatever that extension is, it would have to be *massively* bigger than any extension we have today to blow the existing limit - and absolutely HUGE to go anywhere near 131396. The latency costs of managing such large ClientHello's would be significant so I am really finding it hard to see a future where ClientHello's get even close to approaching the kind of sizes we're talking about. So why would we open up our users today to increased risks for a future that seems quite unlikely? So, what I'm trying to say is it's a balancing act. We shouldn't just accept the biggest possible messages that we can just because that gives us the best interoperability for the future. There are other considerations. Matt From rsalz at akamai.com Sat Sep 26 00:17:20 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 26 Sep 2015 00:17:20 +0000 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <5605CE5E.7040700@openssl.org> References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <20150925191902.GA22214@roeckx.be> <5605CE5E.7040700@openssl.org> Message-ID: > On the other side of the coin handling very large ClientHello's is not without > cost and risk. As long as it's a #define that can be changed in ssl.h (or a runtime global? Ick) we should be okay. From phpdev at ehrhardt.nl Sat Sep 26 00:46:26 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Sat, 26 Sep 2015 02:46:26 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: <0lqb0b5m6vpr12puudogfpr35gqi8fs2hb@4ax.com> Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Fri, 25 Sep 2015 18:54:42 +0000): >On Thu Sep 24 11:52:05 2015, steve wrote: >> >> I've tried a newer version of VC++ and I also get the "No Applink" >> error when >> it is trying to embed the fingerprint in libeay32.dll. I'll see if >> this can be >> fixed. > >Please try the attached patch. X64: passed all tests C:\OpensslVC14.x64\openssl>out32dll\openssl version OpenSSL 1.0.2d-fips 9 Jul 2015 -- Jan From openssl-users at dukhovni.org Sat Sep 26 01:02:15 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 26 Sep 2015 01:02:15 +0000 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: References: <2666857.mJb7Wub1ca@pintsize.usersys.redhat.com> <56056954.1010002@openssl.org> <2347005.W6PQb4aIbL@pintsize.usersys.redhat.com> <20150925191902.GA22214@roeckx.be> <5605CE5E.7040700@openssl.org> Message-ID: <20150926010215.GF21942@mournblade.imrryr.org> On Sat, Sep 26, 2015 at 12:17:20AM +0000, Salz, Rich wrote: > > On the other side of the coin handling very large ClientHello's is not without > > cost and risk. > > As long as it's a #define that can be changed in ssl.h (or a runtime global? Ick) we should be okay. It would have to more configurable than that to be worth the bother. All sorts of "appliance" products with OpenSSL inside would potentially some day pose a barrier to interoperability with clients that send large HELLO messages. I should note that server side session state can also contain a client certificate, which is then embedded in the session ticket. So the outer limits of current practice are somewhat bigger. We could perhaps increase the limit from 16K to 32K bytes, just in case that helps, and hope that the result does not expose servers to significantly higher risk of DoS. Or raise the issue on the TLS WG. Are servers really expected to support up to 128K or so of client HELLO? -- Viktor. From phpdev at ehrhardt.nl Sat Sep 26 02:29:00 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Sat, 26 Sep 2015 04:29:00 +0200 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> Message-ID: <1m0c0b1s4v9cupi9cdpuegc7ld2j0l0h7d@4ax.com> Stephen Henson via RT in gmane.comp.encryption.openssl.devel (Fri, 25 Sep 2015 18:54:42 +0000): >On Thu Sep 24 11:52:05 2015, steve wrote: >> >> I've tried a newer version of VC++ and I also get the "No Applink" >> error when >> it is trying to embed the fingerprint in libeay32.dll. I'll see if >> this can be >> fixed. > >Please try the attached patch. X86: passed all tests C:\OpensslVC14.x86\openssl>out32dll\openssl version OpenSSL 1.0.2d-fips 9 Jul 2015 -- Jan From alessandro at ghedini.me Sat Sep 26 09:12:52 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Sat, 26 Sep 2015 11:12:52 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <5602AFBE.4090407@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> Message-ID: <20150926091251.GA20827@kronk.local> On Wed, Sep 23, 2015 at 03:57:18PM +0200, Andy Polyakov wrote: > > And the mingw build is broken anyway. > > For the record, originally mingw was supported by itself, i.e. under > MSYS, and under cygwin (which is why you'll notice -mno-cygwin). Then is > was empirically confirmed that it works even with cross-compiler under > Linux. But it more than likely happened with 1.0, so that assuming that > 0.9.8 would work was in fact a stretch. > > > Is this something worth fixing in a future > > 0.9.8 release? > > I'd vote against. > > > Otherwise the mingw builds could be simply removed from travis > > for 0.9.8. > > > > Other builds failing are: > > > > - linux-gcc and mingw debug builds in 1.0.2 (I haven't tried to reproduce > > these yet). > > No comment at this point. > > > - mingw debug and shared builds in master. > > While I can confirm problem with shared (fixable with attached patch, > please double-check), I can't confirm problem with debug (please elaborate). I just opened a pull request on GitHub [0] to add your patch for mingw shared builds and another one to fix clang debug builds for master. Let's see what Travis thinks of it. Mingw's debug builds are still broken, but now the following error message is shown: > cc1: error: command line option ?-foutput-class-dir=-DL_ENDIAN? is valid for Java but not for C [-Werror] The problem is that `-d` is a `./config` option, but in the case of mingw it is passed directly to `./Configure` which thinks it's a compiler flag so then gcc gets confused. A solution would be to somehow detect the mingw cross compilation from `./config` so that we would use it for mingw builds too, but I'm not sure what the best way to do that would be (and on top of this we still have the mingw warnings problem). Cheers [0] https://github.com/openssl/openssl/pull/415 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dlmeetei at gmail.com Sat Sep 26 16:18:35 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Sat, 26 Sep 2015 21:48:35 +0530 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: Sure, Sorry for the noise. and Thanks Steve. is the API introduced recently openssl 1.0.1f does not seem to have it? if so, any plan to backport it? On Fri, Sep 25, 2015 at 7:39 PM, Matt Caswell via RT wrote: > Closing this ticket. Please use the API suggested by Steve. > > Matt > > -- 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 -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Sep 26 16:18:48 2015 From: rt at openssl.org (Devchandra L Meetei via RT) Date: Sat, 26 Sep 2015 16:18:48 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: Sure, Sorry for the noise. and Thanks Steve. is the API introduced recently openssl 1.0.1f does not seem to have it? if so, any plan to backport it? On Fri, Sep 25, 2015 at 7:39 PM, Matt Caswell via RT wrote: > Closing this ticket. Please use the API suggested by Steve. > > Matt > > -- 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 From rt at openssl.org Sat Sep 26 16:26:33 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 26 Sep 2015 16:26:33 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: <5606C737.1080204@openssl.org> References: <5606C737.1080204@openssl.org> Message-ID: On 26/09/15 17:18, Devchandra L Meetei via RT wrote: > Sure, Sorry for the noise. > and Thanks Steve. > > is the API introduced recently openssl 1.0.1f does not seem to have it? > > if so, any plan to backport it? This was introduced in 1.0.2. There are no plans to backport it. Regards Matt From openssl-users at dukhovni.org Sat Sep 26 16:31:08 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 26 Sep 2015 16:31:08 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: <5606C737.1080204@openssl.org> Message-ID: <20150926163108.GI21942@mournblade.imrryr.org> On Sat, Sep 26, 2015 at 04:26:33PM +0000, Matt Caswell via RT wrote: > On 26/09/15 17:18, Devchandra L Meetei via RT wrote: > > Is the API introduced recently openssl 1.0.1f does not seem to have it? > > If so, any plan to backport it? > > This was introduced in 1.0.2. There are no plans to backport it. However, in 1.0.1, where the structures in question are not opaque, the OP can just implement it in his own code: int my_SSL_is_server(SSL *s) { return s->server; } -- Viktor. From dlmeetei at gmail.com Sun Sep 27 05:01:55 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Sun, 27 Sep 2015 10:31:55 +0530 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: <20150926163108.GI21942@mournblade.imrryr.org> References: <5606C737.1080204@openssl.org> <20150926163108.GI21942@mournblade.imrryr.org> Message-ID: Thanks Steve and Viktor. Yes, I went ahead with Viktor's suggestion. On Sat, Sep 26, 2015 at 10:01 PM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > On Sat, Sep 26, 2015 at 04:26:33PM +0000, Matt Caswell via RT wrote: > > > On 26/09/15 17:18, Devchandra L Meetei via RT wrote: > > > > Is the API introduced recently openssl 1.0.1f does not seem to have it? > > > If so, any plan to backport it? > > > > This was introduced in 1.0.2. There are no plans to backport it. > > However, in 1.0.1, where the structures in question are not opaque, > the OP can just implement it in his own code: > > int my_SSL_is_server(SSL *s) > { > return s->server; > } > > -- > Viktor. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- 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 -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Sun Sep 27 08:32:11 2015 From: appro at openssl.org (Andy Polyakov) Date: Sun, 27 Sep 2015 10:32:11 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20150926091251.GA20827@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> Message-ID: <5607A98B.9010409@openssl.org> >>> - mingw debug and shared builds in master. >> >> While I can confirm problem with shared (fixable with attached >> patch, please double-check), I can't confirm problem with debug >> (please elaborate). > > I just opened a pull request on GitHub [0] to add your patch for > mingw shared builds and another one to fix clang debug builds for > master. Let's see what Travis thinks of it. The other modification was submitted by Emilia to internal system 4 days ago. Or in other words fixes will show up. But I'd like to use this opportunity to challenge the choice of using --strict-warnings in [all] CI scenarios. Two points. - Just like everything else warning system is subject to bugs and is a changing field. For example -Wshadow complains about local variables shadowing functions. It appeared in specific gcc version and then was removed. Then mingw compiler complains about missing prototypes in a number of *_asn1 modules. I fail to understand why only mingw compiler. - While strict adherence to every letter of the standard is a good thing, some code is (and always will be) system-specific and it might be impractical to treat it otherwise. For example mingw compiler complains about %I64i format string being non-standard. There is nothing that can be done about it (except for implementing own subroutine, but that would be definition of impractical). Another example is complain about assignment of GetProcAddress to void *. Well, it is meaningful warning and we do address it in other non-Win32 places. But how do you handle it in truly standard manner on 32-bit Win32? When you can use GetProcAddress to pull references to either cdecl or stdcall, per-definition implementation-specific thing? [BTW, is it possible that above mentioned missing prototypes thing is because of this?] Note that I'm not saying that warnings should not be fixed. I'm saying that it's impractical to treat all of them equally (not to mention that there are legitimate false positives after all), and CI might be not the right place to catch them. I would even say that on CI it is more valuable to aim for running tests than to stop on warnings. Or maybe it's not mutually exclusive? As for running tests in the context of query, i.e. mingw cross-compilation on Linux. It actually was possible to perform under 'wine' before and surely can be fixed now. Is 'wine' an option in this case? > Mingw's debug builds are still broken, but now the following error > message is shown: > >> cc1: error: command line option ?-foutput-class-dir=-DL_ENDIAN? >> is valid for Java but not for C [-Werror] > > The problem is that `-d` is a `./config` option, but in the case of > mingw it is passed directly to `./Configure` which thinks it's a > compiler flag so then gcc gets confused. A solution would be to > somehow detect the mingw cross compilation from `./config` so that > we would use it for mingw builds too, but I'm not sure what the > best way to do that would be (and on top of this we still have the > mingw warnings problem). I don't understand. Last modifications to .travis.yml switch from ./config to ./Configure on mingw, so that where does this ./config passing -d to ./Configure come from? I'd say that the switch is appropriate, because ./config was never meant and is hardly proper choice for cross-compiler cases. From rsalz at akamai.com Sun Sep 27 19:56:07 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 27 Sep 2015 19:56:07 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: > if so, any plan to backport it? No, it's a new feature; only fixes go into releases. From rt at openssl.org Sun Sep 27 19:56:20 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 27 Sep 2015 19:56:20 +0000 Subject: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL In-Reply-To: References: Message-ID: > if so, any plan to backport it? No, it's a new feature; only fixes go into releases. From rsalz at akamai.com Mon Sep 28 00:55:45 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 28 Sep 2015 00:55:45 +0000 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <5607A98B.9010409@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> Message-ID: > But I'd like to use this opportunity to challenge the choice of using --strict- > warnings in [all] CI scenarios. I think it would be fine if just the Linux gcc/clang builds had the strict warnings on. IMHO. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Mon Sep 28 11:35:15 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Mon, 28 Sep 2015 11:35:15 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> Message-ID: Matt Caswell wrote: > I've been looking into this issue. The reason this fails is because at > some point in the past there has been an explicit design decision to > disallow it. Thank you for your work! I agree with your analysis. > However, I have some concerns with the wording of the RFC. It seems to > place no limits whatsoever on when it is valid to receive app data in > the handshake. By the wording in the RFC it would be valid for app data > to be received *after* the ChangeCipherSpec has been received but > *before* the Finished has been processed. This seems dangerous to me > because it is not until the Finished is processed that we verify the > handshake data MAC - and yet we could already have acted upon app data > received. I assume the intent was to allow the interleaved app data only > up until the point that the CCS is received. I have attached a patch for > 1.0.2 that implements that logic. The RFC writes: Note: If a rehandshake occurs while data is flowing on a connection, the communicating parties may continue to send data using the old CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec MUST be used. The first side to send the ChangeCipherSpec does not know that the other side has finished computing the new keying material (e.g., if it has to perform a time-consuming public key operation). Thus, a small window of time, during which the recipient must buffer the data, MAY exist. In practice, with modern machines this interval is likely to be fairly short. Could that be interpreted to mean that the recepient should buffer all incoming Application Data messages that are sent between ChangeCipherSpec and Finished? However that may be, I tested your patch with PostgreSQL 9.4.4 and OpenJDK 1.7.0_85 and it solves my problem, so it seems like Java does not try to send Application Data between ChangeCipherSpec and Finished. If that patch gets applied, I expect it will make it into all active branches, right? If this bug gets closed, #2481 should probably get closed too. Yours, Laurenz Albe From rt at openssl.org Mon Sep 28 14:17:06 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Mon, 28 Sep 2015 14:17:06 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: Hi, Good morning! I want to know how it's going with the ticket [openssl.org #4060]? The ticket is : "a crash happened inside SSL_Connect function" Thanks, Tyler -----Original Message----- From: The default queue via RT [mailto:rt at openssl.org] Sent: September-24-15 12:08 PM To: Tiantian Liu Subject: [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "a crash happened inside SSL_Connect function", 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 #4060]. Please include the string: [openssl.org #4060] 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 ------------------------------------------------------------------------- Hi, I am a software developer who is struggling on an application development based on OpenSSL 1.0.1 (released on 2012-03-14) under Linux (32-bit Redhat). I used to use the SSL functions from OpenSSL 0.9.8, and my application worked fine. I applied the SSLv23_method() to setup the SSL context and communicate with customer's server over various SSL/TLS protocols. While, recently my customer required me to upgrade my OpenSSL library, because their server only support TLS1.2. So I downloaded OpenSSL 1.0.1 source package, then complied and installed successfully. I configured the OpenSSL as: #./config -prefix=/usr shared //I have to generate the shared library like libssl.so, libcrypto.so Then I found my SSL context, setup by SSLv23_method(), stopped working, I can't reach their server anymore. It looked like they didn't understand my handshake message when I called SSL_Connect(). So I switched to the TLSv1_2_method() to build SSL context. However, my program crashed every time when I called SSL_Connect(), I mean crash happened inside the SSL_Connect(), and it didn't return at all. Now I have tried 2 methods: 1. SSLv23_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = SSLv23_method(); ctx = SSL_CTX_new(meth); //Only allow TLSv1_1 or higher SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); ...... The SSL_Connect() resulted in: ConnectSSL [SSL_connect(ssl)] failed: 5 SSL_ERROR_SYSCALL: 5 2. TLSv1_2_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = TLSv1_2_method(); ctx = SSL_CTX_new(meth); then, the SSL_connect() crashed when I invoked it. Currently, I don't know how to attack this issue, all the code worked fine before. I just changed the SSLv23_method to TLSv1_2_method. Is there any difference between that 2 functions? What I should do if I want to use the TLSv1_2_method? I am very pleased if anyone of you have any idea to help me. Thanks, Tyler From rt at openssl.org Mon Sep 28 14:19:16 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Mon, 28 Sep 2015 14:19:16 +0000 Subject: [openssl-dev] [openssl.org #2772] Bug w/ patch: OpenSSL 1.0.1 rejects empty NewSessionTicket In-Reply-To: <20120323163710.GX32581@randombit.net> References: <20120323163710.GX32581@randombit.net> Message-ID: You're spot on, thanks for the report! The fix ended up being slightly different, but this is now fixed in 1.0.1+. Cheers, Emilia From rt at openssl.org Mon Sep 28 14:34:51 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 28 Sep 2015 14:34:51 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <05d758528e6d42c5bbf903ff4cdfabbf@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <05d758528e6d42c5bbf903ff4cdfabbf@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: > I want to know how it's going with the ticket [openssl.org #4060]? Nobody's looked at it yet. You need to include a backtrace. And a way to reproduce it (sample code) before anyone will really be interested. From rt at openssl.org Mon Sep 28 14:48:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 28 Sep 2015 14:48:05 +0000 Subject: [openssl-dev] [openssl.org #2481] Full-duplex SSL/TLS renegotiation failure (reproducible 100% of the time) In-Reply-To: <49018E648D917349B0E569D33EE246050B311374@ushqwmb08> References: <49018E648D917349B0E569D33EE246050B311374@ushqwmb08> Message-ID: This as a duplicate of 3712. Closing this ticket in favour of that one. See the patch associated with that ticket. Matt From rt at openssl.org Mon Sep 28 14:49:39 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 28 Sep 2015 14:49:39 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <56095381.5060105@openssl.org> References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> <56095381.5060105@openssl.org> Message-ID: On 28/09/15 12:35, Albe Laurenz via RT wrote: > Matt Caswell wrote: >> I've been looking into this issue. The reason this fails is because at >> some point in the past there has been an explicit design decision to >> disallow it. > > Thank you for your work! > I agree with your analysis. > >> However, I have some concerns with the wording of the RFC. It seems to >> place no limits whatsoever on when it is valid to receive app data in >> the handshake. By the wording in the RFC it would be valid for app data >> to be received *after* the ChangeCipherSpec has been received but >> *before* the Finished has been processed. This seems dangerous to me >> because it is not until the Finished is processed that we verify the >> handshake data MAC - and yet we could already have acted upon app data >> received. I assume the intent was to allow the interleaved app data only >> up until the point that the CCS is received. I have attached a patch for >> 1.0.2 that implements that logic. > > The RFC writes: > > Note: If a rehandshake occurs while data is flowing on a connection, > the communicating parties may continue to send data using the old > CipherSpec. However, once the ChangeCipherSpec has been sent, the > new CipherSpec MUST be used. The first side to send the > ChangeCipherSpec does not know that the other side has finished > computing the new keying material (e.g., if it has to perform a > time-consuming public key operation). Thus, a small window of time, > during which the recipient must buffer the data, MAY exist. In > practice, with modern machines this interval is likely to be fairly > short. > > Could that be interpreted to mean that the recepient should buffer > all incoming Application Data messages that are sent between > ChangeCipherSpec and Finished? Thanks. I had missed that wording. I think this means that as soon as the first party sends a CCS, they must not send any app data until they have received a CCS back (they must buffer it until the CCS is seen). So the second party should never expect to see app data between CCS and Finished. It doesn't tell you anything about what the first party can expect though, i.e. is the second party allowed to send app data between the CCS and Finished? > > However that may be, I tested your patch with PostgreSQL 9.4.4 and > OpenJDK 1.7.0_85 and it solves my problem, so it seems like Java does not > try to send Application Data between ChangeCipherSpec and Finished. > > If that patch gets applied, I expect it will make it into all active > branches, right? Well, that depends what you mean be active. 1.0.0 and 0.9.8 are only receiving security fixes at the moment so this patch would not be applied to those branches. It should be applied to master, 1.0.2 and 1.0.1. The patch is currently awaiting internal review. > > If this bug gets closed, #2481 should probably get closed too. I just closed it with a message pointing at this ticket. No point in having both open. Matt From rt at openssl.org Mon Sep 28 15:31:40 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Mon, 28 Sep 2015 15:31:40 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: Hi, I updated the ticket [openssl.org #4060] with some code and log file. I have to tell you, the previous SSLv23_method, I commented it out this time, worked fine with me and SSL server. I just changed that line to TLSv1_2_method. Now my application always crash when I call SSL_connect(). At first, I created the SSL context by the function below (the function looked returned successfully, because it returned the SSL_CTX boject): SSL_CTX *initialize_ctx_ex(char *keyfile, char *password, char *ca_list, char *random, char *error, char *diag, char isDiag) { SSL_METHOD *meth; SSL_CTX *ctx; /* Create our context*/ //meth = SSLv3_method(); /*I previously applied the SSLv23 method, and it worked fine for me.*/ meth = TLSv1_2_method(); /*Now I switch to TLSv1.2, I just changed this one line in my code*/ if (isDiag && meth) { SerialWriteTestLine_Time("initialize_ctx_ex Call TLSv1_2_method(meth) done.", diag); } ctx = SSL_CTX_new(meth); /* Load the CAs we trust*/ if(!(SSL_CTX_load_verify_locations(ctx, ca_list, 0))) { sprintf(error, "Couldn't read CA list: %s", ca_list); if (isDiag) { SerialWriteTestLine_Time(error, diag); } return NULL; } SSL_CTX_set_verify_depth(ctx, 1); /* Load randomness */ if (random && *random) { if(!(RAND_load_file(random, 1024*1024))) { strcpy(error, "Couldn't load randomness"); if (isDiag) { SerialWriteTestLine_Time(error, diag); } return NULL; } } if (isDiag) { SerialWriteTestLine_Time("Exit initialize_ctx_ex", diag); } return ctx; } /*The above initialize_ctx_ex () is invoked inside the following function SSL_connect_tr_ex ()*/ int SSL_connect_tr_ex(pTSSL_connect sslc, char *msg, pTSSL_params pssl, char *diag, char isDiag) { BIO *sbio; int res; /* Build our SSL context*/ memset(sslc, 0, sizeof(TSSL_connect)); if (isDiag) { SerialWriteTestLine_Time("initialize_ctx", diag); SerialWriteTestLine_string_Time("initialize_ctx ipADdress ", pssl->ipaddress, diag); SerialWriteTestLine_int_Time("initialize_ctx ipADdress ", pssl->ipport, diag); } /* the function initialize_ctx_ex () looked returned successfully, because it returned the SSL_CTX boject */ sslc->ctx = initialize_ctx_ex(pssl->keyfile, pssl->password, pssl->ca_list, pssl->random, msg, diag, isDiag); if (!sslc->ctx) { if (isDiag) { SerialWriteTestLine_Time("tcp_connect !ssl->ctx", diag); } return 0; } /*Then I continue to setup TCP socket to server*/ /* Connect the TCP socket*/ if (isDiag) { SerialWriteTestLine_Time("tcp_connect", diag); } sslc->sock = tcp_connect_timeout_ex(pssl->ipaddress, pssl->ipport, pssl->timeout, msg, diag, isDiag); if (sslc->sock == -1) return 0; /* Connect the SSL socket */ if (isDiag) { SerialWriteTestLine_Time("Connect the SSL socket [SSL_new(ctx)]", diag); } sslc->ssl = SSL_new(sslc->ctx); if (isDiag) { SerialWriteTestLine_Time("Connect the SSL socket [BIO_new_socket(sock, BIO_NOCLOSE)]", diag); } sbio = BIO_new_socket(sslc->sock, BIO_NOCLOSE); if (isDiag) { SerialWriteTestLine_Time("Connect the SSL socket [SSL_set_bio(ssl, sbio, sbio)]", diag); } SSL_set_bio(sslc->ssl, sbio, sbio); if (isDiag) { SerialWriteTestLine_Time("Connect the SSL socket [ConnectSSL(ssl, sock, msg)]", diag); } /*Now I am going to connect, and I got crash in the following function*/ res = ConnectSSL_ex(sslc->ssl, sslc->sock, msg, diag, isDiag, pssl->timeout); if (!res) { return 0; } return 1; } /*My ConnectSSL_ex () is defined*/ int ConnectSSL_ex(SSL *ssl, int sock, char *error, char *diag, char isDiag, int timeout) { int flag; int res; int sslerror; time_t exptime; int isexp; if (isDiag) { SerialWriteTestLine_Time("ConnectSSL [ioctlsocket(socket, FIONBIO, &flags)]", diag); } if (timeout > 15) { timeout -= 5; } exptime = set_expire_time(timeout); while (TRUE) { /*!!!!!! I crashed HERE!!!!, the SSL_connect is standard SSL library function!*/ res = SSL_connect(ssl); /*My application terminated at the SSL_connect() due to crash, because if it returned there should be log message as below*/ if (isDiag) { SerialWriteTestLine_int_Time("SSL_connect returned and return value is ", res, diag); } if (res <= 0) { sslerror = SSL_get_error(ssl, res); if (sslerror == SSL_ERROR_WANT_READ) { isexp = is_expired(exptime); if (isexp == 1) { strcpy(error, "SSL connect error"); return 0; } continue; } strcpy(error, "SSL connect error"); return 0; } break; } strcpy(error, "SSL connect OK"); return 1; } It's there any setup about BIO, or SSL context, should be changed? Or any special compiler flag should be used when I compile my application if I want to use TLSv1.2? I am suspecting some setup of my OpenSSL library is wrong (wrong configuration when I compiled and installed the openssl-1.0.1p?). Because my application crashed when I If my code doesn't help you, could you please give some instructions/technical doc to tell me how to use TLSv1.2 for SSL communication. If you can offer me some simple code to setup SSL communication channel with TLSv1.2, that's helpful! Thanks! Tyler -----Original Message----- From: The default queue via RT [mailto:rt at openssl.org] Sent: September-24-15 12:08 PM To: Tiantian Liu Subject: [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "a crash happened inside SSL_Connect function", 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 #4060]. Please include the string: [openssl.org #4060] 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 ------------------------------------------------------------------------- Hi, I am a software developer who is struggling on an application development based on OpenSSL 1.0.1 (released on 2012-03-14) under Linux (32-bit Redhat). I used to use the SSL functions from OpenSSL 0.9.8, and my application worked fine. I applied the SSLv23_method() to setup the SSL context and communicate with customer's server over various SSL/TLS protocols. While, recently my customer required me to upgrade my OpenSSL library, because their server only support TLS1.2. So I downloaded OpenSSL 1.0.1 source package, then complied and installed successfully. I configured the OpenSSL as: #./config -prefix=/usr shared //I have to generate the shared library like libssl.so, libcrypto.so Then I found my SSL context, setup by SSLv23_method(), stopped working, I can't reach their server anymore. It looked like they didn't understand my handshake message when I called SSL_Connect(). So I switched to the TLSv1_2_method() to build SSL context. However, my program crashed every time when I called SSL_Connect(), I mean crash happened inside the SSL_Connect(), and it didn't return at all. Now I have tried 2 methods: 1. SSLv23_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = SSLv23_method(); ctx = SSL_CTX_new(meth); //Only allow TLSv1_1 or higher SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); ...... The SSL_Connect() resulted in: ConnectSSL [SSL_connect(ssl)] failed: 5 SSL_ERROR_SYSCALL: 5 2. TLSv1_2_method() to build SSL context SSL_METHOD *meth; SSL_CTX *ctx; ...... meth = TLSv1_2_method(); ctx = SSL_CTX_new(meth); then, the SSL_connect() crashed when I invoked it. Currently, I don't know how to attack this issue, all the code worked fine before. I just changed the SSLv23_method to TLSv1_2_method. Is there any difference between that 2 functions? What I should do if I want to use the TLSv1_2_method? I am very pleased if anyone of you have any idea to help me. Thanks, Tyler From openssl-users at dukhovni.org Mon Sep 28 16:02:18 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 28 Sep 2015 16:02:18 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: <20150928160218.GQ21942@mournblade.imrryr.org> On Mon, Sep 28, 2015 at 03:31:40PM +0000, Tiantian Liu via RT wrote: > I updated the ticket [openssl.org #4060] with some code and log file. > I have to tell you, the previous SSLv23_method, I commented it out this > time, worked fine with me and SSL server. I just changed that line to > TLSv1_2_method. Now my application always crash when I call SSL_connect(). You SHOULD NOT switch to TLSv1_2_method(). Keep using SSLv23_method(). Just disable SSLv2 and SSLv3 via something like: SSL_CTX_set_options(ctx, SSL_OP_ALL|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3); > SSL_CTX *initialize_ctx_ex(char *keyfile, char *password, char *ca_list, > char *random, char *error, char *diag, char isDiag) { > SSL_METHOD *meth; > SSL_CTX *ctx; > > > > /* Create our context*/ > //meth = SSLv3_method(); /*I previously applied the SSLv23 method, and it worked fine for me.*/ > meth = TLSv1_2_method(); /*Now I switch to TLSv1.2, I just changed this one line in my code*/ Is the library initialization code elsewhere? > SSL_CTX_set_verify_depth(ctx, 1); That's much too restrictive, is the peer's certificate always signed directly by a trusted root? > if (random && *random) > { > if(!(RAND_load_file(random, 1024*1024))) { > strcpy(error, "Couldn't load randomness"); > if (isDiag) { > SerialWriteTestLine_Time(error, diag); > } > return NULL; > } > } This looks bogus. > If my code doesn't help you, could you please give some > instructions/technical doc to tell me how to use TLSv1.2 for SSL > communication. If you can offer me some simple code to setup SSL > communication channel with TLSv1.2, that's helpful! Thanks! You don't need to make any changes to your code to use TLS 1.2, just recompile the same code with OpenSSL 1.0.1 or later. To disable SSLv2 and SSLv3, see above. You have still provided no information as to what you mean by "crash". -- Viktor. From rt at openssl.org Mon Sep 28 16:29:22 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 28 Sep 2015 16:29:22 +0000 Subject: [openssl-dev] [openssl.org #4049] Minor corrections to codingstyle.txt In-Reply-To: <55FA67C7.1040804@gmail.com> References: <55FA67C7.1040804@gmail.com> Message-ID: Well, except numbers less than 10 are written out :) But all other changes accepted, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From alessandro at ghedini.me Mon Sep 28 17:03:40 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Mon, 28 Sep 2015 19:03:40 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <5607A98B.9010409@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> Message-ID: <20150928170340.GA8688@kronk.local> On Sun, Sep 27, 2015 at 10:32:11am +0200, Andy Polyakov wrote: > >>> - mingw debug and shared builds in master. > >> > >> While I can confirm problem with shared (fixable with attached > >> patch, please double-check), I can't confirm problem with debug > >> (please elaborate). > > > > I just opened a pull request on GitHub [0] to add your patch for > > mingw shared builds and another one to fix clang debug builds for > > master. Let's see what Travis thinks of it. > > The other modification was submitted by Emilia to internal system 4 days > ago. Or in other words fixes will show up. > > But I'd like to use this opportunity to challenge the choice of using > --strict-warnings in [all] CI scenarios. Two points. > > - Just like everything else warning system is subject to bugs and is a > changing field. For example -Wshadow complains about local variables > shadowing functions. It appeared in specific gcc version and then was > removed. Then mingw compiler complains about missing prototypes in a > number of *_asn1 modules. I fail to understand why only mingw compiler. Regarding the missing prototypes, I think it's because (some?) Windows builds have OPENSSL_EXPORT_VAR_AS_FUNCTION defined, while normal builds don't. I haven't tried to build the code with normal GCC with that defined though so I don't know if that would fail on with non-mingw. > - While strict adherence to every letter of the standard is a good > thing, some code is (and always will be) system-specific and it might > be impractical to treat it otherwise. For example mingw compiler > complains about %I64i format string being non-standard. There is > nothing that can be done about it (except for implementing own > subroutine, but that would be definition of impractical). We could use -Wno-pedantic-ms-format for that (disabling the warning completely). As you said, there's nothing we can do about it. > Another > example is complain about assignment of getprocaddress to void *. > Well, it is meaningful warning and we do address it in other non-Win32 > places. But how do you handle it in truly standard manner on 32-bit > Win32? When you can use GetProcAddress to pull references to either > cdecl or stdcall, per-definition implementation-specific thing? The return value type of GetProcAddress is documented as being FARPROC, so using that may work. I actually fixed this warning in my famous patch using that, but I can't really say if the change was correct or not. > Note that I'm not saying that warnings should not be fixed. I'm saying > that it's impractical to treat all of them equally (not to mention that > there are legitimate false positives after all), and CI might be not the > right place to catch them. I would even say that on CI it is more > valuable to aim for running tests than to stop on warnings. Or maybe > it's not mutually exclusive? FWIW, Travis CI allows you to define specific builds to be "non-fatal". The failures would still be listed but they wouldn't affect the general state. See for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last two builds fail but are in the "Allowed Failures" section and the general build state is green). So we could add another debug-only configuration that is not allowed to fail, and mark the current debug+strict-warnings builds on mingw as non-fatal. This way the non-fatal builds are still run and someone can have a look at them and try to fix them if they want. > As for running tests in the context of query, i.e. mingw cross-compilation on > Linux. It actually was possible to perform under 'wine' before and surely can > be fixed now. Is 'wine' an option in this case? I don't know if it actually works, but we can configure Travis CI to install wine before starting the builds. > > Mingw's debug builds are still broken, but now the following error > > message is shown: > > > >> cc1: error: command line option ?-foutput-class-dir=-DL_ENDIAN? > >> is valid for Java but not for C [-Werror] > > > > The problem is that `-d` is a `./config` option, but in the case of > > mingw it is passed directly to `./Configure` which thinks it's a > > compiler flag so then gcc gets confused. A solution would be to > > somehow detect the mingw cross compilation from `./config` so that > > we would use it for mingw builds too, but I'm not sure what the > > best way to do that would be (and on top of this we still have the > > mingw warnings problem). > > I don't understand. Last modifications to .travis.yml switch from > ./config to ./Configure on mingw, so that where does this ./config > passing -d to ./Configure come from? I'd say that the switch is > appropriate, because ./config was never meant and is hardly proper > choice for cross-compiler cases. Yeah, but now we pass -d to ./Configure for mingw builds. -d is a ./config-only option, while --debug is the ./Configure one (which only works on master). I think we should restore '--debug' for builds on master (where it worked fine), and just disable mingw debug builds on older branches. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Sep 28 17:38:23 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 28 Sep 2015 17:38:23 +0000 Subject: [openssl-dev] [openssl.org #4053] [PATCH] Fix typo in prime.c error message In-Reply-To: References: Message-ID: fixed in master, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Mon Sep 28 17:38:55 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 28 Sep 2015 17:38:55 +0000 Subject: [openssl-dev] [openssl.org #4052] [PATCH] Print debug info for extended master secret extension In-Reply-To: <20150917212006.GA24360@kronk.local> References: <20150917212006.GA24360@kronk.local> Message-ID: fixed in mater, thanks. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From appro at openssl.org Mon Sep 28 18:49:12 2015 From: appro at openssl.org (Andy Polyakov) Date: Mon, 28 Sep 2015 20:49:12 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20150928170340.GA8688@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> Message-ID: <56098BA8.8000809@openssl.org> >> But I'd like to use this opportunity to challenge the choice of using >> --strict-warnings in [all] CI scenarios. Two points. >> >> - Just like everything else warning system is subject to bugs and is a >> changing field. For example -Wshadow complains about local variables >> shadowing functions. It appeared in specific gcc version and then was >> removed. Then mingw compiler complains about missing prototypes in a >> number of *_asn1 modules. I fail to understand why only mingw compiler. > > Regarding the missing prototypes, I think it's because (some?) Windows builds > have OPENSSL_EXPORT_VAR_AS_FUNCTION defined, while normal builds don't. I > haven't tried to build the code with normal GCC with that defined though so I > don't know if that would fail on with non-mingw. Yes, I've figured out that and a patch is submitted to internal system. So in sense this becomes bad example to underline the point I was trying to make. And the point is that we don't want to become hostages of bugs elsewhere :-) >> - While strict adherence to every letter of the standard is a good >> thing, some code is (and always will be) system-specific and it might >> be impractical to treat it otherwise. For example mingw compiler >> complains about %I64i format string being non-standard. There is >> nothing that can be done about it (except for implementing own >> subroutine, but that would be definition of impractical). > > We could use -Wno-pedantic-ms-format for that (disabling the warning > completely). Cool! Thanks for the hint! > As you said, there's nothing we can do about it. > >> Another > example is complain about assignment of getprocaddress to void *. >> Well, it is meaningful warning and we do address it in other non-Win32 >> places. But how do you handle it in truly standard manner on 32-bit >> Win32? When you can use GetProcAddress to pull references to either >> cdecl or stdcall, per-definition implementation-specific thing? > > The return value type of GetProcAddress is documented as being FARPROC, so > using that may work. I actually fixed this warning in my famous patch using > that, but I can't really say if the change was correct or not. Technical solution/workaround is already submitted, but my comment was more about *formal* impossibility to solve *all* possible problems (GetProcAddress being *an* example) according to the letter of the standard in true neutral way. Because there *is* system-/implementation-specific code and we can't/shouldn't pretend that there is none. >> Note that I'm not saying that warnings should not be fixed. I'm saying >> that it's impractical to treat all of them equally (not to mention that >> there are legitimate false positives after all), and CI might be not the >> right place to catch them. I would even say that on CI it is more >> valuable to aim for running tests than to stop on warnings. Or maybe >> it's not mutually exclusive? > > FWIW, Travis CI allows you to define specific builds to be "non-fatal". The > failures would still be listed but they wouldn't affect the general state. See > for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last > two builds fail but are in the "Allowed Failures" section and the general build > state is green). > > So we could add another debug-only configuration that is not allowed to fail, > and mark the current debug+strict-warnings builds on mingw as non-fatal. This > way the non-fatal builds are still run and someone can have a look at them > and try to fix them if they want. --strict-warnings imply -Werror and then it's rendered all-or-nothing. I mean you can't ignore -Werror failure, because binary code is not generated. On the other hand generating warnings without -Werror is hardly meaningful in CI scenario, because you don't look at log unless there is problem. So it makes sense to bet on -Werror only if one is confident about it being representative, and the problem is that there is no guarantee that it's universally representative. Hence it can be exercised only is specific cases. >> As for running tests in the context of query, i.e. mingw cross-compilation on >> Linux. It actually was possible to perform under 'wine' before and surely can >> be fixed now. Is 'wine' an option in this case? > > I don't know if it actually works, but we can configure Travis CI to install > wine before starting the builds. Can you test and figure out? As implied, currently new 'make test' doesn't work with 'wine' yet, but you can replace 'make test' with e.g. test/sha1test.exe alone. Just to figure out if it works. It might happen that it's not sufficient to simply install package, one might have to perform per-user config prior Win32 .exes can be executed. Thanks! From rt at openssl.org Tue Sep 29 02:08:34 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 29 Sep 2015 02:08:34 +0000 Subject: [openssl-dev] [openssl.org #3948] typos in openssl-1.0.2d In-Reply-To: <55A8FC4A.50905@gmail.com> References: <55A8FC4A.50905@gmail.com> Message-ID: fixed on master; not worth backporting. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Sep 29 08:24:40 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 29 Sep 2015 08:24:40 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <560A4AC2.8080309@openssl.org> References: <560A4AC2.8080309@openssl.org> Message-ID: I agree with everything Viktor said. In particular that you should continue to use SSLv23_method. Some additional comments below: On 28/09/15 16:31, Tiantian Liu via RT wrote: > sslerror = SSL_get_error(ssl, res); > if (sslerror == SSL_ERROR_WANT_READ) { > isexp = is_expired(exptime); > if (isexp == 1) { > strcpy(error, "SSL connect error"); > return 0; > } > continue; > } > strcpy(error, "SSL connect error"); > return 0; You need to handle more that just SSL_ERROR_WANT_READ here. You should also handle SSL_ERROR_WANT_WRITE. You could get either returned from a call to SSL_connect. Please can you supply a backtrace from your crash? Also a packet capture between your application and the server would be useful. Matt From rt at openssl.org Tue Sep 29 10:06:20 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 29 Sep 2015 10:06:20 +0000 Subject: [openssl-dev] [openssl.org #4063] Re: [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <3863905.yAyVtC7CC0@pintsize.usersys.redhat.com> References: <20150925191902.GA22214@roeckx.be> <3863905.yAyVtC7CC0@pintsize.usersys.redhat.com> Message-ID: On Friday 25 September 2015 19:19:12 Kurt Roeckx via RT wrote: > On Fri, Sep 25, 2015 at 04:23:27PM +0000, Hubert Kario via RT wrote: > > Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange > > ends up as an extension, possibly multiple ones), and that quantum > > computing resistant algorithms usually require fairly large key > > sizes (large enough that protocol limitations itself are > > problematic), we may see Client Hellos larger than 16k in not so > > far future. > > Since we don't actually know how things are going to change in the > future and that they can change the maximum size of a Client > Hello, it makes sense to me to not enforce a limit for the Client > Hello message just because that's what the current version only > supports. For all other messages we should be able to tell what > the maximum size is. It was already raised on the IETF mailing list and nobody disagreed that any future Client Hello messages need to be compatible for previous protocol versions. And that was in context of TLS 1.3 and quantum resistant crypto. Finally, there are implementations that do follow the specification to the letter - e.g. Mozilla NSS. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From hkario at redhat.com Tue Sep 29 11:56:28 2015 From: hkario at redhat.com (Hubert Kario) Date: Tue, 29 Sep 2015 13:56:28 +0200 Subject: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected In-Reply-To: <20150926010215.GF21942@mournblade.imrryr.org> References: <20150926010215.GF21942@mournblade.imrryr.org> Message-ID: <1688619.ALiksLuT26@pintsize.usersys.redhat.com> On Saturday 26 September 2015 01:02:15 Viktor Dukhovni wrote: > On Sat, Sep 26, 2015 at 12:17:20AM +0000, Salz, Rich wrote: > > > On the other side of the coin handling very large ClientHello's is > > > not without cost and risk. > > > > As long as it's a #define that can be changed in ssl.h (or a runtime > > global? Ick) we should be okay. > It would have to more configurable than that to be worth the bother. > All sorts of "appliance" products with OpenSSL inside would > potentially some day pose a barrier to interoperability with clients > that send large HELLO messages. > > I should note that server side session state can also contain a > client certificate, which is then embedded in the session ticket. > So the outer limits of current practice are somewhat bigger. > > We could perhaps increase the limit from 16K to 32K bytes, just in > case that helps, and hope that the result does not expose servers > to significantly higher risk of DoS. > > Or raise the issue on the TLS WG. Are servers really expected > to support up to 128K or so of client HELLO? TLS 1.3 Client Hello will contain client key shares for _multiple_ key exchange methods (sending both DH 2048 and ECDH 256 is rather likely). Then we have session tickets, which for case with client certificates can easily be few kilobytes in size (there are "godzillacerts" that are bigger than 16KiB already out there). So I have to retract my initial "unlikely" and "never" and say that even for standard TLSv1.2 with commonly used extensions a Client Hello bigger than 16KiB is not out of the question. Client Hello messages of at least 2^16+? MUST be accepted. Question is, how big the ? needs to be, likely 1KiB at the very least. I'd still say that it's just kicking the can down the road. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From alessandro at ghedini.me Tue Sep 29 12:48:37 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 29 Sep 2015 14:48:37 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <56098BA8.8000809@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> Message-ID: <20150929124837.GA18210@kronk.local> On Mon, Sep 28, 2015 at 08:49:12pm +0200, Andy Polyakov wrote: > > FWIW, Travis CI allows you to define specific builds to be "non-fatal". The > > failures would still be listed but they wouldn't affect the general state. See > > for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last > > two builds fail but are in the "Allowed Failures" section and the general build > > state is green). > > > > So we could add another debug-only configuration that is not allowed to fail, > > and mark the current debug+strict-warnings builds on mingw as non-fatal. This > > way the non-fatal builds are still run and someone can have a look at them > > and try to fix them if they want. > > --strict-warnings imply -Werror and then it's rendered all-or-nothing. I > mean you can't ignore -Werror failure, because binary code is not > generated. On the other hand generating warnings without -Werror is > hardly meaningful in CI scenario, because you don't look at log unless > there is problem. So it makes sense to bet on -Werror only if one is > confident about it being representative, and the problem is that there > is no guarantee that it's universally representative. Hence it can be > exercised only is specific cases. I think we are talking about two different things. What I meant is that due to the debug+strict-warnings+mingw failures, the "global" state on Travis is shown as "failed" https://travis-ci.org/openssl/openssl To fix this, we could either drop those builds completely, or just mark them as "Allowed Failures": they are still run, but even if they fail the Travis state is not shown as "failed". But to do this we would have to add additional debug-only (without --strict-warnings) builds that are *not* allowed to fail. > >> As for running tests in the context of query, i.e. mingw cross-compilation on > >> Linux. It actually was possible to perform under 'wine' before and surely can > >> be fixed now. Is 'wine' an option in this case? > > > > I don't know if it actually works, but we can configure Travis CI to install > > wine before starting the builds. > > Can you test and figure out? As implied, currently new 'make test' > doesn't work with 'wine' yet, but you can replace 'make test' with e.g. > test/sha1test.exe alone. Just to figure out if it works. It might happen > that it's not sufficient to simply install package, one might have to > perform per-user config prior Win32 .exes can be executed. It works!!! Well, sort of. It requires 3 patches [0] (including the changes to the Travis CI config) and there are 3 or so tests that fail (see log at [1]), but it's basically doable. Cheers [0] https://github.com/ghedo/openssl/commits/mingwci [1] https://travis-ci.org/ghedo/openssl/jobs/82727489 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Tue Sep 29 13:56:06 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Tue, 29 Sep 2015 13:56:06 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560A4AC2.8080309@openssl.org> Message-ID: Hi Matt & Vi I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. I only enabled the TLSv1.2 by SSL_CTX_set_option(). You can see my previous code: /*setup up by SSLv23_method*/ meth = SSLv23_method(); ctx = SSL_CTX_new(meth); ............ ............ /*Only allow TLSv1.2 protocol*/ SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as: 17:49:12.939 [5499]- SSL_connect res : -1 17:49:12.939 [5499]- Going to call SSL_connect(): 15 17:49:12.939 [5499]- SSL_connect res : -1 17:49:12.939 [5499]- Going to call SSL_connect(): 15 17:49:12.939 [5499]- SSL_connect res : -1 17:49:12.939 [5499]- Going to call SSL_connect(): 15 17:49:12.940 [5499]- SSL_connect res : -1 17:49:12.940 [5499]- Going to call SSL_connect(): 15 17:49:12.940 [5499]- SSL_connect res : -1 17:49:12.940 [5499]- Going to call SSL_connect(): 15 17:49:12.940 [5499]- SSL_connect res : -1 17:49:12.940 [5499]- Going to call SSL_connect(): 15 17:49:12.940 [5499]- SSL_connect res : -1 17:49:12.940 [5499]- Going to call SSL_connect(): 15 17:49:12.940 [5499]- SSL_connect res : -1 17:49:12.941 [5499]- Going to call SSL_connect(): 15 17:49:12.941 [5499]- SSL_connect res : -1 17:49:12.941 [5499]- Going to call SSL_connect(): 15 17:49:12.941 [5499]- SSL_connect res : -1 17:49:12.941 [5499]- Going to call SSL_connect(): 15 I will continue to investigate, and keep updating the ticket. I will adopt your idea to see if I can obtain more information during crash. Thanks, Tyler -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: September-29-15 4:25 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function I agree with everything Viktor said. In particular that you should continue to use SSLv23_method. Some additional comments below: On 28/09/15 16:31, Tiantian Liu via RT wrote: > sslerror = SSL_get_error(ssl, res); > if (sslerror == SSL_ERROR_WANT_READ) { > isexp = is_expired(exptime); > if (isexp == 1) { > strcpy(error, "SSL connect error"); > return 0; > } > continue; > } > strcpy(error, "SSL connect error"); > return 0; You need to handle more that just SSL_ERROR_WANT_READ here. You should also handle SSL_ERROR_WANT_WRITE. You could get either returned from a call to SSL_connect. Please can you supply a backtrace from your crash? Also a packet capture between your application and the server would be useful. Matt From rt at openssl.org Tue Sep 29 14:05:01 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 29 Sep 2015 14:05:01 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <560A9A8B.8000508@openssl.org> References: <560A4AC2.8080309@openssl.org> <560A9A8B.8000508@openssl.org> Message-ID: On 29/09/15 14:56, Tiantian Liu via RT wrote: > Hi Matt & Vi > > I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. I only enabled the TLSv1.2 by SSL_CTX_set_option(). > You can see my previous code: > > /*setup up by SSLv23_method*/ > meth = SSLv23_method(); > ctx = SSL_CTX_new(meth); > ............ > ............ > /*Only allow TLSv1.2 protocol*/ > SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); > > > While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as: > > 17:49:12.939 [5499]- SSL_connect res : -1 What is the result of SSL_get_error()? Also check the OpenSSL error queue (see ERR_print_errors or ERR_print_errors_fp). Matt From rt at openssl.org Tue Sep 29 14:30:17 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Tue, 29 Sep 2015 14:30:17 +0000 Subject: [openssl-dev] [openssl.org #3986] [PATCH] Implement HKDF algorithm (RFC 5869) In-Reply-To: <20150929143014.GA27490@kronk.local> References: <20150929143014.GA27490@kronk.local> Message-ID: Just FYI, I updated the GitHub pull request [0] with the following: - Merged patches into a single commit. This just makes more sense, and it's not much more complicated to review. - Added HKDF_Extract() function to the interface. This is basically equivalent to calling HMAC(), but the TLS 1.3 draft started using it explicitly so I thought it would make the API more complete. - Added documentation for all the new functions (see doc/crypto/hkdf.pod). - Updated util/mkdef.pl to parse hkdf.h as well, and updated util/libeay.num. Now all the builds on Travis CI run fine (except the ones that were already failing). Cheers [0] https://github.com/openssl/openssl/pull/355 From rt at openssl.org Tue Sep 29 14:45:46 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Tue, 29 Sep 2015 14:45:46 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560A9A8B.8000508@openssl.org> Message-ID: Hi Matt, Thanks for prompt response! While I confirm with you that my application crashed INSIDE the SSL_connect() function. So SSL_connect has no chance to return the 'res' value to me for analysis. Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. /* My debug statement wrote the " Going to call SSL_connect() 15" into my trace file And this message string is THE LAST message in my trace file. */ if (isDiag) { SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); } res = SSL_connect(ssl); /* Oooop!!! The following statement was not executed! No debug message in my trace file anymore. */ if (isDiag) { SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); } if (res <= 0) { sslerror = SSL_get_error(ssl, res); if (sslerror == SSL_ERROR_WANT_READ) { isexp = is_expired(exptime); if (isexp == 1) { if (isDiag) { SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); } strcpy(error, "SSL connect error"); return 0; } continue; } So, do you have any idea to get more information inside the SSL_connect? Should I re-compile and re-install OpenSSL lib? I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. Is there any incorrect setup in the BIO, SSL context and socket? I am using all the setup of previous SSLv23_method(). P.S: I can reach the server by the OpenSSL command: #openssl s_client -connect :PORT -tls1_2 Openssl command returned me the information which looks like I can talk to SSL server over TLS1.2 depth=1 C = US, ST = Illinois, L = Chicago, O = "Trustwave Holdings, Inc.", CN = "Trustwave Organization Validation SHA256 CA, Level 1", emailAddress = ca at trustwave.com verify error:num=20:unable to get local issuer certificate verify return:0 CONNECTED(00000003) --- Certificate chain 0 s:/CN=dev-dataconnect.givex.com/O=Givex Canada Corp/L=Toronto/ST=Ontario/C=CA i:/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation SHA256 CA, Level 1/emailAddress=ca at trustwave.com 1 s:/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation SHA256 CA, Level 1/emailAddress=ca at trustwave.com i:/C=US/O=SecureTrust Corporation/CN=SecureTrust CA --- Server certificate -----BEGIN CERTIFICATE----- MIIFQTCCBCmgAwIBAgITBljEycmHCzUZRdr0HJPkGijEDjANBgkqhkiG9w0BAQsF ADCBtTELMAkGA1UEBhMCVVMxETAPBgNVBAgTCElsbGlub2lzMRAwDgYDVQQHEwdD aGljYWdvMSEwHwYDVQQKExhUcnVzdHdhdmUgSG9sZGluZ3MsIEluYy4xPTA7BgNV BAMTNFRydXN0d2F2ZSBPcmdhbml6YXRpb24gVmFsaWRhdGlvbiBTSEEyNTYgQ0Es IExldmVsIDExHzAdBgkqhkiG9w0BCQEWEGNhQHRydXN0d2F2ZS5jb20wHhcNMTQx MTA3MDkxMjM3WhcNMTcxMTA2MTUxMjM3WjBxMSIwIAYDVQQDDBlkZXYtZGF0YWNv bm5lY3QuZ2l2ZXguY29tMRowGAYDVQQKDBFHaXZleCBDYW5hZGEgQ29ycDEQMA4G A1UEBwwHVG9yb250bzEQMA4GA1UECAwHT250YXJpbzELMAkGA1UEBhMCQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4y7f+C3rEeSekQyCs9NCCrpNw a/RSZX4GROY9HpSdf1o7emBFZ6T6EQaXACU1U4ROFelpKMH/YycGrfXQe3U21eUb 4mCxEfj1N9BK0ZTEQo0j8FmaJdW7kLJIFmjkkK66oUjx9E+KVUamyTOfQLKo/btE r8/JXS94NjVr4hZpRN0el56zc5IQJbKxYzAzFUydPvzWj5Lc/l9+lKj8ZVXEWyrp N9/KWZFpwffhXQwR0iasnLm/Fta9XZ0IyiWk8RrV9rrumOqHxhksHl32MMtJ8J/W m2SmTdOPJaRC3sJbI8hHJoNh3vsxWu8NzmvXmle14nVIcZoMwRHXcrG9ea5TAgMB AAGjggGLMIIBhzALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMBMB0GA1UdDgQWBBTCphjKWT2B04SXoTB53oE93hyU4zAfBgNVHSMEGDAW gBTKzh0YA3ceHPN8WLKacKgIgBb0rjBIBgNVHSAEQTA/MD0GDysGAQQBge0YAwMD AwQEAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3NzbC50cnVzdHdhdmUuY29tL0NB MCQGA1UdEQQdMBuCGWRldi1kYXRhY29ubmVjdC5naXZleC5jb20wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC50cnVzdHdhdmUuY29tL09WQ0EyX0wxLmNybDBx BggrBgEFBQcBAQRlMGMwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLnRydXN0d2F2 ZS5jb20vMDkGCCsGAQUFBzAChi1odHRwOi8vc3NsLnRydXN0d2F2ZS5jb20vaXNz dWVycy9PVkNBMl9MMS5jcnQwDQYJKoZIhvcNAQELBQADggEBAEzB7/euRUBAfXnr AR3BG4VsyLYnOMp148yXNhxwpJnZQVxIf6wgWwxNviUvYQ8lE/UiSEQzL+pUrzr7 wFDzafePHITspWuIwPgivtPUXlYkYBjsLRvpnfwS+ml2/uVtzMlIxdMk9kpumznS aQTW5dLQpn7U70h2ESr2jqVetx9xF/iZxvyPQm+jZ74WkoGYTeDKPzzc5C1JL/4C DU7L6KRvMy9mEMmAm0Uftp4Oi1LLl02Kg8ISv8L0orJCBaieMyjXzsYF1u/WCRmg lXFDb4L4G8DFvSArePBt5iwYiNwJpA5HBKk3cDXv4OpVUCNToGZxwCuIfbf4N4cp P+kPkzY= -----END CERTIFICATE----- subject=/CN=dev-dataconnect.givex.com/O=Givex Canada Corp/L=Toronto/ST=Ontario/C=CA issuer=/C=US/ST=Illinois/L=Chicago/O=Trustwave Holdings, Inc./CN=Trustwave Organization Validation SHA256 CA, Level 1/emailAddress=ca at trustwave.com --- No client certificate CA names sent --- SSL handshake has read 2946 bytes and written 615 bytes --- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : AES256-GCM-SHA384 Session-ID: A6FF6BD6DA9406A8C6148FDDA74E5603FAF8272A5ECFDF1679BA1939F8FC3B25 Session-ID-ctx: Master-Key: 822DCFBFB88F2B4B2BBB9093CE490F8868A0B24BCDAAD0BEB3C717C2EA54DECA4196817E1C5D4C16457B4054C24132C6 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 03 c4 85 89 59 05 ee ec-07 ba 65 5d 5c 06 c1 cf ....Y.....e]\... 0010 - 11 bc b4 48 3e 8c b1 a8-18 ca 33 57 3e b9 36 c2 ...H>.....3W>.6. 0020 - 7a 1a 97 d1 54 ec ab 64-51 08 77 9d 5c b1 1a 10 z...T..dQ.w.\... 0030 - ce 51 a2 12 6b 49 df 32-ec b3 ac d9 dd 54 ba 51 .Q..kI.2.....T.Q 0040 - 78 ac a8 8d 84 09 3f a6-fe bf 9c 97 21 d9 32 ec x.....?.....!.2. 0050 - 4a 55 8f 14 c2 56 d6 0c-26 47 b8 fa fe c5 7f 9d JU...V..&G...... 0060 - 1d cc 22 ec 43 2c 5e ab-48 52 fd 99 04 11 ba 5c ..".C,^.HR.....\ 0070 - 20 0a ef ed 18 02 08 97-7e 75 99 88 7d 73 9f d5 .......~u..}s.. 0080 - 9b 96 a1 d5 20 44 02 cc-3e 71 e2 6f b6 41 71 a7 .... D..>q.o.Aq. 0090 - 8d 82 a4 a8 3e 08 5f 2e-d1 fe c1 44 c4 13 aa 32 ....>._....D...2 Start Time: 1443544275 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate) --- closed Thanks, Tyler -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: September-29-15 10:05 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function On 29/09/15 14:56, Tiantian Liu via RT wrote: > Hi Matt & Vi > > I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. I only enabled the TLSv1.2 by SSL_CTX_set_option(). > You can see my previous code: > > /*setup up by SSLv23_method*/ > meth = SSLv23_method(); > ctx = SSL_CTX_new(meth); > ............ > ............ > /*Only allow TLSv1.2 protocol*/ > SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | > SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); > > > While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as: > > 17:49:12.939 [5499]- SSL_connect res : -1 What is the result of SSL_get_error()? Also check the OpenSSL error queue (see ERR_print_errors or ERR_print_errors_fp). Matt From rt at openssl.org Tue Sep 29 14:55:23 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 29 Sep 2015 14:55:23 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <560AA659.4020503@openssl.org> References: <560A9A8B.8000508@openssl.org> <560AA659.4020503@openssl.org> Message-ID: On 29/09/15 15:45, Tiantian Liu via RT wrote: > Hi Matt, > Thanks for prompt response! > While I confirm with you that my application crashed INSIDE the SSL_connect() function. Your previous email indicated it was not crashing with SSLv23_method(): "While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as..." So my advice was meant for that scenario. > So SSL_connect has no chance to return the 'res' value to me for analysis. > Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. > > /* > My debug statement wrote the " Going to call SSL_connect() 15" into my trace file > And this message string is THE LAST message in my trace file. > */ > if (isDiag) { > SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); > } > res = SSL_connect(ssl); > /* > Oooop!!! The following statement was not executed! No debug message in my trace file anymore. > */ > if (isDiag) { > SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); > } > if (res <= 0) { > sslerror = SSL_get_error(ssl, res); > if (sslerror == SSL_ERROR_WANT_READ) { > isexp = is_expired(exptime); > if (isexp == 1) { > if (isDiag) { > SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); > } > strcpy(error, "SSL connect error"); > return 0; > } > continue; > } > > So, do you have any idea to get more information inside the SSL_connect? If its actually crashing then we need to see a backtrace and a wireshark packet capture. > Should I re-compile and re-install OpenSSL lib? > I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. > You should not get a compilation error. Please post the steps you took to compile the library and the compilation error you received. Matt From rt at openssl.org Tue Sep 29 15:16:55 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 29 Sep 2015 15:16:55 +0000 Subject: [openssl-dev] [openssl.org #4051] [Patch] Fix EECDHE typo in ciphers(1) In-Reply-To: <4780609.ZHMZU9bJPd@pintsize.usersys.redhat.com> References: <4780609.ZHMZU9bJPd@pintsize.usersys.redhat.com> Message-ID: Thanks Hubert, fixed in 1.0.1 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue Sep 29 17:32:00 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Tue, 29 Sep 2015 17:32:00 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560AA659.4020503@openssl.org> Message-ID: I downloaded the OpenSSL-1.0.1p. I configured it as : [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared threads /**************************************************************** ******The configuration result as**************************************** Operating system: i686-whatever-linux2 Configuring for debug-linux-elf Configuring for debug-linux-elf no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =gcc CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM EX_LIBS =-lefence -ldl CPUID_OBJ =x86cpuid.o BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o DES_ENC =des-586.o crypt586.o AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o BF_ENC =bf-586.o CAST_ENC =c_enc.o RC4_ENC =rc4-586.o RC5_ENC =rc5-586.o MD5_OBJ_ASM =md5-586.o SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o RMD160_OBJ_ASM=rmd-586.o CMLL_ENC =cmll-x86.o MODES_OBJ =ghash-x86.o ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/usr/bin/perl THIRTY_TWO_BIT mode DES_PTR used DES_RISC1 used DES_UNROLL used BN_LLONG mode RC4_INDEX mode RC4_CHUNK is undefined e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' crypto.h => ../include/openssl/crypto.h opensslv.h => ../include/openssl/opensslv.h opensslconf.h => ../include/openssl/opensslconf.h ebcdic.h => ../include/openssl/ebcdic.h symhacks.h => ../include/openssl/symhacks.h ossl_typ.h => ../include/openssl/ossl_typ.h constant_time_test.c => ../test/constant_time_test.c making links in crypto/objects... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' objects.h => ../../include/openssl/objects.h obj_mac.h => ../../include/openssl/obj_mac.h make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' making links in crypto/md4... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' md4.h => ../../include/openssl/md4.h md4test.c => ../../test/md4test.c md4.c => ../../apps/md4.c make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' making links in crypto/md5... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' md5.h => ../../include/openssl/md5.h md5test.c => ../../test/md5test.c make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' making links in crypto/sha... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' sha.h => ../../include/openssl/sha.h shatest.c => ../../test/shatest.c sha1test.c => ../../test/sha1test.c sha256t.c => ../../test/sha256t.c sha512t.c => ../../test/sha512t.c make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' making links in crypto/mdc2... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => ../../test/mdc2test.c make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' making links in crypto/hmac... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' hmac.h => ../../include/openssl/hmac.h ...... srptest.c => ../../test/srptest.c make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' making links in crypto/cmac... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' cmac.h => ../../include/openssl/cmac.h make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' making links in ssl... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' ssl.h => ../include/openssl/ssl.h ssl2.h => ../include/openssl/ssl2.h ssl3.h => ../include/openssl/ssl3.h ssl23.h => ../include/openssl/ssl23.h tls1.h => ../include/openssl/tls1.h dtls1.h => ../include/openssl/dtls1.h kssl.h => ../include/openssl/kssl.h srtp.h => ../include/openssl/srtp.h ssltest.c => ../test/ssltest.c heartbeat_test.c => ../test/heartbeat_test.c make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' making links in engines... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' making links in engines/ccgost... make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' make[2]: Nothing to be done for `links'. make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' making links in apps... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' make[1]: Nothing to be done for `links'. make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' making links in test... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' make[1]: Nothing to be done for `links'. make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' making links in tools... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' make[1]: Nothing to be done for `links'. make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' generating dummy tests (if needed)... make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' make[1]: Nothing to be done for `generate'. make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' Configured for debug-linux-elf. ***********************************************************/ Then I make it and got the ERROR message Told me undefined reference to 'pthread_mutex_trylock' Then I added '-lpthread' into the FLAG in Makefile. Then I went through and compiled successfully. Then I will ran my application again to see how SSL_connect() crash.... Any requirement for me to start my application with OpenSSL (with debug enabled)? I mean to show me more information inside SSL_connect() Thanks, Tyler -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: September-29-15 10:55 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function On 29/09/15 15:45, Tiantian Liu via RT wrote: > Hi Matt, > Thanks for prompt response! > While I confirm with you that my application crashed INSIDE the SSL_connect() function. Your previous email indicated it was not crashing with SSLv23_method(): "While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as..." So my advice was meant for that scenario. > So SSL_connect has no chance to return the 'res' value to me for analysis. > Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. > > /* > My debug statement wrote the " Going to call SSL_connect() 15" into my trace file > And this message string is THE LAST message in my trace file. > */ > if (isDiag) { > SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); > } > res = SSL_connect(ssl); > /* > Oooop!!! The following statement was not executed! No debug message in my trace file anymore. > */ > if (isDiag) { > SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); > } > if (res <= 0) { > sslerror = SSL_get_error(ssl, res); > if (sslerror == SSL_ERROR_WANT_READ) { > isexp = is_expired(exptime); > if (isexp == 1) { > if (isDiag) { > SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); > } > strcpy(error, "SSL connect error"); > return 0; > } > continue; > } > > So, do you have any idea to get more information inside the SSL_connect? If its actually crashing then we need to see a backtrace and a wireshark packet capture. > Should I re-compile and re-install OpenSSL lib? > I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. > You should not get a compilation error. Please post the steps you took to compile the library and the compilation error you received. Matt From rt at openssl.org Tue Sep 29 18:26:49 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 29 Sep 2015 18:26:49 +0000 Subject: [openssl-dev] [openssl.org #4042] Build Bug w/ OpenSSL on Windows? No Applink In-Reply-To: References: <201509150831.t8F8Vnex026880@d01av05.pok.ibm.com> <201509270510.t8R5ABG8014634@d03av02.boulder.ibm.com> Message-ID: On Sun Sep 27 05:11:00 2015, cberube at us.ibm.com wrote: > How exactly do I apply this patch? The diffs.applink file should be > input into > what program? I tried the following which did not work: > The patch should be applied to OpenSSL 1.0.2d. Alternatively download the next 1.0.2 snapshot. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Sep 30 02:01:54 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 30 Sep 2015 02:01:54 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1438170735.26511.33.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> Message-ID: We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file return an alternate implementation that returns run-time failures. Almost all of the OpenSSL code uses the BIO object, so we didn't have to remove that. We did #ifdef out any routine that had a "FILE*" param or local variable. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Sep 30 06:24:18 2015 From: rt at openssl.org (Woodhouse, David via RT) Date: Wed, 30 Sep 2015 06:24:18 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1443594239.28791.4.camel@intel.com> References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> Message-ID: On Wed, 2015-09-30 at 02:01 +0000, Rich Salz via RT wrote: > We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file > return an alternate implementation that returns run-time failures. Almost all > of the OpenSSL code uses the BIO object, so we didn't have to remove that. We > did #ifdef out any routine that had a "FILE*" param or local variable. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org If things like BIO_new_file() were inline, or macros, then the compiler could *see* that they'd return NULL. And lots of code in the *calling* functions (basically everything but the error path) could be elided from the compiled result... -- Sent with Evolution's ActiveSync support. David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3437 bytes Desc: not available URL: From rt at openssl.org Wed Sep 30 08:08:42 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 30 Sep 2015 08:08:42 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <560B9885.60205@openssl.org> References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> Message-ID: To question about OPENSSL_stderr() that was removed with "not used" rationale. When it comes to a *library* you always run risk of finding something that it not used by the library itself, something that is meant to be used exclusively by somebody else's application. And OPENSSL_stderr() is such thing. Well, for a Unix person it's really meaningless function, but it was introduced to solve small but irritating problem in FIPS module context on Windows. From appro at openssl.org Wed Sep 30 08:48:01 2015 From: appro at openssl.org (Andy Polyakov) Date: Wed, 30 Sep 2015 10:48:01 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20150929124837.GA18210@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> Message-ID: <560BA1C1.4030606@openssl.org> >>>> As for running tests in the context of query, i.e. mingw >>>> cross-compilation on Linux. It actually was possible to >>>> perform under 'wine' before and surely can be fixed now. Is >>>> 'wine' an option in this case? >>> >>> I don't know if it actually works, but we can configure Travis >>> CI to install wine before starting the builds. >> >> Can you test and figure out? As implied, currently new 'make >> test' doesn't work with 'wine' yet, but you can replace 'make >> test' with e.g. test/sha1test.exe alone. Just to figure out if it >> works. It might happen that it's not sufficient to simply install >> package, one might have to perform per-user config prior Win32 >> .exes can be executed. > > It works!!! Well, sort of. It requires 3 patches [0] (including the > changes to the Travis CI config) and there are 3 or so tests that > fail (see log at [1]), but it's basically doable. > > Cheers > > [0] https://github.com/ghedo/openssl/commits/mingwci [1] > https://travis-ci.org/ghedo/openssl/jobs/82727489 Thanks! I'm looking into it. On related note, you might notice a number of mingw warnings addressed in master. I just want to say that even more will be, i.e. it's work in progress. From rt at openssl.org Wed Sep 30 09:22:39 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Wed, 30 Sep 2015 09:22:39 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <20150930092227.GA4328@kronk.local> References: <1438170735.26511.33.camel@intel.com> <20150930092227.GA4328@kronk.local> Message-ID: On Wed, Sep 30, 2015 at 02:01:54am +0000, Rich Salz via RT wrote: > We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file > return an alternate implementation that returns run-time failures. Almost all > of the OpenSSL code uses the BIO object, so we didn't have to remove that. We > did #ifdef out any routine that had a "FILE*" param or local variable. Note that commit 984d6c6 causes mingw shared builds to fail again: https://travis-ci.org/openssl/openssl/jobs/82855661 The problem seems to be that entries 4991 and 4992 in libeay.num are used twice. Since this is not the first time this happens, I was thinking that maybe having a test for this would be useful. Cheers From laurenz.albe at wien.gv.at Wed Sep 30 09:37:37 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Wed, 30 Sep 2015 09:37:37 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> <56095381.5060105@openssl.org> Message-ID: Matt Caswell wrote: > On 28/09/15 12:35, Albe Laurenz via RT wrote: >> Matt Caswell wrote: >>> However, I have some concerns with the wording of the RFC. It seems to >>> place no limits whatsoever on when it is valid to receive app data in >>> the handshake. By the wording in the RFC it would be valid for app data >>> to be received *after* the ChangeCipherSpec has been received but >>> *before* the Finished has been processed. This seems dangerous to me >>> because it is not until the Finished is processed that we verify the >>> handshake data MAC - and yet we could already have acted upon app data >>> received. I assume the intent was to allow the interleaved app data only >>> up until the point that the CCS is received. I have attached a patch for >>> 1.0.2 that implements that logic. >> The RFC writes: >> >> Note: If a rehandshake occurs while data is flowing on a connection, >> the communicating parties may continue to send data using the old >> CipherSpec. However, once the ChangeCipherSpec has been sent, the >> new CipherSpec MUST be used. The first side to send the >> ChangeCipherSpec does not know that the other side has finished >> computing the new keying material (e.g., if it has to perform a >> time-consuming public key operation). Thus, a small window of time, >> during which the recipient must buffer the data, MAY exist. In >> practice, with modern machines this interval is likely to be fairly >> short. >> >> Could that be interpreted to mean that the recepient should buffer >> all incoming Application Data messages that are sent between >> ChangeCipherSpec and Finished? > Thanks. I had missed that wording. I think this means that as soon as > the first party sends a CCS, they must not send any app data until they > have received a CCS back (they must buffer it until the CCS is seen). So > the second party should never expect to see app data between CCS and > Finished. It doesn't tell you anything about what the first party can > expect though, i.e. is the second party allowed to send app data between > the CCS and Finished? Interesting how we can read this so differently. If anything, that confirms that the wording of the RFC is suboptimal. It is probably both convenient and sensible to follow the following sentence of the RFC, as you have done: A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. This may well be interpreted as "no Application Data records may be sent between CCS and Finished". Yours, Laurenz Albe From rt at openssl.org Wed Sep 30 09:37:48 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Wed, 30 Sep 2015 09:37:48 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <56095381.5060105@openssl.org> Message-ID: Matt Caswell wrote: > On 28/09/15 12:35, Albe Laurenz via RT wrote: >> Matt Caswell wrote: >>> However, I have some concerns with the wording of the RFC. It seems to >>> place no limits whatsoever on when it is valid to receive app data in >>> the handshake. By the wording in the RFC it would be valid for app data >>> to be received *after* the ChangeCipherSpec has been received but >>> *before* the Finished has been processed. This seems dangerous to me >>> because it is not until the Finished is processed that we verify the >>> handshake data MAC - and yet we could already have acted upon app data >>> received. I assume the intent was to allow the interleaved app data only >>> up until the point that the CCS is received. I have attached a patch for >>> 1.0.2 that implements that logic. >> The RFC writes: >> >> Note: If a rehandshake occurs while data is flowing on a connection, >> the communicating parties may continue to send data using the old >> CipherSpec. However, once the ChangeCipherSpec has been sent, the >> new CipherSpec MUST be used. The first side to send the >> ChangeCipherSpec does not know that the other side has finished >> computing the new keying material (e.g., if it has to perform a >> time-consuming public key operation). Thus, a small window of time, >> during which the recipient must buffer the data, MAY exist. In >> practice, with modern machines this interval is likely to be fairly >> short. >> >> Could that be interpreted to mean that the recepient should buffer >> all incoming Application Data messages that are sent between >> ChangeCipherSpec and Finished? > Thanks. I had missed that wording. I think this means that as soon as > the first party sends a CCS, they must not send any app data until they > have received a CCS back (they must buffer it until the CCS is seen). So > the second party should never expect to see app data between CCS and > Finished. It doesn't tell you anything about what the first party can > expect though, i.e. is the second party allowed to send app data between > the CCS and Finished? Interesting how we can read this so differently. If anything, that confirms that the wording of the RFC is suboptimal. It is probably both convenient and sensible to follow the following sentence of the RFC, as you have done: A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. This may well be interpreted as "no Application Data records may be sent between CCS and Finished". Yours, Laurenz Albe From dwmw2 at infradead.org Wed Sep 30 08:52:05 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 30 Sep 2015 08:52:05 -0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> Message-ID: <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> See http://www.infradead.org/rpr.html > To question about OPENSSL_stderr() that was removed with "not used" > rationale. When it comes to a *library* you always run risk of finding > something that it not used by the library itself, something that is > meant to be used exclusively by somebody else's application. And > OPENSSL_stderr() is such thing. Well, for a Unix person it's really > meaningless function, but it was introduced to solve small but > irritating problem in FIPS module context on Windows. You'll note I left it well alone on my 1.0.2 backports; only changed it in HEAD. If you want to keep it can we make it return a BIO? Many platforms could use it then for serial debug output etc. -- dwmw2 From rt at openssl.org Wed Sep 30 10:04:08 2015 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 30 Sep 2015 10:04:08 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> Message-ID: See http://www.infradead.org/rpr.html > To question about OPENSSL_stderr() that was removed with "not used" > rationale. When it comes to a *library* you always run risk of finding > something that it not used by the library itself, something that is > meant to be used exclusively by somebody else's application. And > OPENSSL_stderr() is such thing. Well, for a Unix person it's really > meaningless function, but it was introduced to solve small but > irritating problem in FIPS module context on Windows. You'll note I left it well alone on my 1.0.2 backports; only changed it in HEAD. If you want to keep it can we make it return a BIO? Many platforms could use it then for serial debug output etc. -- dwmw2 From rt at openssl.org Wed Sep 30 11:19:50 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 30 Sep 2015 11:19:50 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <560BC553.6030900@openssl.org> References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> <560BC553.6030900@openssl.org> Message-ID: > See http://www.infradead.org/rpr.html Must be poor timing. First DNS took forever, then I get unable to connect, connection time-outs... >> To question about OPENSSL_stderr() that was removed with "not used" >> rationale. When it comes to a *library* you always run risk of finding >> something that it not used by the library itself, something that is >> meant to be used exclusively by somebody else's application. And >> OPENSSL_stderr() is such thing. Well, for a Unix person it's really >> meaningless function, but it was introduced to solve small but >> irritating problem in FIPS module context on Windows. > > > You'll note I left it well alone on my 1.0.2 backports; only changed it in > HEAD. If you want to keep it can we make it return a BIO? Many platforms > could use it then for serial debug output etc. BIO would be an overkill in the original context, i.e. in context for irritating problem in FIPS module. But as current FIPS module is not really supported option in HEAD and would need overhaul in either case, let's let omission slide in HEAD. BTW, the comment was also meant to be of a little bit more general character, i.e. just because something is not used by the library itself, it doesn't have to be useless. From wayming.z at gmail.com Wed Sep 30 13:47:41 2015 From: wayming.z at gmail.com (Wayming Zhang) Date: Wed, 30 Sep 2015 23:47:41 +1000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560AA659.4020503@openssl.org> Message-ID: <560BE7FD.6050405@gmail.com> Is your process terminated or still alive after printing the last trace message? " Going to call SSL_connect() 15" If it is terminated already, is there any core dump file generated? If it is still alive, pstack command could help you to see what is happening. I don't see turning on debug could print any trace in SSL_Connect() funciton. If you want to see what happens inside the function, run your program under debugger and set break point in SSL_Connect(), then run it step by step. Wayming On 30/09/15 03:32, Tiantian Liu via RT wrote: > I downloaded the OpenSSL-1.0.1p. > > I configured it as : > > [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared threads > > /**************************************************************** > ******The configuration result as**************************************** > > Operating system: i686-whatever-linux2 > Configuring for debug-linux-elf > Configuring for debug-linux-elf > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=0 > CC =gcc > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > EX_LIBS =-lefence -ldl > CPUID_OBJ =x86cpuid.o > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > DES_ENC =des-586.o crypt586.o > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > BF_ENC =bf-586.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-586.o > RC5_ENC =rc5-586.o > MD5_OBJ_ASM =md5-586.o > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > RMD160_OBJ_ASM=rmd-586.o > CMLL_ENC =cmll-x86.o > MODES_OBJ =ghash-x86.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =/usr/bin/ranlib > ARFLAGS = > PERL =/usr/bin/perl > THIRTY_TWO_BIT mode > DES_PTR used > DES_RISC1 used > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' > crypto.h => ../include/openssl/crypto.h > opensslv.h => ../include/openssl/opensslv.h > opensslconf.h => ../include/openssl/opensslconf.h > ebcdic.h => ../include/openssl/ebcdic.h > symhacks.h => ../include/openssl/symhacks.h > ossl_typ.h => ../include/openssl/ossl_typ.h > constant_time_test.c => ../test/constant_time_test.c > making links in crypto/objects... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > objects.h => ../../include/openssl/objects.h > obj_mac.h => ../../include/openssl/obj_mac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > making links in crypto/md4... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > md4.h => ../../include/openssl/md4.h > md4test.c => ../../test/md4test.c > md4.c => ../../apps/md4.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > making links in crypto/md5... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > md5.h => ../../include/openssl/md5.h > md5test.c => ../../test/md5test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > making links in crypto/sha... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > sha.h => ../../include/openssl/sha.h > shatest.c => ../../test/shatest.c > sha1test.c => ../../test/sha1test.c > sha256t.c => ../../test/sha256t.c > sha512t.c => ../../test/sha512t.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > making links in crypto/mdc2... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > mdc2.h => ../../include/openssl/mdc2.h > mdc2test.c => ../../test/mdc2test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > making links in crypto/hmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' > hmac.h => ../../include/openssl/hmac.h > ...... > srptest.c => ../../test/srptest.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' > making links in crypto/cmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > cmac.h => ../../include/openssl/cmac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' > making links in ssl... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' > ssl.h => ../include/openssl/ssl.h > ssl2.h => ../include/openssl/ssl2.h > ssl3.h => ../include/openssl/ssl3.h > ssl23.h => ../include/openssl/ssl23.h > tls1.h => ../include/openssl/tls1.h > dtls1.h => ../include/openssl/dtls1.h > kssl.h => ../include/openssl/kssl.h > srtp.h => ../include/openssl/srtp.h > ssltest.c => ../test/ssltest.c > heartbeat_test.c => ../test/heartbeat_test.c > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' > making links in engines... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' > making links in engines/ccgost... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[2]: Nothing to be done for `links'. > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' > making links in apps... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' > making links in test... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > making links in tools... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' > generating dummy tests (if needed)... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `generate'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > Configured for debug-linux-elf. > > ***********************************************************/ > > > > Then I make it and got the ERROR message > Told me undefined reference to 'pthread_mutex_trylock' > Then I added '-lpthread' into the FLAG in Makefile. Then I went through and compiled successfully. > > Then I will ran my application again to see how SSL_connect() crash.... > Any requirement for me to start my application with OpenSSL (with debug enabled)? I mean to show me more information inside SSL_connect() > > Thanks, > Tyler > > > > > > -----Original Message----- > From: Matt Caswell via RT [mailto:rt at openssl.org] > Sent: September-29-15 10:55 AM > To: Tiantian Liu > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function > > > > On 29/09/15 15:45, Tiantian Liu via RT wrote: >> Hi Matt, >> Thanks for prompt response! >> While I confirm with you that my application crashed INSIDE the SSL_connect() function. > Your previous email indicated it was not crashing with SSLv23_method(): > "While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as..." > > So my advice was meant for that scenario. > >> So SSL_connect has no chance to return the 'res' value to me for analysis. >> Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. >> >> /* >> My debug statement wrote the " Going to call SSL_connect() 15" into my trace file >> And this message string is THE LAST message in my trace file. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); >> } >> res = SSL_connect(ssl); >> /* >> Oooop!!! The following statement was not executed! No debug message in my trace file anymore. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); >> } >> if (res <= 0) { >> sslerror = SSL_get_error(ssl, res); >> if (sslerror == SSL_ERROR_WANT_READ) { >> isexp = is_expired(exptime); >> if (isexp == 1) { >> if (isDiag) { >> SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); >> } >> strcpy(error, "SSL connect error"); >> return 0; >> } >> continue; >> } >> >> So, do you have any idea to get more information inside the SSL_connect? > If its actually crashing then we need to see a backtrace and a wireshark packet capture. > >> Should I re-compile and re-install OpenSSL lib? >> I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. >> > You should not get a compilation error. Please post the steps you took to compile the library and the compilation error you received. > > > 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 Wed Sep 30 13:47:59 2015 From: rt at openssl.org (Wayming Zhang via RT) Date: Wed, 30 Sep 2015 13:47:59 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <560BE7FD.6050405@gmail.com> References: <560AA659.4020503@openssl.org> <560BE7FD.6050405@gmail.com> Message-ID: Is your process terminated or still alive after printing the last trace message? " Going to call SSL_connect() 15" If it is terminated already, is there any core dump file generated? If it is still alive, pstack command could help you to see what is happening. I don't see turning on debug could print any trace in SSL_Connect() funciton. If you want to see what happens inside the function, run your program under debugger and set break point in SSL_Connect(), then run it step by step. Wayming On 30/09/15 03:32, Tiantian Liu via RT wrote: > I downloaded the OpenSSL-1.0.1p. > > I configured it as : > > [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared threads > > /**************************************************************** > ******The configuration result as**************************************** > > Operating system: i686-whatever-linux2 > Configuring for debug-linux-elf > Configuring for debug-linux-elf > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=0 > CC =gcc > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > EX_LIBS =-lefence -ldl > CPUID_OBJ =x86cpuid.o > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > DES_ENC =des-586.o crypt586.o > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > BF_ENC =bf-586.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-586.o > RC5_ENC =rc5-586.o > MD5_OBJ_ASM =md5-586.o > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > RMD160_OBJ_ASM=rmd-586.o > CMLL_ENC =cmll-x86.o > MODES_OBJ =ghash-x86.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =/usr/bin/ranlib > ARFLAGS = > PERL =/usr/bin/perl > THIRTY_TWO_BIT mode > DES_PTR used > DES_RISC1 used > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' > crypto.h => ../include/openssl/crypto.h > opensslv.h => ../include/openssl/opensslv.h > opensslconf.h => ../include/openssl/opensslconf.h > ebcdic.h => ../include/openssl/ebcdic.h > symhacks.h => ../include/openssl/symhacks.h > ossl_typ.h => ../include/openssl/ossl_typ.h > constant_time_test.c => ../test/constant_time_test.c > making links in crypto/objects... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > objects.h => ../../include/openssl/objects.h > obj_mac.h => ../../include/openssl/obj_mac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > making links in crypto/md4... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > md4.h => ../../include/openssl/md4.h > md4test.c => ../../test/md4test.c > md4.c => ../../apps/md4.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > making links in crypto/md5... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > md5.h => ../../include/openssl/md5.h > md5test.c => ../../test/md5test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > making links in crypto/sha... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > sha.h => ../../include/openssl/sha.h > shatest.c => ../../test/shatest.c > sha1test.c => ../../test/sha1test.c > sha256t.c => ../../test/sha256t.c > sha512t.c => ../../test/sha512t.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > making links in crypto/mdc2... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > mdc2.h => ../../include/openssl/mdc2.h > mdc2test.c => ../../test/mdc2test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > making links in crypto/hmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' > hmac.h => ../../include/openssl/hmac.h > ...... > srptest.c => ../../test/srptest.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' > making links in crypto/cmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > cmac.h => ../../include/openssl/cmac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' > making links in ssl... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' > ssl.h => ../include/openssl/ssl.h > ssl2.h => ../include/openssl/ssl2.h > ssl3.h => ../include/openssl/ssl3.h > ssl23.h => ../include/openssl/ssl23.h > tls1.h => ../include/openssl/tls1.h > dtls1.h => ../include/openssl/dtls1.h > kssl.h => ../include/openssl/kssl.h > srtp.h => ../include/openssl/srtp.h > ssltest.c => ../test/ssltest.c > heartbeat_test.c => ../test/heartbeat_test.c > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' > making links in engines... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' > making links in engines/ccgost... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[2]: Nothing to be done for `links'. > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' > making links in apps... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' > making links in test... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > making links in tools... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' > generating dummy tests (if needed)... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `generate'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > Configured for debug-linux-elf. > > ***********************************************************/ > > > > Then I make it and got the ERROR message > Told me undefined reference to 'pthread_mutex_trylock' > Then I added '-lpthread' into the FLAG in Makefile. Then I went through and compiled successfully. > > Then I will ran my application again to see how SSL_connect() crash.... > Any requirement for me to start my application with OpenSSL (with debug enabled)? I mean to show me more information inside SSL_connect() > > Thanks, > Tyler > > > > > > -----Original Message----- > From: Matt Caswell via RT [mailto:rt at openssl.org] > Sent: September-29-15 10:55 AM > To: Tiantian Liu > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function > > > > On 29/09/15 15:45, Tiantian Liu via RT wrote: >> Hi Matt, >> Thanks for prompt response! >> While I confirm with you that my application crashed INSIDE the SSL_connect() function. > Your previous email indicated it was not crashing with SSLv23_method(): > "While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as..." > > So my advice was meant for that scenario. > >> So SSL_connect has no chance to return the 'res' value to me for analysis. >> Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. >> >> /* >> My debug statement wrote the " Going to call SSL_connect() 15" into my trace file >> And this message string is THE LAST message in my trace file. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); >> } >> res = SSL_connect(ssl); >> /* >> Oooop!!! The following statement was not executed! No debug message in my trace file anymore. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); >> } >> if (res <= 0) { >> sslerror = SSL_get_error(ssl, res); >> if (sslerror == SSL_ERROR_WANT_READ) { >> isexp = is_expired(exptime); >> if (isexp == 1) { >> if (isDiag) { >> SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); >> } >> strcpy(error, "SSL connect error"); >> return 0; >> } >> continue; >> } >> >> So, do you have any idea to get more information inside the SSL_connect? > If its actually crashing then we need to see a backtrace and a wireshark packet capture. > >> Should I re-compile and re-install OpenSSL lib? >> I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. >> > You should not get a compilation error. Please post the steps you took to compile the library and the compilation error you received. > > > Matt > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From matt at openssl.org Wed Sep 30 14:45:46 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Sep 2015 15:45:46 +0100 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <20150930092227.GA4328@kronk.local> Message-ID: <560BF59A.8090203@openssl.org> On 30/09/15 10:22, Alessandro Ghedini via RT wrote: > On Wed, Sep 30, 2015 at 02:01:54am +0000, Rich Salz via RT wrote: >> We fixed this in a slightly different way. We made BIO_new_file and BIO_s_file >> return an alternate implementation that returns run-time failures. Almost all >> of the OpenSSL code uses the BIO object, so we didn't have to remove that. We >> did #ifdef out any routine that had a "FILE*" param or local variable. > > Note that commit 984d6c6 causes mingw shared builds to fail again: > https://travis-ci.org/openssl/openssl/jobs/82855661 > > The problem seems to be that entries 4991 and 4992 in libeay.num are used twice. > Fixed: https://github.com/openssl/openssl/commit/dd35486db671dca36caffecc7ee1f5f6483b3a4b > Since this is not the first time this happens, I was thinking that maybe having > a test for this would be useful. Good idea: https://github.com/openssl/openssl/commit/5530d5187c77877b610b11c4aadedd7107386afa Matt From rt at openssl.org Wed Sep 30 15:06:43 2015 From: rt at openssl.org (Haiyang Yin via RT) Date: Wed, 30 Sep 2015 15:06:43 +0000 Subject: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash In-Reply-To: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> References: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hello, I am using memory-based bio to handle dtls sessions. Crash happened after close notify received and SSL was cleaned up ? OpenSSL version is 1.0.2d. If more detailed information required, pls. let me known. Thanks, 2015-09-29 22:59:32.968954 [ DEBUG ] [ StunTransManager.cpp ] [ 95 ] StunTransManager::init() Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x7fffe77fe700 (LWP 16074)]0x00007ffff73ced29 in sk_value () from /usr/local/ssl/lib/libcrypto.so.1.0.0(gdb) bt#0 ?0x00007ffff73ced29 in sk_value () from /usr/local/ssl/lib/libcrypto.so.1.0.0#1 ?0x00007ffff731f8db in int_free_ex_data () from /usr/local/ssl/lib/libcrypto.so.1.0.0#2 ?0x00007ffff73c495a in BIO_free () from /usr/local/ssl/lib/libcrypto.so.1.0.0#3 ?0x00007ffff73c5274 in BIO_free_all () from /usr/local/ssl/lib/libcrypto.so.1.0.0#4 ?0x00007ffff774df5b in SSL_free () from /usr/local/ssl/lib/libssl.so.1.0.0#5 ?0x000000000077ca35 in TestDtlsSession::cleanup (this=0x7fffd4000a50) at /home/hyin/projects/intelligent_home_gateway/test/src/TestDtlsSession.cpp:418#6 ?0x000000000077bcaa in TestDtlsSession::~TestDtlsSession (this=0x7fffd4000a50, __in_chrg=) at /home/hyin/projects/intelligent_home_gateway/test/src/TestDtlsSession.cpp:141#7 ?0x0000000000786760 in __gnu_cxx::new_allocator::destroy (this=0x7fffd4000a50, __p=0x7fffd4000a50) at /usr/include/c++/4.9/ext/new_allocator.h:124#8 ?0x000000000078671d in std::allocator_traits >::_S_destroy (__a=..., __p=0x7fffd4000a50) at /usr/include/c++/4.9/bits/alloc_traits.h:282#9 ?0x00000000007866c5 in std::allocator_traits >::destroy (__a=..., __p=0x7fffd4000a50) at /usr/include/c++/4.9/bits/alloc_traits.h:411#10 0x000000000078656f in std::_Sp_counted_ptr_inplace, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x7fffd4000a40)? ? at /usr/include/c++/4.9/bits/shared_ptr_base.h:524#11 0x000000000073a8d6 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7fffd4000a40) at /usr/include/c++/4.9/bits/shared_ptr_base.h:149#12 0x0000000000739a81 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x7fffe77f5738, __in_chrg=) at /usr/include/c++/4.9/bits/shared_ptr_base.h:666#13 0x0000000000783392 in std::__shared_ptr::~__shared_ptr (this=0x7fffe77f5730, __in_chrg=) at /usr/include/c++/4.9/bits/shared_ptr_base.h:914#14 0x00000000007833d2 in std::shared_ptr::~shared_ptr (this=0x7fffe77f5730, __in_chrg=) at /usr/include/c++/4.9/bits/shared_ptr.h:93#15 0x0000000000781fae in TestStunServer::handleCallback (this=0x7fffffffd230, spTransport=..., sessionMap=..., sender=..., encrypted=0x7fffd8000970 "\025\376", ,?? ? encryptedLen=39, decrypted=0x7fffe77f59e0 "", decryptedLen=@0x7fffe77f5858: 32768, ready=@0x7fffe77f57c7: false) at /home/hyin/projects/intelligent_home_gateway/test/src/TestStunServer.cpp:637#16 0x00000000007812d6 in TestStunServer::transCallback4 (this=0x7fffffffd230, event=com::purplehyacinth::intellihomegateway::transport::DATA_EVT, sender=...,?? ? data=0x7fffd8000970 "\025\376", , dataLen=39) at /home/hyin/projects/intelligent_home_gateway/test/src/TestStunServer.cpp:539#17 0x000000000078594e in std::_Mem_fn::operator()(TestStunServer*, com::purplehyacinth::intellihomegateway::transport::CallbackEvent_e&&, com::purplehyacinth::intellihomegateway::transport::TransportAddress const&, char const*&&, unsigned long&&) const (this=0xc0a070, __object=0x7fffffffd230) at /usr/include/c++/4.9/functional:569#18 0x000000000078539a in std::_Bind (TestStunServer*, std::_Placeholder<1>, std::_Placeholder<2>, std::_Placeholder<3>, std::_Placeholder<4>)>::__call(std::tuple&&, std::_Index_tuple<0ul, 1ul, 2ul, 3ul, 4ul>) (? ? this=0xc0a070, __args=) at /usr/include/c++/4.9/functional:1264#19 0x000000000078479f in std::_Bind (TestStunServer*, std::_Placeholder<1>, std::_Placeholder<2>, std::_Placeholder<3>, std::_Placeholder<4>)>::operator()(com::purplehyacinth::intellihomegateway::transport::CallbackEvent_e&&, com::purplehyacinth::intellihomegateway::transport::TransportAddress const&, char const*&&, unsigned long&&) (this=0xc0a070) at /usr/include/c++/4.9/functional:1323#20 0x0000000000783f59 in std::_Function_handler (TestStunServer*, std::_Placeholder<1>, std::_Placeholder<2>, std::_Placeholder<3>, std::_Placeholder<4>)> >::_M_invoke(std::_Any_data const&, com::purplehyacinth::intellihomegateway::transport::CallbackEvent_e, com::purplehyacinth::intellihomegateway::transport::TransportAddress const&, char const*, unsigned long) (__functor=...,?? ? __args#0=com::purplehyacinth::intellihomegateway::transport::DATA_EVT, __args#1=..., __args#2=0x7fffd8000970 "\025\376", , __args#3=39)? ? at /usr/include/c++/4.9/functional:2039#21 0x00000000008928b6 in std::function::operator()(com::purplehyacinth::intellihomegateway::transport::CallbackEvent_e, com::purplehyacinth::intellihomegateway::transport::TransportAddress const&, char const*, unsigned long) const (this=0xc2d508, __args#0=com::purplehyacinth::intellihomegateway::transport::DATA_EVT, __args#1=..., __args#2=0x7fffd8000970 "\025\376", , __args#3=39)? ? at /usr/include/c++/4.9/functional:2439#22 0x0000000000891841 in com::purplehyacinth::intellihomegateway::transport::ServerCallbackDispatcher::dispatch (this=0xc2d500)? ? at /home/hyin/projects/intelligent_home_gateway/src/com/purplehyacinth/intellihomegateway/transport/ServerCallbackDispatcher.cpp:173#23 0x000000000089684b in std::_Mem_fn::operator()<, void>(com::purplehyacinth::intellihomegateway::transport::ServerCallbackDispatcher*) const (this=0xc086d0, __object=0xc2d500) at /usr/include/c++/4.9/functional:569#24 0x00000000008967c2 in std::_Bind (com::purplehyacinth::intellihomegateway::transport::ServerCallbackDispatcher*)>::__call(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0xc086d0,?? ? __args=) at /usr/include/c++/4.9/functional:1264#25 0x0000000000896664 in std::_Bind (com::purplehyacinth::intellihomegateway::transport::ServerCallbackDispatcher*)>::operator()<, bool>() (this=0xc086d0) at /usr/include/c++/4.9/functional:1323#26 0x0000000000896481 in std::_Function_handler (com::purplehyacinth::intellihomegateway::transport::ServerCallbackDispatcher*)> >::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/4.9/functional:2025#27 0x000000000081dc9e in std::function::operator()() const (this=0xc3daa0) at /usr/include/c++/4.9/functional:2439---Type to continue, or q to quit--- ?#28 0x000000000081d630 in com::purplehyacinth::intellihomegateway::common::ScopedThread >::run() (this=0xc3daa0)? ? at /home/hyin/projects/intelligent_home_gateway/inc/common/ScopedThread.hpp:209#29 0x000000000081fdbf in std::_Mem_fn >::*)()>::operator()<, void>(com::purplehyacinth::intellihomegateway::common::ScopedThread >*) const (this=0xc3dbe8, __object=0xc3daa0) at /usr/include/c++/4.9/functional:569#30 0x000000000081fd28 in std::_Bind >::*)()> (com::purplehyacinth::intellihomegateway::common::ScopedThread >*)>::__call(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0xc3dbe8,?? ? __args=) at /usr/include/c++/4.9/functional:1264#31 0x000000000081fca2 in std::_Bind >::*)()> (com::purplehyacinth::intellihomegateway::common::ScopedThread >*)>::operator()<, void>() (this=0xc3dbe8) at /usr/include/c++/4.9/functional:1323#32 0x000000000081fbf6 in std::_Bind_simple >::*)()> (com::purplehyacinth::intellihomegateway::common::ScopedThread >*)> ()>::_M_invoke<>(std::_Index_tuple<>) (this=0xc3dbe8) at /usr/include/c++/4.9/functional:1700#33 0x000000000081fae3 in std::_Bind_simple >::*)()> (com::purplehyacinth::intellihomegateway::common::ScopedThread >*)> ()>::operator()() (this=0xc3dbe8) at /usr/include/c++/4.9/functional:1688#34 0x000000000081f9fc in std::thread::_Impl >::*)()> (com::purplehyacinth::intellihomegateway::common::ScopedThread >*)> ()> >::_M_run() (this=0xc3dbd0) at /usr/include/c++/4.9/thread:115#35 0x00007ffff6dbce40 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6#36 0x00007ffff7bc4182 in start_thread (arg=0x7fffe77fe700) at pthread_create.c:312#37 0x00007ffff651d47d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111(gdb)?(gdb)?(gdb)?(gdb) q -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From dwmw2 at infradead.org Wed Sep 30 14:37:03 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 30 Sep 2015 16:37:03 +0200 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> <560BC553.6030900@openssl.org> Message-ID: <1443623823.28791.11.camel@infradead.org> On Wed, 2015-09-30 at 11:19 +0000, Andy Polyakov via RT wrote: > > See http://www.infradead.org/rpr.html > > Must be poor timing. First DNS took forever, then I get unable to > connect, connection time-outs... Apologies. I'm travelling and in trying to avoid the mess of top-posted HTML that would result from using the Android mailer, I was using SquirrelMail. For reasons I will attempt to establish when I get home, that results in a line of what *should* have been an RFC822 header, being visible in the body of the email. Please ignore that. (And yes, {ns1,www,ftp}.infradead.org is currently AWOL) > BIO would be an overkill in the original context, i.e. in context for > irritating problem in FIPS module. But as current FIPS module is not > really supported option in HEAD and would need overhaul in either > case, > let's let omission slide in HEAD. BTW, the comment was also meant to > be > of a little bit more general character, i.e. just because something > is > not used by the library itself, it doesn't have to be useless. I think my observation was more than "not used by the library itself". It was also (in HEAD) not in an exported header file, and not documented. And not actually used anywhere outside the FIPS module. The BIO thing came to mind when fixing other no-stdio failures, with code that thinks it's OK to fprintf(stderr, ?). That code *could* potentially use BIO_printf(OPENSSL_stderr(), ?). Or could just be fixed not to do that kind of thing at all. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rsalz at akamai.com Wed Sep 30 15:10:19 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 15:10:19 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> Message-ID: > If things like BIO_new_file() were inline, or macros, then the compiler could > *see* that they'd return NULL. And lots of code in the *calling* functions > (basically everything but the error path) could be elided from the compiled > result... Cool, will do that. From rt at openssl.org Wed Sep 30 15:12:54 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 30 Sep 2015 15:12:54 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> Message-ID: > If things like BIO_new_file() were inline, or macros, then the compiler could > *see* that they'd return NULL. And lots of code in the *calling* functions > (basically everything but the error path) could be elided from the compiled > result... Cool, will do that. From rsalz at akamai.com Wed Sep 30 15:17:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 15:17:01 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> Message-ID: > OPENSSL_stderr() is such thing. Well, for a Unix person it's really meaningless > function, but it was introduced to solve small but irritating problem in FIPS > module context on Windows. I removed it :) Since 1.1 doesn't support FIPS, that's okay. But we'll have something like that for stdin/stdout/stderr. From rt at openssl.org Wed Sep 30 15:17:04 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 30 Sep 2015 15:17:04 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> Message-ID: > OPENSSL_stderr() is such thing. Well, for a Unix person it's really meaningless > function, but it was introduced to solve small but irritating problem in FIPS > module context on Windows. I removed it :) Since 1.1 doesn't support FIPS, that's okay. But we'll have something like that for stdin/stdout/stderr. From matt at openssl.org Wed Sep 30 15:22:02 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Sep 2015 16:22:02 +0100 Subject: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash In-Reply-To: References: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> Message-ID: <560BFE1A.5060009@openssl.org> On 30/09/15 16:06, Haiyang Yin via RT wrote: > Hello, I am using memory-based bio to handle dtls sessions. Crash > happened after close notify received and SSL was cleaned up ? OpenSSL > version is 1.0.2d. If more detailed information required, pls. let me > known. Your gdb output is impossible to read. At least it is for me - all line breaks seem to have been removed. Can you post a more readable version? How are you setting up your memory bios? The OpenSSL memory BIOs don't really work too well with DTLS because they do not preserve packet boundaries. Can you post some code? Matt From rt at openssl.org Wed Sep 30 15:22:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 30 Sep 2015 15:22:05 +0000 Subject: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash In-Reply-To: <560BFE1A.5060009@openssl.org> References: <830657612.2927488.1443584266236.JavaMail.yahoo@mail.yahoo.com> <560BFE1A.5060009@openssl.org> Message-ID: On 30/09/15 16:06, Haiyang Yin via RT wrote: > Hello, I am using memory-based bio to handle dtls sessions. Crash > happened after close notify received and SSL was cleaned up ? OpenSSL > version is 1.0.2d. If more detailed information required, pls. let me > known. Your gdb output is impossible to read. At least it is for me - all line breaks seem to have been removed. Can you post a more readable version? How are you setting up your memory bios? The OpenSSL memory BIOs don't really work too well with DTLS because they do not preserve packet boundaries. Can you post some code? Matt From rsalz at akamai.com Wed Sep 30 15:21:19 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 15:21:19 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> Message-ID: <4d7b2c3d86b94b1788baeefb2c52e004@ustx2ex-dag1mb3.msg.corp.akamai.com> > If you want to keep it can we make it return a BIO? Many platforms could use > it then for serial debug output etc. That's what I'm going to do. From rt at openssl.org Wed Sep 30 15:22:35 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 30 Sep 2015 15:22:35 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <4d7b2c3d86b94b1788baeefb2c52e004@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <1438170735.26511.33.camel@intel.com> <560B9885.60205@openssl.org> <3207646461d4aec623eff63d33a92973.squirrel@twosheds.infradead.org> <4d7b2c3d86b94b1788baeefb2c52e004@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: > If you want to keep it can we make it return a BIO? Many platforms could use > it then for serial debug output etc. That's what I'm going to do. From rt at openssl.org Wed Sep 30 16:49:55 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Wed, 30 Sep 2015 16:49:55 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> Message-ID: On Wednesday 30 September 2015 09:37:37 Albe Laurenz wrote: > Matt Caswell wrote: > > On 28/09/15 12:35, Albe Laurenz via RT wrote: > >> Matt Caswell wrote: > >>> However, I have some concerns with the wording of the RFC. It > >>> seems to place no limits whatsoever on when it is valid to > >>> receive app data in the handshake. By the wording in the RFC it > >>> would be valid for app data to be received *after* the > >>> ChangeCipherSpec has been received but *before* the Finished has > >>> been processed. This seems dangerous to me because it is not > >>> until the Finished is processed that we verify the handshake data > >>> MAC - and yet we could already have acted upon app data received. > >>> I assume the intent was to allow the interleaved app data only up > >>> until the point that the CCS is received. I have attached a patch > >>> for 1.0.2 that implements that logic. > >> > >> The RFC writes: > >> Note: If a rehandshake occurs while data is flowing on a > >> connection, > >> the communicating parties may continue to send data using the > >> old > >> CipherSpec. However, once the ChangeCipherSpec has been sent, > >> the > >> new CipherSpec MUST be used. The first side to send the > >> ChangeCipherSpec does not know that the other side has finished > >> computing the new keying material (e.g., if it has to perform a > >> time-consuming public key operation). Thus, a small window of > >> time, > >> during which the recipient must buffer the data, MAY exist. In > >> practice, with modern machines this interval is likely to be > >> fairly > >> short. > >> > >> Could that be interpreted to mean that the recepient should buffer > >> all incoming Application Data messages that are sent between > >> ChangeCipherSpec and Finished? > > > > Thanks. I had missed that wording. I think this means that as soon > > as > > the first party sends a CCS, they must not send any app data until > > they have received a CCS back (they must buffer it until the CCS is > > seen). So the second party should never expect to see app data > > between CCS and Finished. It doesn't tell you anything about what > > the first party can expect though, i.e. is the second party allowed > > to send app data between the CCS and Finished? > > Interesting how we can read this so differently. > If anything, that confirms that the wording of the RFC is suboptimal. I'd interpret it as not talking about the client's ability to send data but rather about latency observed by application layer. In other words about such situation: ClientKeyExchange [ChangeCipherSpec] Finished Application Data[1] --------> [ChangeCipherSpec] <-------- Finished Application Data[2] <-------> Application Data and how the data [1] will be received by other side's application later than if it wasn't sent during a handshake -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed Sep 30 17:45:09 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 30 Sep 2015 17:45:09 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <560C1FA2.4010906@akamai.com> References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> Message-ID: On 09/30/2015 10:12 AM, Salz, Rich via RT wrote: >> If things like BIO_new_file() were inline, or macros, then the compiler could >> *see* that they'd return NULL. And lots of code in the *calling* functions >> (basically everything but the error path) could be elided from the compiled >> result... > Cool, will do that. > Making things inline functions or macros requires exposing their implementation details to consumers of the header in question. That seems at odds with the goal of making structures opaque, though I don't know whether making BIO opaque was one of the targets for that project. -Ben From rsalz at akamai.com Wed Sep 30 17:53:18 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 17:53:18 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> Message-ID: No, it's this #ifdef OPENSSL_NO_STDIO #define BIO_new_file(f,m) NULL #endif From bkaduk at akamai.com Wed Sep 30 17:57:41 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 30 Sep 2015 12:57:41 -0500 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> Message-ID: <560C2295.4030905@akamai.com> On 09/30/2015 12:53 PM, Salz, Rich wrote: > No, it's this > #ifdef OPENSSL_NO_STDIO > #define BIO_new_file(f,m) NULL > #endif > That looks like the library is conditionally exporting different symbols depending on the build configuration, which I considered doing for my work on OpenAFS but eventually decided that it would cause too many problems and pulled out. I guess this particular case might be reasonable for UEFI use, but I am unconvinced that it's a good idea in general. -Ben From rsalz at akamai.com Wed Sep 30 17:59:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 17:59:35 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <560C2295.4030905@akamai.com> References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> <560C2295.4030905@akamai.com> Message-ID: > That looks like the library is conditionally exporting different symbols > depending on the build configuration No more than any other compile-time control. From bkaduk at akamai.com Wed Sep 30 18:21:10 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 30 Sep 2015 13:21:10 -0500 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> <560C2295.4030905@akamai.com> Message-ID: <560C2816.5050501@akamai.com> On 09/30/2015 12:59 PM, Salz, Rich wrote: >> That looks like the library is conditionally exporting different symbols >> depending on the build configuration > No more than any other compile-time control. > Okay, I guess you have convinced me, in that the ship has already sailed. -Ben From dwmw2 at infradead.org Wed Sep 30 18:02:16 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 30 Sep 2015 20:02:16 +0200 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> Message-ID: <1443636136.28791.40.camel@infradead.org> On Wed, 2015-09-30 at 17:45 +0000, Kaduk, Ben via RT wrote: > Making things inline functions or macros requires exposing their > implementation details to consumers of the header in question. That > seems at odds with the goal of making structures opaque, though I don't > know whether making BIO opaque was one of the targets for that project. You can still have a function that transparently returns (BIO *)NULL, irrespective of whether the BIO structure is opaque or not. If we wanted OPENSSL_NO_STDIO to be a purely internal option, not making any change to the external ABI, then perhaps this would be a consideration. But I don't think that would even be feasible. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Wed Sep 30 18:21:29 2015 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 30 Sep 2015 18:21:29 +0000 Subject: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build In-Reply-To: <1443636136.28791.40.camel@infradead.org> References: <1438170735.26511.33.camel@intel.com> <1443594239.28791.4.camel@intel.com> <560C1FA2.4010906@akamai.com> <1443636136.28791.40.camel@infradead.org> Message-ID: On Wed, 2015-09-30 at 17:45 +0000, Kaduk, Ben via RT wrote: > Making things inline functions or macros requires exposing their > implementation details to consumers of the header in question. That > seems at odds with the goal of making structures opaque, though I don't > know whether making BIO opaque was one of the targets for that project. You can still have a function that transparently returns (BIO *)NULL, irrespective of whether the BIO structure is opaque or not. If we wanted OPENSSL_NO_STDIO to be a purely internal option, not making any change to the external ABI, then perhaps this would be a consideration. But I don't think that would even be feasible. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From karthik.bhargavan at gmail.com Wed Sep 30 18:41:26 2015 From: karthik.bhargavan at gmail.com (Karthikeyan Bhargavan) Date: Wed, 30 Sep 2015 20:41:26 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> Message-ID: A simpler interpretation would be that application data should never be sent or received with sequence number = 0; only finished messages may have this sequence number. For connections with NPN enabled, we may need a slightly more complex rule. In TLS we can also assume that encrypted fragments will not be accepted out of sequence. Perhaps DTLS violates this sequentiality? In which case, the interpretation of the CCS - Finished - AppData ordering becomes more difficult to enforce for DTLS. -K. > I'd interpret it as not talking about the client's ability to send data > but rather about latency observed by application layer. In other words > about such situation: > > > ClientKeyExchange > [ChangeCipherSpec] > Finished > Application Data[1] --------> > [ChangeCipherSpec] > <-------- Finished > Application Data[2] <-------> Application Data > > and how the data [1] will be received by other side's application later > than if it wasn't sent during a handshake > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rt at openssl.org Wed Sep 30 18:41:39 2015 From: rt at openssl.org (Karthikeyan Bhargavan via RT) Date: Wed, 30 Sep 2015 18:41:39 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> Message-ID: A simpler interpretation would be that application data should never be sent or received with sequence number = 0; only finished messages may have this sequence number. For connections with NPN enabled, we may need a slightly more complex rule. In TLS we can also assume that encrypted fragments will not be accepted out of sequence. Perhaps DTLS violates this sequentiality? In which case, the interpretation of the CCS - Finished - AppData ordering becomes more difficult to enforce for DTLS. -K. > I'd interpret it as not talking about the client's ability to send data > but rather about latency observed by application layer. In other words > about such situation: > > > ClientKeyExchange > [ChangeCipherSpec] > Finished > Application Data[1] --------> > [ChangeCipherSpec] > <-------- Finished > Application Data[2] <-------> Application Data > > and how the data [1] will be received by other side's application later > than if it wasn't sent during a handshake > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: not available URL: