| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When switching to the legacy TLS stack we previously copied any remaining
handshake messages into the receive buffer, but do not include any TLS
record header (largely due to the fact that we've already processed part
of the TLS record that we actually received - that part is placed into the
init_buf). This worked fine with the old record layer implementation,
however the new record layer expects to find the TLS record header.
This means that if we switch from the new stack to the legacy stack (i.e.
the remote side does not support TLSv1.3) and there is more than one
handshake message in the TLS plaintext record (which Microsoft's TLS
stack is known to do), we now read a TLS record of zero bytes instead of
getting the correct length.
Fix this by generating a pseudo-TLS record header when switching from the
new TLS stack to the legacy stack.
Found the hard way by guenther@.
Thanks to tb@ for coming up with a reproducible test case and doing much
of the debugging.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When BIO returns a failure, it does not always add an error to the error
stack. In the case of the legacy stack, this was generally handled by the
guesswork performed by SSL_get_error(). However, in the case of the new
stack we push an 'unknown' error onto the stack.
Improve this situation by specifically checking errno in the case of a
BIO_read() or BIO_write() failure. If the error stack is empty then push
a SYSerror() with the errno which is preferable to the 'unknown' error
later.
Noted by bluhm@ via syslogd regress.
ok beck@ tb@
|
|
|
|
|
|
| |
ourselves.
Spotted by tb@ during a previous review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
| |
This makes SNI work correctly with TLSv1.3.
Found the hard way by danj@, gonzalo@ and others.
ok beck@ inoguchi@ tb@
|
|
|
|
|
|
| |
This was missed in previous tls13_server.c commit.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
ok beck@
|
|
|
|
|
|
|
|
| |
Rather than using a mess of SSL_AL_*, SSL_AD_*, SSL3_AD_* and TLS1_AD_*
defines, provide our own TLS13_ALERT_* defines and use those. This also
provides the alerts that are new to TLSv1.3.
ok beck@
|
|
|
|
|
|
| |
No functional change.
ok inoguchi@ tb@
|
|
|
|
|
|
|
| |
The enc function pointers do not serve any purpose these days - remove
a layer of indirection and call dtls1_enc()/tls1_enc() directly.
ok inoguchi@ tb@
|
|
separate file.
Discussed with beck@ and tb@
|