openbsd/src/lib/libssl/tls13_internal.h, branch OPENBSD_6_8_BASEA mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_6_8_BASE2020-07-30T16:23:17+00:00Add minimal info callback support for TLSv1.32020-07-30T16:23:17+00:00tb2020-07-30T16:23:17+00:00urn:sha1:d72120f6c7c798dbddfd43101f7adba6a8f598e0
As abieber@ found the hard way, some python frameworks (twisted, synapse)
thought it a great idea to use the info callback mechanism (designed to
get state information about SSL objects) to modify state information such
as setting and verifying the SNI. The switch of TLS_method() to default
to TLSv1.3 broke these contraptions. Further bits of the info callback
mechanism will likely metastasize throughout the TLSv1.3 stack if we
need them, so we only do what's really necessary now.
Lots of debugging, crucial hint and testing by abieber
input & ok jsing
Improve argument order for the internal tlsext API2020-07-03T04:12:51+00:00tb2020-07-03T04:12:51+00:00urn:sha1:3634005e8a2051a239211f692a45371c14e9d8e4
Move is_server and msg_type right after the SSL object so that CBS
and CBB and alert come last. This brings these functions more in
line with other internal functions and separates state from data.
requested by jsing
Implement a rolling hash of the ClientHello message, Enforce RFC 84462020-06-06T01:40:09+00:00beck2020-06-06T01:40:09+00:00urn:sha1:2d835ca8318d9ce502e9fd2dced3ef440decb39d
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.
ok tb@ jsing@
Wire up the servername callback in the TLSv1.3 server.2020-05-29T17:47:30+00:00jsing2020-05-29T17:47:30+00:00urn:sha1:e0e84f310956950abc8c5d9f225578b3f6945ee9
This makes SNI work correctly with TLSv1.3.
Found the hard way by danj@, gonzalo@ and others.
ok beck@ inoguchi@ tb@
Provide the option to retry or return after post-handshake messages.2020-05-23T11:57:41+00:00jsing2020-05-23T11:57:41+00:00urn:sha1:f86aed14e0c6aa8ca6801c96a09053919b85137e
In TLSv1.3 post-handshake handshake messages are used for key updates and
session tickets. These are in-band and mean that when the upper layer goes
to read application data, we can end up reading and having to process
handshake messages - this option changes whether we retry and read the
next TLS record, or if we return, signalling that we want more data to
be available.
ok beck@ inoguchi@ tb@
Add support for TLS 1.3 server to send certificate status2020-05-19T01:30:34+00:00beck2020-05-19T01:30:34+00:00urn:sha1:e91cca87b14fd6699247757d10bb6df50becf339
messages with oscp staples.
ok jsing@ tb@
Add TLS13_ERR_NO_CERTIFICATE.2020-05-16T14:42:35+00:00jsing2020-05-16T14:42:35+00:00urn:sha1:cd9161dab16deafb0bbe1178eda3d8e5f8a513e4
This was missed in previous tls13_server.c commit.
ok inoguchi@ tb@
Propagate record overflows to the record layer and alert.2020-05-11T18:08:11+00:00jsing2020-05-11T18:08:11+00:00urn:sha1:825052ed723796f9d6cc959761e2a71a4fc8c2bf
ok beck@ tb@
Add record version checks.2020-05-11T18:03:51+00:00jsing2020-05-11T18:03:51+00:00urn:sha1:2772717a6cb57ab7aae538ace180ab5b2886cb99
When legacy version is below TLSv1.2 ensure that the record version is
SSL3/TLS, however when the legacy version is set to TLSv1.2 require this
specifically.
ok beck@ tb@
Provide an alert sent record layer callback.2020-05-11T17:46:46+00:00jsing2020-05-11T17:46:46+00:00urn:sha1:b7219fe30ee8ebb60e558faa30efe4806616d3a0
Use this to push an error on to the SSL error stack so that we report the
details of the alert that we sent, rather than failing with an unknown
error.
ok tb@