| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
The write path can return a failure in the AEAD path and there is no reason
not to check a return value.
Spotted by tb@ during another review.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make the DTLS code much more consistent with the ssl3 code.
- Avoid assigning wr->input and wr->length just so they can be used as
arguments to memcpy().
- Remove the arc4random_buf() call for the explicit IV, since tls1_enc()
already does this for us.
ok tb@
|
|
|
|
|
|
| |
ssl3_create_record().
ok tb@
|
|
|
|
|
|
| |
ourselves.
Spotted by tb@ during a previous review.
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow for further changes to be made with less complexity and
easier review.
In particular, decide if we need an empty fragment early on and only do
the alignment calculation once (rather than in two separate parts of the
function.
ok tb@ inoguchi@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both Perl's HTTP::Tiny and IO::Socket::SSL know about SSL_MODE_AUTO_RETRY
and try to work around the fact that OpenSSL enabled it by default.
However, this can lead to the mode being disabled prior to the TLSv1.3
handshake and then enabled after the handshake has completed.
In order to handle this correctly we have to check the mode and inform the
record layer prior to every read.
Issue reported and test case provided by Nathanael Rensen
<nathanael@polymorpheus.com>.
ok inoguchi@ tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
This is no longer necessary since the TLS_method() now supports TLSv1.3.
Reverts r1.211 of ssl_lib.c.
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
| |
ssl_version is completely unused and get_timeout is the same everywhere.
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
| |
This can be done now that we have both TLSv1.3 client and server.
ok beck@ inoguchi@ tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some TLS extensions need to be treated differently depending on the
handshake message they appear in. Over time, various workarounds and
hacks were used to deal with the unavailability of the message type
in these functions, but this is getting fragile and unwieldy. Having
the message type available will enable us to clean this code up and
will allow simple fixes for a number of bugs in our handling of the
status_request extension reported by Michael Forney.
This approach was suggested a while ago by jsing.
ok beck jsing
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
to match the order they are listed in the RFC. No functional change.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When first called, queue and send a close notify, before returning 0 or 1
to indicate if a close notify has already been received from the peer. If
called again only attempt to read a close notify if there is no pending
application data and only read one record from the wire. In particular,
this avoids continuing to read application data where the peer continues
to send application data.
Issue noted by naddy@ with ftp(1).
ok jca@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RFC 8446 section 9.2 imposes some requirements on the extensions sent
in the ClientHello: key_share and supported_groups must either both be
present or both be absent. If no pre_shared_key was sent, the CH must
contain both signature_algorithms and supported_groups. If either of
these conditions is violated, servers must abort the handshake with a
missing_extensions alert. Add a function that enforces this. If we are
going to enforce that clients send an SNI, we can also do this in this
function.
Fixes failing test case in tlsfuzzer's test-tls13-keyshare-omitted.py
ok beck inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
| |
missed a subsequent fix for an off-by-one in that code. If the first
byte of a CBC padding of length 255 is mangled, we don't detect that.
Adam Langley's BoringSSL commit 80842bdb44855dd7f1dde64a3fa9f4e782310fc7
Fixes the failing tlsfuzzer lucky 13 test case.
ok beck inoguchi
|
|
|
|
|
|
| |
how our tree gets built. If this was done in all the libraries (imagine
sys/dev), it would disrupt the development process hugely. So it should
not be done here either. use 'make includes' by hand instead.
|
|
|
|
|
|
|
|
| |
section 4.1.2 to ensure subsequent ClientHello messages after a
HelloRetryRequest messages must be unchanged from the initial
ClientHello.
ok tb@ jsing@
|
|
|
|
|
|
|
|
|
|
|
| |
IANA has allocated numbers for GOST ClientCertificateType. Use them in
addition to private values (left in place for compatibility).
Diff from Dmitry Baryshkov <dbaryshkov@gmail.com>
Sponsored by ROSA Linux
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
GOST R 34.10-94 is an obsolete certificate type, unsupported by
LibreSSL and by the rest of current software, so there is no point in
sending in the CertificateTypes.
Diff from Dmitry Baryshkov <dbaryshkov@gmail.com>
Sponsored by ROSA Linux
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
| |
Add missing case entry for SSL_PKEY_GOST01.
Diff from Dmitry Baryshkov <dbaryshkov@gmail.com>
Sponsored by ROSA Linux
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GOST cipher suites requires that CertVerify signatures be generated in a
special way (see ssl3_send_client_kex_gost(), ssl3_get_cert_verify()).
However, the GOST_SIG_FORMAT_RS_LE flag was not passed in case of TLS 1.2
connections (because they use different code path). Set this flag on
GOST PKEYs.
Diff from Dmitry Baryshkov <dbaryshkov@gmail.com>
Sponsored by ROSA Linux
ok inoguchi@ tb@
|
|
|
|
|
|
| |
tls13_client_select_certificate().
ok inoguchi
|
|
|
|
|
|
| |
This allows clients to use EC certificates.
ok inoguchi, jsing
|
|
|
|
| |
tb@ OKed this part of a larger diff from inoguchi@
|
|
|
|
|
|
| |
which make no sense as pointed out by gcc on sparc64.
ok jsing
|
| |
|
|
|
|
|
|
|
|
| |
own recv function. This simplifies tls13_recod_layer_read_internal()
greatly and makes the phh handling easier to reason about since the
code is no longer glued to the right hand edge of the terminal.
ok jsing
|
|
|
|
|
|
|
|
|
| |
shares. Previously we would fail and just close the pipe.
Fixes the remaining failing test-dhe-rsa-key-exchange-with-bad-messages.py
tests of tlsfuzzer.
ok beck (earlier version) jsing
|
|
|
|
|
|
|
|
|
|
| |
the record layer that don't do I/O themselves. Use this mechanism
to send a record overflow alert for messages that have overlong
plaintext or inner plaintext.
Fixes most of the remaining record-layer-limits failures of tlsfuzzer.
ok jsing
|
|
|
|
|
|
|
| |
Replace the only occurrence of ssl_max_server_version() with a call
to ssl_downgrade_max_version() and remove ssl_max_server_version().
ok beck@ tb@
|
|
|
|
|
|
|
|
|
| |
Previously only the enabled protocol versions were considered, however we
also have to consider the method in use which may be version pinned.
Found the hard way by danj@ with haproxy and force-tlsv12.
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
|
|
|
| |
This allows an EC certificate to be selected and used, if the client
sigalgs would allow it.
With feedback from tb@
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
In this situation we cannot return zero bytes, as that signals EOF. Rather
we need to return TLS13_IO_WANT_POLLIN so tell the caller to call us again,
at which point we'll pull up the next record.
ok tb@
|
|
|
|
|
|
|
|
| |
This makes SNI work correctly with TLSv1.3.
Found the hard way by danj@, gonzalo@ and others.
ok beck@ inoguchi@ tb@
|
|
|
|
| |
ok beck@ inoguchi@ tb@
|
|
|
|
|
| |
remove references to the SSL protocol which is no longer supported
and use .Xr rather than .Fn for functions documented elsewhere
|
|
|
|
| |
Reminded by and ok beck@
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
| |
Correct SNI alerts to differentiate between illegal parameter
and an unknown name.
ok tb@`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In TLSv1.2 and earlier, when an application goes to read application data,
handshake messages may be received instead, when the peer has triggered
renegotation. A similar thing occurs in TLSv1.3 when key updates are
triggered or the server sends new session tickets. Due to the SSL_read()
API there is no way to indicate that we got no application data, instead
after processing the in-band handshake messages it would be normal to
return SSL_ERROR_WANT_READ and have the caller call SSL_read() again.
However, various applications expect SSL_read() to return with either
application data or a fatal error, when used on a blocking socket. These
applications do not play well with TLSv1.3 post-handshake handshake
messages (PHH), as they fail to handle SSL_ERROR_WANT_READ. The same code
is also broken in the case of a TLSv1.2 or older renegotiation, however
these are less likely to be encountered. Such code should set
SSL_MODE_AUTO_RETRY in order to avoid these issues.
Contrary to the naming, SSL_MODE_AUTO_RETRY does not actually retry in
every case - it retries following handshake messages in the application
data stream (i.e. renegotiation and PHH messages). This works around the
unretried SSL_read() on a blocking socket case, however in the case where
poll/select is used with blocking sockets, the retry will likely result
in the read blocking after the handshake messages are processed.
Rather than pushing for broken code to be fixed, OpenSSL decided to enable
SSL_MODE_AUTO_RETRY by default, instead breaking code that does poll or
select on blocking sockets (like s_client and s_server). Unfortunately we
get to follow suit.
ok beck@ inoguchi@ tb@
|
|
|
|
| |
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implies that we're dealing with a HRR in the extension handling code.
Explicitly check that we're in this situation by inspecting the flag in
the handshake context. Add missing error checks and send the appropriate
alerts. The hrr flag needs to be unset after parsing the client hello
retry to avoid breaking the server hello handling. All this is far from
ideal, but better than nothing.
The correct fix would likely be to make the message type available
but that would need to be part of a more extensive rearchitecture of
the extension handling.
Discussed at length with jsing
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the moment that is all we support. fixes an issue where gnuTLS
cares that mistmatching staples come back on the certs in the chain.
This should be fixed correctly later by associating the staple
to the individual certs rather than the ssl, so this is temporary.
running on www@.
ok tb@, "got that's oopy but an interim ok" jsing@
|
|
|
|
|
|
| |
unindent a bunch of code.
Suggested by jsing
|
|
|
|
|
|
| |
Prompted by tb@
ok tb@
|