Inline the get_cipher implementation (including the special handling
for DTLS) in ssl_cipher_collect_ciphers() (the only consumer), remove
the get_cipher member of SSL_METHOD and mop up dtls1_get_cipher().
ssl3_get_cipher() has always had a strange property of being a reverse
index, which is relied on by the cipher list ordering code, since it
currently assumes that high cipher suite values are preferable. Rather
than complicating ssl3_get_cipher() (and regress), change the iteration
order in ssl_cipher_collect_ciphers() to match what it requires. Lastly,
rename ssl3_get_cipher() to be more descriptive.
ok tb@
OpenSSL has had the concept of cipher IDs, which were a way of working
around overlapping cipher suite values between SSLv2 and SSLv3. Given
that we no longer have to deal with this issue, replace the use of IDs
with cipher suite values. In particular, this means that we can stop
mapping back and forth between the two, simplifying things considerably.
While here, remove the 'valid' member of the SSL_CIPHER. The ssl3_ciphers[]
table is no longer mutable, meaning that ciphers cannot be disabled at
runtime (and we have `#if 0' if we want to do it at compile time).
Clean up the comments and add/update RFC references for cipher suites.
ok tb@
For a long time SSL_SESSION has had both a cipher ID and a pointer to
an SSL_CIPHER (and not both are guaranteed to be populated). There is also
a pointer to an SSL_CIPHER in the SSL_HANDSHAKE that denotes the cipher
being used for this connection. Some code has been using the cipher from
SSL_SESSION and some code has been using the cipher from SSL_HANDSHAKE.
Remove cipher from SSL_SESSION and use the version in SSL_HANDSHAKE
everywhere. If resuming from a session then we need to use the SSL_SESSION
cipher ID to set the SSL_HANDSHAKE cipher. And we still need to ensure that
we update the cipher ID in the SSL_SESSION whenever the SSL_HANDSHAKE
cipher changes (this only occurs in a few places).
ok tb@
SSL_SESSION has a 'ciphers' member which contains a list of ciphers
that were advertised by the client. Move this from SSL_SESSION to
SSL_HANDSHAKE and rename it to match reality.
ok tb@
The handshake MAC needs to be upgraded when TLSv1.0 and TLSv1.1
ciphersuites are used with TLSv1.2. Since we no longer support TLSv1.0
and TLSv1.1, we can simply upgrade the handshake MAC in the ciphersuite
table and remove the various defines/macros/code that existed to handle
the upgrade.
ok tb@
These have not been used for a long time, however SSL_CIPHER was not opaque
at the time, hence they had to stick around. Now that SSL_CIPHER is opaque
we can simply mop them up.
ok tb@
RSA key exchange is known to have multiple security weaknesses,
including being potentially susceptible to padding oracle and timing
attacks.
The RSA key exchange code that we inherited from OpenSSL was riddled
with timing leaks, many of which we fixed (or minimised) early on.
However, a number of issues still remained, particularly those
related to libcrypto's RSA decryption and padding checks.
Rework the RSA key exchange code such that we decrypt with
RSA_NO_PADDING and then check the padding ourselves in constant
time. In this case, the pre-master secret is of a known length,
hence the padding is also a known length based on the size of the
RSA key. This makes it easy to implement a check that is much safer
than having RSA_private_decrypt() depad for us.
Regardless, we still strongly recommend disabling RSA key exchange
and using other key exchange methods that provide perfect forward
secrecy and do not depend on client generated keys.
Thanks to Marcel Maehren, Nurullah Erinola, Robert Merget, Juraj
Somorovsky, Joerg Schwenk and Hubert Kario for raising these issues
with us at various points in time.
ok tb@
This information has been part of tls12_key_block_generate() for a while
now. It remained in this table because at that point SSL_CIPHER was still
public. Nothing can access algorithm2 anymore from the outside, so this is
dead weight.
ok jsing
This version of GOST is old and not anywhere close to compliant with
modern GOST standards. It is also very intrusive in libssl and
makes a mess everywhere. Efforts to entice a suitably minded anyone
to care about it have been unsuccessful.
At this point it is probably best to remove this, and if someone
ever showed up who truly needed a working version, it should be
a clean implementation from scratch, and have it use something
closer to the typical API in libcrypto so it would integrate less
painfully here.
This removes it from libssl in preparation for it's removal from
libcrypto with a future major bump
ok tb@
The TLSv1.3 stack didn't support this in the first place, and in the legacy
stack it only added some dubious BIO_flush(3) calls. The sleep call between
SSL_read(3) and SSL_write(3) advertised in the comment next to the flag has
been a sleep call in the s_server since time immemorial, nota bene between
calls to BIO_gets(3). Anyway. This can all go and what remains will go with
the next major bump.
ok jsing
This was previously the only user of OBJ_bsearch_ssl_cipher_id(), which
in turn is the one remaining user of OBJ_bsearch_() outside of libcrypto.
OBJ_bsearch_() is OpenSSL's idiosyncratic reimplementation of ANSI C89's
bsearch(). Since this used to be hidden behind macro insanity, the result
was three inscrutable layers of comparison functions.
It is much simpler and cleaner to use the standard API. Move all the code
to s3_lib.c, since it's ony used there.
In a few further diffs, OBJ_bsearch_() will be removed from libcrypto.
Unfortunately, we'll need to keep OBJ_bsearch_ex(), because it is
exposed via sk_find_ex(), which is exposed by M2Crypto...
ok jsing
While the cipher id is effectively a 32-bit value, someone decided that
it should be represented by a long in various internal structs, whose
mameber is passed as id. So use a long because of this and also to make
an upcoming diff simpler.
ok jsing
It was left alone and forlorn in the middle of other nonsense. Since there
is only one caller (the OBJ_bsearch_ stupidity), it can be static and there
is no need to prototype it in ssl_local.h.
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
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
