openssl/ssl, branch OpenSSL_1_0_2o

make update

2018-03-27T13:55:22Z

Reviewed-by: Richard Levitte

Update copyright year

2018-03-27T12:46:45Z

Reviewed-by: Richard Levitte

Minor style fixup on recent commit

2018-03-05T14:26:05Z

99bb59d at ssl_scan_clienthello_tlsext Reviewed-by: Rich Salz Reviewed-by: Kurt Roeckx (Merged from https://github.com/openssl/openssl/pull/5507)

Checks ec_points_format extension size

2018-02-22T18:56:40Z

Before reading first byte as length Reviewed-by: Matt Caswell Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/5410)

Sanity check the ticket length before using key name/IV

2018-02-21T11:26:25Z

This could in theory result in an overread - but due to the over allocation of the underlying buffer does not represent a security issue. Thanks to Fedor Indutny for reporting this issue. Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/5417)

Swap the check in ssl3_write_pending to avoid using

2018-02-09T18:31:36Z

the possibly indeterminate pointer value in wpend_buf. Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/5309)

Make sure we check an incoming reneg ClientHello in DTLS

2018-01-30T16:07:30Z

In TLS we have a check to make sure an incoming reneg ClientHello is acceptable. The equivalent check is missing in the DTLS code. This means that if a client does not signal the ability to handle secure reneg in the initial handshake, then a subsequent reneg handshake should be rejected by the server. In the DTLS case the reneg was being allowed if the the 2nd ClientHello had a renegotiation_info extension. This is incorrect. While incorrect, this does not represent a security issue because if the renegotiation_info extension is present in the second ClientHello it also has to be *correct*. Therefore this will only work if both the client and server believe they are renegotiating, and both know the previous Finished result. This is not the case in an insecure rengotiation attack. I have also tidied up the check in the TLS code and given a better check for determining whether we are renegotiating or not. Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/5192)

Changed OPENSSL_gmtime so macOS uses threadsafe gmtime_r instead of gmtime.

2018-01-24T15:23:20Z

Updated uses of gmtime to now call OPENSSL_gmtime instead. Used similar preprocessor logic to make sure localtime_r is called instead of localtime when applicable. Reviewed-by: Rich Salz Reviewed-by: Richard Levitte (Merged from https://github.com/openssl/openssl/pull/3609)

Cleanup ctxs if callback fail to retrieve session ticket

2018-01-24T12:17:11Z

If tlsext ticket decrypt callback returns error, cleanup ctxs Reviewed-by: Rich Salz Reviewed-by: Matt Caswell (Merged from https://github.com/openssl/openssl/pull/3273)

Tolerate DTLS alerts with an incorrect version number

2018-01-09T22:14:59Z

In the case of a protocol version alert being sent by a peer the record version number may not be what we are expecting. In DTLS records with an unexpected version number are silently discarded. This probably isn't appropriate for alerts, so we tolerate a mismatch in the minor version number. This resolves an issue reported on openssl-users where an OpenSSL server chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version alert with a 1.2 record number. This was silently ignored by the server. Reviewed-by: Viktor Dukhovni (Merged from https://github.com/openssl/openssl/pull/5019)