Just tested this branch with OpenSSL 1.1.1p9. Haven't found issues yet. > Listen 42002 https > SSLHonorCipherOrder on > SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
Server error.log > AH00489: Apache/2.4.35-dev (FreeBSD) OpenSSL/1.1.1-pre9 configured -- > resuming normal operations client `openssl s_client -connect localhost:42002` > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 I like the default server cipher selection! On Wed, Sep 5, 2018 at 1:36 PM Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > > A member of the OpenSSL project gave me a "go ahead" and we now have branch: > > https://svn.apache.org/repos/asf/httpd/httpd/branches/tlsv1.3-for-2.4.x > > as a copy of 2.4.x with > 1827912,1827924,1827992,1828222,1828720,1828723,1833588,1833589,1839920,1839946 > merged in. If was not a clean merge as some feature from trunk are not > present in 2.4.x, so peer review/test is definitely desired. > > I put a backport proposal into 2.4.x/STATUS > > Cheers, Stefan > > > > Am 03.09.2018 um 15:45 schrieb Jim Jagielski <j...@jagunet.com>: > > > > +1! for backporting > > > >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > >> wrote: > >> > >> Dear SSL care takers and stake holders, > >> > >> trunk has TLSv1.3 support for some time. I just now changed the 'all' > >> SSLProtocol selection, so that it does not include TLSv1.3. This means > >> that in order to enable it, admins must add an explicit '+TLSv1.3' to > >> their config (same for SSLProxyProtocl of course). > >> > >> With this, the added support is really an opt-in and we could backport it > >> to 2.4.x, if we want. We have been burned with backporting SSL features > >> just recently (by my mistake), so I would understand that people feel a > >> bit reluctant here. On the other hand, there is certainly interest by > >> users. > >> > >> So, what is your opinion? > >> > >> Cheers, > >> > >> Stefan > >> > >> PS. There are some combinations in renegotiation/client certs that are not > >> tested well. Therefore, '+TLSv1.3' should be tagged as 'experimental' or > >> at least with a heavy caveat for those setups. But I see no issue with > >> using it for plain-vanilla https: setups. > > >
