TLS 1.3: crash with selfserv when attempting to use bypass



2 years ago
2 years ago


(Reporter: kaie, Assigned: ekr)



Firefox Tracking Flags

(Not tracked)




2 years ago
The following experiment was done while testing something else, I don't claim it should work, but it shouldn't crash.

selfserv -d ../server -n localhost.localdomain -e localhost.localdomain-ec -H 1 -p 9955 \
 -w nss -V tls1.3:  -r -r -B

tstclnt -d ../client -n TestUser -h localhost.localdomain -p 9955 -w nss -V tls1.3:

selfserv crashes with the following stack:

SSL: tracing set to 3
29616: SSL3[6931440]: handle client_hello handshake
29616: SSL3[6931440]: handle key_share extension
29616: SSL3[6931440]: Set XXX Pending Cipher Suite to 0xc02b
29616: TLS13[6931440]: handle client_key_share handshake
29616: TLS13[6931440]: begin send server_hello sequence
29616: SSL3[6931440]: send server_hello handshake
29616: SSL3[6931440]: Set XXX Pending Cipher Suite to 0xc02b
29616: SSL3[6931440] SendRecord type: handshake  (22) nIn=116
29616: TLS13[6931440]: protect record of length 116, seq=0x00

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff52e7700 (LWP 29681)]
0x00007ffff76194cb in PK11_CloneContext (old=0x0) at pk11cxt.c:407
407	     newcx = pk11_CreateNewContextInSlot(old->type, old->slot, old->operation,
Missing separate debuginfos, use: dnf debuginfo-install zlib-1.2.8-9.fc23.x86_64
(gdb) bt
#0  0x00007ffff76194cb in PK11_CloneContext (old=0x0) at pk11cxt.c:407
#1  0x00007ffff7bba675 in tls13_ComputeHandshakeHashes (ss=0x7b1c50, hashes=0x7ffff52e3a20) at tls13con.c:1627
#2  0x00007ffff7bb9d82 in tls13_DeriveTrafficKeys (ss=0x7b1c50, spec=0x7fffec0050d0, type=TrafficKeyHandshake) at tls13con.c:1490
#3  0x00007ffff7bba527 in tls13_InitCipherSpec (ss=0x7b1c50, type=TrafficKeyHandshake, install=InstallCipherSpecBoth) at tls13con.c:1588
#4  0x00007ffff7bb835d in tls13_InitializeHandshakeEncryption (ss=0x7b1c50) at tls13con.c:925
#5  0x00007ffff7bb84be in tls13_SendServerHelloSequence (ss=0x7b1c50) at tls13con.c:953
#6  0x00007ffff7bb76cf in tls13_HandleClientHelloPart2 (ss=0x7b1c50, suites=0x7ffff52e3c40, sid=0x7fffec00d1a0) at tls13con.c:654
#7  0x00007ffff7b900d9 in ssl3_HandleClientHello (ss=0x7b1c50, b=0x8ef6c2 '\332' <repeats 199 times>, <incomplete sequence \332>..., length=0) at ssl3con.c:9026
#8  0x00007ffff7b9791b in ssl3_HandleHandshakeMessage (ss=0x7b1c50, b=0x8ef5f4 "\003\004'\310\334\336 \330\304\341\017\357W\036A+0p<#5jy\260\264\320gC\245\n\257\v~\226", length=206, endOfRecord=1) at ssl3con.c:12452
#9  0x00007ffff7b980a2 in ssl3_HandleHandshake (ss=0x7b1c50, origBuf=0x7b1e88) at ssl3con.c:12648
#10 0x00007ffff7b99662 in ssl3_HandleRecord (ss=0x7b1c50, cText=0x7ffff52e3ef0, databuf=0x7b1e88) at ssl3con.c:13338
#11 0x00007ffff7b9b938 in ssl3_GatherCompleteHandshake (ss=0x7b1c50, flags=0) at ssl3gthr.c:480
#12 0x00007ffff7b9c5b7 in ssl_GatherRecord1stHandshake (ss=0x7b1c50) at sslcon.c:81
#13 0x00007ffff7ba4f8f in ssl_Do1stHandshake (ss=0x7b1c50) at sslsecur.c:70
#14 0x00007ffff7ba6e95 in ssl_SecureRecv (ss=0x7b1c50, buf=0x7ffff52e4370 "", len=10239, flags=0) at sslsecur.c:845
#15 0x00007ffff7ba6f62 in ssl_SecureRead (ss=0x7b1c50, buf=0x7ffff52e4370 "", len=10239) at sslsecur.c:865
#16 0x00007ffff7bb0b42 in ssl_Read (fd=0x69c3f0, buf=0x7ffff52e4370, len=10239) at sslsock.c:2537
#17 0x00007ffff6d593c1 in PR_Read (fd=0x69c3f0, buf=0x7ffff52e4370, amount=10239) at ../../../../pr/src/io/priometh.c:109
#18 0x0000000000407abe in handle_connection (tcp_sock=0x69c3f0, model_sock=0x620fb0, requestCert=2) at selfserv.c:1355
#19 0x0000000000406a74 in jobLoop (a=0x0, b=0x0, c=2) at selfserv.c:638
#20 0x0000000000406922 in thread_wrapper (arg=0x683830) at selfserv.c:607
#21 0x00007ffff6d806c6 in _pt_root (arg=0x688d10) at ../../../../pr/src/pthreads/ptthread.c:216
#22 0x00007ffff6b3460a in start_thread () from /lib64/
#23 0x00007ffff666a59d in clone () from /lib64/

Comment 1

2 years ago
The crash might be triggered by my base patch.

Comment 2

2 years ago
(In reply to Kai Engert (:kaie) from comment #1)
> The crash might be triggered by my base patch.

no, it happens with current trunk, too.

Comment 3

2 years ago
As noted in a separate bug. TLS 1.3 and bypass are incompatible and expected to remain so.

I think what I'll do here is return an error when you try to enable TLS 1.3 and have bypass on and vice versa. Objections?

Comment 4

2 years ago
(In reply to Eric Rescorla (:ekr) from comment #3)
> I think what I'll do here is return an error when you try to enable TLS 1.3
> and have bypass on and vice versa. Objections?

Sounds good. We should check how tstclnt/selfserv behave after your change, when used with -B -V tls1.3: to ensure they cleanly exit (with a failure error code, but not crash).
Will be "fixed" by bug 1303224.
Depends on: 1303224
Last Resolved: 2 years ago
Resolution: --- → FIXED
Version: 3.25 → 3.28
You need to log in before you can comment on or make changes to this bug.