IF OPENSSL_init_ssl() is called with the option flag
OPENSSL_INIT_LOAD_CONFIG, any SSL config will be handled wrongly
(i.e. there will be an attempt to load libssl_conf.so or whatever
corresponds to that on non-Unix platforms). Therefore, at least
SSL_add_ssl_module() MUST be called before OPENSSL_init_crypto() is
called. The base ssl init does that, plus adds all kinds of ciphers
and digests, which is harmless.
Fixes#4788
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4792)
The check_fatal macro is supposed to only be called if we are already
expecting to be in the fatal state. The macro asserts that we are and
puts us into the fatal state if not.
This issue combined with the problem fixed in the previous commit meant
that the fuzzer detected a crash at a point in the processing when we
should have already been in the fatal state.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4847)
The recent SSL error overhaul left a case where an error occurs but
SSLfatal() is not called.
Credit to OSSfuzz for finding this issue.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4847)
The most likely explanation for us ending up at this point in the code
is that we were called by the user application incorrectly - so use an
appropriate error code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
Follow up from the conversion to use SSLfatal() in the state machine to
clean things up a bit more.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
We shouldn't call SSLfatal() multiple times for the same error condition.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
Sometimes at the top level of the state machine code we know we are
supposed to be in a fatal error condition. This commit adds some sanity
checks to ensure that SSLfatal() has been called.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
This is an initial step towards using SSLfatal() everywhere. Initially in
this commit and in subsequent commits we focus on the state machine code.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
Typically if a fatal error occurs three things need to happen:
- Put an error on the error queue
- Send an alert
- Put the state machine into the error state
Although all 3 of these things need to be done every time we hit a fatal
error the responsibilities for doing this are distributed throughout the
code. The place where the error goes on the queue, where the alert gets
sent and where the state machine goes into the error state are almost
invariably different. It has been a common pattern to pass alert codes up
and down the stack to get the alert information from the point in the code
where the error is detected to the point in the code where the alert gets
sent.
This commit provides an SSLfatal() macro (backed by an ossl_statem_fatal
function) that does all 3 of the above error tasks. This is largely a drop
in replacement for SSLerr, but takes a couple of extra parameters (the SSL
object, and an alert code).
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4778)
This is a specific 1.1.1 change; do not squash if the chacha
prioritization code is to be backported
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4436)
IFF the client has ChaCha first, and server cipher priority is used,
and the new SSL_OP_PRIORITIZE_CHACHA_FOR_MOBILE option is used,
then reprioritize ChaCha above everything else. This way, A matching
ChaCha cipher will be selected if there is a match. If no ChaCha ciphers
match, then the other ciphers are used.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4436)
These functions needed updates for the various state machine states that
have been added for TLSv1.3.
Fixes#4795
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4801)
SNI needs to be consistent before we accept early_data. However a
server may choose to not acknowledge SNI. In that case we have to
expect that a client may send it anyway. We change the consistency
checks so that not acknowledging is treated more a like a "wild card",
accepting any SNI as being consistent.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4738)
We can only send early_data if the SNI is consistent. However it is valid
for the client to set SNI and the server to not use it. This would still be
counted as consistent. OpenSSL client was being overzealous in this check
and disallowing this scenario.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4738)
It's argued that /WX allows to keep better focus on new code, which
motivates its comeback...
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4721)
It's argued that /WX allows to keep better focus on new code, which
motivates its comeback...
[Keep this commit separate as reminder for time overhaul.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4721)
Around 138 distinct errors found and fixed; thanks!
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)
If SSL_read() is called with a zero length buffer, and we read a zero length
record then we should mark that record as read.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4685)
We currently increment the SSL_CTX stats.sess_accept field in
tls_setup_handshake(), which is invoked from the state machine well
before ClientHello processing would have had a chance to switch
the SSL_CTX attached to the SSL object due to a provided SNI value.
However, stats.sess_accept_good is incremented in tls_finish_handshake(),
and uses the s->ctx.stats field (i.e., the new SSL_CTX that was switched
to as a result of SNI processing). This leads to the confusing
(nonsensical) situation where stats.sess_accept_good is larger than
stats.sess_accept, as the "sess_accept" value was counted on the
s->session_ctx.
In order to provide some more useful numbers, increment
s->ctx.stats.sess_accept after SNI processing if the SNI processing
changed s->ctx to differ from s->session_ctx. To preserve the
property that any given accept is counted only once, make the
corresponding decrement to s->session_ctx.stats.sess_accept when
doing so.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4549)
For client SSL objects and before any callbacks have had a chance
to be called, we can write the stats accesses using the session_ctx,
which makes sense given that these values are all prefixed with
"sess_".
For servers after a client_hello or servername callback has been
called, retain the existing behavior of modifying the statistics
for the current (non-session) context. This has some value,
in that it allows the statistics to be viewed on a per-vhost level.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4549)
It is expected that SSL_CTX objects are shared across threads,
and as such we are responsible for ensuring coherent data accesses.
Aligned integer accesses ought to be atomic already on all supported
architectures, but we can be formally correct.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4549)
Use the newly introduced sk_TYPE_new_reserve API to simplify the
reservation of stack as creating it.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4592)
Add a check for NULL return in t1_lib.c.
Since return type of ssl_cert_lookup_by_idx is pointer and unify coding
style, I changed from zero to NULL in ssl_cert.c.
Remove unnecessary space for ++.
Fix incorrect condition
Expression is always false because 'else if' condition matches previous
condition. SInce the next line of 'else if' condition has substituted
TLSEXT_ECPOINTFORMAT_ansiX962_compressed_char2, the 'else if'
condition should compare with NID_X9_62_characteristic_two_field.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4562)
Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)
The drbg's lock must be held across calls to RAND_DRBG_generate()
to prevent simultaneous modification of internal state.
This was observed in practice with simultaneous SSL_new() calls attempting
to seed the (separate) per-SSL RAND_DRBG instances from the global
rand_drbg instance; this eventually led to simultaneous calls to
ctr_BCC_update() attempting to increment drbg->bltmp_pos for their
respective partial final block, violating the invariant that bltmp_pos < 16.
The AES operations performed in ctr_BCC_blocks() makes the race window
quite easy to trigger. A value of bltmp_pos greater than 16 induces
catastrophic failure in ctr_BCC_final(), with subtraction overflowing
and leading to an attempt to memset() to zero a very large range,
which eventually reaches an unmapped page and segfaults.
Provide the needed locking in get_entropy_from_parent(), as well as
fixing a similar issue in RAND_priv_bytes(). There is also an
unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the
requisite serialization is already guaranteed by the requirements on
the application's usage of SSL objects, and no further locking is
needed for correct behavior. In that case, leave a comment noting
the apparent discrepancy and the reason for its safety (at present).
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4328)
Reseeding is handled very differently by the classic RAND_METHOD API
and the new RAND_DRBG api. These differences led to some problems when
the new RAND_DRBG was made the default OpenSSL RNG. In particular,
RAND_add() did not work as expected anymore. These issues are discussed
on the thread '[openssl-dev] Plea for a new public OpenSSL RNG API'
and in Pull Request #4328. This commit fixes the mentioned issues,
introducing the following changes:
- Replace the fixed size RAND_BYTES_BUFFER by a new RAND_POOL API which
facilitates collecting entropy by the get_entropy() callback.
- Don't use RAND_poll()/RAND_add() for collecting entropy from the
get_entropy() callback anymore. Instead, replace RAND_poll() by
RAND_POOL_acquire_entropy().
- Add a new function rand_drbg_restart() which tries to get the DRBG
in an instantiated state by all means, regardless of the current
state (uninstantiated, error, ...) the DRBG is in. If the caller
provides entropy or additional input, it will be used for reseeding.
- Restore the original documented behaviour of RAND_add() and RAND_poll()
(namely to reseed the DRBG immediately) by a new implementation based
on rand_drbg_restart().
- Add automatic error recovery from temporary failures of the entropy
source to RAND_DRBG_generate() using the rand_drbg_restart() function.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4328)
The previous commit removed version negotiation on an HRR. However we should
still sanity check the contents of the version field.
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4527)
Previously if a client received an HRR then we would do version negotiation
immediately - because we know we are going to get TLSv1.3. However this
causes a problem when we emit the 2nd ClientHello because we start changing
a whole load of stuff to ommit things that aren't relevant for < TLSv1.3.
The spec requires that the 2nd ClientHello is the same except for changes
required from the HRR. Therefore the simplest thing to do is to defer the
version negotiation until we receive the ServerHello.
Fixes#4292
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4527)
Now that we are moving to support named FFDH groups, these fields are not
ec-specific, so we need them to always be available.
This fixes the no-ec --strict-warnings build, since gcc
5.4.0-6ubuntu1~16.04.4 appears to always try to compile the static inline
functions from ssl_locl.h, even when they are not used in the current
compilation unit.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4518)
The function tls_check_curve is only called on clients and contains
almost identical functionaity to tls1_check_group_id when called from
a client. Merge the two.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4475)
