summaryrefslogtreecommitdiff
path: root/src/regress/lib/libssl/tlslegacy/tlslegacytest.c
diff options
context:
space:
mode:
authorjsing <>2020-10-07 07:46:18 +0000
committerjsing <>2020-10-07 07:46:18 +0000
commit42db3438e170653a0dea8617f6b9a9f5f25fd2be (patch)
tree798bca469eaa323240a2e9ea4adae4ba698cf94c /src/regress/lib/libssl/tlslegacy/tlslegacytest.c
parent5da2fd84e6a7a1bc9c1fe0780bdeabf515e71884 (diff)
downloadopenbsd-42db3438e170653a0dea8617f6b9a9f5f25fd2be.tar.gz
openbsd-42db3438e170653a0dea8617f6b9a9f5f25fd2be.tar.bz2
openbsd-42db3438e170653a0dea8617f6b9a9f5f25fd2be.zip
Include a TLS record header when switching to the legacy stack.
When switching to the legacy TLS stack we previously copied any remaining handshake messages into the receive buffer, but do not include any TLS record header (largely due to the fact that we've already processed part of the TLS record that we actually received - that part is placed into the init_buf). This worked fine with the old record layer implementation, however the new record layer expects to find the TLS record header. This means that if we switch from the new stack to the legacy stack (i.e. the remote side does not support TLSv1.3) and there is more than one handshake message in the TLS plaintext record (which Microsoft's TLS stack is known to do), we now read a TLS record of zero bytes instead of getting the correct length. Fix this by generating a pseudo-TLS record header when switching from the new TLS stack to the legacy stack. Found the hard way by guenther@. Thanks to tb@ for coming up with a reproducible test case and doing much of the debugging. ok inoguchi@ tb@
Diffstat (limited to 'src/regress/lib/libssl/tlslegacy/tlslegacytest.c')
0 files changed, 0 insertions, 0 deletions