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