deps: upgrade openssl sources to 1.0.2i

This replaces all sources of openssl-1.0.2i.tar.gz into
deps/openssl/openssl

PR-URL: #8714
Reviewed-By: Fedor Indutny <fedor@indutny.com>

deps/openssl/openssl/CHANGES

@@ -2,6 +2,166 @@
  OpenSSL CHANGES
  _______________
 
+ Changes between 1.0.2h and 1.0.2i [22 Sep 2016]
+
+  *) OCSP Status Request extension unbounded memory growth
+
+     A malicious client can send an excessively large OCSP Status Request
+     extension. If that client continually requests renegotiation, sending a
+     large OCSP Status Request extension each time, then there will be unbounded
+     memory growth on the server. This will eventually lead to a Denial Of
+     Service attack through memory exhaustion. Servers with a default
+     configuration are vulnerable even if they do not support OCSP. Builds using
+     the "no-ocsp" build time option are not affected.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6304)
+     [Matt Caswell]
+
+  *) In order to mitigate the SWEET32 attack, the DES ciphers were moved from
+     HIGH to MEDIUM.
+
+     This issue was reported to OpenSSL Karthikeyan Bhargavan and Gaetan
+     Leurent (INRIA)
+     (CVE-2016-2183)
+     [Rich Salz]
+
+  *) OOB write in MDC2_Update()
+
+     An overflow can occur in MDC2_Update() either if called directly or
+     through the EVP_DigestUpdate() function using MDC2. If an attacker
+     is able to supply very large amounts of input data after a previous
+     call to EVP_EncryptUpdate() with a partial block then a length check
+     can overflow resulting in a heap corruption.
+
+     The amount of data needed is comparable to SIZE_MAX which is impractical
+     on most platforms.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6303)
+     [Stephen Henson]
+
+  *) Malformed SHA512 ticket DoS
+
+     If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a
+     DoS attack where a malformed ticket will result in an OOB read which will
+     ultimately crash.
+
+     The use of SHA512 in TLS session tickets is comparatively rare as it requires
+     a custom server callback and ticket lookup mechanism.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6302)
+     [Stephen Henson]
+
+  *) OOB write in BN_bn2dec()
+
+     The function BN_bn2dec() does not check the return value of BN_div_word().
+     This can cause an OOB write if an application uses this function with an
+     overly large BIGNUM. This could be a problem if an overly large certificate
+     or CRL is printed out from an untrusted source. TLS is not affected because
+     record limits will reject an oversized certificate before it is parsed.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-2182)
+     [Stephen Henson]
+
+  *) OOB read in TS_OBJ_print_bio()
+
+     The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is
+     the total length the OID text representation would use and not the amount
+     of data written. This will result in OOB reads when large OIDs are
+     presented.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-2180)
+     [Stephen Henson]
+
+  *) Pointer arithmetic undefined behaviour
+
+     Avoid some undefined pointer arithmetic
+
+     A common idiom in the codebase is to check limits in the following manner:
+     "p + len > limit"
+
+     Where "p" points to some malloc'd data of SIZE bytes and
+     limit == p + SIZE
+
+     "len" here could be from some externally supplied data (e.g. from a TLS
+     message).
+
+     The rules of C pointer arithmetic are such that "p + len" is only well
+     defined where len <= SIZE. Therefore the above idiom is actually
+     undefined behaviour.
+
+     For example this could cause problems if some malloc implementation
+     provides an address for "p" such that "p + len" actually overflows for
+     values of len that are too big and therefore p + len < limit.
+
+     This issue was reported to OpenSSL by Guido Vranken
+     (CVE-2016-2177)
+     [Matt Caswell]
+
+  *) Constant time flag not preserved in DSA signing
+
+     Operations in the DSA signing algorithm should run in constant time in
+     order to avoid side channel attacks. A flaw in the OpenSSL DSA
+     implementation means that a non-constant time codepath is followed for
+     certain operations. This has been demonstrated through a cache-timing
+     attack to be sufficient for an attacker to recover the private DSA key.
+
+     This issue was reported by César Pereida (Aalto University), Billy Brumley
+     (Tampere University of Technology), and Yuval Yarom (The University of
+     Adelaide and NICTA).
+     (CVE-2016-2178)
+     [César Pereida]
+
+  *) DTLS buffered message DoS
+
+     In a DTLS connection where handshake messages are delivered out-of-order
+     those messages that OpenSSL is not yet ready to process will be buffered
+     for later use. Under certain circumstances, a flaw in the logic means that
+     those messages do not get removed from the buffer even though the handshake
+     has been completed. An attacker could force up to approx. 15 messages to
+     remain in the buffer when they are no longer required. These messages will
+     be cleared when the DTLS connection is closed. The default maximum size for
+     a message is 100k. Therefore the attacker could force an additional 1500k
+     to be consumed per connection. By opening many simulataneous connections an
+     attacker could cause a DoS attack through memory exhaustion.
+
+     This issue was reported to OpenSSL by Quan Luo.
+     (CVE-2016-2179)
+     [Matt Caswell]
+
+  *) DTLS replay protection DoS
+
+     A flaw in the DTLS replay attack protection mechanism means that records
+     that arrive for future epochs update the replay protection "window" before
+     the MAC for the record has been validated. This could be exploited by an
+     attacker by sending a record for the next epoch (which does not have to
+     decrypt or have a valid MAC), with a very large sequence number. This means
+     that all subsequent legitimate packets are dropped causing a denial of
+     service for a specific DTLS connection.
+
+     This issue was reported to OpenSSL by the OCAP audit team.
+     (CVE-2016-2181)
+     [Matt Caswell]
+
+  *) Certificate message OOB reads
+
+     In OpenSSL 1.0.2 and earlier some missing message length checks can result
+     in OOB reads of up to 2 bytes beyond an allocated buffer. There is a
+     theoretical DoS risk but this has not been observed in practice on common
+     platforms.
+
+     The messages affected are client certificate, client certificate request
+     and server certificate. As a result the attack can only be performed
+     against a client or a server which enables client authentication.
+
+     This issue was reported to OpenSSL by Shi Lei (Gear Team, Qihoo 360 Inc.)
+     (CVE-2016-6306)
+     [Stephen Henson]
+
  Changes between 1.0.2g and 1.0.2h [3 May 2016]
 
   *) Prevent padding oracle in AES-NI CBC MAC check
@@ -8669,7 +8829,7 @@ des-cbc           3624.96k     5258.21k     5530.91k     5624.30k     5628.26k
 
   *) Source code cleanups: use const where appropriate, eliminate casts,
      use void * instead of char * in lhash.
-     [Ulf Möller]
+     [Ulf Möller] 
 
   *) Bugfix: ssl3_send_server_key_exchange was not restartable
      (the state was not changed to SSL3_ST_SW_KEY_EXCH_B, and because of

deps/openssl/openssl/CONTRIBUTING

@@ -1,38 +1,75 @@
-HOW TO CONTRIBUTE TO OpenSSL
-----------------------------
+HOW TO CONTRIBUTE TO PATCHES OpenSSL
+------------------------------------
 
-Development is coordinated on the openssl-dev mailing list (see
-http://www.openssl.org for information on subscribing). If you
-would like to submit a patch, send it to rt@openssl.org with
-the string "[PATCH]" in the subject. Please be sure to include a
-textual explanation of what your patch does.
-
-You can also make GitHub pull requests. If you do this, please also send
-mail to rt@openssl.org with a brief description and a link to the PR so
-that we can more easily keep track of it.
+(Please visit https://www.openssl.org/community/getting-started.html for
+other ideas about how to contribute.)
 
+Development is coordinated on the openssl-dev mailing list (see the
+above link or https://mta.openssl.org for information on subscribing).
 If you are unsure as to whether a feature will be useful for the general
-OpenSSL community please discuss it on the openssl-dev mailing list first.
-Someone may be already working on the same thing or there may be a good
-reason as to why that feature isn't implemented.
+OpenSSL community you might want to discuss it on the openssl-dev mailing
+list first.  Someone may be already working on the same thing or there
+may be a good reason as to why that feature isn't implemented.
 
-Patches should be as up to date as possible, preferably relative to the
-current Git or the last snapshot. They should follow our coding style
-(see https://www.openssl.org/policies/codingstyle.html) and compile without
-warnings using the --strict-warnings flag.  OpenSSL compiles on many varied
-platforms: try to ensure you only use portable features.
+The best way to submit a patch is to make a pull request on GitHub.
+(It is not necessary to send mail to rt@openssl.org to open a ticket!)
+If you think the patch could use feedback from the community, please
+start a thread on openssl-dev.
 
-Our preferred format for patch files is "git format-patch" output. For example
-to provide a patch file containing the last commit in your local git repository
-use the following command:
+You can also submit patches by sending it as mail to rt@openssl.org.
+Please include the word "PATCH" and an explanation of what the patch
+does in the subject line.  If you do this, our preferred format is "git
+format-patch" output. For example to provide a patch file containing the
+last commit in your local git repository use the following command:
 
-# git format-patch --stdout HEAD^ >mydiffs.patch
+    % git format-patch --stdout HEAD^ >mydiffs.patch
 
 Another method of creating an acceptable patch file without using git is as
 follows:
 
-# cd openssl-work
-# [your changes]
-# ./Configure dist; make clean
-# cd ..
-# diff -ur openssl-orig openssl-work > mydiffs.patch
+    % cd openssl-work
+    ...make your changes...
+    % ./Configure dist; make clean
+    % cd ..
+    % diff -ur openssl-orig openssl-work >mydiffs.patch
+
+Note that pull requests are generally easier for the team, and community, to
+work with.  Pull requests benefit from all of the standard GitHub features,
+including code review tools, simpler integration, and CI build support.
+
+No matter how a patch is submitted, the following items will help make
+the acceptance and review process faster:
+
+    1. Anything other than trivial contributions will require a contributor
+    licensing agreement, giving us permission to use your code. See
+    https://www.openssl.org/policies/cla.html for details.
+
+    2.  All source files should start with the following text (with
+    appropriate comment characters at the start of each line and the
+    year(s) updated):
+
+        Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
+
+        Licensed under the OpenSSL license (the "License").  You may not use
+        this file except in compliance with the License.  You can obtain a copy
+        in the file LICENSE in the source distribution or at
+        https://www.openssl.org/source/license.html
+
+    3.  Patches should be as current as possible.  When using GitHub, please
+    expect to have to rebase and update often. Note that we do not accept merge
+    commits. You will be asked to remove them before a patch is considered
+    acceptable.
+
+    4.  Patches should follow our coding style (see
+    https://www.openssl.org/policies/codingstyle.html) and compile without
+    warnings. Where gcc or clang is availble you should use the
+    --strict-warnings Configure option.  OpenSSL compiles on many varied
+    platforms: try to ensure you only use portable features.
+
+    5.  When at all possible, patches should include tests. These can either be
+    added to an existing test, or completely new.  Please see test/README
+    for information on the test framework.
+
+    6.  New features or changed functionality must include documentation. Please
+    look at the "pod" files in doc/apps, doc/crypto and doc/ssl for examples of
+    our style.

deps/openssl/openssl/Configure

@@ -799,7 +799,7 @@ my @experimental = ();
 
 # This is what $depflags will look like with the above defaults
 # (we need this to see if we should advise the user to run "make depend"):
-my $default_depflags = " -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST";
+my $default_depflags = " -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS";
 
 # Explicit "no-..." options will be collected in %disabled along with the defaults.
 # To remove something from %disabled, use "enable-foo" (unless it's experimental).
@@ -1082,11 +1082,6 @@ if (defined($disabled{"md5"}) || defined($disabled{"sha"})
 	$disabled{"tls1"} = "forced";
 	}
 
-if (defined($disabled{"tls1"}))
-	{
-	$disabled{"tlsext"} = "forced";
-	}
-
 if (defined($disabled{"ec"}) || defined($disabled{"dsa"})
     || defined($disabled{"dh"}))
 	{
@@ -1254,6 +1249,7 @@ my $shared_extension = $fields[$idx_shared_extension];
 my $ranlib = $ENV{'RANLIB'} || $fields[$idx_ranlib];
 my $ar = $ENV{'AR'} || "ar";
 my $arflags = $fields[$idx_arflags];
+my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || "windres";
 my $multilib = $fields[$idx_multilib];
 
 # if $prefix/lib$multilib is not an existing directory, then
@@ -1562,8 +1558,15 @@ $cpuid_obj="mem_clr.o"	unless ($cpuid_obj =~ /\.o$/);
 $des_obj=$des_enc	unless ($des_obj =~ /\.o$/);
 $bf_obj=$bf_enc		unless ($bf_obj =~ /\.o$/);
 $cast_obj=$cast_enc	unless ($cast_obj =~ /\.o$/);
-$rc4_obj=$rc4_enc	unless ($rc4_obj =~ /\.o$/);
 $rc5_obj=$rc5_enc	unless ($rc5_obj =~ /\.o$/);
+if ($rc4_obj =~ /\.o$/)
+	{
+	$cflags.=" -DRC4_ASM";
+	}
+else
+	{
+	$rc4_obj=$rc4_enc;
+	}
 if ($sha1_obj =~ /\.o$/)
 	{
 #	$sha1_obj=$sha1_enc;
@@ -1717,12 +1720,14 @@ while (<IN>)
 		s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/;
 		s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/;
 		s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/;
+		s/^RC=\s*/RC= \$\(CROSS_COMPILE\)/;
 		s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc eq "gcc";
 		}
 	else	{
 		s/^CC=.*$/CC= $cc/;
 		s/^AR=\s*ar/AR= $ar/;
 		s/^RANLIB=.*/RANLIB= $ranlib/;
+		s/^RC=.*/RC= $windres/;
 		s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq "gcc";
 		s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $ecc eq "gcc" || $ecc eq "clang";
 		}

deps/openssl/openssl/INSTALL.W32

@@ -300,17 +300,17 @@
 
  If you link with static OpenSSL libraries [those built with ms/nt.mak],
  then you're expected to additionally link your application with
- WS2_32.LIB, ADVAPI32.LIB, GDI32.LIB and USER32.LIB. Those developing
- non-interactive service applications might feel concerned about linking
- with the latter two, as they are justly associated with interactive
- desktop, which is not available to service processes. The toolkit is
- designed to detect in which context it's currently executed, GUI,
- console app or service, and act accordingly, namely whether or not to
- actually make GUI calls. Additionally those who wish to
- /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and actually keep them
- off service process should consider implementing and exporting from
- .exe image in question own _OPENSSL_isservice not relying on USER32.DLL.
- E.g., on Windows Vista and later you could:
+ WS2_32.LIB, GDI32.LIB, ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those
+ developing non-interactive service applications might feel concerned about
+ linking with GDI32.LIB and USER32.LIB, as they are justly associated with
+ interactive desktop, which is not available to service processes. The toolkit
+ is designed to detect in which context it's currently executed, GUI, console
+ app or service, and act accordingly, namely whether or not to actually make
+ GUI calls. Additionally those who wish to /DELAYLOAD:GDI32.DLL and
+ /DELAYLOAD:USER32.DLL and actually keep them off service process should
+ consider implementing and exporting from .exe image in question own
+ _OPENSSL_isservice not relying on USER32.DLL. E.g., on Windows Vista and
+ later you could:
 
 	__declspec(dllexport) __cdecl BOOL _OPENSSL_isservice(void)
 	{   DWORD sess;