This should be a one off operation (subsequent invokation of the
script should not move them)
Reviewed-by: NTim Hudson <tjh@openssl.org>

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

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

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

OpenSSL clients would tolerate temporary RSA keys in non-export
ciphersuites. It also had an option SSL_OP_EPHEMERAL_RSA which
enabled this server side. Remove both options as they are a
protocol violation.

Thanks to Karthikeyan Bhargavan for reporting this issue.
(CVE-2015-0204)
Reviewed-by: NMatt Caswell <matt@openssl.org>

Fix bug where an OpenSSL client would accept a handshake using an
ephemeral ECDH ciphersuites with the server key exchange message omitted.

Thanks to Karthikeyan Bhargavan for reporting this issue.

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

indent will not alter them when reformatting comments
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

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

The client_version needs to be preserved for the RSA key exchange.

This change also means that renegotiation will, like TLS, repeat the old
client_version rather than advertise only the final version. (Either way,
version change on renego is not allowed.) This is necessary in TLS to work
around an SChannel bug, but it's not strictly necessary in DTLS.

(From BoringSSL)
Reviewed-by: NEmilia Käsper <emilia@openssl.org>

Signed-off-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatt Caswell <matt@openssl.org>

FIPS_mode() exists in all versions of OpenSSL but always returns 0 if OpenSSL is not FIPS
capable.
Reviewed-by: NTim Hudson <tjh@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>

The server must send a NewSessionTicket message if it advertised one
in the ServerHello, so make a missing ticket message an alert
in the client.

An equivalent change was independently made in BoringSSL, see commit
6444287806d801b9a45baf1f6f02a0e3a16e144c.
Reviewed-by: NMatt Caswell <matt@openssl.org>

The client sends a session ID with the session ticket, and uses
the returned ID to detect resumption, so we do not need to peek
at handshake messages: s->hit tells us explicitly if we're resuming.

An equivalent change was independently made in BoringSSL, see commit
407886f589cf2dbaed82db0a44173036c3bc3317.
Reviewed-by: NMatt Caswell <matt@openssl.org>

The same change was independently made in BoringSSL, see commit
9eaeef81fa2d4fd6246dc02b6203fa936a5eaf67
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>

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: NEmilia Käsper <emilia@openssl.org>

Tighten client-side session ticket handling during renegotiation:
ensure that the client only accepts a session ticket if the server sends
the extension anew in the ServerHello. Previously, a TLS client would
reuse the old extension state and thus accept a session ticket if one was
announced in the initial ServerHello.
Reviewed-by: NBodo Moeller <bodo@openssl.org>

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

that fixed PR#3450 where an existing cast masked an issue when i was changed
from int to long in that commit

Picked up on z/linux (s390) where sizeof(int)!=sizeof(long)
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Fix a bug in handling of 128 byte long PSK identity in
psk_client_callback.

OpenSSL supports PSK identities of up to (and including) 128 bytes in
length. PSK identity is obtained via the psk_client_callback,
implementors of which are expected to provide a NULL-terminated
identity. However, the callback is invoked with only 128 bytes of
storage thus making it impossible to return a 128 byte long identity and
the required additional NULL byte.

This CL fixes the issue by passing in a 129 byte long buffer into the
psk_client_callback. As a safety precaution, this CL also zeroes out the
buffer before passing it into the callback, uses strnlen for obtaining
the length of the identity returned by the callback, and aborts the
handshake if the identity (without the NULL terminator) is longer than
128 bytes.

(Original patch amended to achieve strnlen in a different way.)
Reviewed-by: NRich Salz <rsalz@openssl.org>

PR#3450
Reviewed-by: NEmilia Käsper <emilia@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: NMatt Caswell <matt@openssl.org>

Check SRP parameters when they are received so we can send back an
appropriate alert.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

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

Remove RFC5878 code. It is no longer needed for CT and has numerous bugs

Allow CCS after finished has been sent by client: at this point
keys have been correctly set up so it is OK to accept CCS from
server. Without this renegotiation can sometimes fail.

PR#3400

If application uses tls_session_secret_cb for session resumption
set the CCS_OK flag.

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)

Check session_cert is not NULL before dereferencing it.
(cherry picked from commit 8011cd56e39a433b1837465259a9bd24a38727fb)

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.

(cherry picked from commit b709f8ef54b1c9ad513878ba0213aa651a9acef8)

Whitespace fixes

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.

DHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEDH should probably be deprecated at some
point, though.

ECDHE is the standard term used by the RFCs and by other TLS
implementations.  It's useful to have the internal variables use the
standard terminology.

This patch leaves a synonym SSL_kEECDH in place, though, so that older
code can still be built against it, since that has been the
traditional API.  SSL_kEECDH should probably be deprecated at some
point, though.