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.eiss...@greenbytes.de> 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.eiss...@greenbytes.de>: > > > > > > > >> Am 03.09.2018 um 13:19 schrieb Joe Orton <jor...@redhat.com>: > >> > >> 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 >
