summaryrefslogtreecommitdiff
path: root/src/lib/libc
diff options
context:
space:
mode:
authorjsing <>2022-09-17 17:14:06 +0000
committerjsing <>2022-09-17 17:14:06 +0000
commitd0670f66492b039f0e82fff119d3e75395bf2ddb (patch)
tree3b2719490fff13b2c9a162765cb36e12b1f794be /src/lib/libc
parenta59763ac6d9278c585e3fe8acb0e5338e5b12762 (diff)
downloadopenbsd-d0670f66492b039f0e82fff119d3e75395bf2ddb.tar.gz
openbsd-d0670f66492b039f0e82fff119d3e75395bf2ddb.tar.bz2
openbsd-d0670f66492b039f0e82fff119d3e75395bf2ddb.zip
Allow TLSv1.3 clients to send CCS without middlebox compatibility mode.
While RFC 8446 is clear about what legacy session identifiers can be sent by a TLSv1.3 client and how middlebox compatibility mode is requested, it is delightfully vague about the circumstances under which a client is permitted to send CCS messages. While it does not make sense for a client to send CCS messages when they are not requesting middlebox compatibility mode, it is not strictly forbidden by the RFC and at least one (unknown) TLSv1.3 stack has been observed to do this in the wild. Revert part of the previous change and allow clients to send CCS messages, even if they are not requesting middlebox compatibility mode. Found the hard way by florian@ ok tb@
Diffstat (limited to 'src/lib/libc')
0 files changed, 0 insertions, 0 deletions