This change saves several EC routines from crashing when an EC_KEY is
missing a public key. The public key is optional in the EC private key
format and, without this patch, running the following through `openssl
ec` causes a crash:

-----BEGIN EC PRIVATE KEY-----
MBkCAQEECAECAwQFBgcIoAoGCCqGSM49AwEH
-----END EC PRIVATE KEY-----

Reviewed-by: Dr Stephen Henson <steve@openssl.org>
(cherry picked from commit b391570bdeb386d4fd325917c248d593d3c43930)

I also removed some trailing whitespace and cleaned
up the "see also" list.

Reviewed-by: Emilia Kasper <emilia@openssl.org>
(cherry picked from commit 7b3e11c5)

Extra SSL_get_selected_srtp_profile() declaration in ssl/srtp.h
causes -Werror builds to fail.

Cherry-picked from 3609b023



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

The description of when the server creates a DH key is
confusing.  This cleans it up.
(rsalz: also removed trailing whitespace.)

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

The EXAMPLE that used FILE and RC2 doesn't compile due to a
few minor errors.  Tweak to use IDEA and AES-128. Remove
examples about RC2 and RC5.

Reviewed-by: Emilia Kasper <emilia@openssl.org>

This patch was submitted by user "Kox" via the wiki

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 2dd8cb3b)

Limit the number of empty records that will be processed consecutively
in order to prevent ssl3_get_record from never returning.

Reported by "oftc_must_be_destroyed" and George Kadianakis.

Reviewed-by: Bodo Moeller <bodo@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Clarify the intended use of EVP_PKEY_sign. Make the code example compile.

Reviewed-by: Dr Stephen Henson <steve@openssl.org>
(cherry picked from commit d64c533a)

In Visual Studio, inline is available in C++ only, however __inline is available for C, see
http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx



Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Dr Stephen Henson <steve@openssl.org>
(cherry picked from commit f511b25a)

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit da92be4d)

RT: 2835

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 15735e4f)

Reviewed-by: Emilia Kasper <emilia@openssl.org>
(cherry picked from commit e608273a)

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 2893a302)

Reviewed-by: Emilia Kasper <emilia@openssl.org>
(cherry picked from commit 55eb14da)

PR#3450

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 5afa57fb7b17aa51cfba1ffa94e900fc7a5f0e04)

group_order_tests (ectest.c).  Also fix the EC_POINTs_mul documentation (ec.h).

Reviewed-by:  <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: Matt Caswell <matt@openssl.org>
(cherry picked from commit 8f5a8805b82d1ae81168b11b7f1506db9e047dec)

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 193c1c07165b0042abd217274a084b49459d4443)

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 1433cac5)

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

Invalid parameters passed to the SRP code can be overrun an internal
buffer. Add sanity check that g, A, B < N to SRP code.

Thanks to Sean Devlin and Watson Ladd of Cryptography Services, NCC
Group for reporting this issue.

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: Tim Hudson <tjh@openssl.org>

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

- Upon parsing, reject OIDs with invalid base-128 encoding.
- Always NUL-terminate the destination buffer in OBJ_obj2txt printing function.

CVE-2014-3508

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>

CVE-2014-3510

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

CVE-2014-3511

Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Bodo Möller <bodo@openssl.org>

In a couple of functions, a sequence number would be calculated twice.

Additionally, in |dtls1_process_out_of_seq_message|, we know that
|frag_len| <= |msg_hdr->msg_len| so the later tests for |frag_len <
msg_hdr->msg_len| can be more clearly written as |frag_len !=
msg_hdr->msg_len|, since that's the only remaining case.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

Applying same fix as in dtls1_process_out_of_seq_message. A truncated DTLS fragment would cause *ok to be clear, but the return value would still be the number of bytes read.

Problem identified by Emilia Käsper, based on previous issue/patch by Adam
Langley.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Previously, a truncated DTLS fragment in
|dtls1_process_out_of_seq_message| would cause *ok to be cleared, but
the return value would still be the number of bytes read. This would
cause |dtls1_get_message| not to consider it an error and it would
continue processing as normal until the calling function noticed that
*ok was zero.

I can't see an exploit here because |dtls1_get_message| uses
|s->init_num| as the length, which will always be zero from what I can
see.

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

The |pqueue_insert| function can fail if one attempts to insert a
duplicate sequence number. When handling a fragment of an out of
sequence message, |dtls1_process_out_of_seq_message| would not call
|dtls1_reassemble_fragment| if the fragment's length was zero. It would
then allocate a fresh fragment and attempt to insert it, but ignore the
return value, leaking the fragment.

This allows an attacker to exhaust the memory of a DTLS peer.

Fixes CVE-2014-3507

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

In |dtls1_reassemble_fragment|, the value of
|msg_hdr->frag_off+frag_len| was being checked against the maximum
handshake message size, but then |msg_len| bytes were allocated for the
fragment buffer. This means that so long as the fragment was within the
allowed size, the pending handshake message could consume 16MB + 2MB
(for the reassembly bitmap). Approx 10 outstanding handshake messages
are allowed, meaning that an attacker could consume ~180MB per DTLS
connection.

In the non-fragmented path (in |dtls1_process_out_of_seq_message|), no
check was applied.

Fixes CVE-2014-3506

Wholly based on patch by Adam Langley with one minor amendment.

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Reviewed-by: Emilia Käsper <emilia@openssl.org>

The |item| variable, in both of these cases, may contain a pointer to a
|pitem| structure within |s->d1->buffered_messages|. It was being freed
in the error case while still being in |buffered_messages|. When the
error later caused the |SSL*| to be destroyed, the item would be double
freed.

Thanks to Wah-Teh Chang for spotting that the fix in 1632ef74

 was
inconsistent with the other error paths (but correct).

Fixes CVE-2014-3505

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>

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

We can't rename ssleay_rand_bytes to md_rand_bytes_lock as this will cause
an error code discrepancy. Instead keep ssleay_rand_bytes and add an
extra parameter: since ssleay_rand_bytes is not part of the public API
this wont cause any binary compatibility issues.
Reviewed-by: Kurt Roeckx <kurt@openssl.org >

don't list it again under changes between 1.0.1h and 1.0.2.

(which didn't always handle value 0 correctly).

Reviewed-by:  <emilia@openssl.org>