[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLSv1.3 supprt for 2.4.x?

On Thu, Sep 6, 2018 at 3:13 AM Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx> wrote:

> 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.

+1 - no breaking changes. Adding the parameter optional (default TLS 1.2 and earlier) should accomplish this. Trusting OpenSSL initially to provide only more-secure TLS 1.3 ciphers suggests that folks won't need to drop ciphers from that list for some time, yet.
- 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.

+1 - If we still compile successfully against 0.9.8/1.0.0/1.0.1 it would be a kindness to our users on older OS distributions, granted only 1.0.2 and onwards are still "supported" by OpenSSL, but OS vendors may be maintaining their forks longer.
- 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.

+1 - Given the (presumably) sane set of defaults.
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?

Agreed, as to review for release. To the subject top-thread, feedback to the merge branch would be early, easy, appreciated, and save iterations, so is not a waste of effort for those willing to review the design decisions. For who are uncomfortable running ./buildconf against a checkout, they do not lose the opportunity to review.