1.1.1-pre2: testsuite failure in libnet-ssleay-perl

[sebastianas]

Running the testsuite of libnet-ssleay-perl 1.84 leads to a stall and never completes while the same binary completes against latest 1.1.0.
Aside from #5511 there seems to be a change in behavior in SSL_read().
The problematic test is t/local/07_sslecho.t. That test creates a server and a client and communicate via TCP/localhost. Once side does accept+ SSL_read+ SSL_write+ while other does connect+ SSL_write+ SSL_read. Multiple times.

t/local/07_sslecho.t ...................
1..78
$ make test TEST_VERBOSE=1
ok 1 - CTX_new
ok 2 - CTX_set_cipher_list
ok 3 - set_cert_and_key:
ok 4 - new
ok 5 - set_fd using fileno
ok 6 - accept1
ok 7 - get_cipher
ok 8 - get_shared_ciphers
ok 9 - ssl_read_all
ok 10 - ssl_write_all
ok 11 - new
ok 12 - set_fd using fileno
Use of uninitialized value $got in concatenation (.) or string at t/local/07_sslecho.t line 134.
ok 13 - accept1
ok 14 - get_cipher
…

The ::read is a wrapper around SSL_read(). The ::read_all() invokes ::read multiple times (until it finally returns 0).
The uninitialized value here is is because Net::SSLeay::read() didn't read anything/ SSL_read() returned 0. After that, SSL_get_error() returns SSL_ERROR_WANT_READ. If I retry the read then the expected value is received. Is that the expected behavior?

Later the test suite stalls later because one side does write+shutdown while other stalls in write(). The read seems to have made it.
Is this somehow helping to narrow down this or should I try to comeup with a simple test case?

[sebastianas]

According to bisect the problem start with commit f518cef ("Enable TLSv1.3 by default"). By building master with tls1.3 disabled the testsuite passes again.

[kroeckx]

The SSL_ERROR_WANT_READ indicates that OpenSSL needs to get more data from the peer and that you should call SSL_read() or SSL_write() again when more data is available. This has always been the case, and it might have worked by coincidence before.

[richsalz]

Yes, it seems like a bug in the perl test case.

[bernd-edlinger]

IIRC, previously the SSL_ERROR_WANT_READ did only show up when the other side explicitly
requested a renegotiation. But with resumed tls1.3 sessions we have that much more often.

[sebastianas]

got more time to look into this.
After handling SSL_ERROR_WANT_READ in read and so on, the next problem was this:

one side did
SSL_write(sockfd, );
shutdown(sockfd, SHUT_RDWR);

while the other did
SSL_read(sockfd, );
SSL_write(sockfd,);

pre-TLS1.3 is seems to "just" continue. With TLS1.3 there was a SIGPIPE which resulted in a hang of the perl code. By ignoring the SIGPIPE it complains about the return code so I think it is another failure in the testcase.

Let me close this and swing over to perl and let them know…

Sebastian