openssl, branch OpenSSL_1_0_2j

Prepare for 1.0.2j release

2016-09-26T09:49:49Z

Reviewed-by: Richard Levitte

Update CHANGES and NEWS for the new release

2016-09-26T09:02:06Z

Reviewed-by: Richard Levitte

Add some sanity checks when checking CRL scores

2016-09-26T08:19:50Z

Note: this was accidentally omitted from OpenSSL 1.0.2 branch. Without this fix any attempt to use CRLs will crash. CVE-2016-7052 Thanks to Bruce Stephens and Thomas Jakobi for reporting this issue. Reviewed-by: Stephen Henson Reviewed-by: Rich Salz

Fix build with no-nextprotoneg

2016-09-22T14:17:45Z

Add a missing ifdef. Same change is already present in master. Reviewed-by: Matt Caswell Reviewed-by: Rich Salz (Merged from https://github.com/openssl/openssl/pull/1100)

Fix typo introduced by a03f81f4

2016-09-22T12:57:09Z

Reviewed-by: Richard Levitte

Prepare for 1.0.2j-dev

2016-09-22T10:25:49Z

Reviewed-by: Richard Levitte

Prepare for 1.0.2i release

2016-09-22T10:24:53Z

Reviewed-by: Richard Levitte

Updates CHANGES and NEWS for new release

2016-09-22T08:22:05Z

Reviewed-by: Richard Levitte

Avoid KCI attack for GOST

2016-09-22T08:22:05Z

Russian GOST ciphersuites are vulnerable to the KCI attack because they use long-term keys to establish the connection when ssl client authorization is on. This change brings the GOST implementation into line with the latest specs in order to avoid the attack. It should not break backwards compatibility. Reviewed-by: Rich Salz Reviewed-by: Richard Levitte Reviewed-by: Matt Caswell

Fix a mem leak in NPN handling

2016-09-22T08:22:05Z

If a server sent multiple NPN extensions in a single ClientHello then a mem leak can occur. This will only happen where the client has requested NPN in the first place. It does not occur during renegotiation. Therefore the maximum that could be leaked in a single connection with a malicious server is 64k (the maximum size of the ServerHello extensions section). As this is client side, only occurs if NPN has been requested and does not occur during renegotiation this is unlikely to be exploitable. Issue reported by Shi Lei. Reviewed-by: Rich Salz