My view: Shipping the TLSv1.3 support has risks, but we also need to enable people to have the latest in transport security.
We paid attention to keeping the behaviour with older versions of openssl unchanged and our test cases confirm that this is the case - as far or short as they go. People linking their server (or shipping a distro) with openssl 1.1.1 or the relevant libressl version for TLSv1.3 opt in to share that risk, consciously. We can mitigate the risk of such changes with a) better test suites b) a broader test community While no one is prevented from voting on a release candidate, the time window is too short for some people, I believe. My experience with making mod_http2 and mod_md available standalone on github is: - it's a platform for people who make "bleeding-edge" packages available to a range of people who like to run on the latest and greatest. - it broadens the test base considerably - it simplifies testing of fixes - it simplifies analysis of bug reports against our 2.4.x releases as issues are often reported more than once and I can point people to the github release for checking their bug against fixes already made. The httpd project is, right now, not offering this. People can check out 2.4.x, sure, but fixes often trickle only in just before a release. Also, the 2.4.x branch is not intended for testing a "hopeful" fix. And testing the dev branch is not the same either. So, it seems to me, as we are missing a 2.4.x-candy branch that is CTR and where from RTC merges with votes are done to 2.4.x. From 2.4.x-candy we could tag "release-candidates" and provide our usual tar balls in a pretty automated way. They'd have not CVE relevant changes and need no big announcements. I imagine Daniels scripts can make them easily. For 2.4.36 it would have meant that we'd had people testing TLSv1.3 for weeks now, in much broader settings. And it would not have cost us much. Cheers, Stefan > Am 10.10.2018 um 22:45 schrieb Gregg Smith <g...@gknw.net>: > > FWIW, I've been running 2.4.36-dev at revision 1841586 for 19 days 35 minutes > as of this writing and I've seen no problems up to this point. Granted I only > get a few thousand hits a day and not millions but so far so good. Haven't > had many tls/1.3 but I would assume that's to be expected for another week or > two until Chrome 70 and Firefox 63 come out. > > Now off to build .36 > > On 10/10/2018 1:29 PM, William A Rowe Jr wrote: >> On Wed, Oct 10, 2018, 14:53 Mark Blackman <m...@exonetric.com> wrote: >>> >>> Does the TLSv1.3 support need to be production ready? >>> >>> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger >>> existing behaviours, I would have assumed it’s relatively safe to release >>> with caveats in the docs. >>> Of course, once there’s more take-up of TLSv1.3, then the test suite needs >>> to be useful. Getting real-world feedback about something completely new >>> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably >>> worthwhile. >>> >> Were it so easy... >> It turns out httpd through 2.4.35 remain incompatible with changes to >> openssl 1.1.1. This was disappointing from this project's perspective, the >> issues are tracked on openssl project GitHub tickets. >> If everything is good about this candidate, it should build and run against >> 1.1.0, or 1.1.1, whether or not TLS 1.3 is enabled or avoided. >> Ben Laurie last decade tried to address this with mod_tls, but mod_ssl >> remains deeply tied to the internal behavior of libssl and libcrypto, to a >> degree that it is effectively impossible to drop in 1.1.1 due to mechanical >> changes in the protocol. >> Dropping httpd 2.4.any into openssl 1.1.1 is a mess that several committers >> have applied a great deal of attention to. We've undergone the same >> problems with 1.1.0, 1.0.1, 1.0.0 and 0.9.8, so this didn't come as a >> surprise.
