Create bn_free_d utility routine and use it.
Fix RT3950
Also a missing cleanse, from Loganaden Velvindron (loganaden@gmail.com),
who noticed it in a Cloudflare patch.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Removed ability to set ex_data impl at runtime. This removed these
three functions:
const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void);
int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i);
int CRYPTO_ex_data_new_class(void);
It is no longer possible to change the ex_data implementation at
runtime. (Luckily those functions were never documented :)
Also removed the ability to add new exdata "classes." We don't believe
this received much (if any) use, since you can't add it to OpenSSL objects,
and there are probably better (native) methods for developers to add
their own extensible data, if they really need that.
Replaced the internal hash table (of per-"class" stacks) with a simple
indexed array. Reserved an index for "app" application.
Each API used to take the lock twice; now it only locks once.
Use local stack storage for function pointers, rather than malloc,
if possible (i.e., number of ex_data items is under a dozen).
Make CRYPTO_EX_DATA_FUNCS opaque/internal.
Also fixes RT3710; index zero is reserved.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Richard Levitte [Mon, 13 Jul 2015 14:53:37 +0000 (16:53 +0200)]
Conversion to UTF-8 where needed
This leaves behind files with names ending with '.iso-8859-1'. These
should be safe to remove. If something went wrong when re-encoding,
there will be some files with names ending with '.utf8' left behind.
Richard Levitte [Fri, 10 Jul 2015 13:40:53 +0000 (15:40 +0200)]
Stop using tardy
Instead of piping through tardy, and possibly suffering from bugs in certain
versions, use --transform, --owner and --group directly with GNU tar (we
already expect that tar variant).
Matt Caswell [Thu, 25 Jun 2015 11:28:28 +0000 (12:28 +0100)]
Extend -show_chain option to verify to show more info
The -show_chain flag to the verify command line app shows information about
the chain that has been built. This commit adds the text "untrusted" against
those certificates that have been used from the untrusted list.
Matt Caswell [Thu, 25 Jun 2015 08:47:15 +0000 (09:47 +0100)]
Reject calls to X509_verify_cert that have not been reinitialised
The function X509_verify_cert checks the value of |ctx->chain| at the
beginning, and if it is NULL then it initialises it, along with the value
of ctx->untrusted. The normal way to use X509_verify_cert() is to first
call X509_STORE_CTX_init(); then set up various parameters etc; then call
X509_verify_cert(); then check the results; and finally call
X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
|ctx->chain| to NULL. The only place in the OpenSSL codebase where
|ctx->chain| is set to anything other than a non NULL value is in
X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
non NULL on entry to X509_verify_cert is if one of the following occurs:
1) An application calls X509_verify_cert() twice without re-initialising
in between.
2) An application reaches inside the X509_STORE_CTX structure and changes
the value of |ctx->chain| directly.
With regards to the second of these, we should discount this - it should
not be supported to allow this.
With regards to the first of these, the documentation is not exactly
crystal clear, but the implication is that you must call
X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
to do this then, at best, the results would be undefined.
Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
likely to have unexpected results, and could be dangerous. This commit
changes the behaviour of X509_verify_cert() so that it causes an error if
|ctx->chain| is anything other than NULL (because this indicates that we
have not been initialised properly). It also clarifies the associated
documentation. This is a follow up commit to CVE-2015-1793.
Matt Caswell [Wed, 24 Jun 2015 14:55:36 +0000 (15:55 +0100)]
Fix alternate chains certificate forgery issue
During certificate verfification, OpenSSL will attempt to find an
alternative certificate chain if the first attempt to build such a chain
fails. An error in the implementation of this logic can mean that an
attacker could cause certain checks on untrusted certificates to be
bypassed, such as the CA flag, enabling them to use a valid leaf
certificate to act as a CA and "issue" an invalid certificate.
This occurs where at least one cert is added to the first chain from the
trust store, but that chain still ends up being untrusted. In that case
ctx->last_untrusted is decremented in error.
The PSK identity hint should be stored in the SSL_SESSION structure
and not in the parent context (which will overwrite values used
by other SSL structures with the same SSL_CTX).
Rewrite ssl3_digest_cached_records handling. Only digest cached records
if digest array is NULL: this means it is safe to call
ssl3_digest_cached_records multiple times (subsequent calls are no op).
Remove flag TLS1_FLAGS_KEEP_HANDSHAKE instead only update handshake buffer
if digest array is NULL.
Add additional "keep" parameter to ssl3_digest_cached_records to indicate
if the handshake buffer should be retained after digesting cached records
(needed for TLS 1.2 client authentication).
Add secure heap for storage of private keys (when possible).
Add BIO_s_secmem(), CBIGNUM, etc.
Add BIO_CTX_secure_new so all BIGNUM's in the context are secure.
Contributed by Akamai Technologies under the Corporate CLA.
Reviewed-by: Richard Levitte <levitte@openssl.org>
As numerous comments indicate the certificate and key array is not an
appopriate structure to store the peers certificate: so remove it and
just the s->session->peer instead.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Richard Levitte [Sun, 21 Jun 2015 17:11:43 +0000 (19:11 +0200)]
Cleanup mttest.c : modernise output
Construct bio_err and bio_stdout from file handles instead of FILE
pointers, since the latter might not be implemented (when OPENSSL_NO_STDIO
is defined).
Convert all output to use BIO_printf.
Change lh_foo to lh_SSL_SESSION_foo.
Rich Salz [Sat, 2 May 2015 14:01:33 +0000 (10:01 -0400)]
RT2547: Tighten perms on generated privkey files
When generating a private key, try to make the output file be readable
only by the owner. Put it in CHANGES file since it might be noticeable.
Add "int private" flag to apps that write private keys, and check that it's
set whenever we do write a private key. Checked via assert so that this
bug (security-related) gets fixed. Thanks to Viktor for help in tracing
the code-paths where private keys are written.
Rich Salz [Sat, 13 Jun 2015 14:50:00 +0000 (10:50 -0400)]
Refactor into clear_ciphers; RT3588
While closing RT3588 (Remove obsolete comment) Kurt and I saw that a
few lines to completely clear the SSL cipher state could be moved into
a common function.
Emilia Kasper [Tue, 9 Jun 2015 12:17:50 +0000 (14:17 +0200)]
Remove SSL_OP_TLS_BLOCK_PADDING_BUG
This is a workaround so old that nobody remembers what buggy clients
it was for. It's also been broken in stable branches for two years and
nobody noticed (see
https://boringssl-review.googlesource.com/#/c/1694/).
It should not be possible for DTLS message fragments to span multiple
packets. However previously if the message header fitted exactly into one
packet, and the fragment body was in the next packet then this would work.
Obviously this would fail if packets get re-ordered mid-flight.