Bug #126976 for POE-Component-SSLify: t/connect_hook_nodata.t fails with OpenSSL 1.1.1

> OpenSSL released 1.1.1 prerelease that implements TLSv1.3 and enables > it by default. TLSv1.3 differs from TLSv1.2 and patched Net-SSLeay > (CPAN RT#125218) is needed. With these a POE-Component-SSLify-1.012 > test still fails: > > $ perl -Ilib t/connect_hook_nodata.t > ok 1 - SERVER: SSLify_Options > ok 2 - SERVER: Server_SSLify > ok 3 - SERVER: SSLify_GetStatus is pending > ok 4 - SERVER: accepted > ok 5 - CLIENT: Client_SSLify > ok 6 - CLIENT: SSLify_GetStatus is pending > ok 7 - CLIENT: connected > ok 8 - CLIENT: Got callback hook > ok 9 - CLIENT: Status received from callback is OK > ok 10 - CLIENT: SSLify_GetCipher: TLS_AES_256_GCM_SHA384 > ok 11 - CLIENT: SSLify_GetStatus is done > ok 12 - SERVER: Got callback hook > not ok 13 - SERVER: Status received from callback is OK > # Failed test 'SERVER: Status received from callback is OK' > # at t/connect_hook_nodata.t line 57. > # got: '0' > # expected: '1' > ok 14 - SERVER: SSLify_GetCipher: TLS_AES_256_GCM_SHA384 > not ok 15 - SERVER: SSLify_GetStatus is done > # Failed test 'SERVER: SSLify_GetStatus is done' > # at t/connect_hook_nodata.t line 62. > ok 16 - SERVER: client disconnected > 1..16 > # Looks like you failed 2 tests of 16. > > There are other differences in TLS resulting in SIGPIPE OpenSSL issue > <https://github.com/openssl/openssl/issues/6904#issuecomment- > connection to fast, TLS server will fail in SSL_accept() on EPIPE > error from writing to the server socket descriptor). And this cannot > be masked by Net-SSLeay because Net-SSLeay is a low-level wrapper > exposing bare OpenSSL API. > > After adding some debugging to ServerHandle::_check_status() one can > see it's because the of the same SIGIPE issue: > > $ perl -Ilib t/connect_hook_nodata.t > ok 1 - SERVER: SSLify_Options > ok 2 - SERVER: Server_SSLify > ok 3 - SERVER: SSLify_GetStatus is pending > ok 4 - SERVER: accepted > ok 5 - CLIENT: Client_SSLify > ok 6 - CLIENT: SSLify_GetStatus is pending > ok 7 - CLIENT: connected > not ok 8 - Test::FailWarnings should catch no warnings > # Failed test 'Test::FailWarnings should catch no warnings' > # at lib/POE/Component/SSLify/ServerHandle.pm line 74. > # Warning was '_check_status(): status=-1, errval=2, errno=Resource > temporarily unavailable at lib/POE/Component/SSLify/ServerHandle.pm > line 74.' > ok 9 - CLIENT: Got callback hook > ok 10 - CLIENT: Status received from callback is OK > ok 11 - CLIENT: SSLify_GetCipher: TLS_AES_256_GCM_SHA384 > ok 12 - CLIENT: SSLify_GetStatus is done > not ok 13 - Test::FailWarnings should catch no warnings > # Failed test 'Test::FailWarnings should catch no warnings' > # at lib/POE/Component/SSLify/ServerHandle.pm line 74. > # Warning was '_check_status(): status=-1, errval=5, errno=Broken pipe > at lib/POE/Component/SSLify/ServerHandle.pm line 74.' > ok 14 - SERVER: Got callback hook > not ok 15 - SERVER: Status received from callback is OK > # Failed test 'SERVER: Status received from callback is OK' > # at t/connect_hook_nodata.t line 57. > # got: '0' > # expected: '1' > ok 16 - SERVER: SSLify_GetCipher: TLS_AES_256_GCM_SHA384 > not ok 17 - SERVER: SSLify_GetStatus is done > # Failed test 'SERVER: SSLify_GetStatus is done' > # at t/connect_hook_nodata.t line 62. > ok 18 - SERVER: client disconnected > 1..18 > # Looks like you failed 4 tests of 18. > > As POE-Component-SSLify is a high-level abstraction, I believe this is > the right place for handling the SIGPIPE issue. I believe it can be > fixed by properly shutting down the TLS connection. Although this will > not help if a foreign TLS client does not perform proper TLS shutdown. > But there is not much to do except from pressing OpenSSL developers to > resolve the SIGPIPE issue internally.

> Dne Út 28.srp.2018 08:56:22, ppisar napsal(a): > Attached patch work arounds this issue and the test failure by > disabling session tickets if OpenSSL 1.1.1 is in use. That has a > drawback the clients won't be able to quickly resume a TLS session. > > A proper fix should have done something like this but in a non- > blocking way: > > --- a/lib/POE/Component/SSLify/ServerHandle.pm > +++ b/lib/POE/Component/SSLify/ServerHandle.pm > @@ -219,6 +219,44 @@ sub BINMODE { > sub CLOSE { > my $self = shift; > if ( defined $self->{'socket'} ) { > + if ( $self->{'ssl_started'} ) { > + local $SIG{PIPE} = 'IGNORE'; > + my $retval; > + SHUTDOWN: { > + do { > + $retval = Net::SSLeay::shutdown( $self->{'ssl'} > ); > + if ($retval < 0) { > + my $errval = Net::SSLeay::get_error( $self- > + $retval ); > + if ( $errval == ERROR_WANT_READ or > + $errval == ERROR_WANT_WRITE ) { > + # FIXME: We should retry CLOSE by > returning to POE, > + # but I don't know POE. This code simply > blocks. > + my $rin = my $win = my $ein = ''; > + vec($rin, $self->{'fileno'}, 1) = 1; > + vec($win, $self->{'fileno'}, 1) = 1; > + $ein = $rin | $win; > + print STDERR "WAIT "; > + my $nfound = select(my $rout = $rin, > + my $wout = $win, my $eout = $ein, > undef); > + print STDERR "$nfound\n"; > + if ($nfound <= 0 || vec($eout, $self- > + last; > + } > + # Retry > + $retval = 0; > + } elsif ($retval == 0) { > + # SSL_shutdown() require SSL_read() all > data between > + # first and second SSL_shutdown() > + while (defined Net::SSLeay::read( $self- > + } else { > + # Some error, shutdown failed > + last; > + } > + } > + } while ($retval == 0); > + } > + } > Net::SSLeay::free( $self->{'ssl'} );