| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TLSv1.3 code that drives a BIO currently checks BIO_should_read()
after BIO_write() and BIO_should_write() after BIO_read(), which was
modelled on SSL_get_error(). However, there are certain cases where
this can confuse the caller - primarily where the same BIO is being
used for both read and write and the caller is manipulating the retry
flags. SSL_get_error() tends avoids this issue by relying on another
layer of state tracking.
Unfortunately haproxy hits this situation - it has its own BIO_METHOD,
the same BIO is used for both read and write and it manipulates the
retry flags - resulting in it stalling.
Issued noted by Thorsten Lockert <tholo@tzecmaun.org>
ok beck@ tb@
|
| |
|
|
|
|
|
| |
with #defines for the per-version initializers instead of extern
globals. Add SSL_USE_SHA256_PRF() to complete the abstraction.
ok tb@ jsing@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When transitioning from the TLSv1.3 stack to the legacy stack, grow
init_buf before stashing the handshake message. The TLSv1.3 stack has
already received the handshake message (potentially from multiple TLS
records) and validated its size, however the default allocation is only
for a single plaintext record, which can result in the handshake message
failing to fit in certain cases.
Issue noted by tb@ via tlsfuzzer.
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, OpenSSL has had client and server specific methods - the only
difference between these is that the .ssl_connect or .ssl_accept function
pointer is set to ssl_undefined_function, with the intention of reducing
code size for a statically linked binary that was only a client or server.
These days the difference is minimal or non-existant in many cases and
we can reduce the amount of code and complexity by having single method.
Internally remove all of the client and server specific methods,
simplifying code in the process. The external client/server specific API
remain, however these now return the same thing as TLS_method() does.
ok tb@
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
