summaryrefslogtreecommitdiff
path: root/regress
diff options
context:
space:
mode:
authorJoel Sing <jsing@cvs.openbsd.org>2020-10-07 07:46:19 +0000
committerJoel Sing <jsing@cvs.openbsd.org>2020-10-07 07:46:19 +0000
commit57ee20cf62279c53c1d951ac9e1c1bb898a8939e (patch)
treef5497aa3bb82107061c384e6463936507bd8843b /regress
parenta7242fd75318b2230f989b7be6181c221109f60a (diff)
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 'regress')
0 files changed, 0 insertions, 0 deletions