On Thu, Sep 6, 2018 at 3:13 AM Stefan Eissing <[email protected]> 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.
