Control: clone -1 -2 Control: reassign -2 libio-socket-ssl-perl 2.060-3 Control: retitle -2 libio-socket-ssl-perl: TLSv1.3 connection deadlock
On Tue, Nov 13, 2018 at 12:10:12AM +0200, Niko Tyni wrote: > FWIW this smells to me most likely a bug in IO::Socket::SSL TLSv1.3 > support but I haven't managed to get a minimal example together with > just that module. > > Cloning a separate issue for libio-socket-ssl-perl and patching the > libhttp-daemon-ssl-perl test suite to use TLSv1.2 for now would seem > like an appropriate action to me, assuming my analysis is correct and > it's just a problem of the test client. Would be nice to have some other > eyeballs on that though (hi Dam, hope you don't mind the Cc :) Cloning now despite the lack of eyeballs. Will upload a workaround in libhttp-daemon-ssl-perl shortly that forces the use of TLSv1.2 for the test. Leaving the clone at RC severity as this is clearly a serious issue somewhere. Reiterating a bit: the underlying issue with TLSv1.3 seems to be related to handling of 'non-application_data_records'. The client tries to POST but gets an 'SSL wants a read first' error, then waits until timeout for the socket to become writable. A simple way to reproduce it here is perl -MLWP::UserAgent -e 'LWP::UserAgent->new->post("https://facebook.com", { data => "foo" }) or die' which deadlocks for me. TLSv1.2 works OK: perl -MLWP::UserAgent -le 'print LWP::UserAgent->new(ssl_opts => { SSL_version => "TLSv1_2"})->post("https://facebook.com", { data => "foo" })->message or die' Moved Permanently IO::Socket::SSL seems the most likely culprint though I guess the bug could be elsewhere too... -- Niko