| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently three different handshake structs that are in use -
the SSL_HANDSHAKE struct (as S3I(s)->hs), the SSL_HANDSHAKE_TLS13 struct
(as S3I(s)->hs_tls13 or ctx->hs in the TLSv1.3 code) and the infamous
'tmp' embedded in SSL3_STATE_INTERNAL (as S3I(s)->tmp)).
This is the first step towards cleaning up the handshake structs so that
shared data is in the SSL_HANDSHAKE struct, with sub-structs for TLSv1.2
and TLSv1.3 specific information. Place SSL_HANDSHAKE_TLS13 inside
SSL_HANDSHAKE and change ctx->hs to refer to the SSL_HANDSHAKE struct
instead of the SSL_HANDSHAKE_TLS13 struct. This allows the TLSv1.3 code
to access the shared handshake data without needing the SSL struct.
ok inoguchi@ tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
DTLS protocol version numbers are the 1's compliment of human readable TLS
version numbers, which means that newer versions decrease in value and
there is no direct mapping between TLS protocol version numbers and DTLS
protocol version numbers.
Rather than having to deal with this internally, only use TLS versions
internally and map between DTLS and TLS protocol versions when necessary.
Rename functions and variables to use 'tls_version' when they contain a
TLS version (and never a DTLS version).
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In our tls13_* files, we use SSL *s for local variables and SSL *ssl
for function arguments. This is odd, but probably the result of finger
memory. We intended to use ssl everywhere. Be that as it may, all local
variables except in two functions ended up being called s, so align the
two outliers with that. As noted by jsing, this is not ideal either as
in tls13_legacy_servername_process() the ssl_ctx is now inconsistent.
Renaming all s to ssl is a substantial amount of unnecessary churn at a
moment that isn't ideal, so we have to live with that.
ok bcook inoguchi jsing
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
jsing
tb
guenther