Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Thanks folks:
        348 Benjamin Kaduk
        317 Christian Brueffer
        254 Erik Tews
        253 Erik Tews
        219 Carl Mehner
        155 (ghost)
        95 mancha
        51 DominikNeubauer

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

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

This flag was not set anywhere within the codebase (only read). It could
only be set by an app reaching directly into s->s3->flags and setting it
directly. However that method became impossible when libssl was opaquified.

Even in 1.0.2/1.0.1 if an app set the flag directly it is only relevant to
ssl3_connect(), which calls SSL_clear() during initialisation that clears
any flag settings. Therefore it could take effect if the app set the flag
after the handshake has started but before it completed. It seems quite
unlikely that any apps really do this (especially as it is completely
undocumented).

The purpose of the flag is suppress flushing of the write bio on the client
side at the end of the handshake after the client has written the Finished
message whilst resuming a session. This enables the client to send
application data as part of the same flight as the Finished message.

This flag also controls the setting of a second flag SSL3_FLAGS_POP_BUFFER.
There is an interesting comment in the code about this second flag in the
implementation of ssl3_write:

	/* This is an experimental flag that sends the
	 * last handshake message in the same packet as the first
	 * use data - used to see if it helps the TCP protocol during
	 * session-id reuse */

It seems the experiment did not work because as far as I can tell nothing
is using this code. The above comment has been in the code since SSLeay.

This commit removes support for SSL3_FLAGS_DELAY_CLIENT_FINISHED, as well
as the associated SSL3_FLAGS_POP_BUFFER.

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

This leaves behind files with names ending with '.iso-8859-1'.  These
should be safe to remove.  If something went wrong when re-encoding,
there will be some files with names ending with '.utf8' left behind.

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

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

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

Add secure heap for storage of private keys (when possible).
Add BIO_s_secmem(), CBIGNUM, etc.
Add BIO_CTX_secure_new so all BIGNUM's in the context are secure.
Contributed by Akamai Technologies under the Corporate CLA.

Reviewed-by: Richard Levitte <levitte@openssl.org>

When generating a private key, try to make the output file be readable
only by the owner.  Put it in CHANGES file since it might be noticeable.

Add "int private" flag to apps that write private keys, and check that it's
set whenever we do write a private key.  Checked via assert so that this
bug (security-related) gets fixed.  Thanks to Viktor for help in tracing
the code-paths where private keys are written.

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

Updates to CHANGES and NEWS to take account of the latest security fixes.

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

This is a workaround so old that nobody remembers what buggy clients
it was for. It's also been broken in stable branches for two years and
nobody noticed (see
https://boringssl-review.googlesource.com/#/c/1694/

).

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

The return type of BIO_number_read() and BIO_number_written() as well as
the corresponding num_read and num_write members in the BIO structure has
been changed from unsigned long to uint64_t. On platforms where an unsigned
long is 32 bits (e.g. Windows) these counters could overflow if >4Gb is
transferred.

With thanks to the Open Crypto Audit Project for reporting this issue.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Remove support for the two export grade static DH ciphersuites. These two
ciphersuites were newly added (along with a number of other static DH
ciphersuites) to 1.0.2. However the two export ones have *never* worked
since they were introduced. It seems strange in any case to be adding new
export ciphersuites, and given "logjam" it also does not seem correct to
fix them.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Also reorder preferences to prefer prime curves to binary curves, and P-256 to everything else.

The result:

$ openssl s_server -named_curves "auto"

This command will negotiate an ECDHE ciphersuite with P-256:

$ openssl s_client

This command will negotiate P-384:

$ openssl s_client -curves "P-384"

This command will not negotiate ECDHE because P-224 is disabled with "auto":

$ openssl s_client -curves "P-224"

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>

Update various documentation references to the new TLS_*_method names. Also
add a CHANGES entry.

Reviewed-by: Kurt Roeckx <kurt@openssl.org>

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

 https://github.com/openssl/openssl/pull/176 (CHANGES)
 https://rt.openssl.org/Ticket/Display.html?id=3545 (objects.txt)
 https://rt.openssl.org/Ticket/Display.html?id=3796

 (verify.pod)

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

Reviewed-by: Andy Polyakov <appro@openssl.org>

Remove CA.sh script and use CA.pl for testing, etc.

Reviewed-by: Richard Levitte <levitte@openssl.org>

The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
the default implementation both end up calling ssleay_rand_bytes. Both may
return -1 in an error condition. If there is insufficient entropy then
both will return 0, but RAND_bytes will additionally add an error to the
error queue. They both return 1 on success.
Therefore the fundamental difference between the two is that one will add an
error to the error queue with insufficient entory whilst the other will not.
Frequently there are constructions of this form:

if(RAND_pseudo_bytes(...) <= 1)
	goto err;

In the above form insufficient entropy is treated as an error anyway, so
RAND_bytes is probably the better form to use.

This form is also seen:
if(!RAND_pseudo_bytes(...))
	goto err;

This is technically not correct at all since a -1 return value is
incorrectly handled - but this form will also treat insufficient entropy as
an error.

Within libssl it is required that you have correctly seeded your entropy
pool and so there seems little benefit in using RAND_pseudo_bytes.
Similarly in libcrypto many operations also require a correctly seeded
entropy pool and so in most interesting cases you would be better off
using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
being incorrectly used in scenarios where security can be compromised by
insufficient entropy.

If you are not using the default implementation, then most engines use the
same function to implement RAND_bytes and RAND_pseudo_bytes in any case.

Given its misuse, limited benefit, and potential to compromise security,
RAND_pseudo_bytes has been deprecated.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Start ensuring all OpenSSL "free" routines allow NULL, and remove
any if check before calling them.
This gets ASN1_OBJECT_free and ASN1_STRING_free.

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

Resync CHANGES with the latest version from 1.0.2.

Reviewed-by: Richard Levitte <levitte@openssl.org>

Suggested by John Foley <foleyj@cisco.com>.

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

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

Includes VMS fixes from Richard.
Includes Kurt's destest fixes (RT 1290).
Closes tickets 1290 and 1291

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

This removes all code surrounded by '#ifdef undef'
One case is left: memmove() replaced by open-coded for loop,
in crypto/stack/stack.c  That needs further review.

Also removed a couple of instances of /* dead code */ if I saw them
while doing the main removal.

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

If you examine changes, you are likely to wonder "but what about ILP64,
elusive as they are, don't they fall victim to 16-bit rationalization?"
No, the case was modeled and verified to work.

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

Rename OPENSSL_SYSNAME_xxx to OPENSSL_SYS_xxx
Remove MS_STATIC; it's a relic from platforms <32 bits.

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

Use setbuf(fp, NULL) instead of setvbuf().  This removes some
ifdef complexity because all of our platforms support setbuf.

Reviewed-by: Richard Levitte <levitte@openssl.org>

OPENSSL_NO_RIPEMD160, OPENSSL_NO_RIPEMD merged into OPENSSL_NO_RMD160
OPENSSL_NO_FP_API merged into OPENSSL_NO_STDIO
Two typo's on #endif comments fixed:
	OPENSSL_NO_ECB fixed to OPENSSL_NO_OCB
	OPENSSL_NO_HW_SureWare fixed to OPENSSL_NO_HW_SUREWARE

Reviewed-by: Richard Levitte <levitte@openssl.org>

This last one for this ticket.  Removes WIN16.
So long, MS_CALLBACK and MS_FAR.  We won't miss you.

Reviewed-by: Richard Levitte <levitte@openssl.org>

This commit removes NCR, Tandem, Cray.
Regenerates TABLE.
Removes another missing BEOS fluff.
The last platform remaining on this ticket is WIN16.

Reviewed-by: Richard Levitte <levitte@openssl.org>

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

This is re-commit without unrelated modification.

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

This reverts commit 4fec9150

.

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

Reviewed-by: Matt 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: Matt Caswell <matt@openssl.org>