Re: s6-tlsd immediately sending EOF during TLS handshake
El vie., 14 feb. 2020 a las 22:59, Laurent Bercot escribió: > > Indeed, the client's error message indicates that the handshake did > not complete. But in that case, that would mean the error is in > libtls, not s6-tlsd. If this turns out to be a bug in LibreSSL triggered by the OP's particular certificate and key, it will be hard to debug. It could be worth trying to obtain a backtrace with GDB. s6-networking and skalibs would have to be rebuilt with debugging symbols (CFLAGS=-ggdb ./configure $configure-arguments), and debugging symbols for LibreSSL would also have to be installed, which apparently is possible on Void: * https://docs.voidlinux.org/xbps/repositories/official/debug.html Then I'd try launching s6-tlsserver with: $(which export) CERTFILE /etc/letsencrypt/live/$REDACTED/fullchain.pem \ $(which export) KEYFILE /etc/letsencrypt/live/$REDACTED/privkey.pem \ s6-tcpserver 0.0.0.0 443 ./script where 'script' is: #!/bin/execlineb -P # Possibly drop privileges with s6-setuidgid getpid PID importas -u PID PID background -d { redirfd -w 1 gdb-output.txt gdb -batch -ex continue -ex bt s6-tlsd $PID } s6-tlsd exit 0 This should hopefully attach the s6-tlsd process to GDB in batch mode, and when the s6-tlsclient invocation makes it segfault, create a backtrace in file gdb-output.txt. I don't have s6-networking, but this works for me when used with s6-ipcserver and a test program that raises SIGSEGV on purpose: $ cat test-program.c #include #include void do_it_for_real () { sleep(5); raise(SIGSEGV); } void do_it () { do_it_for_real(); } int main () { do_it(); return 0; } $ s6-ipcserver -v socket ./script & s6-ipcserverd: info: starting s6-ipcserverd: info: status: 0/40 $ s6-ipcclient socket exit 0 s6-ipcserverd: info: allow 1000:1000 pid 556 count 1/40 s6-ipcserverd: info: status: 1/40 s6-ipcserverd: info: end pid 556 uid 1000 signal 11 s6-ipcserverd: info: status: 0/40 $ cat gdb-output.txt 0x7fe21b52f3a8 in nanosleep () from /lib64/libc.so.6 Program received signal SIGSEGV, Segmentation fault. 0x7fe21b498ec1 in raise () from /lib64/libc.so.6 #0 0x7fe21b498ec1 in raise () from /lib64/libc.so.6 #1 0x56114282316d in do_it_for_real () at test-program.c:6 #2 0x56114282317e in do_it () at test-program.c:10 #3 0x56114282318f in main () at test-program.c:14 [Inferior 1 (process 556) detached] Hope that helps, G.
Re: s6-tlsd immediately sending EOF during TLS handshake
Do you think that the handshake completes? I'm not sure that execution is even reaching the stls_run() call; the segfault could have happened during the tls_handshake() call in stls_s6tlsd() (i.e. while executing LibreSSL code), and the tls_handshake() call in stls_s6tlsc() would report a failed handshake accordingly. Indeed, the client's error message indicates that the handshake did not complete. But in that case, that would mean the error is in libtls, not s6-tlsd. I really am not sure how to debug this, since I cannot reproduce it under the same conditions (x86_64, Linux, musl, libressl 3.0.2, statically linked s6-tlsd). It may be something broken in the Void packaging of libressl. Ilaia, can you test with a manually built libressl instead of the version provided by Void? (No particular configure options.) -- Laurent
Re: s6-tlsd immediately sending EOF during TLS handshake
El jue., 13 feb. 2020 a las 6:50, Laurent Bercot escribió: > > >So I guess that means there is either a bug in LibreSSL (oh no), or in > >s6-networking's LibreSSL code? > > Probably the latter; given your trace, it seems to be the tunnel code > not handling it correctly when it receives a EOF just after the > handshake. Do you think that the handshake completes? I'm not sure that execution is even reaching the stls_run() call; the segfault could have happened during the tls_handshake() call in stls_s6tlsd() (i.e. while executing LibreSSL code), and the tls_handshake() call in stls_s6tlsc() would report a failed handshake accordingly. G.
Re: s6-tlsd immediately sending EOF during TLS handshake
> Could you please try with the latest gits and see if you still > experience the crash? Unfortunately, LibreSSL is still crashing for me with the latest gits, and in the exact same way. I have an strace on hand if you want, though I don't know if that might reveal very much: https://privatebin.net/?3babca3a786afef5#Lz5jGZQ4ueNhS81D9E2EhH4mJTerhP782ytXLy9Y6eh —ilaia
Re: s6-tlsd immediately sending EOF during TLS handshake
I am unable to reproduce the problem on x86_64 with LibreSSL 3.0.2 and the latest git heads of the skarnet.org software stack. I haven't tried with the latest stable releases (the next ones are due soon). Could you please try with the latest gits and see if you still experience the crash? Thanks, -- Laurent
Re: s6-tlsd immediately sending EOF during TLS handshake
So I guess that means there is either a bug in LibreSSL (oh no), or in s6-networking's LibreSSL code? Probably the latter; given your trace, it seems to be the tunnel code not handling it correctly when it receives a EOF just after the handshake. I don't have time to debug it right now, but I will take a look this week-end at worst. -- Laurent
Re: s6-tlsd immediately sending EOF during TLS handshake
Update: just to try it, I rebuilt the current release of s6-networking against BearSSL, and things are working perfectly… So I guess that means there is either a bug in LibreSSL (oh no), or in s6-networking's LibreSSL code? —ilaia
Re: s6-tlsd immediately sending EOF during TLS handshake
(Apologies, I accidentally replied directly to Laurent instead of the mailing list, and only just noticed.) > Did you build s6-networking against bearssl or libressl, and which > version are you using? Sorry, should have mentioned that. libressl, v3.0.2, as provided by Void Linux > Can you please do a "strace -vf -s 256" of your command line, and > pastebin it somewhere? that would help pinpoint where the segfault is > happening and what led to it. Thanks! https://privatebin.net/?7bfc69985ca1ec4c#Dt4ejFDtxEMrsd4AJaRXSCvVEC3u1AxKqKYABYZ7uxrS (Oh, also: > On an unrelated note, your server command line should end with something > like "cat" instead of "exit 0" if you want to test that it echoes what > the client is sending. :) (I appreciate the comment, but I was *specifically* just looking for what happened during the handshake, so I wasn't really concerned about what the forked-off program was doing.) —ilaia
Re: s6-tlsd immediately sending EOF during TLS handshake
s6-tcpserver4d: info: end pid 29407 ip [redacted] signal 11 "signal 11" is a segfault, so you may have found a bug in s6-tlsd, but I haven't managed to reproduce it. Did you build s6-networking against bearssl or libressl, and which version are you using? Can you please do a "strace -vf -s 256" of your command line, and pastebin it somewhere? that would help pinpoint where the segfault is happening and what led to it. Thanks! On an unrelated note, your server command line should end with something like "cat" instead of "exit 0" if you want to test that it echoes what the client is sending. :) -- Laurent