Hi, On Sat, Mar 06, 2021 at 09:56:36PM +0100, Antonio Quartulli wrote: > On 05/03/2021 15:13, Arne Schwabe wrote: > > This moves from using our own copy of the TLS1 PRF function to using > > TLS library provided function where possible. This includes currently > > OpenSSL 1.1.0+ and mbed TLS 2.18+. [..] > It looks good and passes my basic tests. > > Acked-by: Antonio Quartulli <anto...@openvpn.net>
ACKs are good, but SIGSEGV are bad.
This crashes for me on the "--tls-client, but no --client" test case,
with "Linux, mbed TLS 2.25.0" (talking to a server with the same code,
"3338f2d5a2b7 + this patch"
run openvpn --ca /home/gert/src/openvpn.git-keys/ca.crt --cert
/home/gert/src/openvpn.git-keys/cron2-gentoo-i386.crt --key
/home/gert/src/openvpn.git-keys/cron2-gentoo-i386.key --remote-cert-tls
server --nobind --comp-lzo --verb 3
--tls-client --dev tap --proto tcp-client --remote
gentoo.ov.greenie.net 51204 --ifconfig 10.204.9.2 255.255.255.0 --comp-lzo
--tun-ipv6 --ifconfig-ipv6 fd00:abcd:204:9::2/64 fd00:abcd:204:9::1 --route
10.204.0.0 255.255.0.0 10.204.9.1 --route-ipv6 fd00:abcd:204::/48
Segmentation fault
GDB tells me:
...
2021-03-07 19:27:15 ++ Certificate has EKU (str) TLS Web Server Authentication,
expects TLS Web Server Authentication
2021-03-07 19:27:15 VERIFY EKU OK
2021-03-07 19:27:15 VERIFY OK: depth=0, C=US, ST=California, L=Pleasanton,
O=OpenVPN community project, CN=server, emailAddress=sam...@openvpn.net
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7f34ef8 in ?? () from /usr/lib64/libmbedtls.so.13
(gdb) where
#0 0x00007ffff7f34ef8 in ?? () from /usr/lib64/libmbedtls.so.13
#1 0x00007ffff7f35945 in ?? () from /usr/lib64/libmbedtls.so.13
#2 0x00007ffff7f37234 in ?? () from /usr/lib64/libmbedtls.so.13
#3 0x00007ffff7f3a727 in mbedtls_ssl_handshake_client_step () from
/usr/lib64/libmbedtls.so.13
#4 0x00007ffff7f4c12d in mbedtls_ssl_handshake_step () from
/usr/lib64/libmbedtls.so.13
#5 0x00007ffff7f4c1b8 in mbedtls_ssl_handshake () from
/usr/lib64/libmbedtls.so.13
#6 0x00007ffff7f429b8 in mbedtls_ssl_read () from /usr/lib64/libmbedtls.so.13
#7 0x00005555555d0c38 in key_state_read_plaintext (ks=ks@entry=0x555555627d00,
buf=buf@entry=0x555555627eb0, maxlen=maxlen@entry=2048) at
../../../openvpn/src/openvpn/buffer.h:231
#8 0x00005555555c9a38 in tls_process (wakeup=0x7fffffffd8b4,
to_link_socket_info=<optimized out>,
to_link_addr=0x7fffffffd7c8, to_link=<optimized out>, session=<optimized
out>, multi=0x555555627720)
at ../../../openvpn/src/openvpn/ssl.c:2806
#9 tls_multi_process (multi=0x555555627720,
to_link=to_link@entry=0x7fffffffe6d0,
to_link_addr=to_link_addr@entry=0x7fffffffe3c0,
to_link_socket_info=<optimized out>,
wakeup=wakeup@entry=0x7fffffffd8d4) at
../../../openvpn/src/openvpn/ssl.c:3009
#10 0x000055555556c593 in check_tls (c=c@entry=0x7fffffffd910) at
../../../openvpn/src/openvpn/forward.c:148
#11 0x000055555556fc68 in pre_select (c=c@entry=0x7fffffffd910)
at ../../../openvpn/src/openvpn/forward.c:1837
#12 0x000055555559375e in tunnel_point_to_point (c=0x7fffffffd910)
at ../../../openvpn/src/openvpn/openvpn.c:79
#13 openvpn_main (argc=35, argv=0x7fffffffe998) at
../../../openvpn/src/openvpn/openvpn.c:283
It passes the test same case (same OS, same build tree) for OpenSSL 1.1.1j
and also for FreeBSD/OpenSSL 1.0.2u and FreeBSD/mbed TLS 2.16.9.
As the commit message talks about "mbed TLS 2.18+", it seems that code
gets irked by --tls-client/p2p.
I do not understand these code paths enough to do further educated guesses,
but we can't merge it like that.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
