Re: s6-tlsd immediately sending EOF during TLS handshake

2020-02-16 Thread Guillermo
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

2020-02-14 Thread Laurent Bercot

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

2020-02-14 Thread Guillermo
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

2020-02-13 Thread ilaia
> 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

2020-02-13 Thread Laurent Bercot



 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

2020-02-13 Thread Laurent Bercot

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

2020-02-12 Thread ilaia
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

2020-02-12 Thread ilaia
(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

2020-02-11 Thread Laurent Bercot

 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