| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
These are currently guarded by LIBRESSL_HAS_DTLS1_2 and LIBRESSL_INTERNAL.
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
|
| |
Per RFC 6347 section 4.2.1, the HelloVerifyRequest should always contain
DTLSv1.0 - ensure this is the case on the server side, allow both DTLSv1.0
and DTLSv1.2 on the client.
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
| |
These are currently guarded by LIBRESSL_HAS_DTLS1_2 and LIBRESSL_INTERNAL.
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
| |
ECC and OCSP can be used with DTLS, so remove bogus checks that currently
prevent it. These are long lasting remnants from the original OpenSSL code.
ok tb@
|
|
|
|
|
|
|
| |
DTLS is largely broken/useless without read ahead being enabled, so enforce
it for DTLS. This behaviour matches both our documentation and OpenSSL.
ok tb@
|
|
|
|
|
|
|
| |
Replace the current copy of dtls1_retrieve_buffered_record() with a call
to it instead.
ok tb@
|
|
|
|
|
|
|
|
| |
The mess that is ssl_get_algorithm2() only exists to upgrade the handshake
MAC of a pre-TLSv1.2 cipher suite to SHA256 when used with TLSv1.2. We can
readily do this in ssl_get_handshake_evp_md(), which is far more readable.
ok tb@
|
|
|
|
|
|
|
|
| |
For some reason various TLSv1.2 cipher suites were added with the default
handshake MAC and PRF, rather than the SHA256 handshake MAC and PRF. This
gets patched up in ssl3_get_algorithm2(), hence goes unnoticed.
ok tb@
|
|
|
|
|
|
|
| |
Also check for explicit version numbers, rather than just the major version
value.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
The exporter depends on having a master secret. If the handshake is
not completed, it is neither guaranteed that a shared ciphersuite was
selected (in which case tls1_PRF() will currently NULL deref) or that
a master secret was set up (in which case the exporter will succeed
with a predictable value). Neither outcome is desirable, so error out
early instead of entering the sausage factory unprepared. This aligns
the legacy exporter with the TLSv1.3 exporter in that regard.
with/ok jsing
|
| |
|
|
|
|
|
|
| |
Now that AEAD is handled internally, we should no longer be assigning
aead_ctx directly, as this will result in a leak. Missed during the
previous change.
|
|
|
|
| |
ok tb@
|
| |
|
|
|
|
| |
ok beck
|
|
|
|
|
|
| |
add HISTORY section. This is currently ignored input next to
SSL_get0_peername() and will be unignored once the symbols are
made publicly visible in libssl.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Yet another one of these X509_VERIFY_PARAM reacharounds into
libcrypto. Recently found in imapfilter, also used elsewhere.
Will be made publicly visible with the next minor bump.
ok jsing
|
|
|
|
|
|
|
| |
This allows for all of the DTLS sequence number save/restore code to be
removed.
ok inoguchi@ "whee!" tb@
|
| |
|
|
|
|
|
|
|
| |
eiv_len was changed from an int to a size_t in r1.10, so casting it
to a size_t is now a noop.
ok jsing
|
|
|
|
|
|
|
|
|
|
| |
This provides the basic framework for handling change of cipher state in
the new TLSv1.2 record layer, creating new record protection. In the DTLS
case we retain the previous write record protection and can switch back to
it when retransmitting. This will allow the record layer to start owning
sequence numbers and encryption/decryption state.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
| |
Call these functions from code that needs to know if we've changed cipher
state and enabled record protection, rather than inconsistently checking
various pointers from other places in the code base. This also fixes a
minor bug where the wrong pointers are checked if we're operating with
AEAD.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
Rather than manually calculating the maximum record layer overhead in the
DTLS code, have the record layer provide this information. This also makes
it work correctly with AEAD ciphersuites.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
Pull this code up into the record protection struct, which means we only
need the length checks in one place. This code will soon be used for
additional purposes.
ok inoguchi@ tb@
|
|
|
|
|
|
| |
Inline/remove some variables and use sizeof with the correct variables.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
| |
Pass the explicit DTLS read sequence number to dtls1_record_bitmap_update()
and dtls1_record_replay_check(), rather than expecting it to be in
S3I(s)->read_sequence. Also, store the read sequence number into
S3I(s)->rrec.seq_num when we're processing the record header, rather than
having dtls1_record_replay_check() be responsible for copying it.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
| |
Handle protocol specific (DTLS vs TLS) sequence number differences in the
open/seal record functions and propagate the sequence number through to
the called functions. This means that DTLS specific knowledge is limited
to two functions and also avoids building sequence numbers multiple times
over. As a result, the DTLS explicit sequence number is now extracted from
the record header and passed through for processing, which makes the read
epoch handling redundant.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When changing cipher state, DTLS requires that the previous write
protection state remain available so that messages can be retransmitted.
Currently, this is done by DTLS saving and restoring various pointers,
along with special casing to not free the cipher and hash where it would
normally be freed for TLS (and requiring DTLS to free things at the
appropriate times).
This can be handled in a much cleaner manner by splitting the record
protection from the record layer. This allows for the previous write state
to be retained and restored by swapping a single pointer. Additionally,
it also results in more readable and manageable code.
This diff simply splits the record protection from the record layer -
future changes will add support for maintaining and switching between
write states.
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From schwarze, who explains:
* Even though i wrote the original version of our documentation
for this function, i now think the design of this function is so
atrocious that it is better to call out the main limitations
up front (server side only and silent truncation) rather than
first giving the impression that it achieves something it
actually doesn't and then later try to row back in a piece-meal
manner.
* Using a .Bl list for failure conditions in the RETURN VALUES
section is no doubt unusual, but the conditions are so numerous
and some of them are so surprising that i think it makes sense
in this case. If a function is badly designed and has surprising
properties, precision and clarity in the description are even
more important than usual, and conciseness is better sacrificed.
* Adding .Xr SSL_get_ciphers 3 seems helpful.
ok beck inoguchi jsing tb
|
|
|
|
|
|
|
|
|
| |
As reported by Steffen Ullrich and bluhm, since enabling TLSv1.3 server
some tests fail in t/local/07_sslecho.c of security/p5-Net-SSLeay due
to missing support for SSL_get_shared_ciphers(). This fixes the parts
related to shared ciphers.
ok beck inoguchi jsing
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SSL_get_shared_ciphers() has been quite broken forever (see BUGS).
What's maybe even worse than those bugs is that it only ever returned
the string representing the client's ciphers which happen to fit into
buf. That's kind of odd, given its name.
This commit brings it in line with OpenSSL's version which changed
behavior almost three years ago.
reviewed and stupid bug caught by schwarze
ok beck inoguchi jsing
commit a216df599a6076147c27acea6c976fb11f505b1a
Author: Matt Caswell <matt@openssl.org>
Date: Fri Apr 27 11:20:52 2018 +0100
Fix SSL_get_shared_ciphers()
The function SSL_get_shared_ciphers() is supposed to return
ciphers shared by the client and the server. However it only
ever returned the client ciphers.
Fixes #5317
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6113)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is not an issue currently, but avoids future surprises.
Noted by tb@
|
|
|
|
| |
ok inoguchi@ tb@
|
|
|
|
|
|
|
|
| |
This trades an array on the stack for a dynamically allocated secret in
tls13_{client,server}_finished_send() but has the benefit of wiping out
an intermediate secret on function exit.
ok jsing
|
|
|
|
| |
suggested by jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
| |
ok jsing
|
|
|
|
|
|
|
|
| |
These are two functions that will help streamlining various functions
in the TLSv1.3 code that do not need to know about the interna of this
struct.
input/ok jsing
|
|
|
|
|
|
|
|
|
| |
In tls13_{client,server}_finished_recv() we use verify_data_len, which
makes more sense than hmac_len. Use the same name in
tls13_{client,server}_finished_send(), keeping things consistent between
functions.
ok tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new verifier builds all chains, starting with the shortest possible
path. It also does not currently return partial chains. Both of these
things conflict with auto chain, where we want to build the longest
possible chain (to include all intermediates, and probably the root
unnecessarily), as well as using an incomplete chain when a trusted chain
is not known.
Depending on software configuration, we can end up building a chain
consisting only of a leaf certificate, rather than a longer chain. This
results in auto chain not including intermediates, which is undesireable.
For now, switch auto chain building to use the legacy verifier.
This should resolve the issues encountered by ajacoutot@ with sendmail.
ok tb@
|
| |
|