A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix (CVE-2014-0160)
(cherry picked from commit 96db9023b8)
Don't clear verification errors from the error queue unless
SSL_BUILD_CHAIN_FLAG_CLEAR_ERROR is set.
If errors occur during verification and SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR
is set return 2 so applications can issue warnings.
Although the memory allocated by compression methods is fixed and
cannot grow over time it can cause warnings in some leak checking
tools. The function SSL_COMP_free_compression_methods() will free
and zero the list of supported compression methods. This should
*only* be called in a single threaded context when an application
is shutting down to avoid interfering with existing contexts
attempting to look up compression methods.
New flags to build certificate chains. The can be used to rearrange
the chain so all an application needs to do is add all certificates
in arbitrary order and then build the chain to check and correct them.
Add verify error code when building chain.
Update docs.
(cherry picked from commit 13dc3ce9ab)
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 ac20719d99)
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 36086186a9)
Conflicts:
Configure
apps/s_client.c
apps/s_server.c
ssl/ssl.h
ssl/ssl3.h
ssl/ssltest.c
If an application calls the macro SSL_CTX_get_extra_chain_certs
return either the old "shared" extra certificates or those associated
with the current certificate.
This means applications which call SSL_CTX_use_certificate_chain_file
and retrieve the additional chain using SSL_CTX_get_extra_chain_certs
will still work. An application which only wants to check the shared
extra certificates can call the new macro
SSL_CTX_get_extra_chain_certs_only
(cherry picked from commit a51f767645)
New ctrl sets current certificate based on certain criteria. Currently
two options: set the first valid certificate as current and set the
next valid certificate as current. Using these an application can
iterate over all certificates in an SSL_CTX or SSL structure.
(cherry picked from commit 0f78819c8c)
The flag SSL_OP_MSIE_SSLV2_RSA_PADDING hasn't done anything since OpenSSL
0.9.7h but deleting it will break source compatibility with any software
that references it. Restore it but #define to zero.
Fix a limitation in SSL_CTX_use_certificate_chain_file(): use algorithm
specific chains instead of the shared chain.
Update docs.
(cherry picked from commit a4339ea3ba)
Conflicts:
CHANGES
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 b77b58a398)
For DTLS we might need to retransmit messages from the previous session
so keep a copy of write context in DTLS retransmission buffers instead
of replacing it after sending CCS. CVE-2013-6450.
(cherry picked from commit 34628967f1)
If pointer comparison for current certificate fails check
to see if a match using X509_cmp succeeds for the current
certificate: this is useful for cases where the certificate
pointer is not available.
(cherry picked from commit 6856b288a6e66edd23907b7fa264f42e05ac9fc7)
PR#3169
This patch, which currently applies successfully against master and
1_0_2, adds the following functions:
SSL_[CTX_]select_current_cert() - set the current certificate without
disturbing the existing structure.
SSL_[CTX_]get0_chain_certs() - get the current certificate's chain.
SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain.
The patch also adds these functions to, and fixes some existing errors
in, SSL_CTX_add1_chain_cert.pod.
(cherry picked from commit 2f56c9c015dbca45379c9a725915b3b8e765a119)
PR: 2808
With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and
FORWARD-TSN chunks. The key for this extension is derived from the
master secret and changed with the next ChangeCipherSpec, whenever a new
key has been negotiated. The following Finished then already uses the
new key. Unfortunately, the ChangeCipherSpec and Finished are part of
the same flight as the ClientKeyExchange, which is necessary for the
computation of the new secret. Hence, these messages are sent
immediately following each other, leaving the server very little time to
compute the new secret and pass it to SCTP before the finished arrives.
So the Finished is likely to be discarded by SCTP and a retransmission
becomes necessary. To prevent this issue, the Finished of the client is
still sent with the old key.
Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.
This is a forward-port of commits:
4af793036ff4c93b46ed3da721dac92583270191
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.
Removing RSA+MD5 from the default signature algorithm list
prevents its use by default.
If a broken implementation attempts to use RSA+MD5 anyway the sanity
checking of signature algorithms will cause a fatal alert.
(cherry picked from commit 77a0f740d00ecf8f6b01c0685a2f858c3f65a3dd)
Make DTLS behave like TLS when negotiating version: record layer has
DTLS 1.0, message version is 1.2.
Tolerate different version numbers if version hasn't been negotiated
yet.
(cherry picked from commit 40088d8b81)
Add DTLS record header parsing, different client hello format and add
HelloVerifyRequest message type.
Add code to d1_pkt.c to send message headers to the message callback.
(cherry picked from commit 890f2f8b92)
Conflicts:
ssl/ssl_locl.h
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 4544f0a691)
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 c56f5b8edf)
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 c6913eeb76)
Conflicts:
CHANGES
Add DTLS1.2 support for cached records when computing handshake macs
instead of the MD5+SHA1 case for DTLS < 1.2 (this is a port of the
equivalent TLS 1.2 code to DTLS).
(cherry picked from commit 04fac50045)
Add correct flags for DTLS 1.2, update s_server and s_client to handle
DTLS 1.2 methods.
Currently no support for version negotiation: i.e. if client/server selects
DTLS 1.2 it is that or nothing.
(cherry picked from commit c3b344e36a)
Conflicts:
apps/s_server.c
Since this is always called from DTLS code it is safe to assume the header
length should be the DTLS value. This avoids the need to check the version
number and should work with any version of DTLS (not just 1.0).
(cherry picked from commit 9cf0f18754)
Some TLS extensions were disabled for DTLS. Possibly because they caused
problems with the old duplicated code. Enable them again.
(cherry picked from commit 874a18cfad)
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 cbd64894ec)
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 173e72e64c)
This fix ensures that
* A HelloRequest is retransmitted if not responded by a ClientHello
* The HelloRequest "consumes" the sequence number 0. The subsequent
ServerHello uses the sequence number 1.
* The client also expects the sequence number of the ServerHello to
be 1 if a HelloRequest was received earlier.
This patch fixes the RFC violation.
(cherry picked from commit b62f4daac0)
Note that it initially applies to 1.0.2, and not to HEAD. This is
in order to allow development with existing libunbound installations
that are dependent on OpenSSL 1.0.x. More details in RT.
RT: 3003
The version check for DTLS1_VERSION was redundant as
DTLS1_VERSION > TLS1_1_VERSION, however we do need to
check for DTLS1_BAD_VER for compatibility.
PR:2984
(cherry picked from commit d980abb22e)
Fix the calculation that checks there is enough room in a record
after removing padding and optional explicit IV. (by Steve)
For AEAD remove the correct number of padding bytes (by Andy)
(cherry picked from commit 32cc2479b4)
MD5 should use little endian order. Fortunately the only ciphersuite
affected is EXP-RC2-CBC-MD5 (TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5) which
is a rarely used export grade ciphersuite.
(cherry picked from commit f306b87d76)
Kludge alert. This is arranged by passing padding length in unused
bits of SSL3_RECORD->type, so that orig_len can be reconstructed.
(cherry picked from commit 8bfd4c659f)
Break dependency on uint64_t. It's possible to declare bits as
unsigned int, because TLS packets are limited in size and 32-bit
value can't overflow.
(cherry picked from commit cab13fc847)
We have to use EVP in FIPS mode so we can only partially mitigate
timing differences.
Make an extra call to EVP_DigestSignUpdate to hash additonal blocks
to cover any timing differences caused by removal of padding.
(cherry picked from commit b908e88ec1)
The previous CBC patch was bugged in that there was a path through enc()
in s3_pkt.c/d1_pkt.c which didn't set orig_len. orig_len would be left
at the previous value which could suggest that the packet was a
sufficient length when it wasn't.
(cherry picked from commit 6cb19b7681)
This patch makes the decoding of SSLv3 and TLS CBC records constant
time. Without this, a timing side-channel can be used to build a padding
oracle and mount Vaudenay's attack.
This patch also disables the stitched AESNI+SHA mode pending a similar
fix to that code.
In order to be easy to backport, this change is implemented in ssl/,
rather than as a generic AEAD mode. In the future this should be changed
around so that HMAC isn't in ssl/, but crypto/ as FIPS expects.
(cherry picked from commit e130841bcc)
This change adds CRYPTO_memcmp, which compares two vectors of bytes in
an amount of time that's independent of their contents. It also changes
several MAC compares in the code to use this over the standard memcmp,
which may leak information about the size of a matching prefix.
(cherry picked from commit 2ee798880a)
client hello message. Previously this could only be retrieved on an initial
connection and it was impossible to determine the cipher IDs of any uknown
ciphersuites.
(backport from HEAD)
by a certificate chain. Add additional tests to handle client
certificates: checks for matching certificate type and issuer name
comparison.
Print out results of checks for each candidate chain tested in
s_server/s_client.
(backport from HEAD)
possible to have different stores per SSL structure or one store in
the parent SSL_CTX. Include distint stores for certificate chain
verification and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN
to build and store a certificate chain in CERT structure: returing
an error if the chain cannot be built: this will allow applications
to test if a chain is correctly configured.
Note: if the CERT based stores are not set then the parent SSL_CTX
store is used to retain compatibility with existing behaviour.
(backport from HEAD)
details in s_client.
Also add ctrl to set client certificate types. If not used sensible values
will be included based on supported signature algorithms: for example if
we don't include any DSA signing algorithms the DSA certificate type is
omitted.
Fix restriction in old code where certificate types would be truncated
if it exceeded TLS_CT_NUMBER.
(backport from HEAD)
the permitted signature algorithms for server and client authentication
are the same but it is now possible to set different algorithms for client
authentication only.
(backport from HEAD)
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)
the certificate can be used for (if anything). Set valid_flags field
in new tls1_check_chain function. Simplify ssl_set_cert_masks which used
to have similar checks in it.
Add new "cert_flags" field to CERT structure and include a "strict mode".
This enforces some TLS certificate requirements (such as only permitting
certificate signature algorithms contained in the supported algorithms
extension) which some implementations ignore: this option should be used
with caution as it could cause interoperability issues.
(backport from HEAD)
Only store encoded versions of peer and configured signature algorithms.
Determine shared signature algorithms and cache the result along with NID
equivalents of each algorithm.
(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)
Reported by: Phil Pennock <openssl-dev@spodhuis.org>
Make renegotiation work for TLS 1.2, 1.1 by not using a lower record
version client hello workaround if renegotiating.
If OPENSSL_MAX_TLS1_2_CIPHER_LENGTH is set then limit the size of client
ciphersuites to this value. A value of 50 should be sufficient.
Document workarounds in CHANGES.
Some servers hang when presented with a client hello record length exceeding
255 bytes but will work with longer client hellos if the TLS record version
in client hello does not exceed TLS v1.0. Unfortunately this doesn't fix all
cases...
enabled instead of requiring an application to hard code a (possibly
inappropriate) parameter set and delve into EC internals we just
automatically use the preferred curve.
(backport from HEAD)
Tidy some code up.
Don't allocate a structure to handle ECC extensions when it is used for
default values.
Make supported curves configurable.
Add ctrls to retrieve shared curves: not fully integrated with rest of
ECC code yet.
(backport from HEAD)
extensions to s_client and s_server to print out retrieved valued.
Extend CERT structure to cache supported signature algorithm data.
(backport from HEAD)
structure.
Before this the only way to add a custom chain was in the parent SSL_CTX
(which is shared by all key types and SSL structures) or rely on auto
chain building (which is performed on each handshake) from the trust store.
(backport from HEAD)
