> Am 29.03.2018 um 06:21 schrieb Greg Stein <gst...@gmail.com>: > > On Wed, Mar 28, 2018 at 10:49 AM, Stefan Eissing > <stefan.eiss...@greenbytes.de> wrote: > Just added TLSv1.3 support in trunk. No fancy new early data features, just > the basic. > > Open for discussion: > - The Mozilla server-side-tls people are still thinking of what they will > recommend, see: > > https://github.com/mozilla/server-side-tls/issues/191#issuecomment-376918933 > - Turns out, cipher suites are separate from <= TLSv1.2. Since servers will > co-host 1.2 and 1.3 > for some time, we need additional config directives, I think. Added > "SSLCipherSuiteV1_3" and > am ashamed of the name. > > Why not something simple like: > > TLSVersion 1.3 > > and have that impute a specific set of ciphers? Get's away from the old "SSL" > name, and moves us to a directive that can accept version into the future > (instead of a new directive every time). > > And if you want to *refine* the behavior, then do it with new TLS* > directives. I've always had a problem with setting up TLS servers because of > the huge number of directives. It would be nice to just introduce a new, > simple directive that produces "all" the default handling for the majority of > users.
That is the intention behind "SSLPolicy modern|intermediate|old" that configures the TLS stack according to the Mozilla server-side-tls recommendations. So, one does not have to mess with many directives to have a site with an "A" SSL Labs rating. Besides, except for data center setups, Apache will be used *only* with https: (and http: redirects to https:) very, very soon. That shifts the average expertise of an admin setting up a https: site. Back to TLSv1.3: I do not like to invent new config directives for a new TLS version either. The protocol on/off switch is now in "SSLProtocol" and that's where it should be. AFAIK, it's only the cipher list that needs special treatment (if one wants to override defaults or what SSLPolicy will do for it, once a recommendation is out). So, looking at "SSLCipherSuite". It basically passes the string to the *SSL library. The manual page makes a big explanation and tables of ciphers, but the lists repeats basically how OpenSSL cipher strings work. It would be better to scrap that and replace it with a link to https://www.openssl.org/docs/man1.0.2/apps/ciphers.html, now that openssl has nicer documentation) Along the gist of your proposal, I think I'll expand "SSLCipherSuite" to take more than 1 argument and look for optional prefixes to the suite strings given, so one could do # as before, applies to all TLS protocols <=TLSv1.2 SSLCipherSuite XXX:YY:-AASSD:DSDS # Set ciphers for TLSv1.3, does not replace the previous line SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 So, the directive becomes: SSLCipherSuite [ ProtocolClass ] Cipher-String where ProtocolClass is: SSL (default) all TLS/SSL Protocols <= TLSv1.2 TLSv1.3 TLS version 1.3 That would mean we have no new directives. > - The current handling of TLS versions that are not supported by the *SSL > lib linked is not > super helpful. It more or less pretends that the version does not exist > (unknown protocol), > but that is far from the truth. Shall we continue that or is this an > opportunity to reconsider? > > Euh, if the underlying libraries cannot support a new TLS version, *and* > httpd hasn't been coded to support that version, then yes: it should fail. > Both parts are needed. > > Did I misunderstand your query? > > - Should we allow the configuration of TLSv1_3 ciphers, even if the linked > SSL does not support > it? This is different from SSLProtocol which of course needs to fail if it > cannot enable the > version that is explicitly configured. > I think it is ok to take it into the config, even though it never > activates. > > Oh no no. If I want to configure "SuperAwesomeGJSCipher", and that isn't > available like I *expect* it to be ... then yeah. "Cipher not available. You > won't get the security you're seeking." #FAIL > > Cheers, > -g >
