Odd-length lists should be rejected everywhere upon parsing. Nevertheless,
be extra careful and add guards against off-by-one reads.

Also, drive-by replace inexplicable double-negation with an explicit comparison.
Reviewed-by: NMatt Caswell <matt@openssl.org>

The Supported Elliptic Curves extension contains a vector of NamedCurves
of 2 bytes each, so the total length must be even. Accepting odd-length
lists was observed to lead to a non-exploitable one-byte out-of-bounds
read in the latest development branches (1.0.2 and master). Released
versions of OpenSSL are not affected.

Thanks to Felix Groebert of the Google Security Team for reporting this issue.
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

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: NMatt Caswell <matt@openssl.org>

This ensures that it's zeroed even if the SSL object is reused
(as in ssltest.c). It also ensures that it applies to DTLS, too.
Reviewed-by: NMatt Caswell <matt@openssl.org>

Don't send or parse any extensions other than RI (which is needed
to handle secure renegotation) for SSLv3.
Reviewed-by: NMatt Caswell <matt@openssl.org>

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: NMatt Caswell <matt@openssl.org>

(cherry picked from commit 56e8dc542bd693b2dccea8828b3d8e5fc6932d0c)

Conflicts:
	ssl/ssl.h
	ssl/ssl_err.c

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

CVE-2014-3567
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

CVE-2014-3513

This issue was reported to OpenSSL on 26th September 2014, based on an original
issue and patch developed by the LibreSSL project. Further analysis of the issue
was performed by the OpenSSL team.

The fix was developed by the OpenSSL team.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Support separate parse and add callback arguments.
Add new callback so an application can free extension data.
Change return value for send functions so < 0 is an error 0
omits extension and > 0 includes it. This is more consistent
with the behaviour of other functions in OpenSSL.

Modify parse_cb handling so <= 0 is an error.

Make SSL_CTX_set_custom_cli_ext and SSL_CTX_set_custom_cli_ext argument
order consistent.

NOTE: these changes WILL break existing code.

Remove (now inaccurate) in line documentation.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Since sanity checks are performed for all custom extensions the
serverinfo checks are no longer needed.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Reject attempts to use extensions handled internally.

Add flags to each extension structure to indicate if an extension
has been sent or received. Enforce RFC5246 compliance by rejecting
duplicate extensions and unsolicited extensions and only send a
server extension if we have sent the corresponding client extension.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Use the same structure for client and server custom extensions.

Add utility functions in new file t1_ext.c.
Use new utility functions to handle custom server and client extensions
and remove a lot of code duplication.
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Add a dozen more const declarations where appropriate.
These are from Justin; while adding his patch, I noticed
ASN1_BIT_STRING_check could be fixed, too.
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Move custom extension structures from SSL_CTX to CERT structure.

This change means the form can be revised in future without binary
compatibility issues. Also since CERT is part of SSL structures
so per-SSL custom extensions could be supported in future as well as
per SSL_CTX.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

If a client attempted to use an SRP ciphersuite and it had not been
set up correctly it would crash with a null pointer read. A malicious
server could exploit this in a DoS attack.

Thanks to Joonas Kuorilehto and Riku Hietamäki from Codenomicon
for reporting this issue.

CVE-2014-2970
Reviewed-by: NTim Hudson <tjh@openssl.org>

CVE-2014-3509
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

(cherry picked from commit 2db3ea29298bdc347f15fbfab6d5746022f05101)

Conflicts:
	ssl/t1_lib.c

PR#2531

Add TLS padding extension to SSL_OP_ALL so it is used with other
"bugs" options and can be turned off.

This replaces SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG which is an ancient
option referring to SSLv2 and SSLREF.

PR#3336

Closes #74.

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 96db9023b881d7cd9f379b0c154650d6c108e9a3)

Enable TLS padding extension using official value from:

http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Security callback: selects which parameters are permitted including
sensible defaults based on bits of security.

The "parameters" which can be selected include: ciphersuites,
curves, key sizes, certificate signature algorithms, supported
signature algorithms, DH parameters, SSL/TLS version, session tickets
and compression.

In some cases prohibiting the use of a parameters will mean they are
not advertised to the peer: for example cipher suites and ECC curves.
In other cases it will abort the handshake: e.g DH parameters or the
peer key size.

Documentation to follow...

New function ssl_cipher_disabled.

Check for disabled client ciphers using ssl_cipher_disabled.

New function to return only supported ciphers.

New option to ciphers utility to print only supported ciphers.

Add auto DH parameter support. This is roughly equivalent to the
ECDH auto curve selection but for DH. An application can just call

SSL_CTX_set_auto_dh(ctx, 1);

and appropriate DH parameters will be used based on the size of the
server key.

Unlike ECDH there is no way a peer can indicate the range of DH parameters
it supports. Some peers cannot handle DH keys larger that 1024 bits for
example. In this case if you call:

SSL_CTX_set_auto_dh(ctx, 2);

Only 1024 bit DH parameters will be used.

If the server key is 7680 bits or more in size then 8192 bit DH parameters
will be used: these will be *very* slow.

The old export ciphersuites aren't supported but those are very
insecure anyway.

(cherry picked from commit bc5ec653ba65fedb1619c8182088497de8a97a70)

Add the extension parser in the s_client, ocsp and x509 apps.

The contract for custom extension callbacks has changed - all custom extension callbacks are triggered