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

Re: TLSv1.3 supprt for 2.4.x?

> Am 03.09.2018 um 13:19 schrieb Joe Orton <jorton@xxxxxxxxxx>:
> On Mon, Sep 03, 2018 at 11:17:39AM +0200, Stefan Eissing 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?
> Yes, I just worked on a backport of that set for Fedora, so I'm on board 
> for pushing & testing that in 2.4.x.  Possibly warrants a branch to work 
> through the merge?

We could do that. The patch, right now, is not that large, I think, but
a branch does not hurt.

>> 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.
> AIUI the various bits of new API added for TLS/1.3 are not necessarily 
> stable until there is a final OpenSSL 1.1.1 release, so maybe we should 
> wait for that first?  

I think they (or at least the parts we use) have been stable since pre3 in 
spring. There have been fixes under the hood in timing of callbacks, AFAIK.
Since none of these are in any public part of httpd - apart from the
protocol config which we alaways be there - I think we could broaden the
test audience without much risk.

> IMO there is no problem with supporting it by default (not needing 
> explicit +TLSv1.3) in 2.4.  Since "bleeding edge OpenSSL" is needed to 
> enable it at build time, this isn't going to break production users on 
> current systems.

Interesting. If that is consensus, I'd revert my change from earlier today.

Cheers, Stefan

> Regards, Joe