| Age | Commit message (Collapse) | Author |
|---|
|
Instead of attempting to allocate a few times and only then check all the
returned pointers for NULL, allocate and check one after the othre. This
is easier on the eyes and what we usually do.
Prompted by a report by Ilya Shipitsin
ok beck
|
|
Their time has long since past, and they should not be used.
This change restricts ssl to versions 1.2 and 1.3, and changes
the regression tests to understand we no longer speak the legacy
protocols.
For the moment the magical "golden" byte for byte comparison
tests of raw handshake values are disabled util jsing fixes them.
ok jsing@ tb@
|
|
The existence of the public get_rfc*() API is a historic curiosity that may
soon be corrected. We inherited its use and it survived in libssl until now.
Switch to the better named BN_get_rfc*() wrappers.
ok jsing
|
|
This converts ssl3_{get,send}_server_key_exchange() to EVP_DigestVerify()
and EVP_DigestSign(). In order to do this, build the full signed_params
up front and rework the way the key exchange parameters are constructed.
This way we can do the verify and sign steps in one go and at the same
use a more idiomatic approach with CBB/CBS.
with/ok jsing
|
|
Convert ssl3_send_client_verify_{sigalgs,gost}() to EVP_DigestSign() and
ssl3_get_cert_verify() to EVP_DigestVerify().
ok jsing
|
|
Using one-shot EVP_DigestSign() and EVP_DigestVerify() is slightly shorter
and is needed for Ed25519 support.
ok jsing
|
|
This is a better version of the fix for the missing pointer invalidation
but a bit larger, so errata got the minimal fix.
tested by jcs
ok jsing
|
|
ok tb
|
|
ok jsing (a very long time ago)
|
|
(which they aren't), so appease them.
|
|
Needed for the tlsexttest.c
ok jsing
|
|
|
|
Reported by anton
|
|
Reported by anton
|
|
Aligns tlsext_randomize_build_order() with tlsext_linearize_build_order()
and will help regression testing.
ok jsing
|
|
|
|
On creation of an SSL using SSL_new(), randomize the order in which the
extensions will be sent. There are several constraints: the PSK extension
must always come last. The order cannot be randomized on a per-message
basis as the strict interpretation of the standard chosen in the CH hashing
doesn't allow changing the order between first and second ClientHello.
Another constraint is that the current code calls callbacks directly on
parsing an extension, which means that the order callbacks are called
depends on the order in which the peer sent the extensions. This results
in breaking apache-httpd setups using virtual hosts with full ranomization
because virtual hosts don't work if the SNI is unknown at the time the
ALPN callback is called. So for the time being, we ensure that SNI always
precedes ALPN to avoid issues until this issue is fixed.
This is based on an idea by David Benjamin
https://boringssl-review.googlesource.com/c/boringssl/+/48045
Input & ok jsing
|
|
for the various BIO types.
|
|
|
|
LCRYPTO_ALIAS() and LSSL_ALIAS() contained a trailing semicolon.
This does not conform to style(9), breaks editors and ctags and
(most importantly) my workflow. Fix this by neutering them with
asm("") so that -Wpedantic doesn't complain. There's precedent
in libc's namespace.h
fix suggested by & ok jsing
|
|
one wouldn't have triggered a spell checker though)
|
|
ok tb
|
|
|
|
|
|
|
|
Not all of them, only those that didn't leak into a public header...
Yes.
|
|
Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.
Adjust all .c files in libcrypto, libssl and regress.
The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.
discussed with jsing,
no objection bcook
|
|
We want to copy the tls_content_cbs() into the cbs, not the other way around
CID 377013
ok jsing
|
|
|
|
This converts the legacy TLS stack to tls_content - records are now
opened into a tls_content structure, rather than being written back into
the same buffer that the sealed record was read into.
This will allow for further clean up of the legacy record layer.
ok tb@
|
|
While grouping the API by its purpose is nice, it doesn't help much if >90%
is "general API".
ok jsing
|
|
Fully explained in libcrypto/README. TL;DR make sure libcrypto
and libssl's function calls internally and to each other are via
symbol names that won't get overridden by linking other libraries.
Mostly work by guenther@, which will currently be gated behind a
build setting NAMESPACE=yes. once we convert all the symbols to
this method we will do a major bump and pick up the changes.
ok tb@ jsing@
|
|
This avoids a bunch of pointer munging and a handrolled memmove.
ok tb@
|
|
|
|
Replace the grotty TLSv1.2 key exporter with a cleaner version that uses
CBB and CBS.
ok tb@
|
|
It makes more sense to have tls13_exporter() in tls13_key_schedule.c,
rather than tls13_lib.c
ok tb@
|
|
While ssl3_setup_read_buffer() success alone is enough to imply that
the read bufer is non-NULL, several static analyzers fail to recognize
that and throw fits about possible NULL accesses.
CID 331010
Fix from and ok jsing
|
|
TLSv1.3 introduces a New Session Ticket post-handshake handshake message
that allows a unique association between a ticket value and a pre-shared
key derived from the resumption master secret. Servers may send this
message arbitrarily often at any time after receiving the client's
Finished message.
Implement tls13_new_session_ticket_recv() which parses the contents of
the NewSessionTicket message into a fresh session derived from the
current session so as to avoid modifying sessions that are already in
the session cache.
This uses tls13_new_session_ticket_recv() in tls13_phh_received_cb().
We currently rely on the general rate limiting of 100 PHH messages per
connection and hour to avoid problems from connecting to a misbehaving
or malicious server.
ok jsing
|
|
TLSv1.3 servers must not indicate a lifetime longer than 7 days and
clients must not cache sessions for longer than 7 days. Encode this
in a macro internal to tls13_lib.c for now.
ok jsing
|
|
SSL_SESSION_dup() is a currently essentially unused public OpenSSL 1.1.1
API. Add a version that does not duplicate the secrets for internal use.
If the public API should be needed, we can easily make it a wrapper.
ok jsing
|
|
ok jsing
|
|
Add members necessary to store the "ticket_age_add" value and the
resumption master secret needed in the TLSv1.3 version of session
resumption.
ok jsing
|
|
The session_id member of SSL_SESSION has 32 bytes for historical
reasons. This precisely accommodates a SHA-256 and is currently
computed using this hash. If the hash function is ever changed,
this will likely overflow. This should be fixed in code. Leave
it at an XXX comment for now.
Pointed out by jsing
|
|
Calling HKDF_expand() with a length of 0 happens to succeed due to a quirk
in the API inherited from BoringSSL. This hides caller-side errors during
development. Error out to catch such mistakes early on.
ok jsing
|
|
|
|
These are no longer necessary due to SSL_CTX and SSL now being fully
opaque. Merge SSL_CTX_INTERNAL back into SSL_CTX and SSL_INTERNAL back
into SSL.
Prompted by tb@
|
|
Currently, ssl_both.c contains several functions that are used by both the
legacy client and legacy server. This interwines the client and server,
making it harder to make progressive changes. While it does deduplicate
some code, it also ends up with code that is conditioned on s->server and
forces the caller to pass in SSL3_ST_* values.
Move these functions from ssl_both.c into ssl_clnt.c and ssl_srvr.c,
renaming as appropriate and removing the s->server conditionals. Also move
the client and server function prototypes from ssl_locl.h into the .c
files, making them static in the process.
ok tb@
|
|
While RFC 8446 is clear about what legacy session identifiers can be sent
by a TLSv1.3 client and how middlebox compatibility mode is requested, it
is delightfully vague about the circumstances under which a client is
permitted to send CCS messages. While it does not make sense for a client
to send CCS messages when they are not requesting middlebox compatibility
mode, it is not strictly forbidden by the RFC and at least one (unknown)
TLSv1.3 stack has been observed to do this in the wild.
Revert part of the previous change and allow clients to send CCS messages,
even if they are not requesting middlebox compatibility mode.
Found the hard way by florian@
ok tb@
|
|
OK tb
|
|
ok tb@
|
