From BoringSSL
- Send an alert when the client key exchange isn't correctly formatted.
- Reject overly short RSA ciphertexts to avoid a (benign) out-of-bounds memory access.
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 4aecfd4d9f366c849c9627ab666d1b1addc024e6)
the session's version (server).
See also BoringSSL's commit bdf5e72f50e25f0e45e825c156168766d8442dde.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 9e189b9dc10786c755919e6792e923c584c918a1)
once the ChangeCipherSpec message is received. Previously, the server would
set the flag once at SSL3_ST_SR_CERT_VRFY and again at SSL3_ST_SR_FINISHED.
This would allow a second CCS to arrive and would corrupt the server state.
(Because the first CCS would latch the correct keys and subsequent CCS
messages would have to be encrypted, a MitM attacker cannot exploit this,
though.)
Thanks to Joeri de Ruiter for reporting this issue.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit e94a6c0ede623960728415b68650a595e48f5a43)
When no-ssl3 is set only make SSLv3 disabled by default. Retain -ssl3
options for s_client/s_server/ssltest.
When no-ssl3-method is set SSLv3_*method() is removed and all -ssl3
options.
We should document this somewhere, e.g. wiki, FAQ or manual page.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 3881d8106df732fc433d30446625dfa2396da42d)
The supported signature algorithms extension needs to be processed before
the certificate to use is decided and before a cipher is selected (as the
set of shared signature algorithms supported may impact the choice).
Reviewed-by: Matt Caswell <matt@openssl.org>
(Original commit adb46dbc6dd7347750df2468c93e8c34bcb93a4b)
Use the new constant-time methods consistently in s3_srvr.c
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 455b65dfab0de51c9f67b3c909311770f2b3f801)
that bad encryptions are treated like random session keys in constant
time.
(cherry picked from commit adb46dbc6dd7347750df2468c93e8c34bcb93a4b)
Reviewed-by: Rich Salz <rsalz@openssl.org>
The addition of SRP authentication needs to be checked in various places
to work properly. Specifically:
A certificate is not sent.
A certificate request must not be sent.
Server key exchange message must not contain a signature.
If appropriate SRP authentication ciphersuites should be chosen.
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 8f5a8805b82d1ae81168b11b7f1506db9e047dec)
Only accept change cipher spec when it is expected instead of at any
time. This prevents premature setting of session keys before the master
secret is determined which an attacker could use as a MITM attack.
Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for reporting this issue
and providing the initial fix this patch is based on.
(cherry picked from commit bc8923b1ec9c467755cd86f7848c50ee8812e441)
Make sure there is an extra 4 bytes for server done message when
NETSCAPE_HANG_BUG is defined.
PR#3361
(cherry picked from commit 92d81ba622396425764d676ba4fb3f0dac273f17)
Replace manual ASN.1 decoder with ASN1_get object. This
will decode the tag and length properly and check against
it does not exceed the supplied buffer length.
PR#3335
(cherry picked from commit b0308dddd1cc6a8e1de803ef29ba6da25ee072c2)
If multiple TLS extensions are expected but not received, the TLS extension and supplemental data 'generate' callbacks are the only chance for the receive-side to trigger a specific TLS alert during the handshake.
Removed logic which no-op'd TLS extension generate callbacks (as the generate callbacks need to always be called in order to trigger alerts), and updated the serverinfo-specific custom TLS extension callbacks to track which custom TLS extensions were received by the client, where no-ops for 'generate' callbacks are appropriate.
(cherry picked from commit ac20719d994729970eb3b775c7bffa81f0e9f960)
Conflicts:
ssl/t1_lib.c
Removed prior audit proof logic - audit proof support was implemented using the generic TLS extension API
Tests exercising the new supplemental data registration and callback api can be found in ssltest.c.
Implemented changes to s_server and s_client to exercise supplemental data callbacks via the -auth argument, as well as additional flags to exercise supplemental data being sent only during renegotiation.
(cherry picked from commit 36086186a9b90cdad0d2cd0a598a10f03f8f4bcc)
Conflicts:
Configure
apps/s_client.c
apps/s_server.c
ssl/ssl.h
ssl/ssl3.h
ssl/ssltest.c
When sending an invalid version number alert don't change the
version number to the client version if a session is already
established.
Thanks to Marek Majkowski for additional analysis of this issue.
PR#3191
(cherry picked from commit b77b58a398c8b9b4113f3fb6b48e162a3b8d4527)
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.
This is a forward-port of commits:
4af793036f6ef4f0a1078e5d7155426a98d50e37
f4c93b46edb51da71f09eda99e83eaf193a33c08
3da721dac9382c48812c8eba455528fd59af2eef
2583270191a8b27eed303c03ece1da97b9b69fd3
While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear. This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:
* It's quite possible to open two TLS connections in one second.
* If the PRNG output is prone to repeat itself, ephemeral
handshakes (and who knows what else besides) are broken.
Check for Suite B support using method flags instead of version numbers:
anything supporting TLS 1.2 cipher suites will also support Suite B.
Return an error if an attempt to use DTLS 1.0 is made in Suite B mode.
(cherry picked from commit 4544f0a69161a37ee3edce3cc1bc34c3678a4d64)
If we successfully match a cookie don't set return value to 2 as this
results in other error conditions returning 2 as well.
Instead set return value to -2 which can be checked later if everything
else is OK.
(cherry picked from commit c56f5b8edfbcec704f924870daddd96a5f768fbb)
Add new methods DTLS_*_method() which support both DTLS 1.0 and DTLS 1.2 and
pick the highest version the peer supports during negotiation.
As with SSL/TLS options can change this behaviour specifically
SSL_OP_NO_DTLSv1 and SSL_OP_NO_DTLSv1_2.
(cherry picked from commit c6913eeb762edffddecaaba5c84909d7a7962927)
Conflicts:
CHANGES
Use the enc_flags field to determine whether we should use explicit IV,
signature algorithms or SHA256 default PRF instead of hard coding which
versions support each requirement.
(cherry picked from commit cbd64894ec687c6f37d8e43c16dff78e63f6be87)
Conflicts:
ssl/ssl_locl.h
Revise DTLS code. There was a *lot* of code duplication in the
DTLS code that generates records. This makes it harder to maintain and
sometimes a TLS update is omitted by accident from the DTLS code.
Specifically almost all of the record generation functions have code like
this:
some_pointer = buffer + HANDSHAKE_HEADER_LENGTH;
... Record creation stuff ...
set_handshake_header(ssl, SSL_MT_SOMETHING, message_len);
...
write_handshake_message(ssl);
Where the "Record creation stuff" is identical between SSL/TLS and DTLS or
in some cases has very minor differences.
By adding a few fields to SSL3_ENC to include the header length, some flags
and function pointers for handshake header setting and handshake writing the
code can cope with both cases.
(cherry picked from commit 173e72e64c6a07ae97660c322396b66215009f33)
is required by client or server. An application can decide which
certificate chain to present based on arbitrary criteria: for example
supported signature algorithms. Add very simple example to s_server.
This fixes many of the problems and restrictions of the existing client
certificate callback: for example you can now clear existing certificates
and specify the whole chain.
(backport from HEAD)
TLS v1.2. These are sent as an extension for clients and during a certificate
request for servers.
TODO: add support for shared signature algorithms, respect shared algorithms
when deciding which ciphersuites and certificates to permit.
(backport from HEAD)
