OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLSv1.3 supprt for 2.4.x?


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.eissing@xxxxxxxxxxxxx> 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 <jim@xxxxxxxxxxx>:
> >
> > +1! for backporting
> >
> >> On Sep 3, 2018, at 5:17 AM, Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx> 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.
> >
>