summaryrefslogtreecommitdiff
path: root/src/lib/libc/string
diff options
context:
space:
mode:
authorjsing <>2022-09-17 17:14:06 +0000
committerjsing <>2022-09-17 17:14:06 +0000
commit74f7c264c9c7cf9fa2bbccfe73e2d98bf2e07476 (patch)
tree3b2719490fff13b2c9a162765cb36e12b1f794be /src/lib/libc/string
parent70f7b2faa17684b3944dd57095e0993328b1b4a3 (diff)
downloadopenbsd-74f7c264c9c7cf9fa2bbccfe73e2d98bf2e07476.tar.gz
openbsd-74f7c264c9c7cf9fa2bbccfe73e2d98bf2e07476.tar.bz2
openbsd-74f7c264c9c7cf9fa2bbccfe73e2d98bf2e07476.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/string')
0 files changed, 0 insertions, 0 deletions