From matt at openssl.org Sun Jan 6 15:23:18 2019 From: matt at openssl.org (Matt Caswell) Date: Sun, 6 Jan 2019 15:23:18 +0000 Subject: [openssl-project] Monthly Status Report (December) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Continued input on the FIPS design - Fixed an Ed448 signature maleability issue - Fixed a regression in SSL_export_keying_material which was impacting Tor - Added documentation for the num_tickets option to s_server - Updated the CLA templates to fix the snail mail address - PR review work related to the Apache licence change - Fixed an issue with the OPENSSL_VERSION_NUMBER macro - Coordinated feedback on the OSTIF audit - Investigated a potential PSK interop issue (no change required) Note that December was a short month due to annual leave followed by Xmas holidays. Matt From Matthias.St.Pierre at ncp-e.com Wed Jan 9 16:21:06 2019 From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre) Date: Wed, 9 Jan 2019 17:21:06 +0100 Subject: [openssl-project] Update release strategy to document new versioning scheme Message-ID: Hi, I just happened to notice that the Release Strategy [1] on our homepage is outdated w.r.t. the versioning scheme: It still calls the 1.x.y versioning scheme the 'improved' one, and does not mention the new 3.0.0+ scheme at all. > As of release 1.0.0 the OpenSSL versioning scheme was improved > to better meet developers' and vendors' expectations. Letter > releases, such as 1.0.2a, exclusively contain bug and security > fixes and no new features. Minor releases that change the last > digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new > features, but in a way that does not break binary > compatibility. ... In fact, the only official mentions of the new versioning scheme are the blog post [2] from November 28 and (indirectly) the License page [3] because it has been updated for the Apache relicensing. So maybe `releasestrat.html` needs an update? You could also add a separate `versioning.html` for versioning details, if you don't want to overload `releasestrats.html`. The contents of `versioning.html` could be taken partially from [1] and [3]. Matthias [1] https://www.openssl.org/policies/releasestrat.html [2] https://www.openssl.org/blog/blog/2018/11/28/version/ [3] https://www.openssl.org/source/license.html From matt at openssl.org Mon Jan 14 15:21:24 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Jan 2019 15:21:24 +0000 Subject: [openssl-project] Release strategy updates In-Reply-To: <75452fd2-9d54-3b43-8daf-24961c7af1e0@openssl.org> References: <75452fd2-9d54-3b43-8daf-24961c7af1e0@openssl.org> Message-ID: <57dee26e-e204-dbf7-4704-e312285a0661@openssl.org> On 21/09/2018 14:19, Matt Caswell wrote: > I am very concerned about stability of our API moving forwards. There > are various discussions about changing the version number to 1.2.0 (or > possibly 2.0.0) - which according to our versioning scheme would allow > breaking changes. Whilst this is true I think we need to be very wary > about "opening the flood gates" for breaking changes. > > The move from 1.0.x to 1.1.0 was hard on our users and we should avoid > that again. > > With that in mind I have opened the following PR (based largely on > wording suggested by Viktor): > > https://github.com/openssl/web/pull/82 > > At the same time I have taken the opportunity to clean up some > out-of-date stuff in the release strategy. > > This is independent of the semantic versioning discussion which may > itself see further changes being made to the release strategy. > > Thoughts? > > Matt > A somewhat tardy follow up on this...I updated this PR with the latest comments so please take a look. Matt From openssl-users at dukhovni.org Tue Jan 22 19:48:26 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Jan 2019 14:48:26 -0500 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: Message-ID: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> > On Jan 22, 2019, at 2:06 PM, Adam Langley wrote: > > (This is another installment of our experiences with deploying the > RFC-final TLS 1.3?previous messages: [1][2]. We share these with the > community to hopefully avoid other people hitting the same issues.) > > [...] > > However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3 > post-handshake messages are received[5], including KeyUpdate. This > causes KeyUpdate messages to break with, at least, HAProxy, and with > NGINX prior to this commit[6]. (There may well be more, but that level > of breakage was enough to drown any other signal.) > > Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages > per connection[7]. Therefore clients that send periodic KeyUpdates > based on elapsed time or transmitted bytes will eventually hit that > limit, which is fatal to the connection. > > Therefore KeyUpdate messages are not currently viable on the web, at > least when client initiated. > > [1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE > [2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ > [3] https://bugs.openjdk.java.net/browse/JDK-8211806 > [4] https://bugs.openjdk.java.net/browse/JDK-8213202 > [5] https://github.com/openssl/openssl/issues/8069 > [6] https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c > [7] https://github.com/openssl/openssl/issues/8068 > [8] https://twitter.com/__subodh/status/1085642001595265024 I think we should remediate the reported issues in the 1.1.1b release. We should probably clear the keyUpdate count when sufficient application data has been received from the peer. Where sufficient could be as little as 1 byte, or could be something more reasonable (say 1MB, allowing for up to 32 rekeys per MB, which is plenty). As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure what to do there, but perhaps we could define a new even for keyUpdates that does not mislead applications into assuming a new "handshake". -- Viktor. From davidben at google.com Tue Jan 22 20:41:27 2019 From: davidben at google.com (David Benjamin) Date: Tue, 22 Jan 2019 14:41:27 -0600 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> Message-ID: On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni wrote: > > > > On Jan 22, 2019, at 2:06 PM, Adam Langley > wrote: > > > > (This is another installment of our experiences with deploying the > > RFC-final TLS 1.3?previous messages: [1][2]. We share these with the > > community to hopefully avoid other people hitting the same issues.) > > > > [...] > > > > However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3 > > post-handshake messages are received[5], including KeyUpdate. This > > causes KeyUpdate messages to break with, at least, HAProxy, and with > > NGINX prior to this commit[6]. (There may well be more, but that level > > of breakage was enough to drown any other signal.) > > > > Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages > > per connection[7]. Therefore clients that send periodic KeyUpdates > > based on elapsed time or transmitted bytes will eventually hit that > > limit, which is fatal to the connection. > > > > Therefore KeyUpdate messages are not currently viable on the web, at > > least when client initiated. > > > > [1] > https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE > > [2] > https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ > > [3] https://bugs.openjdk.java.net/browse/JDK-8211806 > > [4] https://bugs.openjdk.java.net/browse/JDK-8213202 > > [5] https://github.com/openssl/openssl/issues/8069 > > [6] > https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c > > [7] https://github.com/openssl/openssl/issues/8068 > > [8] https://twitter.com/__subodh/status/1085642001595265024 > > I think we should remediate the reported issues in the 1.1.1b release. > We should probably clear the keyUpdate count when sufficient application > data has been received from the peer. Where sufficient could be as little > as 1 byte, or could be something more reasonable (say 1MB, allowing for > up to 32 rekeys per MB, which is plenty). > > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > what to do there, but perhaps we could define a new even for keyUpdates > that does not mislead applications into assuming a new "handshake". > I think this is clearly the right option. This is a compatibility break, IMO. Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 1.3), this was the only way to disable renegotiations. I've seen a lot of codebases do this. I don't think one could even call it a mishandling. The natural interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has started. Thus, if you wish to block renegotiations, absent a more direct API, it's natural to count those and fail if you see more than one. A KeyUpdate is not a handshake. It's some internal rejiggering of the record layer. In an alternate universe, the IETF might have specified KeyUpdate as distinct record type. (It probably should have, given that KeyUpdate in DTLS and QUIC necessarily look different.) Skimming the code, it looks like OpenSSL only surfaces SSL_CB_HANDSHAKE_START because it internally sends post-handshake messages through the handshake path? This is an implementation detail shouldn't be visible in the public API. At the public API, one needs to think about what a given API *means*. (Does that implementation strategy even work? Handshakes tie up read and write flows, while the unidirectional post-handshake messages shouldn't. If you're trying to send a KeyUpdate and the transport blocks, does that block SSL_read? If I send you half a NewSessionTicket and pause, does that block SSL_write?) BoringSSL does not signal SSL_CB_HANDSHAKE_START on KeyUpdate, just something out the msg_callback. One could imagine dedicated SSL_CB_* hooks for KeyUpdate if anyone needed it, I suppose, but it's unclear to me if that's necessary. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Jan 22 20:49:14 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 22 Jan 2019 21:49:14 +0100 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> Message-ID: <20190122204913.GA29040@roeckx.be> On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote: > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > what to do there, but perhaps we could define a new even for keyUpdates > that does not mislead applications into assuming a new "handshake". I think calling anything a handshake that is not a handshake should either be removed or renamed. KeyUpdate is not a handshake. I'm not sure what we do in case of a session ticket, but it also shouldn't send such events, but other events are probably useful in that case. Kurt From davidben at google.com Tue Jan 22 21:29:51 2019 From: davidben at google.com (David Benjamin) Date: Tue, 22 Jan 2019 15:29:51 -0600 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <20190122204913.GA29040@roeckx.be> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <20190122204913.GA29040@roeckx.be> Message-ID: On Tue, Jan 22, 2019 at 2:49 PM Kurt Roeckx wrote: > On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote: > > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > > what to do there, but perhaps we could define a new even for keyUpdates > > that does not mislead applications into assuming a new "handshake". > > I think calling anything a handshake that is not a handshake > should either be removed or renamed. KeyUpdate is not a handshake. > I'm not sure what we do in case of a session ticket, but it also > shouldn't send such events, but other events are probably useful > in that case. > That one's already signaled out of SSL_CTX_sess_set_new_cb. I don't think you need particularly need another event given that exists. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 23 10:24:18 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 23 Jan 2019 10:24:18 +0000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> Message-ID: <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> On 22/01/2019 20:41, David Benjamin wrote: > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > wrote: > > > > > On Jan 22, 2019, at 2:06 PM, Adam Langley > wrote: > > > > (This is another installment of our experiences with deploying the > > RFC-final TLS 1.3?previous messages: [1][2]. We share these with the > > community to hopefully avoid other people hitting the same issues.) > > > > [...] > > > > However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3 > > post-handshake messages are received[5], including KeyUpdate. This > > causes KeyUpdate messages to break with, at least, HAProxy, and with > > NGINX prior to this commit[6]. (There may well be more, but that level > > of breakage was enough to drown any other signal.) > > > > Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages > > per connection[7]. Therefore clients that send periodic KeyUpdates > > based on elapsed time or transmitted bytes will eventually hit that > > limit, which is fatal to the connection. > > > > Therefore KeyUpdate messages are not currently viable on the web, at > > least when client initiated. > > > > [1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE > > [2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ > > [3] https://bugs.openjdk.java.net/browse/JDK-8211806 > > [4] https://bugs.openjdk.java.net/browse/JDK-8213202 > > [5] https://github.com/openssl/openssl/issues/8069 > > [6] > https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c > > [7] https://github.com/openssl/openssl/issues/8068 > > [8] https://twitter.com/__subodh/status/1085642001595265024 > > I think we should remediate the reported issues in the 1.1.1b release. > We should probably clear the keyUpdate count when sufficient application > data has been received from the peer.? Where sufficient could be as little > as 1 byte, or could be something more reasonable (say 1MB, allowing for > up to 32 rekeys per MB, which is plenty). > > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > what to do there, but perhaps we could define a new even for keyUpdates > that does not mislead applications into assuming a new "handshake". > > > I think this is clearly the right option. This is a compatibility break, IMO. > > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 1.3), this > was the only way to disable renegotiations. I've seen a lot of codebases do > this. I don't think one could even call it a mishandling. The natural > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has started. > Thus, if you wish to block renegotiations, absent a more direct API, it's > natural to count those and fail if you see more than one. > > A KeyUpdate is not a handshake. That's depends on your perspective. One peer sends a message, and the other peer (may) respond with a message. Sounds like a handshake to me. KeyUpdate gets sent in handshake records, with a HandshakeType value of 24 and is defined in section 4 of the RFC ("Handshake Protocol"). To me it makes perfect sense to signal it this way. In fact it was a deliberate decision to do so and is documented accordingly: =item SSL_CB_HANDSHAKE_START Callback has been called because a new handshake is started. In TLSv1.3 this is also used for the start of post-handshake message exchanges such as for the exchange of session tickets, or for key updates. It also occurs when resuming a handshake following a pause to handle early data. =item SSL_CB_HANDSHAKE_DONE 0x20 Callback has been called because a handshake is finished. In TLSv1.3 this is also used at the end of an exchange of post-handshake messages such as for session tickets or key updates. It also occurs if the handshake is paused to allow the exchange of early data. Ironically it was done this way with a view to *avoiding* a compatibility break. The thinking was that applications written with TLSv1.2 in mind may find it surprising to start receiving events after the initial connection setup that are not enclosed in HANDSHAKE_START/HANDSHAKE_DONE. The info callback is intended as a tracing API IMO. It's only the fact that it has been used in ways other than we might have expected that we have this problem. In fact if your application is using the API to detect renegs because it wants to report when key updates are happening (rather than blocking them)....well that application will continue to work and will stop working if we change the events. Given this is documented that way, some applications may already be using it - so changing the events now should be done with caution. That itself could cause a break. We know that this is causing some problems now because of the way that some applications are (mis)using this API. What we don't know is what new problems would surface if we changed its semantics in a letter release. Really the root of this problem is not in the info callback at all. It is the fact that in earlier 1.1.0 releases we did not have an effective way of blocking renegs. We now have SSL_OP_NO_RENEGOTIATION which is the "right" way to do this. I'd also note that this was backported to the 1.1.0 branch in 1.1.0h (March 2018) and so has been available to all 1.1.x users for some while. Matt From davidben at google.com Wed Jan 23 17:42:07 2019 From: davidben at google.com (David Benjamin) Date: Wed, 23 Jan 2019 11:42:07 -0600 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell wrote: > On 22/01/2019 20:41, David Benjamin wrote: > > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni < > openssl-users at dukhovni.org > > > wrote: > > As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite > sure > > what to do there, but perhaps we could define a new even for > keyUpdates > > that does not mislead applications into assuming a new "handshake". > > > > I think this is clearly the right option. This is a compatibility break, > IMO. > > > > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added > 1.3), this > > was the only way to disable renegotiations. I've seen a lot of codebases > do > > this. I don't think one could even call it a mishandling. The natural > > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has > started. > > Thus, if you wish to block renegotiations, absent a more direct API, it's > > natural to count those and fail if you see more than one. > > > > A KeyUpdate is not a handshake. > > That's depends on your perspective. One peer sends a message, and the > other peer > (may) respond with a message. Sounds like a handshake to me. KeyUpdate > gets sent > in handshake records, with a HandshakeType value of 24 and is defined in > section > 4 of the RFC ("Handshake Protocol"). > This notion of "handshake" is not supported by RFC 8446 uses the terms "the handshake", "a handshake", and "post-handshake". "Post-handshake", in particular, implies KeyUpdate are after the handshake, not part of it. KeyUpdate is also not quite a request/response pair. The caller is allowed to coalesce consecutive key_update_requests . This was done to avoid DoS and allow a lighter strategy: if you see key_update_request on read, set a flag and continue. When you make an outgoing record on write, if the flag is set, queue a KeyUpdate up first and clear the flag. This avoids the DoS: write overhead is bounded and read/write flows are independent. Finally, compare with TCP socket APIs, which most applications have in mind. There is a connect() phase that happens *once* at the start, afterwards one calls read() and write(). During read() and write(), TCP still ends other non-data packets, but those are abstracted away. > To me it makes perfect sense to signal it this way. In fact it was a > deliberate > decision to do so and is documented accordingly: > > =item SSL_CB_HANDSHAKE_START > > Callback has been called because a new handshake is started. In TLSv1.3 > this is > also used for the start of post-handshake message exchanges such as for > the > exchange of session tickets, or for key updates. It also occurs when > resuming a > handshake following a pause to handle early data. > > =item SSL_CB_HANDSHAKE_DONE 0x20 > > Callback has been called because a handshake is finished. In TLSv1.3 this > is > also used at the end of an exchange of post-handshake messages such as for > session tickets or key updates. It also occurs if the handshake is paused > to > allow the exchange of early data. > This documentation does not help code written prior to TLSv1.3, which is the problem here. OpenSSL claims that TLS 1.3 is a backwards-compatible addition, so documentation updates for 1.3 may clarify but cannot be necessary. More on this below. > Ironically it was done this way with a view to *avoiding* a compatibility > break. > The thinking was that applications written with TLSv1.2 in mind may find it > surprising to start receiving events after the initial connection setup > that are > not enclosed in HANDSHAKE_START/HANDSHAKE_DONE. The info callback is > intended as > a tracing API IMO. It's only the fact that it has been used in ways other > than > we might have expected that we have this problem. In fact if your > application is > using the API to detect renegs because it wants to report when key updates > are > happening (rather than blocking them)....well that application will > continue to > work and will stop working if we change the events. > > Given this is documented that way, some applications may already be using > it - > so changing the events now should be done with caution. That itself could > cause > a break. We know that this is causing some problems now because of the way > that > some applications are (mis)using this API. What we don't know is what new > problems would surface if we changed its semantics in a letter release. > > Really the root of this problem is not in the info callback at all. It is > the > fact that in earlier 1.1.0 releases we did not have an effective way of > blocking > renegs. We now have SSL_OP_NO_RENEGOTIATION which is the "right" way to do > this. > I'd also note that this was backported to the 1.1.0 branch in 1.1.0h (March > 2018) and so has been available to all 1.1.x users for some while. > The fact of the matter is the TLS 1.3 ecosystem is intolerant to KeyUpdates, as a result of behavior in OpenSSL and its consumers. As a result of this failure, *no one* can use KeyUpdate. This warrants consideration on both sides of the API boundary. You're right that adapting this API to 1.3 required a judgement call. It observed a state machine which changes across versions. There isn't a right answer, a priori. Elsewhere in this thread, I pushed against adding new tracing events without a clear need. This is counter to OpenSSL's usual API style but comes from experience developing on both sides of the API. (My day job involves working both on BoringSSL itself and code calling into it, much of which was written to OpenSSL.) APIs like that are problematic. I'll note BoringSSL doesn't expose state constants at all. But OpenSSL 1.1.0 and 1.0.x had that API without SSL_OP_NO_RENEGOTIATION, so we must deal with it. Note March 2018 is not "for some while" on the timescales of OpenSSL consumers, sadly. Ubuntu 18.04 LTS still ships 1.1.0g (plus security fix backports). OpenSSL 1.0.x is also relevant. Projects did not port to OpenSSL 1.1.0 by revising every API call against the new documentation. They tried to compile it, fixed any errors, maybe ran some basic tests, fixed any obvious runtime issues, and called it done. This is simply the natural way to do it. Change strategies must take this reality into account . OpenSSL's API thus has a long history. Its consumers grew up organically with OpenSSL, sometimes even SSLeay. Judgement calls cannot be made in a vacuum. When we were designing TLS 1.3 support for BoringSSL, every question like this was backed by sampling existing callers. From that experience, I have seen the following uses of the info callback: (a) Debugging hooks for tracing, often copied from the openssl binary . (b) As a callback to know when the handshake (in the RFC8446 sense described above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE. (c) As a callback to block renegotiations. The problem here is (c), and empirically has affected versions of NGINX, Node, HAProxy and the real TLS 1.3 ecosystem. There may be more yet undiscovered problems; we only had KeyUpdates on in Chrome for a week on Chrome Canary before we had to shut it off. At three affected callers, one cannot simply say this is the consumer's fault. As for the others, (b) also doesn't want to trigger on KeyUpdate, though it may tolerate it. (I have seen versions of (b) which ignore duplicates and versions which break on renegos---no one tests against it, which is why it's off by default in BoringSSL.) (a) is closest to the scenario you are concerned about, but such debugging notes are just that: debugging. I have never seen code which cares about their particulars. Indeed, if it did, adding TLS 1.3 would not be compatible because 1.3 changes the state machine. Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on KeyUpdate. Not signaling has some risk , but it is low, especially in comparison to the known breakage and ecosystem damage caused by signaling. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 23 18:29:11 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 23 Jan 2019 13:29:11 -0500 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: > On Jan 23, 2019, at 12:42 PM, David Benjamin wrote: > > (a) Debugging hooks for tracing, often copied from the openssl binary. > (b) As a callback to know when the handshake (in the RFC8446 sense described above, not the OpenSSL sense) is done, sensitive to SSL_CB_HANDSHAKE_DONE. > (c) As a callback to block renegotiations. > > The problem here is (c), and empirically has affected versions of NGINX, Node, HAProxy and the real TLS 1.3 ecosystem. There may be more yet undiscovered problems; we only had KeyUpdates on in Chrome for a week on Chrome Canary before we had to shut it off. At three affected callers, one cannot simply say this is the consumer's fault. > > As for the others, (b) also doesn't want to trigger on KeyUpdate, though it may tolerate it. (I have seen versions of (b) which ignore duplicates and versions which break on renegos---no one tests against it, which is why it's off by default in BoringSSL.) (a) is closest to the scenario you are concerned about, but such debugging notes are just that: debugging. I have never seen code which cares about their particulars. Indeed, if it did, adding TLS 1.3 would not be compatible because 1.3 changes the state machine. > > Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on KeyUpdate. Not signaling has some risk, but it is low, especially in comparison to the known breakage and ecosystem damage caused by signaling. I'm inclined to agree with David here. I should also note that there are two issues in this thread, of which this is the second. The first one is about the limit on the number of key update messages per connection, and I hope that we can do something sensible there with less controversy. -- Viktor. From matt at openssl.org Thu Jan 24 11:45:12 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 24 Jan 2019 11:45:12 +0000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: On 23/01/2019 17:42, David Benjamin wrote: > On Wed, Jan 23, 2019 at 4:24 AM Matt Caswell > wrote: > > On 22/01/2019 20:41, David Benjamin wrote: > > On Tue, Jan 22, 2019 at 1:48 PM Viktor Dukhovni > > > >> > wrote: > >? ? ?As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure > >? ? ?what to do there, but perhaps we could define a new even for keyUpdates > >? ? ?that does not mislead applications into assuming a new "handshake". > > > > I think this is clearly the right option. This is a compatibility break, IMO. > > > > Prior to SSL_OP_NO_RENEGOTIATION (new in the same release that added 1.3), > this > > was the only way to disable renegotiations. I've seen a lot of codebases do > > this. I don't think one could even call it a mishandling. The natural > > interpretation of "SSL_CB_HANDSHAKE_START" is that a handshake has started. > > Thus, if you wish to block renegotiations, absent a more direct API, it's > > natural to count those and fail if you see more than one. > > > > A KeyUpdate is not a handshake. > > That's depends on your perspective. One peer sends a message, and the other peer > (may) respond with a message. Sounds like a handshake to me. KeyUpdate gets sent > in handshake records, with a HandshakeType value of 24 and is defined in section > 4 of the RFC ("Handshake Protocol"). > > > This notion of "handshake" is not supported by RFC 8446 uses the terms "the > handshake",?"a handshake", and "post-handshake". "Post-handshake", in > particular, implies?KeyUpdate are after the handshake, not part of it. I just don't agree with you here. About the best that can be said about RFC8446 in this regards is that the term handshake is overloaded. It certainly does mean "the initial handshake" in the way that you describe (and I myself use the term to mean that). But it is *also* used in other contexts, such as "handshake messages" or "handshake protocol" where it is referring to things not necessarily constrained to the initial handshake. Ignoring the unexpected interaction with KeyUpdates for the moment, it seems perfectly reasonable to me to use the SSL_CB_HANDSHAKE_START event to indicate "we are about to exchange handshake messages" - whether or not that is in the context of the initial handshake or not. > This documentation does not help code written prior to TLSv1.3, which is the > problem here. OpenSSL claims that TLS 1.3 is a backwards-compatible addition, so > documentation updates for 1.3 may clarify but cannot be necessary. More on this > below. I agree with this. That is precisely what I think that documentation does. > Thus, the fix is clear: don't signal HANDSHAKE_START and HANDSHAKE_DONE on > KeyUpdate. Not signaling has some risk > , > but it is low, especially in comparison to the known breakage and ecosystem > damage caused by signaling. Note: I have not said that we should not do this. All I have said is that changing the events should be done with caution. We do not (usually) allow breaking changes into stable releases - and with good reason. 1.1.1 has been declared as an LTS release. At the same time both 1.1.0 and 1.0.2 have moved to "security fix only" mode. So we are actively encouraging all users to move to that version. It's not a great message to send out if we are changing documented behaviour in a letter release and it could break some applications. What that means in practice is that in order for that change to be accepted I think it would require an OMC vote. I don't think the normal review process is good enough since this change would be actively breaking policy and isn't a bug fix (at least not in the usual sense of what that means). If we decided to make the change then we would also need to consider what it would mean for other message exchanges such as CertificateRequest and HelloRequest (not sure what we do now with this last one). Would we only change KeyUpdate (which would be a bit weird)? Or should we change all post-handshake messages to be consistent (which might risk more breakage than is strictly necessary to fix the KeyUpdate problem). Matt From matt at openssl.org Thu Jan 24 11:46:36 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 24 Jan 2019 11:46:36 +0000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: On 23/01/2019 18:29, Viktor Dukhovni wrote: > I should also note that there are two > issues in this thread, of which this is the second. The first one is about > the limit on the number of key update messages per connection, and I hope > that we can do something sensible there with less controversy. > I don't consider that aspect to be controversial - although we do need to give some thought to what the right fix looks like. Matt From tjh at openssl.org Thu Jan 24 12:02:59 2019 From: tjh at openssl.org (Tim Hudson) Date: Thu, 24 Jan 2019 22:02:59 +1000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: On Thu, Jan 24, 2019 at 9:45 PM Matt Caswell wrote: > > This notion of "handshake" is not supported by RFC 8446 uses the terms > "the > > handshake", "a handshake", and "post-handshake". "Post-handshake", in > > particular, implies KeyUpdate are after the handshake, not part of it. > > I just don't agree with you here. About the best that can be said about > RFC8446 > in this regards is that the term handshake is overloaded. It certainly > does mean > "the initial handshake" in the way that you describe (and I myself use the > term > to mean that). But it is *also* used in other contexts, such as "handshake > messages" or "handshake protocol" where it is referring to things not > necessarily constrained to the initial handshake. > I agree with Matt here - there is no such clear distinction made in RFC8446 - with "handshake" being used in *all *contexts. If such a distinction was intended by the IETF WG then they failed to achieve it in RFC8446 in numerous places. Quoting RFC8446 ... 4.6.3. Key and Initialization Vector Update The KeyUpdate *handshake message ...* It doesn't help that it has 4.6 Post-Handshake Message section which states "after the main handshake" also indicating that the handshake messages are handshakes too - just not the "main handshake". Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 24 14:36:06 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 24 Jan 2019 14:36:06 +0000 Subject: [openssl-project] Point compression config Message-ID: Issue 8067 points out that we have code for enabling the configuration of the ec point formats: https://github.com/openssl/openssl/issues/8067 However, while the code exists, it is not exposed in any public API - so it is effectively dead code. I suppose in 1.0.2 it could have been used by diving directly into the non-opaque structs to set custom values (even though it is undocumented). From 1.1.0 that is no longer possible. I can't think of a good reason for why anyone would want to do this (the explanation given by the OP in 8067 isn't convincing), so I'm tempted to just rip out this code. Before I do that though: is there a good reason for wanting to be able to do this? Matt From vieuxtech at gmail.com Thu Jan 24 18:12:45 2019 From: vieuxtech at gmail.com (Sam Roberts) Date: Thu, 24 Jan 2019 10:12:45 -0800 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: I appreciate that there are multiple ways of looking at this, but I don't think that looking at the info callback from the point of view of "is it or is it not a handshake record" is pragmatic. The SSL_set_msg_callback could be used by people wanting to see all the underlying records. The way the info callbacks are behaving for TLS1.3 is a major obstacle to Node.js supporting TLS1.3. The intention of 1.1.1 was to make TLS1.3 support as painfree as possible, and it doesn't seem to be doing that. When it was just Node.js that was having to work around this, I was convinced that we had some kind of historical abuse of the info callback we would just have to fix. Now that I hear that (at least) haproxy and nginx are also affected, I'd appreciate a reconsideration of this from the purely pragmatic point of view of "how do we make TLS1.3 support easy to achieve", the ultimate goal here for everyone (I think!). The behaviour of the info callbacks is already backwards incompatible with openssl 1.1.0, even for TLS1.2 (https://github.com/openssl/openssl/issues/7199). For API users wanting to detect ticket exchange, HelloRequest, and other "handshake" records with the info callbacks, changing to use different "where" values would not be as disruptive as the affect is on users trying to detect handshake start/done via callback. If I am underestimating how disruptive that is, its not out of the question to have a "compatibility" mode where the info callbacks change their behaviour based on how the context is set up No one likes having to support these kinds of flags, but it would remove concerns about introducing breaking changes in the 1.1.1 line if they were opt-in, so this doesn't become a question of "who's code do we break". Its also not clear whether all uses of the info callback actually have another API alternatives. We use the info callbacks to reject renegotiation. Apparently there is an option to do this now with a mode, so we could likely adopt that way. We use the info callbacks to time renegotiations, and reject them if they take too long. I'm not aware of any other API that would allow us to do this. We use the info callbacks to detect when renegotiation has been requested on an existing connection, and inform node API users. I'm not aware of any other API that would allow us to do that. Changing from using the info callbacks to get notified of start/done of the initial handshake using SSL_do_handshake() (or SSL_connect/SSL_accept) is theoretically possible, but turns out to be easy to say, and has been much harder to do. The interactions with node.js internal stream and async mechanisms are subtle, and after close to a week of concerted effort, I still haven't gotten it working (some things work, some don't, its been a discouraging game of whack-a-bug). It can't be impossible, but its the type of substantial rewrite necessary to support TLS1.3 that ideally would not be necessary. The other changes that TLS1.3 requires, multiple session tickets, a few new APIs to replace some of the SSL_renegotiate use-cases, etc., all are pretty routine. We could get TLS1.3 support in Node.js fairly quickly if the info callback issue was solved openssl side. I'm even happy to help work on it if that's an issue, it would be more productive than what I've been trying to do in Node.js. Thanks, Sam From tjh at openssl.org Sun Jan 27 10:33:06 2019 From: tjh at openssl.org (Tim Hudson) Date: Sun, 27 Jan 2019 20:33:06 +1000 Subject: [openssl-project] inline functions Message-ID: >From https://github.com/openssl/openssl/pull/7721 Tim - I think inline functions in public header files simply shouldn't be present. Matt - I agree Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made static inline expressly to get better C type safety, and to get away from the mkstack.pl horror. It would be good to get a sense of the collective thoughts on the topic. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Sun Jan 27 10:53:46 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 27 Jan 2019 11:53:46 +0100 Subject: [openssl-project] inline functions In-Reply-To: References: Message-ID: <20190127105345.GA863@roeckx.be> On Sun, Jan 27, 2019 at 08:33:06PM +1000, Tim Hudson wrote: > From https://github.com/openssl/openssl/pull/7721 > > Tim - I think inline functions in public header files simply shouldn't be > present. > Matt - I agree > Richard - I'm ambivalent... in the case of stack and lhash, the generated > functions we made static inline expressly to get better C type safety, and > to get away from the mkstack.pl horror. In general I have to agree that it's not a good thing to do, specially in cases where it calls other functions. We went away from making them just defines into functions, but they should instead be functions in the library, at least for external users of the library. Kurt From paul.dale at oracle.com Sun Jan 27 11:30:07 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sun, 27 Jan 2019 21:30:07 +1000 Subject: [openssl-project] inline functions In-Reply-To: References: Message-ID: <2E765629-DC91-4609-BB30-486F742681CC@oracle.com> I?d generally prefer functions over macros ? I think that the ctrl calls e.g. would be better wrapped with function to provide type checking. The overhead of a function call is pretty light these days so inline functions are difficult to justify (as anything except a premature optimisation?). Both safestack and lhash are problematic cases. The inline functions come from macros which I view as okay. The problem is that some of these macros are expanded in the header for common cases (e.g. stack of stings). We could address this by distinguishing between the function declarations and their instantiation and move the latter into its own C file. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 27 Jan 2019, at 8:33 pm, Tim Hudson wrote: > > From https://github.com/openssl/openssl/pull/7721 > > Tim - I think inline functions in public header files simply shouldn't be present. > Matt - I agree > Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made static inline expressly to get better C type safety, and to get away from the mkstack.pl horror. > > It would be good to get a sense of the collective thoughts on the topic. > > Tim. > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sun Jan 27 12:58:54 2019 From: levitte at openssl.org (Richard Levitte) Date: Sun, 27 Jan 2019 13:58:54 +0100 Subject: [openssl-project] inline functions In-Reply-To: <2E765629-DC91-4609-BB30-486F742681CC@oracle.com> References: <2E765629-DC91-4609-BB30-486F742681CC@oracle.com> Message-ID: <87womqmf3l.wl-levitte@openssl.org> You're talking about these lines from safestack.h: DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING, char) DEFINE_SPECIAL_STACK_OF_CONST(OPENSSL_CSTRING, char) DEFINE_SPECIAL_STACK_OF(OPENSSL_BLOCK, void) and these from lhash.h: DEFINE_LHASH_OF(OPENSSL_STRING); DEFINE_LHASH_OF(OPENSSL_CSTRING); I didn't think of those when looking at the PR, but you're entirely correct that they are the direct cause of the issue, and should move to someplace internal. Cheers, Richard On Sun, 27 Jan 2019 12:30:07 +0100, Dr Paul Dale wrote: > > > I?d generally prefer functions over macros ? I think that the ctrl calls e.g. would be better > wrapped with function to provide type checking. > The overhead of a function call is pretty light these days so inline functions are difficult to > justify (as anything except a premature optimisation?). > > Both safestack and lhash are problematic cases. The inline functions come from macros which I > view as okay. The problem is that some of these macros are expanded in the header for common > cases (e.g. stack of stings). We could address this by distinguishing between the function > declarations and their instantiation and move the latter into its own C file. > > Pauli > -- > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > On 27 Jan 2019, at 8:33 pm, Tim Hudson wrote: > > From https://github.com/openssl/openssl/pull/7721 > > Tim - I think inline functions in public header files simply shouldn't be present. > Matt - I agree > Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made > static inline expressly to get better C type safety, and to get away from the mkstack.pl > horror. > > It would be good to get a sense of the collective thoughts on the topic. > > Tim. > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Sun Jan 27 13:23:46 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Sun, 27 Jan 2019 23:23:46 +1000 Subject: [openssl-project] inline functions In-Reply-To: <87womqmf3l.wl-levitte@openssl.org> References: <2E765629-DC91-4609-BB30-486F742681CC@oracle.com> <87womqmf3l.wl-levitte@openssl.org> Message-ID: <7F858857-4E28-4751-81F1-33ADE60FCF79@oracle.com> Yes, those are the problematic cases. I think that making the symbols weak is ?good enough? for the moment. Longer term, we could do with a better solution. Moving the implementations into another file is one option. There is another longer term alternative: migrate OpenSSL away from lhash and safestack by introducing new internal functionality that replaces them. We can?t remove either in case users user them but we could stop using them ourselves. Lhash is based on a clever hash table that dynamically resizes (both increasing and decreasing) and amortises the rehashing costs over time. If the OpenSSL source code is looked through, there are relatively few removals from the hash table. I.e. the size decrease isn?t used much, if at all. Likewise, the rehashing checks one bit in the hash for each item and moves it into one of two lists based based on the result. I.e. rehashing should be a fast operation and amortising it doesn?t feel like a win. On the down side, lhash runs with a fairly high level of loading (many entries relative to table size) and its collision resolution is a linked list (i.e. O(n) worst case instead of O(1)). There have also been improvements in hash technology since the lhash algorithm was created ? cache coherent algorithms and lock free ones spring to mind. Safestack isn?t a stack anymore. It is used as a vector, an array substitute, a queue and more. I don?t think I?ve seen it used as a stack but it probably is. We should have separate data structures for the different uses, each optimised for its specific usage. This would be a long path (and I?m hijacking this thread a bit), but it is something I?ve been wanting to do for a while now. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 27 Jan 2019, at 10:58 pm, Richard Levitte wrote: > > You're talking about these lines from safestack.h: > > DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING, char) > DEFINE_SPECIAL_STACK_OF_CONST(OPENSSL_CSTRING, char) > DEFINE_SPECIAL_STACK_OF(OPENSSL_BLOCK, void) > > and these from lhash.h: > > DEFINE_LHASH_OF(OPENSSL_STRING); > DEFINE_LHASH_OF(OPENSSL_CSTRING); > > I didn't think of those when looking at the PR, but you're entirely > correct that they are the direct cause of the issue, and should move > to someplace internal. > > Cheers, > Richard > > On Sun, 27 Jan 2019 12:30:07 +0100, > Dr Paul Dale wrote: >> >> >> I?d generally prefer functions over macros ? I think that the ctrl calls e.g. would be better >> wrapped with function to provide type checking. >> The overhead of a function call is pretty light these days so inline functions are difficult to >> justify (as anything except a premature optimisation?). >> >> Both safestack and lhash are problematic cases. The inline functions come from macros which I >> view as okay. The problem is that some of these macros are expanded in the header for common >> cases (e.g. stack of stings). We could address this by distinguishing between the function >> declarations and their instantiation and move the latter into its own C file. >> >> Pauli >> -- >> Dr Paul Dale | Cryptographer | Network Security & Encryption >> Phone +61 7 3031 7217 >> Oracle Australia >> >> On 27 Jan 2019, at 8:33 pm, Tim Hudson wrote: >> >> From https://github.com/openssl/openssl/pull/7721 >> >> Tim - I think inline functions in public header files simply shouldn't be present. >> Matt - I agree >> Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made >> static inline expressly to get better C type safety, and to get away from the mkstack.pl >> horror. >> >> It would be good to get a sense of the collective thoughts on the topic. >> >> Tim. >> >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project >> >> >> _______________________________________________ >> openssl-project mailing list >> openssl-project at openssl.org >> https://mta.openssl.org/mailman/listinfo/openssl-project > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd.edlinger at hotmail.de Sun Jan 27 16:30:06 2019 From: bernd.edlinger at hotmail.de (Bernd Edlinger) Date: Sun, 27 Jan 2019 16:30:06 +0000 Subject: [openssl-project] inline functions In-Reply-To: <7F858857-4E28-4751-81F1-33ADE60FCF79@oracle.com> References: <2E765629-DC91-4609-BB30-486F742681CC@oracle.com> <87womqmf3l.wl-levitte@openssl.org> <7F858857-4E28-4751-81F1-33ADE60FCF79@oracle.com> Message-ID: ./config -fkeep-inline-functions && make -> build fails with unresolved externals in test/rsa_complex and test/shlibloadtest On 1/27/19 2:23 PM, Dr Paul Dale wrote: > Yes, those are the problematic cases. I think that making the symbols weak is ?good enough? for the moment. Longer term, we could do with a better solution. Moving the implementations into another file is one option. There is another longer term alternative: migrate OpenSSL away from lhash and safestack by introducing new internal functionality that replaces them. We can?t remove either in case users user them but we could stop using them ourselves. > > Lhash is based on a clever hash table that dynamically resizes (both increasing and decreasing) and amortises the rehashing costs over time. If the OpenSSL source code is looked through, there are relatively few removals from the hash table. I.e. the size decrease isn?t used much, if at all. Likewise, the rehashing checks one bit in the hash for each item and moves it into one of two lists based based on the result. I.e. rehashing should be a fast operation and amortising it doesn?t feel like a win. On the down side, lhash runs with a fairly high level of loading (many entries relative to table size) and its collision resolution is a linked list (i.e. O(n) worst case instead of O(1)). There have also been improvements in hash technology since the lhash algorithm was created ? cache coherent algorithms and lock free ones spring to mind. > > Safestack isn?t a stack anymore. It is used as a vector, an array substitute, a queue and more. I don?t think I?ve seen it used as a stack but it probably is. We should have separate data structures for the different uses, each optimised for its specific usage. > > > This would be a long path (and I?m hijacking this thread a bit), but it is something I?ve been wanting to do for a while now. > > > Pauli > > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > From openssl-users at dukhovni.org Sun Jan 27 17:51:58 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 27 Jan 2019 12:51:58 -0500 Subject: [openssl-project] inline functions In-Reply-To: References: Message-ID: > On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: > > Tim - I think inline functions in public header files simply shouldn't be present. I think they have their place, and we should try to make them more portable to less capable toolchains as needed. -- Viktor. From levitte at openssl.org Sun Jan 27 18:56:01 2019 From: levitte at openssl.org (Richard Levitte) Date: Sun, 27 Jan 2019 19:56:01 +0100 Subject: [openssl-project] inline functions In-Reply-To: References: Message-ID: <87va2alyke.wl-levitte@openssl.org> On Sun, 27 Jan 2019 18:51:58 +0100, Viktor Dukhovni wrote: > > > On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: > > > > Tim - I think inline functions in public header files simply shouldn't be present. > > I think they have their place, and we should try to make them more portable > to less capable toolchains as needed. A simple way to handle it is to move the DEFINE_ expansions to another header file. I suggest common_stacks.h and common_lhashes.h At the very least for 3.0.0. For 1.1.1, I have no idea... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From paul.dale at oracle.com Sun Jan 27 22:18:06 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 28 Jan 2019 08:18:06 +1000 Subject: [openssl-project] inline functions In-Reply-To: <87va2alyke.wl-levitte@openssl.org> References: <87va2alyke.wl-levitte@openssl.org> Message-ID: Isn?t this going to run into the same issues? The DEFINE_ expansions need to be in their own .c file (one file with all or one file per, I?m not fussed much but the latter seems nicer). The DEFINE_ macros need to stay in the header for compatibility. To handle the external linkage, a new macro that declares the function prototypes should be introduced. I.e.: # define DECLARE_LHASH_OF(type) \ LHASH_OF(type) * ln_##type##_new(unsigned long (*)(const type *), int (*)(const type *, const type *)); \ void lh_##type##_free(LHASH_OF(type) *); \ ? # define DEFINE_LHASH_OF(type) \ DECLARE LHASH_OF(type); \ LHASH_OF(type) { union lh_##type##_dummy { void* d1; unsigned long d2; int d3; } dummy; }; \ static ossl_inline LHASH_OF(type) * \ lh_##type##_new(unsigned long (*hfn)(const type *), \ int (*cfn)(const type *, const type *)) \ { \ return (LHASH_OF(type) *) \ OPENSSL_LH_new((OPENSSL_LH_HASHFUNC)hfn, (OPENSSL_LH_COMPFUNC)cfn); \ } \ static ossl_inline void lh_##type##_free(LHASH_OF(type) *lh) \ { \ OPENSSL_LH_free((OPENSSL_LHASH *)lh); \ } \ ? The headers can then use the DECLARE_LHASH_OF macro to prototype the functions. The .c file uses the DEFINE_LHASH_OF macro to create them. I chose lhash here because it is the simpler of the two, safestack has more options and is a bit more convoluted. I?m willing to make a stab at a PR for this. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia > On 28 Jan 2019, at 4:56 am, Richard Levitte wrote: > > On Sun, 27 Jan 2019 18:51:58 +0100, > Viktor Dukhovni wrote: >> >>> On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: >>> >>> Tim - I think inline functions in public header files simply shouldn't be present. >> >> I think they have their place, and we should try to make them more portable >> to less capable toolchains as needed. > > A simple way to handle it is to move the DEFINE_ expansions to another > header file. I suggest common_stacks.h and common_lhashes.h > > At the very least for 3.0.0. For 1.1.1, I have no idea... > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jan 28 04:16:18 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 28 Jan 2019 05:16:18 +0100 Subject: [openssl-project] inline functions In-Reply-To: References: <87va2alyke.wl-levitte@openssl.org> Message-ID: <058A6731-ED17-45C1-8E05-F3DC514BD7B3@openssl.org> Dr Paul Dale skrev: (27 januari 2019 23:18:06 CET) >Isn?t this going to run into the same issues? No. It's the expansion of the macros that causes the problem, not the macros themselves. So if you move the expansions to the .c that actually use stacks / lhashes, they should obviously be linked with libcrypto, problem solved. >The DEFINE_ expansions need to be in their own .c file (one file with >all or one file per, I?m not fussed much but the latter seems nicer). Not really, since they are static inline. This is by design, that for any file you want to use a safestack in, you just start with a DEFINE_ line. The mistake we did was to leave a few common ones in the safestack header file. (same thing for lhash) >The DEFINE_ macros need to stay in the header for compatibility. Yup. >To handle the external linkage, a new macro that declares the function >prototypes should be introduced. I.e.: Again, no need because of the static nature of the resulting inline functions. > ># define DECLARE_LHASH_OF(type) \ >LHASH_OF(type) * ln_##type##_new(unsigned long (*)(const type *), int >(*)(const type *, const type *)); \ > void lh_##type##_free(LHASH_OF(type) *); \ > ? > ># define DEFINE_LHASH_OF(type) \ > DECLARE LHASH_OF(type); \ >LHASH_OF(type) { union lh_##type##_dummy { void* d1; unsigned long d2; >int d3; } dummy; }; \ > static ossl_inline LHASH_OF(type) * \ > lh_##type##_new(unsigned long (*hfn)(const type *), \ > int (*cfn)(const type *, const type *)) \ > { \ > return (LHASH_OF(type) *) \ > OPENSSL_LH_new((OPENSSL_LH_HASHFUNC)hfn, (OPENSSL_LH_COMPFUNC)cfn); \ > } \ > static ossl_inline void lh_##type##_free(LHASH_OF(type) *lh) \ > { \ > OPENSSL_LH_free((OPENSSL_LHASH *)lh); \ > } \ > ? > >The headers can then use the DECLARE_LHASH_OF macro to prototype the >functions. The .c file uses the DEFINE_LHASH_OF macro to create them. > >I chose lhash here because it is the simpler of the two, safestack has >more options and is a bit more convoluted. I?m willing to make a stab >at a PR for this. > > >Pauli -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From paul.dale at oracle.com Mon Jan 28 05:17:35 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Mon, 28 Jan 2019 15:17:35 +1000 Subject: [openssl-project] inline functions In-Reply-To: <058A6731-ED17-45C1-8E05-F3DC514BD7B3@openssl.org> References: <87va2alyke.wl-levitte@openssl.org> <058A6731-ED17-45C1-8E05-F3DC514BD7B3@openssl.org> Message-ID: <4E83E62C-9239-4489-A0FB-D69D88D81794@oracle.com> Richard wrote: > Not really, since they are static inline. This is by design, that for any file you want to use a safestack in, you just start with a DEFINE_ line. The mistake we did was to leave a few common ones in the safestack header file. (same thing for lhash) Which means we?ve a compatibility issue. The functions are in a public header, they can be used by any application. We need to continue supporting such use. Asking a user to add a DEFINE_ line is API breaking. I would be pro making such a change but we?d need to accept the consequences. Pauli -- Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Jan 28 06:10:55 2019 From: levitte at openssl.org (Richard Levitte) Date: Mon, 28 Jan 2019 07:10:55 +0100 Subject: [openssl-project] inline functions In-Reply-To: <4E83E62C-9239-4489-A0FB-D69D88D81794@oracle.com> References: <87va2alyke.wl-levitte@openssl.org> <058A6731-ED17-45C1-8E05-F3DC514BD7B3@openssl.org> <4E83E62C-9239-4489-A0FB-D69D88D81794@oracle.com> Message-ID: <87sgxdmhw0.wl-levitte@openssl.org> On Mon, 28 Jan 2019 06:17:35 +0100, Dr Paul Dale wrote: > Richard wrote: > > Not really, since they are static inline. This is by design, that for any file you want to use > a safestack in, you just start with a DEFINE_ line. The mistake we did was to leave a few > common ones in the safestack header file. (same thing for lhash) > > Which means we?ve a compatibility issue. The functions are in a public header, they can be used > by any application. We need to continue supporting such use. > Asking a user to add a DEFINE_ line is API breaking. > > I would be pro making such a change but we?d need to accept the consequences. We have to accept consequences either way, either: 1. the surprise breakage if someone includes but doesn't link with libcrypto, while compiling with -fkeep-inline-functions (explicitly or implicitly, depending on the compiler) 2. The controlled and documented change / breakage that they will have to either add those DEFINE lines where they need the functionality, or include another header file with common stack / lhash type implementations (with the caveat that they MUST link with libcrypto if they use those headers) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From matt at openssl.org Mon Jan 28 15:38:50 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 28 Jan 2019 15:38:50 +0000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> Message-ID: <8ae9e081-3b2f-87b1-05d6-b2915d19524a@openssl.org> On 24/01/2019 18:12, Sam Roberts wrote: > The other changes that TLS1.3 requires, multiple session tickets, a > few new APIs to replace some of the SSL_renegotiate use-cases, etc., > all are pretty routine. We could get TLS1.3 support in Node.js fairly > quickly if the info callback issue was solved openssl side. I'm even > happy to help work on it if that's an issue, it would be more > productive than what I've been trying to do in Node.js. In case anyone missed it I opened a PR for this over the weekend: https://github.com/openssl/openssl/pull/8096 I'm leaving it there for a day or two for people to comment. Assuming no major issues are identified I'll will raise an OMC vote for it. Matt From kaduk at mit.edu Mon Jan 28 16:25:09 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Mon, 28 Jan 2019 10:25:09 -0600 Subject: [openssl-project] inline functions In-Reply-To: <87sgxdmhw0.wl-levitte@openssl.org> References: <87va2alyke.wl-levitte@openssl.org> <058A6731-ED17-45C1-8E05-F3DC514BD7B3@openssl.org> <4E83E62C-9239-4489-A0FB-D69D88D81794@oracle.com> <87sgxdmhw0.wl-levitte@openssl.org> Message-ID: <20190128162509.GY49072@kduck.mit.edu> On Mon, Jan 28, 2019 at 07:10:55AM +0100, Richard Levitte wrote: > On Mon, 28 Jan 2019 06:17:35 +0100, > Dr Paul Dale wrote: > > Richard wrote: > > > > Not really, since they are static inline. This is by design, that for any file you want to use > > a safestack in, you just start with a DEFINE_ line. The mistake we did was to leave a few > > common ones in the safestack header file. (same thing for lhash) > > > > Which means we?ve a compatibility issue. The functions are in a public header, they can be used > > by any application. We need to continue supporting such use. > > Asking a user to add a DEFINE_ line is API breaking. > > > > I would be pro making such a change but we?d need to accept the consequences. > > We have to accept consequences either way, either: > > 1. the surprise breakage if someone includes but > doesn't link with libcrypto, while compiling with > -fkeep-inline-functions (explicitly or implicitly, depending on the > compiler) This one is only "surprising and new" the first time a user/project tries to turn on -fkeep-inline-functions. > 2. The controlled and documented change / breakage that they will have > to either add those DEFINE lines where they need the functionality, > or include another header file with common stack / lhash type > implementations (with the caveat that they MUST link with libcrypto > if they use those headers) This one is "surprising and new" to everyone using the stuff (i.e., more people). -Ben From kurt at roeckx.be Mon Jan 28 21:18:25 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 28 Jan 2019 22:18:25 +0100 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <8ae9e081-3b2f-87b1-05d6-b2915d19524a@openssl.org> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> <8ae9e081-3b2f-87b1-05d6-b2915d19524a@openssl.org> Message-ID: <20190128211825.GA26672@roeckx.be> On Mon, Jan 28, 2019 at 03:38:50PM +0000, Matt Caswell wrote: > > > On 24/01/2019 18:12, Sam Roberts wrote: > > The other changes that TLS1.3 requires, multiple session tickets, a > > few new APIs to replace some of the SSL_renegotiate use-cases, etc., > > all are pretty routine. We could get TLS1.3 support in Node.js fairly > > quickly if the info callback issue was solved openssl side. I'm even > > happy to help work on it if that's an issue, it would be more > > productive than what I've been trying to do in Node.js. > > In case anyone missed it I opened a PR for this over the weekend: > > https://github.com/openssl/openssl/pull/8096 > > I'm leaving it there for a day or two for people to comment. Assuming no major > issues are identified I'll will raise an OMC vote for it. Can I suggest you just describe what the patch does, and call a vote on that? Kurt From matt at openssl.org Mon Jan 28 22:36:09 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 28 Jan 2019 22:36:09 +0000 Subject: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates In-Reply-To: <20190128211825.GA26672@roeckx.be> References: <55A4AB22-EA16-4A4A-9C6F-5CBA83512DC6@dukhovni.org> <10c4de72-d8e6-8c51-2090-66c35a96c9cb@openssl.org> <8ae9e081-3b2f-87b1-05d6-b2915d19524a@openssl.org> <20190128211825.GA26672@roeckx.be> Message-ID: On 28/01/2019 21:18, Kurt Roeckx wrote: > On Mon, Jan 28, 2019 at 03:38:50PM +0000, Matt Caswell wrote: >> >> >> On 24/01/2019 18:12, Sam Roberts wrote: >>> The other changes that TLS1.3 requires, multiple session tickets, a >>> few new APIs to replace some of the SSL_renegotiate use-cases, etc., >>> all are pretty routine. We could get TLS1.3 support in Node.js fairly >>> quickly if the info callback issue was solved openssl side. I'm even >>> happy to help work on it if that's an issue, it would be more >>> productive than what I've been trying to do in Node.js. >> >> In case anyone missed it I opened a PR for this over the weekend: >> >> https://github.com/openssl/openssl/pull/8096 >> >> I'm leaving it there for a day or two for people to comment. Assuming no major >> issues are identified I'll will raise an OMC vote for it. > > Can I suggest you just describe what the patch does, and call a > vote on that? Sure. I'll post the proposed text for comment before I call the vote anyway. Matt From matt at openssl.org Tue Jan 29 13:43:48 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Jan 2019 13:43:48 +0000 Subject: [openssl-project] Release strategy updates In-Reply-To: <57dee26e-e204-dbf7-4704-e312285a0661@openssl.org> References: <75452fd2-9d54-3b43-8daf-24961c7af1e0@openssl.org> <57dee26e-e204-dbf7-4704-e312285a0661@openssl.org> Message-ID: <36fdcf3d-ef9f-0437-b77a-8067b2e9026b@openssl.org> On 14/01/2019 15:21, Matt Caswell wrote: > > > On 21/09/2018 14:19, Matt Caswell wrote: >> I am very concerned about stability of our API moving forwards. There >> are various discussions about changing the version number to 1.2.0 (or >> possibly 2.0.0) - which according to our versioning scheme would allow >> breaking changes. Whilst this is true I think we need to be very wary >> about "opening the flood gates" for breaking changes. >> >> The move from 1.0.x to 1.1.0 was hard on our users and we should avoid >> that again. >> >> With that in mind I have opened the following PR (based largely on >> wording suggested by Viktor): >> >> https://github.com/openssl/web/pull/82 >> >> At the same time I have taken the opportunity to clean up some >> out-of-date stuff in the release strategy. >> >> This is independent of the semantic versioning discussion which may >> itself see further changes being made to the release strategy. >> >> Thoughts? >> >> Matt >> > > A somewhat tardy follow up on this...I updated this PR with the latest comments > so please take a look. Another update to the PR. Most significantly I merged the commits from PR 104 into this one. Please take another look. In particular I guess the most controversial bit is the the stability policy words at the end. Matt From matt at openssl.org Tue Jan 29 14:07:09 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 29 Jan 2019 14:07:09 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change Message-ID: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> So I plan to start the vote soon for merging PR#8096 and backporting it to 1.1.1. This is a breaking change as previously discussed. My proposed vote text is as follows. Please let me know asap of any feedback. Otherwise I will start the vote soon. "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and SSL_CB_HANDSHAKE_END)." Matt From kurt at roeckx.be Tue Jan 29 17:31:38 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 29 Jan 2019 18:31:38 +0100 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> Message-ID: <20190129173137.GA28734@roeckx.be> On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > So I plan to start the vote soon for merging PR#8096 and backporting it to > 1.1.1. This is a breaking change as previously discussed. > > My proposed vote text is as follows. Please let me know asap of any feedback. > Otherwise I will start the vote soon. > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > SSL_CB_HANDSHAKE_END)." This will only cover the key update currently? Does that come with some parameter telling which kind of handshake is happening? If not, is it more useful to just say that a key update is happening? Kurt From davidben at google.com Tue Jan 29 19:27:24 2019 From: davidben at google.com (David Benjamin) Date: Tue, 29 Jan 2019 13:27:24 -0600 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190129173137.GA28734@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx wrote: > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > So I plan to start the vote soon for merging PR#8096 and backporting it > to > > 1.1.1. This is a breaking change as previously discussed. > > > > My proposed vote text is as follows. Please let me know asap of any > feedback. > > Otherwise I will start the vote soon. > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START > and > > SSL_CB_HANDSHAKE_END)." > What exactly is a post-handshake message exchange? Do the NewSessionTicket sent by the server at the beginning count as the part of the handshake? Are they each separate post-handshake exchanges? Are all of them together one exchange? Conversely, what happens when you receive that NewSessionTicket as a client? When you send a KeyUpdate with key_update_requested, is the reply you expect part of the exchange or separate? What if the peer coalesced them to avoid DoS problems? Conversely, if you receive a KeyUpdate with key_update_requested, is your reply part of the exchange? What if you coalesced them to avoid DoS problems? What if I send a CertificateRequest, but the other side sends me a KeyUpdate with key_update_requested before responding with Certificate, so I respond with my own KeyUpdate? What and how many exchanges are there? Is it important that both sides agree what an "exchange" is? What I'm getting at here is that "post-handshake exchange" does not seem to be a meaningful construct to the protocol. I would thus advocate not signaling START/END things to begin with. That way, if TLS 1.4 comes by and shuffles around again, we don't repeat this adventure. I think one clear conclusion from this incident is that this sort of low-level API should be avoided, or people will use them in finicky ways that break unexpectedly when you change things. Better defer such mechanisms to when concrete use cases come up, and then implement direct APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback hadn't existed, OpenSSL would hopefully have learned sooner that SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided today's TLS 1.3 KeyUpdate intolerance in the ecosystem.) > This will only cover the key update currently? Does that come with > some parameter telling which kind of handshake is happening? If > not, is it more useful to just say that a key update is happening? > There's already a message callback. Why not just use that? It's unclear to me why anyone would want to know when KeyUpdates happen anyway, aside from low-level logging and debugging. The message callback works fairly well for such things. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Jan 29 20:11:26 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 29 Jan 2019 21:11:26 +0100 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: <20190129201126.GA8039@roeckx.be> On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote: > I think one clear conclusion from this incident is that this sort of > low-level API should be avoided, or people will use them in finicky ways > that break unexpectedly when you change things. Better defer such > mechanisms to when concrete use cases come up, and then implement direct > APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. I have to agree to that. Kurt From kaduk at mit.edu Wed Jan 30 01:21:04 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Tue, 29 Jan 2019 19:21:04 -0600 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: <20190130012104.GO49072@kduck.mit.edu> On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote: > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx wrote: > > > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > > So I plan to start the vote soon for merging PR#8096 and backporting it > > to > > > 1.1.1. This is a breaking change as previously discussed. > > > > > > My proposed vote text is as follows. Please let me know asap of any > > feedback. > > > Otherwise I will start the vote soon. > > > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START > > and > > > SSL_CB_HANDSHAKE_END)." > > > > What exactly is a post-handshake message exchange? Do the NewSessionTicket > sent by the server at the beginning count as the part of the handshake? Are > they each separate post-handshake exchanges? Are all of them together one > exchange? Conversely, what happens when you receive that NewSessionTicket > as a client? I don't think we should try to get into the business of demarcating the start and end of post-handshake exchanges. (In particular, the NewSessionTickets are formally not grouped with anything, whether the initial handshake or each other.) > When you send a KeyUpdate with key_update_requested, is the reply you > expect part of the exchange or separate? What if the peer coalesced them to > avoid DoS problems? Conversely, if you receive a KeyUpdate with > key_update_requested, is your reply part of the exchange? What if you > coalesced them to avoid DoS problems? > > What if I send a CertificateRequest, but the other side sends me a > KeyUpdate with key_update_requested before responding with Certificate, so > I respond with my own KeyUpdate? What and how many exchanges are there? > > Is it important that both sides agree what an "exchange" is? > > What I'm getting at here is that "post-handshake exchange" does not seem to > be a meaningful construct to the protocol. I would thus advocate not > signaling START/END things to begin with. That way, if TLS 1.4 comes by and > shuffles around again, we don't repeat this adventure. +1 > I think one clear conclusion from this incident is that this sort of > low-level API should be avoided, or people will use them in finicky ways > that break unexpectedly when you change things. Better defer such > mechanisms to when concrete use cases come up, and then implement direct > APIs for those use cases, like SSL_OP_NO_RENEGOTIATION. (If info_callback > hadn't existed, OpenSSL would hopefully have learned sooner that > SSL_OP_NO_RENEGOTIATION was important, added it earlier, and avoided > today's TLS 1.3 KeyUpdate intolerance in the ecosystem.) > > > > This will only cover the key update currently? Does that come with > > some parameter telling which kind of handshake is happening? If > > not, is it more useful to just say that a key update is happening? > > > > There's already a message callback. Why not just use that? It's unclear to > me why anyone would want to know when KeyUpdates happen anyway, aside from > low-level logging and debugging. The message callback works fairly well for > such things. +1 -Ben From kurt at roeckx.be Wed Jan 30 08:02:30 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 30 Jan 2019 09:02:30 +0100 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> Message-ID: <20190130080229.GA29942@roeckx.be> On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > So I plan to start the vote soon for merging PR#8096 and backporting it to > 1.1.1. This is a breaking change as previously discussed. > > My proposed vote text is as follows. Please let me know asap of any feedback. > Otherwise I will start the vote soon. > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > SSL_CB_HANDSHAKE_END)." So my proposal would be: Don't call the callback for post handshake messages. (It could use some rewording.) Kurt From matt at openssl.org Wed Jan 30 10:22:25 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Jan 2019 10:22:25 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190129173137.GA28734@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: <193457c9-1571-6f1a-b0d7-4eb2fc78f201@openssl.org> On 29/01/2019 17:31, Kurt Roeckx wrote: > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: >> So I plan to start the vote soon for merging PR#8096 and backporting it to >> 1.1.1. This is a breaking change as previously discussed. >> >> My proposed vote text is as follows. Please let me know asap of any feedback. >> Otherwise I will start the vote soon. >> >> "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and >> SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake >> message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and >> SSL_CB_HANDSHAKE_END)." > > This will only cover the key update currently? Does that come with > some parameter telling which kind of handshake is happening? If > not, is it more useful to just say that a key update is happening? The info callback calls SSL_CB_POST_HANDSHAKE_START, followed by a series of SSL_CB_LOOP events for each state change of the state machine, followed by SSL_CB_POST_HANDSHAKE_END. It is possible to query the state machine to find out what kind of message we are currently processing. That's the way the callback works for all other "initial" handshake messages. The new SSL_CB_POST_HANDSHAKE_* events apply to all post-handshake message exchanges - not just key update. Matt From matt at openssl.org Wed Jan 30 10:44:12 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Jan 2019 10:44:12 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: On 29/01/2019 19:27, David Benjamin wrote: > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx > wrote: > > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > So I plan to start the vote soon for merging PR#8096 and backporting it to > > 1.1.1. This is a breaking change as previously discussed. > > > > My proposed vote text is as follows. Please let me know asap of any feedback. > > Otherwise I will start the vote soon. > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > > SSL_CB_HANDSHAKE_END)." > > > What exactly is a post-handshake message exchange? Do the NewSessionTicket sent > by the server at the beginning count as the part of the handshake? Are they each > separate post-handshake exchanges? Are all of them together one exchange? > Conversely, what happens when you receive that NewSessionTicket as a client? They are each separate post-handshake exchanges. Both on the server and on the client. > > When you send a KeyUpdate with key_update_requested, is the reply you expect > part of the exchange or separate? What if the peer coalesced them to avoid DoS > problems? Conversely, if you receive a KeyUpdate with key_update_requested, is > your reply part of the exchange? What if you coalesced them to avoid DoS problems? > > What if I send a CertificateRequest, but the other side sends me a KeyUpdate > with key_update_requested before responding with Certificate, so I respond with > my own KeyUpdate? What and how many exchanges are there? > > Is it important that both sides agree what an "exchange" is? The answers all depend on how the OpenSSL state machine views them. At the moment the peer sending a KeyUpdate sees that as a single standalone exchange. If an update has been requested then the receiving peer sees the receiving and subsequent sending of the next KeyUpdate as a single exchange. Certificate requests are similar, i.e. the server sees the sending of the certificate request as a single standalone exchange, and the receipt of the subsequent Certificate/Finished as a separate exchange. The client sees the receipt of the request and its response as one single exchange. > > What I'm getting at here is that "post-handshake exchange" does not seem to be a > meaningful construct to the protocol. I would thus advocate not signaling > START/END things to begin with. That way, if TLS 1.4 comes by and shuffles > around again, we don't repeat this adventure. If we signal them at all then I think they must be signalled with start/end since there can be multiple state changes for a single exchange (e.g. when the client receives a certificate request). Matt From kaduk at mit.edu Wed Jan 30 16:20:40 2019 From: kaduk at mit.edu (Benjamin Kaduk) Date: Wed, 30 Jan 2019 10:20:40 -0600 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190130080229.GA29942@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190130080229.GA29942@roeckx.be> Message-ID: <20190130162040.GB49072@kduck.mit.edu> On Wed, Jan 30, 2019 at 09:02:30AM +0100, Kurt Roeckx wrote: > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > So I plan to start the vote soon for merging PR#8096 and backporting it to > > 1.1.1. This is a breaking change as previously discussed. > > > > My proposed vote text is as follows. Please let me know asap of any feedback. > > Otherwise I will start the vote soon. > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > > SSL_CB_HANDSHAKE_END)." > > So my proposal would be: Don't call the callback for post > handshake messages. (It could use some rewording.) That does have a fair bit of appeal to it, though perhaps not enough to justify the breaking change in 1.1.1. -Ben From kurt at roeckx.be Wed Jan 30 17:20:30 2019 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 30 Jan 2019 18:20:30 +0100 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> Message-ID: <20190130172030.GA7513@roeckx.be> On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote: > > > On 29/01/2019 19:27, David Benjamin wrote: > > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx > > wrote: > > > > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > > So I plan to start the vote soon for merging PR#8096 and backporting it to > > > 1.1.1. This is a breaking change as previously discussed. > > > > > > My proposed vote text is as follows. Please let me know asap of any feedback. > > > Otherwise I will start the vote soon. > > > > > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > > > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > > > SSL_CB_HANDSHAKE_END)." > > > > > > What exactly is a post-handshake message exchange? Do the NewSessionTicket sent > > by the server at the beginning count as the part of the handshake? Are they each > > separate post-handshake exchanges? Are all of them together one exchange? > > Conversely, what happens when you receive that NewSessionTicket as a client? > > > They are each separate post-handshake exchanges. Both on the server and on the > client. > > > > > When you send a KeyUpdate with key_update_requested, is the reply you expect > > part of the exchange or separate? What if the peer coalesced them to avoid DoS > > problems? Conversely, if you receive a KeyUpdate with key_update_requested, is > > your reply part of the exchange? What if you coalesced them to avoid DoS problems? > > > > What if I send a CertificateRequest, but the other side sends me a KeyUpdate > > with key_update_requested before responding with Certificate, so I respond with > > my own KeyUpdate? What and how many exchanges are there? > > > > Is it important that both sides agree what an "exchange" is? > > The answers all depend on how the OpenSSL state machine views them. At the > moment the peer sending a KeyUpdate sees that as a single standalone exchange. > If an update has been requested then the receiving peer sees the receiving and > subsequent sending of the next KeyUpdate as a single exchange. This "at the moment" sounds a lot like "we can change this at any time, for whatever reason". I can actually see a use case for wanting to know if a key update has been received and sent. Maybe the application wants to make sure that at regular intervals this is done. I just doubt that this is the most useful interface for that. The way to do that is to tell OpenSSL to do that instead. > Certificate requests are similar, i.e. the server sees the sending of the > certificate request as a single standalone exchange, and the receipt of the > subsequent Certificate/Finished as a separate exchange. The client sees the > receipt of the request and its response as one single exchange. I think the server really only cares that it's been received, and you can argue that it should be 1 exchange. Kurt From matt at openssl.org Wed Jan 30 17:36:12 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Jan 2019 17:36:12 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190130172030.GA7513@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> Message-ID: On 30/01/2019 17:20, Kurt Roeckx wrote: > On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote: >> >> >> On 29/01/2019 19:27, David Benjamin wrote: >>> On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx >> > wrote: >>> >>> On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: >>> > So I plan to start the vote soon for merging PR#8096 and backporting it to >>> > 1.1.1. This is a breaking change as previously discussed. >>> > >>> > My proposed vote text is as follows. Please let me know asap of any feedback. >>> > Otherwise I will start the vote soon. >>> > >>> > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and >>> > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake >>> > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and >>> > SSL_CB_HANDSHAKE_END)." >>> >>> >>> What exactly is a post-handshake message exchange? Do the NewSessionTicket sent >>> by the server at the beginning count as the part of the handshake? Are they each >>> separate post-handshake exchanges? Are all of them together one exchange? >>> Conversely, what happens when you receive that NewSessionTicket as a client? >> >> >> They are each separate post-handshake exchanges. Both on the server and on the >> client. >> >>> >>> When you send a KeyUpdate with key_update_requested, is the reply you expect >>> part of the exchange or separate? What if the peer coalesced them to avoid DoS >>> problems? Conversely, if you receive a KeyUpdate with key_update_requested, is >>> your reply part of the exchange? What if you coalesced them to avoid DoS problems? >>> >>> What if I send a CertificateRequest, but the other side sends me a KeyUpdate >>> with key_update_requested before responding with Certificate, so I respond with >>> my own KeyUpdate? What and how many exchanges are there? >>> >>> Is it important that both sides agree what an "exchange" is? >> >> The answers all depend on how the OpenSSL state machine views them. At the >> moment the peer sending a KeyUpdate sees that as a single standalone exchange. >> If an update has been requested then the receiving peer sees the receiving and >> subsequent sending of the next KeyUpdate as a single exchange. > > This "at the moment" sounds a lot like "we can change this at any > time, for whatever reason". No, it means that is how it currently coded. We are discussing a PR to change how this works so we have the opportunity to make it work differently if we so wish. However since this is a breaking change I'm of the view that we should be making the minimal change necessary. IMO that is the change that I have proposed in PR 8096 and as described in the vote text at the beginning of this thread. I don't think we should be looking at this as a wholesale redesign of how the info callback works and its relative merits an disadvantages. Like it or not we have an info callback, and it does what it does. It is in our API and we cannot remove it (at least not any time soon - see https://github.com/openssl/web/pull/82). We implemented it in a particular way for TLSv1.3 and if we wanted something else then the time to debate that was prior to the release of 1.1.1. The *only* reason that this is being discussed now is because of the specific issue with KeyUpdates. PR8096 fixes that in the simplest way I could think of. > > I can actually see a use case for wanting to know if a key update > has been received and sent. Maybe the application wants to make > sure that at regular intervals this is done. I just doubt that > this is the most useful interface for that. The way to do that is > to tell OpenSSL to do that instead. > >> Certificate requests are similar, i.e. the server sees the sending of the >> certificate request as a single standalone exchange, and the receipt of the >> subsequent Certificate/Finished as a separate exchange. The client sees the >> receipt of the request and its response as one single exchange. > > I think the server really only cares that it's been received, and > you can argue that it should be 1 exchange. I'm not entirely sure what you mean by "1 exchange", but if you mean the sending of the request and the subsequent receipt of the certificate/finished should be 1 exchange as far as the info callback is concerned then I don't think that would work. There may be intervening messages and application data transfer. Matt From davidben at google.com Thu Jan 31 18:50:13 2019 From: davidben at google.com (David Benjamin) Date: Thu, 31 Jan 2019 12:50:13 -0600 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: <20190130172030.GA7513@roeckx.be> References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> Message-ID: On Wed, Jan 30, 2019 at 11:20 AM Kurt Roeckx wrote: > On Wed, Jan 30, 2019 at 10:44:12AM +0000, Matt Caswell wrote: > > > > > > On 29/01/2019 19:27, David Benjamin wrote: > > > On Tue, Jan 29, 2019 at 11:31 AM Kurt Roeckx > > > wrote: > > > > > > On Tue, Jan 29, 2019 at 02:07:09PM +0000, Matt Caswell wrote: > > > > So I plan to start the vote soon for merging PR#8096 and > backporting it to > > > > 1.1.1. This is a breaking change as previously discussed. > > > > > > > > My proposed vote text is as follows. Please let me know asap of > any feedback. > > > > Otherwise I will start the vote soon. > > > > > > > > "master and 1.1.1 will be updated to use > SSL_CB_POST_HANDSHAKE_START and > > > > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post > handshake > > > > message exchange in the info callback (replacing > SSL_CB_HANDSHAKE_START and > > > > SSL_CB_HANDSHAKE_END)." > > > > > > > > > What exactly is a post-handshake message exchange? Do the > NewSessionTicket sent > > > by the server at the beginning count as the part of the handshake? Are > they each > > > separate post-handshake exchanges? Are all of them together one > exchange? > > > Conversely, what happens when you receive that NewSessionTicket as a > client? > > > > > > They are each separate post-handshake exchanges. Both on the server and > on the > > client. > > > > > > > > When you send a KeyUpdate with key_update_requested, is the reply you > expect > > > part of the exchange or separate? What if the peer coalesced them to > avoid DoS > > > problems? Conversely, if you receive a KeyUpdate with > key_update_requested, is > > > your reply part of the exchange? What if you coalesced them to avoid > DoS problems? > > > > > > What if I send a CertificateRequest, but the other side sends me a > KeyUpdate > > > with key_update_requested before responding with Certificate, so I > respond with > > > my own KeyUpdate? What and how many exchanges are there? > > > > > > Is it important that both sides agree what an "exchange" is? > > > > The answers all depend on how the OpenSSL state machine views them. At > the > > moment the peer sending a KeyUpdate sees that as a single standalone > exchange. > > If an update has been requested then the receiving peer sees the > receiving and > > subsequent sending of the next KeyUpdate as a single exchange. > > This "at the moment" sounds a lot like "we can change this at any > time, for whatever reason". > Indeed, this is the whole reason we are in this mess right now. "How OpenSSL's state machine views these events" is fundamentally not a workable API definition. In OpenSSL 1.1.0, OpenSSL had the SSL_CB_HANDSHAKE_START API. The semantics were "what the OpenSSL state machine thinks is a new handshake". This aligned with the natural definition of a "handshake", so callers, quite naturally, used that to be notified of handshakes. Then OpenSSL made a purportedly backwards-compatible release in 1.1.1. It added TLS 1.3, chose a particular implementation strategy and made the SSL_CB_HANDSHAKE_START semantics mirror the existing "what the OpenSSL state machine thinks is a new handshake" semantics. But now it does not align with the natural definition of a handshake. Indeed the response above demonstrates there is no such natural definition that covers post-handshake messages. The result is OpenSSL 1.1.1 subtly broke existing code, in a way that damaged the TLS 1.3 ecosystem. We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can at least help slow its spread by issuing a fix and announcing to all consumers (e.g. Linux distros) they need to take the fix. In doing so, it is important to understand the root cause so that this mistake does not repeat. As a heuristic for API design: if the caller needs to know the implementation details of OpenSSL to understand what this API does, the API is no good. Existing code cannot possibly predict how OpenSSL's implementation will evolve over time, so there is no way to use such an API in a future-proof way. Do not introduce such APIs. > I can actually see a use case for wanting to know if a key update > has been received and sent. Maybe the application wants to make > sure that at regular intervals this is done. I just doubt that > this is the most useful interface for that. The way to do that is > to tell OpenSSL to do that instead. > > > Certificate requests are similar, i.e. the server sees the sending of the > > certificate request as a single standalone exchange, and the receipt of > the > > subsequent Certificate/Finished as a separate exchange. The client sees > the > > receipt of the request and its response as one single exchange. > > I think the server really only cares that it's been received, and > you can argue that it should be 1 exchange. > > > Kurt > > _______________________________________________ > openssl-project mailing list > openssl-project at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Jan 31 19:42:10 2019 From: matt at openssl.org (Matt Caswell) Date: Thu, 31 Jan 2019 19:42:10 +0000 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> Message-ID: On 31/01/2019 18:50, David Benjamin wrote: > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL can at > least help slow its spread by issuing a fix That's precisely what PR 8096 does. > As a heuristic for API design: if the caller needs to know the implementation > details of OpenSSL to understand what this API does, the API is no good. > Existing code cannot possibly predict how OpenSSL's implementation will evolve > over time, so there is no way to use such an API in a future-proof way. Do not > introduce such APIs. The info callback has been around a *long* time. In fact OpenSSL did not introduce it at all - we inherited it from SSLeay. Arguments about whether it is a good API or not don't help the issue at hand. The API exists, applications use it, and so (for now at least) we continue to support it. Given that it already existed we had to make a decision about how it was going to work in the presence of TLSv1.3. We did what we believed to be the correct thing at the time. The changes were pretty minimal and we tried to keep things as close to what existing users of the callback would expect. It turns out we got it wrong. Matt From davidben at google.com Thu Jan 31 20:19:28 2019 From: davidben at google.com (David Benjamin) Date: Thu, 31 Jan 2019 14:19:28 -0600 Subject: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change In-Reply-To: References: <246a49e1-48b6-22e3-5de5-35d93ca3c9bb@openssl.org> <20190129173137.GA28734@roeckx.be> <20190130172030.GA7513@roeckx.be> Message-ID: On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote: > > On 31/01/2019 18:50, David Benjamin wrote: > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL > can at > > least help slow its spread by issuing a fix > > That's precisely what PR 8096 does. > > > > As a heuristic for API design: if the caller needs to know the > implementation > > details of OpenSSL to understand what this API does, the API is no good. > > Existing code cannot possibly predict how OpenSSL's implementation will > evolve > > over time, so there is no way to use such an API in a future-proof way. > Do not > > introduce such APIs. > > The info callback has been around a *long* time. In fact OpenSSL did not > introduce it at all - we inherited it from SSLeay. Arguments about whether > it is > a good API or not don't help the issue at hand. The API exists, > applications use > it, and so (for now at least) we continue to support it. > > Given that it already existed we had to make a decision about how it was > going > to work in the presence of TLSv1.3. We did what we believed to be the > correct > thing at the time. The changes were pretty minimal and we tried to keep > things > as close to what existing users of the callback would expect. It turns out > we > got it wrong. > Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are new. It seems best to just omit it, so OpenSSL is not tied to the nebulous notion of "post-handshake exchange". I.e. don't bracket post-handshake things with START/END at all. David -------------- next part -------------- An HTML attachment was scrubbed... URL: