diff options
| author | jsing <> | 2020-05-03 15:57:25 +0000 |
|---|---|---|
| committer | jsing <> | 2020-05-03 15:57:25 +0000 |
| commit | 7a3a8eb5b74aad740ccb6e2e651923eca93ed061 (patch) | |
| tree | 755d94da4a23dcf730eefb7412abdd7925f3d7a7 /src/regress/lib/libssl/handshake/handshake_table.c | |
| parent | 1d3c89be75bbddb0d38a97088d71b1bb685bacad (diff) | |
| download | openbsd-7a3a8eb5b74aad740ccb6e2e651923eca93ed061.tar.gz openbsd-7a3a8eb5b74aad740ccb6e2e651923eca93ed061.tar.bz2 openbsd-7a3a8eb5b74aad740ccb6e2e651923eca93ed061.zip | |
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 'src/regress/lib/libssl/handshake/handshake_table.c')
0 files changed, 0 insertions, 0 deletions