openssl, branch OpenSSL_1_0_0n

Prepare for 1.0.0n release

2014-08-06T21:24:50Z

Reviewed-by: Stephen Henson

make update

2014-08-06T21:24:50Z

Reviewed-by: Stephen Henson

Updates to CHANGES and NEWS

2014-08-06T20:34:00Z

Reviewed-by: Kurt Roeckx

Fix race condition in ssl_parse_serverhello_tlsext

2014-08-06T20:30:39Z

CVE-2014-3509 Reviewed-by: Tim Hudson Reviewed-by: Dr. Stephen Henson

Fix OID handling:

2014-08-06T20:30:39Z

- 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 Reviewed-by: Kurt Roeckx Reviewed-by: Tim Hudson

Fix DTLS anonymous EC(DH) denial of service

2014-08-06T20:30:39Z

CVE-2014-3510 Reviewed-by: Dr. Stephen Henson

Fix protocol downgrade bug in case of fragmented packets

2014-08-06T20:30:39Z

CVE-2014-3511 Reviewed-by: Emilia Käsper Reviewed-by: Bodo Möller

Remove some duplicate DTLS code.

2014-08-06T20:30:39Z

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.

2014-08-06T20:30:39Z

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

Fix return code for truncated DTLS fragment.

2014-08-06T20:30:39Z

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 Reviewed-by: Emilia Käsper