openbsd/src/lib/libssl, branch OPENBSD_6_7_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_6_7_BASE2020-05-03T15:57:25+00:00Accept two ChangeCipherSpec messages during a TLSv1.3 handshake.2020-05-03T15:57:25+00:00jsing2020-05-03T15:57:25+00:00urn:sha1:c011805d37d80a9f55b2f013aa73f0183dff7d25
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@
Add const to TLS1.3 internal vectors2020-05-02T00:31:54+00:00inoguchi2020-05-02T00:31:54+00:00urn:sha1:2e6d47dd230cf0a1dc61aea57faf78019cf22858
ok tb@
tls13_record_layer internal functions to static in libssl2020-04-29T01:22:28+00:00inoguchi2020-04-29T01:22:28+00:00urn:sha1:cbd0a539eed34c8b6b65717c68d01a47aa9aa314
We might remove static again for further regress around record layer
in the future.
ok jsing@ tb@
tls13_handshake internal functions to static in libssl2020-04-29T01:16:49+00:00inoguchi2020-04-29T01:16:49+00:00urn:sha1:45496e817033f7b731f4e6b1bd4022d97015713d
ok jsing@ tb@
Move legacy stack interfacing functions into tls13_legacy.c.2020-04-28T20:37:22+00:00jsing2020-04-28T20:37:22+00:00urn:sha1:5f2791387a6d20d8b8294b1c9ca4e982c7ae6f7e
No functional change.
ok inoguchi@ tb@
Rename tls13_client_synthetic_handshake_message() and move to tls13_lib.c.2020-04-28T20:30:41+00:00jsing2020-04-28T20:30:41+00:00urn:sha1:d1fef479fc505086d5703546f04121c5c2c8c507
The server-side will need to use the same function.
No functional change.
ok inoguchi@ tb@
Shuffle some functions around.2020-04-27T20:15:17+00:00jsing2020-04-27T20:15:17+00:00urn:sha1:e59cdf2c749347a4acc7576297f18cebeee7d37d
Move functions so that they are in the order that the TLSv1.3 messages are
processed. While here, also move tls13_client_end_of_early_data_send() from
tls13_client.c to tls13_server.c.
No functional change.
ok beck@ tb@
Switch to NEGOTIATED when using WITHOUT_HRR.2020-04-25T18:06:28+00:00jsing2020-04-25T18:06:28+00:00urn:sha1:a7581a822f0bc19b45352503668b6abfc1ca794f
This ensures that we remain in a valid handshake state in the TLSv1.3
server. Ideally we would not switch to NEGOTIATED until after record
protection has been enabled, but we'll revisit this later.
Issue noted by inoguchi@
ok tb@
Move unsupported, obsolete ciphers and deprecated aliases out of2020-04-25T14:03:38+00:00schwarze2020-04-25T14:03:38+00:00urn:sha1:9f387f3e78bf4cb12aeaa458a5fc6a4f255f6874
the main list of words to make it more readable, even though it
remains long.
Avoid using deprecated aliases in explanations what other words mean.
Stop documenting aDSS because it is *both* a deprecated alias *and*
no longer matches anything at all.
General direction discussed with jsing@ some time ago.
tweak the wording to make it clearer under which conditions exactly2020-04-25T13:50:05+00:00schwarze2020-04-25T13:50:05+00:00urn:sha1:d6fa67c92dc4116f4e29bca2c0a205d922a9bac5
the TLSv1.3 cipher suites are made available, too;
related to ssl_ciph.c rev. 1.115