summaryrefslogtreecommitdiff
path: root/lib/libssl/ssl_asn1.c
diff options
context:
space:
mode:
authorJoel Sing <jsing@cvs.openbsd.org>2020-05-03 15:57:26 +0000
committerJoel Sing <jsing@cvs.openbsd.org>2020-05-03 15:57:26 +0000
commitc2c636122df9e366095ad1200a7107fa6e57069a (patch)
tree767cb45f9e61568f256a441121929dc2424d6d95 /lib/libssl/ssl_asn1.c
parent6e6d58fc4d2962e92589fbf441dd1ce3e82337f3 (diff)
Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.
In compatibility mode, a TLSv1.3 server MUST send a dummy CCS message immediately after its first handshake message. This is normally after the ServerHello message, but it can be after the HelloRetryRequest message. As such we accept one CCS message from the server during the handshake. However, it turns out that in the HelloRetryRequest case, Facebook's fizz TLSv1.3 stack sends CCS messages after both the HelloRetryRequest message and the ServerHello message. This is unexpected and as far as I'm aware, no other TLSv1.3 implementation does this. Unfortunately the RFC is rather ambiguous here, which probably means it is not strictly an RFC violation. Relax the CCS message handling to allow two dummy CCS messages during a TLSv1.3. This makes our TLSv1.3 client work with Facebook Fizz when HRR is triggered. Issue discovered by inoguchi@ and investigated by tb@. ok deraadt@ tb@
Diffstat (limited to 'lib/libssl/ssl_asn1.c')
0 files changed, 0 insertions, 0 deletions