SSLProtocol TLSv1.2 TLSv1.3 SSLProxyProtocol TLSv1.2 TLSv1.3 should be syntactically valid, no?
[Wed Apr 04 18:21:11.465896 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. [Wed Apr 04 18:21:11.465946 2018] [ssl:warn] [pid 2228052:tid 140031042861312] AH02532: SSLProxyProtocol: Protocol 'TLSv1.3' overrides already set parameter(s). Check if a +/- prefix is missing. TLSv1.3 should begin 'unset' if TLSv1.2 is given without modifiers. 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. > - 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? > - 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. > > Cheers, > > Stefan > > PS. If a FreeBSD libressl+apache maintainer is listening here, he may try if > trunk compiles with it. I would not stop him. >
