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

[Steffen Ullrich]

On Mon, May 13, 2019 at 01:02:45AM +0200, Guilhem Moulin <guilhem at debian.org> wrote:
> Thanks for your analysis, Steffen.  Dropping the Debian-specific patch
> is definitely the way to go for libwww/LWP.  However I still believe
> IO::Socket::SSL should provide a way to clear SSL_MODE_AUTO_RETRY in
> order to fix applications relying on the former OpenSSL defaults, as
> suggested in the OpenSSL changelog:
>
>     “SSL_MODE_AUTO_RETRY is enabled by default. Applications that use
>     blocking I/O in combination with something like select() or poll()
>     will hang. This can be turned off again using SSL_CTX_clear_mode().”
>
> Otherwise the “usual” way to write event loops in blocking I/O won't be
> possible with IO::Socket::SSL.

Applications which relied on blocking I/O in connection with select could
also hang before, only this problem is worse now. Before TLS 1.3 these
applications could hang if the peer initiated a renegotiation since this
were TCP level data without any SSL application payload, i.e. select was
triggered but sysread would not return with data. It could also lead to
delays when SSL frames larger than the TCP window size where used or due to
interactions with NAGLE algorithms or delayed ACK. In this case too TCP
level data were received but the SSL level data where only received later
once the SSL frame was completed, which means it had to wait until
completation of the SSL frame in sysread.

With TLS 1.3 this problem is now worse since it happens more often. And
frankly, I'd rather see the applications fix their wrong approach than to
give them an opportunity to work around the most common cause and leave
them wondering about strange problems which happen from time to time and
which nobody can really reproduce.

Additionally switching off SSL_MODE_AUTO_RETRY would actually just add a
different unexpected behavior: that sysread might return with EAGAIN on a
blocking socket. This is not the behavior one expects from a blocking
socket, i.e. it should block until it returns data, should return no data
only on connection shutdown or should fail permanently.
It was just a coincidence that LWP::protocol::http could deal with this
situation. And this coincidence came from the fact, that this code was
actually designed for non-blocking sockets and only the Debian patch caused
it to use a blocking socket instead.

I've added more information regarding this to the IO::Socket::SSL
documentation:
https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

Regards,
Steffen