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

Re: TLSv1.3 supprt for 2.4.x?


Hi All,

I've received a patch from the LibreSSL devs via mail. That resolves
the renegotiation issue. Patch is awaiting review, I expect it to land
in the LibreSSL repo soon.

Cheers, Bernard.
On Mon, Sep 3, 2018 at 1:36 PM Stefan Eissing
<stefan.eissing@xxxxxxxxxxxxx> wrote:
>
> Speaking of SSL and rare renegotiation setups: Bernard and me are suspecting that
> libressl has issues here for quite some time. At least it looks that way:
>
> https://github.com/libressl-portable/portable/issues/443
>
> Just FYI in case someone encounters such things.
>
> > Am 03.09.2018 um 13:32 schrieb Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx>:
> >
> >
> >
> >> 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
>