Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Dimitri John Ledkov]

On Tue, 7 May 2019 19:39:15 +0200 Guilhem Moulin <guilhem at debian.org> wrote:
> Hi Dimitri,
>
> On Tue, 07 May 2019 at 15:46:25 +0100, Dimitri John Ledkov wrote:
> > On Tue, 7 May 2019 14:16:43 +0100 Dimitri John Ledkov <xnox at ubuntu.com> wrote:
> >> This issue concerns me a lot at the moment. I am currently trying to
> >> upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And
> >> as far as I understand all the comment on this debian bug report,
> >> current application are potentially broken and brokeness happens more
> >> often with TLSv1.3 and the new OpenSSL 1.1.1 defaults
> >> (SSL_MODE_AUTO_RETRY).
> >>
> >> As far as I understand we do not have a fixed LWP that works correctly
> >> in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing
> >> existing users further, does it make sense for me to make updates in
> >> bionic that:
> >>
> >> 1) limit SSL_new and SSL_CTX_new to TLS v1.2 max
> >> and
> >> 2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections?
> >>
> >> My goal is to keep existing breakages as is, without introducing new
> >> ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not
> >> get TLS v1.3 enabled for perl server/clients without code changes, but
> >> oh well. Those who want it, will be able to force / start using it.
>
> It's IMHO unfortunate to change the default in Net::SSLeay, as TLSv1.3
> brings quite a few improvements (in terms of security as well as
> performance).  OpenSSL 1.1.1 was released on 11 Sep 2018 and uploaded to
> sid the day after, breaking programs using select()/poll() with blocking
> I/O; this is not specific to Perl bindings — other languages are also
> affected — yet no one is suggesting to disable TLSv1.3 globally in
> libssl :-)
>
> If TLSv1.3 should be disabled (and the SSL_MODE_AUTO_RETRY flag cleared)
> then IMHO I think it should be done as close at possible to the leaf
> application (LWP in this case), not in the library itself.  After all we
> have only one RC bug about this, so I guess other programs (in any
> language) 1/ have workarounds; 2/ aren't using select()/poll() with
> blocking I/O; or 3/ aren't affected because they never used SSL_read()
> as documented.  IHMO the libssl change shouldn't be reason to penalize
> all applications, given most seems unaffected.
>
> I still think the right fix is to make SSL_MODE_AUTO_RETRY (or even the
> whole mode bitmask mode?) configurable in IO::Socket::SSL, and clear it
> in programs and libraries using select()/poll() with blocking I/O, such
> as LWP in this case.  AFAICT that follows the intention of OpenSSL's
> development team, unlike global library changes.  AFAICT the attached
> patch (to sid's IO::Socket::SSL and LWP::Protocol::https, respectively
> 2.060-3 and 6.36-1) fixes the problem for me, while preserving TLSv1.3
> support and default.
>

I like this, and your proposed patch as it solved the issue with
TLSv1.3 and my changes kept things still broken over TLSv1.3.

Can we get this upstreamed? (or as you suggest even exposing the whole
bitmask mode).

> > I proposed the following patch upstream / request for comments
> > https://github.com/radiator-software/p5-net-ssleay/pull/139
>
> I personally don't like this change as I hope Buster's Net::SSLeay and
> other SSL libraries will default to TLSv1.3 on capable servers :-)  2
> comments anyway:

I have now self-rejected that merge proposal and reverted it in Ubuntu.

>
>   * OpenSSL <1.1.0 has no SSL_CTX_set_max_proto_version(), so an OpenSSL
>     version test is lacking (nothing more as <1.1.0 has no TLSv1.3