Re: TLSv1.3 supprt for 2.4.x?
> Am 05.09.2018 um 18:52 schrieb William A Rowe Jr <wrowe@xxxxxxxxxxxxx>:
> On Wed, Sep 5, 2018 at 10:52 AM, Dennis Clarke <dclarke@xxxxxxxxxxxxx> wrote:
> On 09/05/2018 07:36 AM, Stefan Eissing wrote:
> A member of the OpenSSL project gave me a "go ahead" and we now have branch:
> as a copy of 2.4.x with 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 merged in. If was not a clean merge as some feature from trunk are not present in 2.4.x, so peer review/test is definitely desired.
> I put a backport proposal into 2.4.x/STATUS
> Cheers, Stefan
> Awesome but there are plenty of folks that will want a simple tarball
> with the usual autoconf/configure magic done for them. Could be a waste
> of effort given that OpenSSL 1.1.1 release is 6 days away.
> Not a waste of effort.
> The project can't realistically deliver such a large changeset without wider
> testing, the number of issues raised on multiple forums demonstrate that.
> (Thankfully > 50% are users who were unaware of draft vs. final TLS
> handshake signatures, and such inattentive users aren't productively
> contributing to interoperability review.) Users who are prepared to
> *constructively* engage on any proposed changeset should have few
> problems with a couple extra steps.
If there are interop problems at the TLS layer itself, these are not directly
a concert to httpd, but a matter of IETF draft versions and implementations
to sort out. At this point, we will not help resolving interop issues by
holding back a release that can use TLSv1.3.
> I can't imagine the project releasing this changeset without first releasing
> a stable 2.4.35, followed shortly thereafter with a less stable TLS 1.3
> release. It appears to introduce a set of required(?) config changes,
> something we've never purposefully done in a major.minor update.
I think we will find common ground in that we do not want to interrupt existing
httpd deployments with such a feature. On the other hand, we have a responsibility
also as one of the leading HTTP servers on this planet, to enable our users to
protect themselves by applying the latest tech in security.
This, we have to balance.
Precisely for this feature, we need to evaluate:
- do we introduce config breaking changes?
I added the optional parameter to SSLCipherSuite in a way that does not (or should not) affect existing configurations. If I erred, it would be good to find out.
- does this change affect servers linked with OpenSSL 1.0.x or older?
The intention of the change is to not do that. The guarding of changes by #ifdef make it work with OpenSSL 1.0.2 for me. I invited Bernard explicitly to test his libressl setups to get broader coverage. Maybe Rainer and Rüdiger will find the time to tests their various setups.
- servers linking with a latest *SSL library (or distros shipping it that way) will see TLSv1.3 enabled, unless the configurations remove it explicitly. I think, based on feedback from others, this is what we want to happen.
All this can and should be discussed by bringing forth technical arguments or counter examples, IMO. For the release, there will be voting, just as with other backport proposals, will it not?