- Always process ALPN (previously there was an early return in the
certificate status handling)
- Don't send a duplicate alert. Previously, both
ssl_check_clienthello_tlsext_late and its caller would send an
alert. Consolidate alert sending code in the caller.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the ECDHE aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the DHE aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit. Refactor tls_process_key_exchange() to
split out into a separate function the SRP aspects.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_process_key_exchange() function is too long. This commit starts
the process of splitting it up by moving the PSK preamble code to a
separate function.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The function tls_process_key_exchange() is too long. This commit moves
the PSK preamble processing out to a separate function.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Add some more tests for sessions following on from the previous commit
to ensure the callbacks are called when appropriate.
Reviewed-by: Richard Levitte <levitte@openssl.org>
If the SSL_SESS_CACHE_NO_INTERNAL_STORE cache mode is used then we weren't
removing sessions from the external cache, e.g. if an alert occurs the
session is supposed to be automatically removed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Don't call strncpy with strlen of the source as the length. Don't call
strlen multiple times. Eventually we will want to replace this with a proper
PACKET style handling (but for construction of PACKETs instead of just
reading them as it is now). For now though this is safe because
PSK_MAX_IDENTITY_LEN will always fit into the destination buffer.
This addresses an OCAP Audit issue.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the SRP
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the GOST
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the ECDHE
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing previous commit to break up the
tls_construct_client_key_exchange() function. This splits out the DHE
code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_construct_client_key_exchange() function is too long. This splits
out the construction of the PSK pre-amble into a separate function as well
as the RSA construction.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commits, this splits out the GOST code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commits, this splits out the ECDHE code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Continuing from the previous commit, this splits out the DHE code into
a separate function from the process CKE code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The tls_process_client_key_exchange() function is far too long. This
splits out the PSK preamble processing, and the RSA processing into
separate functions.
Reviewed-by: Richard Levitte <levitte@openssl.org>
In preparation for splitting this function up into smaller functions this
commit reduces the scope of some of the variables to only be in scope for
the algorithm specific parts. In some cases that makes the error handling
more verbose than it needs to be - but we'll clean that up in a later
commit.
Reviewed-by: Richard Levitte <levitte@openssl.org>
This adds a new target 'build_programs' and makes 'build_apps' and
'build_tests' aliases for it, for backward compatibility.
Reviewed-by: Rich Salz <rsalz@openssl.org>
PROGRAM_NO_INST, ENGINES_NO_INST, SCRIPTS_NO_INST and LIBS_NO_INST are
to be used to specify program, engines, scripts and libraries that are
not to be installed in the system. Fuzzers, test programs, that sort
of things are of the _NO_INST type, for example.
For the benefit of build file templates and other templates that use
data from configdata.pm, a new hash table $unified_info{install} is
created. It contains a set of subhashes, one for each type of
installable, each having an array of file names as values. For
example, it can look like this:
"install" =>
{
"engines" =>
[
"engines/afalg/afalg",
"engines/capi",
"engines/dasync",
"engines/padlock",
],
"libraries" =>
[
"libcrypto",
"libssl",
],
"programs" =>
[
"apps/openssl",
],
"scripts" =>
[
"apps/CA.pl",
"apps/tsget",
"tools/c_rehash",
],
},
Reviewed-by: Rich Salz <rsalz@openssl.org>
The logic testing whether a CKE message is allowed or not was a little
difficult to follow. This tries to clean it up.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
The static function key_exchange_expected() used to return -1 on error.
Commit 361a119127 changed that so that it can never fail. This means that
some tidy up can be done to simplify error handling in callers of that
function.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Having received a ClientKeyExchange message instead of a Certificate we
know that we are not going to receive a CertificateVerify message. This
means we can free up the handshake_buffer. However we better call
ssl3_digest_cached_records() instead of just freeing it up, otherwise we
later try and use it anyway and a core dump results. This could happen,
for example, in SSLv3 where we send a CertificateRequest but the client
sends no Certificate message at all. This is valid in SSLv3 (in TLS
clients are required to send an empty Certificate message).
Found using the BoringSSL test suite.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
In TLS if the server sends a CertificateRequest and the client does not
provide one, if the server cannot continue it should send a
HandshakeFailure alert. In SSLv3 the same should happen, but instead we
were sending an UnexpectedMessage alert. This is incorrect - the message
isn't unexpected - it is valid for the client not to send one - its just
that we cannot continue without one.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
