
 OpenSSL CHANGES
 _______________

 This is a high-level summary of the most important changes.
 For a full list of changes, see the git commit log; for example,
 https://github.com/openssl/openssl/commits/ and pick the appropriate
 release branch.

 Changes between 1.1.1za and 1.1.1zb [20 Jan 2025]

 *) Fix timing side-channel in ECDSA signature computation

    There is a timing signal of around 300 nanoseconds when the top word of
    the inverted ECDSA nonce value is zero. This can happen with significant
    probability only for some of the supported elliptic curves. In particular
    the NIST P-521 curve is affected. To be able to measure this leak, the
    attacker process must either be located in the same physical computer or
    must have a very fast network connection with low latency.

    Attacks on ECDSA nonce are also known as Minerva attack.

    [CVE-2024-13176]
    [Tomas Mraz]

 *) Harden BN_GF2m_poly2arr against misuse

    The BN_GF2m_poly2arr() function converts characteristic-2 field
    (GF_{2^m}) Galois polynomials from a representation as a BIGNUM bitmask,
    to a compact array with just the exponents of the non-zero terms.

    These polynomials are then used in BN_GF2m_mod_arr() to perform modular
    reduction.  A precondition of calling BN_GF2m_mod_arr() is that the
    polynomial must have a non-zero constant term (i.e. the array has `0` as
    its final element).

    Internally, callers of BN_GF2m_poly2arr() did not verify that
    precondition, and binary EC curve parameters with an invalid polynomial
    could lead to out of bounds memory reads and writes in BN_GF2m_mod_arr().

    The precondition is always true for polynomials that arise from the
    standard form of EC parameters for characteristic-two fields (X9.62).
    See the "Finite Field Identification" section of:

    https://www.itu.int/ITU-T/formal-language/itu-t/x/x894/2018-cor1/ANSI-X9-62.html

    The OpenSSL GF(2^m) code supports only the trinomial and pentanomial
    basis X9.62 forms.

    This commit updates BN_GF2m_poly2arr() to return `0` (failure) when
    the constant term is zero (i.e. the input bitmask BIGNUM is not odd).

    Additionally, the return value is made unambiguous when there is not
    enough space to also pad the array with a final `-1` sentinel value.
    The return value is now always the number of elements (including the
    final `-1`) that would be filled when the output array is sufficiently
    large.  Previously the same count was returned both when the array has
    just enough room for the final `-1` and when it had only enough space
    for non-sentinel values.

    Finally, BN_GF2m_poly2arr() is updated to reject polynomials whose
    degree exceeds `OPENSSL_ECC_MAX_FIELD_BITS`, this guards against
    CPU exhausition attacks via excessively large inputs.

    The above issues do not arise in processing X.509 certificates.  These
    generally have EC keys from "named curves", and RFC5840 (Section 2.1.1)
    disallows explicit EC parameters.  The TLS code in OpenSSL enforces this
    constraint only after the certificate is decoded, but, even if explicit
    parameters are specified, they are in X9.62 form, which cannot represent
    problem values as noted above.

    (CVE-2024-9143)
    [Viktor Dukhovni]

 Changes between 1.0.2zj and 1.0.2zk [27 May 2024]

 *) Fixed possible buffer overread in SSL_select_next_proto().

    Calling the OpenSSL API function SSL_select_next_proto with an empty
    supported client protocols buffer may cause a crash or memory contents
    to be sent to the peer.

    (CVE-2024-5535)
    [Matt Caswell]

 Changes between 1.0.2zi and 1.0.2zj [25 Jan 2024]

 *) A file in PKCS12 format can contain certificates and keys and may come from
    an untrusted source. The PKCS12 specification allows certain fields to be
    NULL, but OpenSSL did not correctly check for this case. A fix has been
    applied to prevent a NULL pointer dereference that results in OpenSSL
    crashing. If an application processes PKCS12 files from an untrusted source
    using the OpenSSL APIs then that application will be vulnerable to this
    issue prior to this fix.

    OpenSSL APIs that were vulnerable to this are: PKCS12_parse(),
    PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
    and PKCS12_newpass().

    We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
    function is related to writing data we do not consider it security
    significant.

    (CVE-2024-0727)
    [Matt Caswell]

 *) Fix excessive time spent in DH check / generation with large Q parameter
    value.

    Applications that use the functions DH_generate_key() to generate an
    X9.42 DH key may experience long delays. Likewise, applications that use
    DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
    to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
    Where the key or parameters that are being checked have been obtained from
    an untrusted source this may lead to a Denial of Service.

    (CVE-2023-5678)
    [Richard Levitte]

 Changes between 1.0.2zh and 1.0.2zi [1 Aug 2023]

 *) Fix excessive time spent checking DH q parameter value.

    The function DH_check() performs various checks on DH parameters. After
    fixing CVE-2023-3446 it was discovered that a large q parameter value can
    also trigger an overly long computation during some of these checks.
    A correct q value, if present, cannot be larger than the modulus p
    parameter, thus it is unnecessary to perform these checks if q is larger
    than p.

    If DH_check() is called with such q parameter value,
    DH_CHECK_INVALID_Q_VALUE return flag is set and the computationally
    intensive checks are skipped.

    (CVE-2023-3817)
    [Tomáš Mráz]

 *) Fix DH_check() excessive time with over sized modulus

    The function DH_check() performs various checks on DH parameters. One of
    those checks confirms that the modulus ("p" parameter) is not too large.
    Trying to use a very large modulus is slow and OpenSSL will not normally use
    a modulus which is over 10,000 bits in length.

    However the DH_check() function checks numerous aspects of the key or
    parameters that have been supplied. Some of those checks use the supplied
    modulus value even if it has already been found to be too large.

    A new limit has been added to DH_check of 32,768 bits. Supplying a
    key/parameters with a modulus over this size will simply cause DH_check() to
    fail.
    (CVE-2023-3446)
    [Matt Caswell]

 Changes between 1.0.2zg and 1.0.2zh [30 May 2023]

  *) Mitigate for the time it takes for `OBJ_obj2txt` to translate gigantic
     OBJECT IDENTIFIER sub-identifiers to canonical numeric text form.

     OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
     numeric text form.  For gigantic sub-identifiers, this would take a very
     long time, the time complexity being O(n^2) where n is the size of that
     sub-identifier.  (CVE-2023-2650)

     To mitigitate this, `OBJ_obj2txt()` will only translate an OBJECT
     IDENTIFIER to canonical numeric text form if the size of that OBJECT
     IDENTIFIER is 586 bytes or less, and fail otherwise.

     The basis for this restriction is RFC 2578 (STD 58), section 3.5. OBJECT
     IDENTIFIER values, which stipulates that OBJECT IDENTIFIERS may have at
     most 128 sub-identifiers, and that the maximum value that each sub-
     identifier may have is 2^32-1 (4294967295 decimal).

     For each byte of every sub-identifier, only the 7 lower bits are part of
     the value, so the maximum amount of bytes that an OBJECT IDENTIFIER with
     these restrictions may occupy is 32 * 128 / 7, which is approximately 586
     bytes.

     Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5

     [Richard Levitte]

  *) Reworked the Fix for the Timing Oracle in RSA Decryption (CVE-2022-4304).
     The previous fix for this timing side channel turned out to cause
     a severe 2-3x performance regression in the typical use case
     compared to 1.1.1s. The new fix uses existing constant time
     code paths, and restores the previous performance level while
     fully eliminating all existing timing side channels.
     The fix was developed by Bernd Edlinger with testing support
     by Hubert Kario.
     [Bernd Edlinger]

  *) Corrected documentation of X509_VERIFY_PARAM_add0_policy() to mention
     that it does not enable policy checking. Thanks to
     David Benjamin for discovering this issue. (CVE-2023-0466)
     [Tomas Mraz]

  *) Fixed an issue where invalid certificate policies in leaf certificates are
     silently ignored by OpenSSL and other certificate policy checks are skipped
     for that certificate. A malicious CA could use this to deliberately assert
     invalid certificate policies in order to circumvent policy checking on the
     certificate altogether. (CVE-2023-0465)
     [Matt Caswell]

  *) Limited the number of nodes created in a policy tree to mitigate
     against CVE-2023-0464.  The default limit is set to 1000 nodes, which
     should be sufficient for most installations.  If required, the limit
     can be adjusted by setting the OPENSSL_POLICY_TREE_NODES_MAX build
     time define to a desired maximum number of nodes or zero to allow
     unlimited growth. (CVE-2023-0464)
     [Paul Dale]

 Changes between 1.0.2zf and 1.0.2zg [7 Feb 2023]

  *) Fixed X.400 address type confusion in X.509 GeneralName.

     There is a type confusion vulnerability relating to X.400 address processing
     inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
     but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
     vulnerability may allow an attacker who can provide a certificate chain or
     CRL (neither of which need have a valid signature) to pass arbitrary
     pointers to a memcmp call, creating a possible read primitive, subject to
     some constraints. Refer to the advisory for more information. Thanks to
     David Benjamin for discovering this issue. (CVE-2023-0286)

     This issue has been fixed by changing the public header file definition of
     GENERAL_NAME so that x400Address reflects the implementation. It was not
     possible for any existing application to successfully use the existing
     definition; however, if any application references the x400Address field
     (e.g. in dead code), note that the type of this field has changed. There is
     no ABI change.
     [Hugo Landau]

  *) Fixed Use-after-free following BIO_new_NDEF.

     The public API function BIO_new_NDEF is a helper function used for
     streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
     to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
     be called directly by end user applications.

     The function receives a BIO from the caller, prepends a new BIO_f_asn1
     filter BIO onto the front of it to form a BIO chain, and then returns
     the new head of the BIO chain to the caller. Under certain conditions,
     for example if a CMS recipient public key is invalid, the new filter BIO
     is freed and the function returns a NULL result indicating a failure.
     However, in this case, the BIO chain is not properly cleaned up and the
     BIO passed by the caller still retains internal pointers to the previously
     freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
     then a use-after-free will occur. This will most likely result in a crash.
     (CVE-2023-0215)
     [Viktor Dukhovni, Matt Caswell]

  *) Fixed Timing Oracle in RSA Decryption.

     A timing based side channel exists in the OpenSSL RSA Decryption
     implementation which could be sufficient to recover a plaintext across
     a network in a Bleichenbacher style attack. To achieve a successful
     decryption an attacker would have to be able to send a very large number
     of trial messages for decryption. The vulnerability affects all RSA padding
     modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
     (CVE-2022-4304)
     [Dmitry Belyavsky, Hubert Kario]

 Changes between 1.0.2ze and 1.0.2zf [21 Jun 2022]

  *) In addition to the c_rehash shell command injection identified in
     CVE-2022-1292, further bugs where the c_rehash script does not
     properly sanitise shell metacharacters to prevent command injection have been
     fixed.

     When the CVE-2022-1292 was fixed it was not discovered that there
     are other places in the script where the file names of certificates
     being hashed were possibly passed to a command executed through the shell.

     This script is distributed by some operating systems in a manner where
     it is automatically executed.  On such operating systems, an attacker
     could execute arbitrary commands with the privileges of the script.
     (CVE-2022-2068)
     [Daniel Fiala, Tomáš Mráz]

 Changes between 1.0.2zd and 1.0.2ze [3 May 2022]

  *) Fixed a bug in the c_rehash script which was not properly sanitising shell
    metacharacters to prevent command injection.  This script is distributed by
    some operating systems in a manner where it is automatically executed.  On
    such operating systems, an attacker could execute arbitrary commands with the
    privileges of the script.
    (CVE-2022-1292)
    [Tomáš Mráz]

 Changes between 1.0.2zc and 1.0.2zd [15 Mar 2022]

  *) Fixed a bug in the BN_mod_sqrt() function that can cause it to loop forever
     for non-prime moduli.

     Internally this function is used when parsing an elliptic curve public key
     in compressed form or explicit elliptic curve parameters with a base point
     encoded in compressed form.

     It is possible to trigger the infinite loop by crafting a certificate that
     has invalid explicit curve parameters and then performing an operation
     that requires the public key. For example the attacker can use a
     self-signed certificate to trigger the loop during verification of the
     certificate signature. Any process that parses and verifies an externally
     supplied certificate may thus be subject to a denial of service attack. The
     infinite loop can also be reached when parsing crafted private keys as they
     can contain explicit elliptic curve parameters.

     Thus vulnerable situations include:

      - TLS clients consuming server certificates
      - TLS servers consuming client certificates
      - Hosting providers taking certificates or private keys from customers
      - Certificate authorities parsing certification requests from subscribers
      - Anything else which parses ASN.1 elliptic curve parameters

     Also any other applications that use the BN_mod_sqrt() where the attacker
     can control the parameter values are vulnerable to this DoS issue.
     (CVE-2022-0778)
     [Tomáš Mráz]

 Changes between 1.0.2zb and 1.0.2zc [22 Feb 2022]

  *) If the X509_V_FLAG_X509_STRICT flag is set in the certificate verification
     parameters any certificates with explicit elliptic curve parameters will be
     rejected if present in the certificate chain to be verified.
     [Tomáš Mráz]

 Changes between 1.0.2za and 1.0.2zb [23 Sep 2021]

  *) The X509_V_FLAG_TRUSTED_FIRST is set by default on certificate verification
     if -DOPENSSL_TRUSTED_FIRST_DEFAULT is used with the build configuration.
     [Tomáš Mráz]

 Changes between 1.0.2y and 1.0.2za [24 Aug 2021]

  *) Fixed an SM2 Decryption Buffer Overflow.

     In order to decrypt SM2 encrypted data an application is expected to call the
     API function EVP_PKEY_decrypt(). Typically an application will call this
     function twice. The first time, on entry, the "out" parameter can be NULL and,
     on exit, the "outlen" parameter is populated with the buffer size required to
     hold the decrypted plaintext. The application can then allocate a sufficiently
     sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL
     value for the "out" parameter.

     A bug in the implementation of the SM2 decryption code means that the
     calculation of the buffer size required to hold the plaintext returned by the
     first call to EVP_PKEY_decrypt() can be smaller than the actual size required by
     the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is
     called by the application a second time with a buffer that is too small.

     A malicious attacker who is able present SM2 content for decryption to an
     application could cause attacker chosen data to overflow the buffer by up to a
     maximum of 62 bytes altering the contents of other data held after the
     buffer, possibly changing application behaviour or causing the application to
     crash. The location of the buffer is application dependent but is typically
     heap allocated.
     (CVE-2021-3711)
     [Matt Caswell]

  *) Fixed various read buffer overruns processing ASN.1 strings

     ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
     structure which contains a buffer holding the string data and a field holding
     the buffer length. This contrasts with normal C strings which are repesented as
     a buffer for the string data which is terminated with a NUL (0) byte.

     Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
     own "d2i" functions (and other similar parsing functions) as well as any string
     whose value has been set with the ASN1_STRING_set() function will additionally
     NUL terminate the byte array in the ASN1_STRING structure.

     However, it is possible for applications to directly construct valid ASN1_STRING
     structures which do not NUL terminate the byte array by directly setting the
     "data" and "length" fields in the ASN1_STRING array. This can also happen by
     using the ASN1_STRING_set0() function.

     Numerous OpenSSL functions that print ASN.1 data have been found to assume that
     the ASN1_STRING byte array will be NUL terminated, even though this is not
     guaranteed for strings that have been directly constructed. Where an application
     requests an ASN.1 structure to be printed, and where that ASN.1 structure
     contains ASN1_STRINGs that have been directly constructed by the application
     without NUL terminating the "data" field, then a read buffer overrun can occur.

     The same thing can also occur during name constraints processing of certificates
     (for example if a certificate has been directly constructed by the application
     instead of loading it via the OpenSSL parsing functions, and the certificate
     contains non NUL terminated ASN1_STRING structures). It can also occur in the
     X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions.

     If a malicious actor can cause an application to directly construct an
     ASN1_STRING and then process it through one of the affected OpenSSL functions
     then this issue could be hit. This might result in a crash (causing a Denial of
     Service attack). It could also result in the disclosure of private memory
     contents (such as private keys, or sensitive plaintext).
     (CVE-2021-3712)
     [Matt Caswell]

 Changes between 1.0.2x and 1.0.2y [16 Feb 2021]

  *) Fixed the X509_issuer_and_serial_hash() function. It attempts to
     create a unique hash value based on the issuer and serial number data
     contained within an X509 certificate. However it was failing to correctly
     handle any errors that may occur while parsing the issuer field (which might
     occur if the issuer field is maliciously constructed). This may subsequently
     result in a NULL pointer deref and a crash leading to a potential denial of
     service attack.
     (CVE-2021-23841)
     [Matt Caswell]

  *) Fixed an SSLv2 rollback attack vulnerability. If a client attempts to
     negotiate SSLv2 with a server that is configured to support both SSLv2 and
     more recent SSL and TLS versions then a check is made for a version
     rollback attack when unpadding an RSA signature. Clients that support SSL
     or TLS versions greater than SSLv2 are supposed to use a special form of
     padding. A server that supports greater than SSLv2 is supposed to reject
     connection attempts from a client where this special form of padding is
     present, because this indicates that a version rollback has occurred (i.e.
     both client and server support greater than SSLv2, and yet this is the
     version that is being requested).

     The implementation of this padding check inverted the logic so that the
     connection attempt is accepted if the padding is present, and rejected if
     it is absent. This means that such as server will accept a connection if a
     version rollback attack has occurred. Further the server will erroneously
     reject a connection if a normal SSLv2 connection attempt is made.
     (CVE-2021-23839)
     [Matt Caswell]

  *) Fixed the EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate
     functions. Previously they could overflow the output length argument in some
     cases where the input length is close to the maximum permissable length for
     an integer on the platform. In such cases the return value from the function
     call would be 1 (indicating success), but the output length value would be
     negative. This could cause applications to behave incorrectly or crash.
     (CVE-2021-23840)
     [Matt Caswell]

  *) Fixed SRP_Calc_client_key so that it runs in constant time. The previous
     implementation called BN_mod_exp without setting BN_FLG_CONSTTIME. This
     could be exploited in a side channel attack to recover the password. Since
     the attack is local host only this is outside of the current OpenSSL
     threat model and therefore no CVE is assigned.

     Thanks to Mohammed Sabt and Daniel De Almeida Braga for reporting this
     issue.
     [Matt Caswell]

 Changes between 1.0.2w and 1.0.2x [8 Dec 2020]

  *) Fixed NULL pointer deref in the GENERAL_NAME_cmp function
     This function could crash if both GENERAL_NAMEs contain an EDIPARTYNAME.
     If an attacker can control both items being compared  then this could lead
     to a possible denial of service attack. OpenSSL itself uses the
     GENERAL_NAME_cmp function for two purposes:
     1) Comparing CRL distribution point names between an available CRL and a
        CRL distribution point embedded in an X509 certificate
     2) When verifying that a timestamp response token signer matches the
        timestamp authority name (exposed via the API functions
        TS_RESP_verify_response and TS_RESP_verify_token)
     (CVE-2020-1971)
     [Matt Caswell]

 Changes between 1.0.2v and 1.0.2w [9 Sep 2020]

  *) Due to the Raccoon attack static "DH" ciphersuites have been moved to the
     "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled
     in by default. Support can be added by configuring OpenSSL at compile time
     with the "enable-weak-ssl-ciphers" option.
     This is not recommended.
     (CVE-2020-1968)
     [Matt Caswell]

  *) As a response to the Raccoon attack (CVE-2020-1968) the option
     SSL_OP_SINGLE_ECDH_USE has been made the default and mandaotry (i.e. you
     cannnot turn it off). This means that ephemeral ECDH secrets are never
     reused across TLS connections. While Raccoon only affects DH (not ECDH)
     this change has been made as a precautionary measure.
     [Matt Caswell]

 Changes between 1.0.2u and 1.0.2v [5 May 2020]

  *) Implemented coordinate blinding for the generic implementations of both
     binary and prime elliptic curves to avoid leaking bits of the scalar and,
     potentially, bug attacks. A group of security researchers and
     cryptographers from academia and industry, listed below, reported a
     successful cache timing attack in OpenSSL 1.0.2u against specific prime and
     binary curves whose order or field length is close to a word boundary. They
     also provided the fix. This attack does not fit the OpenSSL threat model
     and so no CVE is assigned, but a fix is implemented nonetheless.
     [Diego F. Aranha, Akira Takahashi, Mehdi Tibouchi, Yuval Yarom]

 Changes between 1.0.2t and 1.0.2u [20 Dec 2019]

  *) Fixed an an overflow bug in the x64_64 Montgomery squaring procedure
     used in exponentiation with 512-bit moduli. No EC algorithms are
     affected. Analysis suggests that attacks against 2-prime RSA1024,
     3-prime RSA1536, and DSA1024 as a result of this defect would be very
     difficult to perform and are not believed likely. Attacks against DH512
     are considered just feasible. However, for an attack the target would
     have to re-use the DH512 private key, which is not recommended anyway.
     Also applications directly using the low level API BN_mod_exp may be
     affected if they use BN_FLG_CONSTTIME.
     (CVE-2019-1551)
     [Andy Polyakov]

 Changes between 1.0.2s and 1.0.2t [10 Sep 2019]

   *) For built-in EC curves, ensure an EC_GROUP built from the curve name is
      used even when parsing explicit parameters, when loading a serialized key
      or calling `EC_GROUP_new_from_ecpkparameters()`/
      `EC_GROUP_new_from_ecparameters()`.
      This prevents bypass of security hardening and performance gains,
      especially for curves with specialized EC_METHODs.
      By default, if a key encoded with explicit parameters is loaded and later
      serialized, the output is still encoded with explicit parameters, even if
      internally a "named" EC_GROUP is used for computation.
      [Nicola Tuveri]

  *) Compute ECC cofactors if not provided during EC_GROUP construction. Before
     this change, EC_GROUP_set_generator would accept order and/or cofactor as
     NULL. After this change, only the cofactor parameter can be NULL. It also
     does some minimal sanity checks on the passed order.
     (CVE-2019-1547)
     [Billy Bob Brumley]

  *) Fixed a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey.
     An attack is simple, if the first CMS_recipientInfo is valid but the
     second CMS_recipientInfo is chosen ciphertext. If the second
     recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct
     encryption key will be replaced by garbage, and the message cannot be
     decoded, but if the RSA decryption fails, the correct encryption key is
     used and the recipient will not notice the attack.
     As a work around for this potential attack the length of the decrypted
     key must be equal to the cipher default key length, in case the
     certifiate is not given and all recipientInfo are tried out.
     The old behaviour can be re-enabled in the CMS code by setting the
     CMS_DEBUG_DECRYPT flag.
     (CVE-2019-1563)
     [Bernd Edlinger]

  *) Document issue with installation paths in diverse Windows builds

     '/usr/local/ssl' is an unsafe prefix for location to install OpenSSL
     binaries and run-time config file.
     (CVE-2019-1552)
     [Richard Levitte]

 Changes between 1.0.2r and 1.0.2s [28 May 2019]

  *) Change the default RSA, DSA and DH size to 2048 bit instead of 1024.
     This changes the size when using the genpkey app when no size is given. It
     fixes an omission in earlier changes that changed all RSA, DSA and DH
     generation apps to use 2048 bits by default.
     [Kurt Roeckx]

  *) Add FIPS support for Android Arm 64-bit

     Support for Android Arm 64-bit was added to the OpenSSL FIPS Object
     Module in Version 2.0.10. For some reason, the corresponding target
     'android64-aarch64' was missing OpenSSL 1.0.2, whence it could not be
     built with FIPS support on Android Arm 64-bit. This omission has been
     fixed.
     [Matthias St. Pierre]

 Changes between 1.0.2q and 1.0.2r [26 Feb 2019]

  *) 0-byte record padding oracle

     If an application encounters a fatal protocol error and then calls
     SSL_shutdown() twice (once to send a close_notify, and once to receive one)
     then OpenSSL can respond differently to the calling application if a 0 byte
     record is received with invalid padding compared to if a 0 byte record is
     received with an invalid MAC. If the application then behaves differently
     based on that in a way that is detectable to the remote peer, then this
     amounts to a padding oracle that could be used to decrypt data.

     In order for this to be exploitable "non-stitched" ciphersuites must be in
     use. Stitched ciphersuites are optimised implementations of certain
     commonly used ciphersuites. Also the application must call SSL_shutdown()
     twice even if a protocol error has occurred (applications should not do
     this but some do anyway).

     This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod
     Aviram, with additional investigation by Steven Collison and Andrew
     Hourselt. It was reported to OpenSSL on 10th December 2018.
     (CVE-2019-1559)
     [Matt Caswell]

  *) Move strictness check from EVP_PKEY_asn1_new() to EVP_PKEY_asn1_add0().
     [Richard Levitte]

 Changes between 1.0.2p and 1.0.2q [20 Nov 2018]

  *) Microarchitecture timing vulnerability in ECC scalar multiplication

     OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been
     shown to be vulnerable to a microarchitecture timing side channel attack.
     An attacker with sufficient access to mount local timing attacks during
     ECDSA signature generation could recover the private key.

     This issue was reported to OpenSSL on 26th October 2018 by Alejandro
     Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and
     Nicola Tuveri.
     (CVE-2018-5407)
     [Billy Brumley]

  *) Timing vulnerability in DSA signature generation

     The OpenSSL DSA signature algorithm has been shown to be vulnerable to a
     timing side channel attack. An attacker could use variations in the signing
     algorithm to recover the private key.

     This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser.
     (CVE-2018-0734)
     [Paul Dale]

  *) Resolve a compatibility issue in EC_GROUP handling with the FIPS Object
     Module, accidentally introduced while backporting security fixes from the
     development branch and hindering the use of ECC in FIPS mode.
     [Nicola Tuveri]

 Changes between 1.0.2o and 1.0.2p [14 Aug 2018]

  *) Client DoS due to large DH parameter

     During key agreement in a TLS handshake using a DH(E) based ciphersuite a
     malicious server can send a very large prime value to the client. This will
     cause the client to spend an unreasonably long period of time generating a
     key for this prime resulting in a hang until the client has finished. This
     could be exploited in a Denial Of Service attack.

     This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken
     (CVE-2018-0732)
     [Guido Vranken]

  *) Cache timing vulnerability in RSA Key Generation

     The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to
     a cache timing side channel attack. An attacker with sufficient access to
     mount cache timing attacks during the RSA key generation process could
     recover the private key.

     This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
     Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
     (CVE-2018-0737)
     [Billy Brumley]

  *) Make EVP_PKEY_asn1_new() a bit stricter about its input.  A NULL pem_str
     parameter is no longer accepted, as it leads to a corrupt table.  NULL
     pem_str is reserved for alias entries only.
     [Richard Levitte]

  *) Revert blinding in ECDSA sign and instead make problematic addition
     length-invariant. Switch even to fixed-length Montgomery multiplication.
     [Andy Polyakov]

  *) Change generating and checking of primes so that the error rate of not
     being prime depends on the intended use based on the size of the input.
     For larger primes this will result in more rounds of Miller-Rabin.
     The maximal error rate for primes with more than 1080 bits is lowered
     to 2^-128.
     [Kurt Roeckx, Annie Yousar]

  *) Increase the number of Miller-Rabin rounds for DSA key generating to 64.
     [Kurt Roeckx]

  *) Add blinding to ECDSA and DSA signatures to protect against side channel
     attacks discovered by Keegan Ryan (NCC Group).
     [Matt Caswell]

  *) When unlocking a pass phrase protected PEM file or PKCS#8 container, we
     now allow empty (zero character) pass phrases.
     [Richard Levitte]

  *) Certificate time validation (X509_cmp_time) enforces stricter
     compliance with RFC 5280. Fractional seconds and timezone offsets
     are no longer allowed.
     [Emilia Käsper]

 Changes between 1.0.2n and 1.0.2o [27 Mar 2018]

  *) Constructed ASN.1 types with a recursive definition could exceed the stack

     Constructed ASN.1 types with a recursive definition (such as can be found
     in PKCS7) could eventually exceed the stack given malicious input with
     excessive recursion. This could result in a Denial Of Service attack. There
     are no such structures used within SSL/TLS that come from untrusted sources
     so this is considered safe.

     This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz
     project.
     (CVE-2018-0739)
     [Matt Caswell]

 Changes between 1.0.2m and 1.0.2n [7 Dec 2017]

  *) Read/write after SSL object in error state

     OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
     mechanism. The intent was that if a fatal error occurred during a handshake
     then OpenSSL would move into the error state and would immediately fail if
     you attempted to continue the handshake. This works as designed for the
     explicit handshake functions (SSL_do_handshake(), SSL_accept() and
     SSL_connect()), however due to a bug it does not work correctly if
     SSL_read() or SSL_write() is called directly. In that scenario, if the
     handshake fails then a fatal error will be returned in the initial function
     call. If SSL_read()/SSL_write() is subsequently called by the application
     for the same SSL object then it will succeed and the data is passed without
     being decrypted/encrypted directly from the SSL/TLS record layer.

     In order to exploit this issue an application bug would have to be present
     that resulted in a call to SSL_read()/SSL_write() being issued after having
     already received a fatal error.

     This issue was reported to OpenSSL by David Benjamin (Google).
     (CVE-2017-3737)
     [Matt Caswell]

  *) rsaz_1024_mul_avx2 overflow bug on x86_64

     There is an overflow bug in the AVX2 Montgomery multiplication procedure
     used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
     Analysis suggests that attacks against RSA and DSA as a result of this
     defect would be very difficult to perform and are not believed likely.
     Attacks against DH1024 are considered just feasible, because most of the
     work necessary to deduce information about a private key may be performed
     offline. The amount of resources required for such an attack would be
     significant. However, for an attack on TLS to be meaningful, the server
     would have to share the DH1024 private key among multiple clients, which is
     no longer an option since CVE-2016-0701.

     This only affects processors that support the AVX2 but not ADX extensions
     like Intel Haswell (4th generation).

     This issue was reported to OpenSSL by David Benjamin (Google). The issue
     was originally found via the OSS-Fuzz project.
     (CVE-2017-3738)
     [Andy Polyakov]

 Changes between 1.0.2l and 1.0.2m [2 Nov 2017]

  *) bn_sqrx8x_internal carry bug on x86_64

     There is a carry propagating bug in the x86_64 Montgomery squaring
     procedure. No EC algorithms are affected. Analysis suggests that attacks
     against RSA and DSA as a result of this defect would be very difficult to
     perform and are not believed likely. Attacks against DH are considered just
     feasible (although very difficult) because most of the work necessary to
     deduce information about a private key may be performed offline. The amount
     of resources required for such an attack would be very significant and
     likely only accessible to a limited number of attackers. An attacker would
     additionally need online access to an unpatched system using the target
     private key in a scenario with persistent DH parameters and a private
     key that is shared between multiple clients.

     This only affects processors that support the BMI1, BMI2 and ADX extensions
     like Intel Broadwell (5th generation) and later or AMD Ryzen.

     This issue was reported to OpenSSL by the OSS-Fuzz project.
     (CVE-2017-3736)
     [Andy Polyakov]

  *) Malformed X.509 IPAddressFamily could cause OOB read

     If an X.509 certificate has a malformed IPAddressFamily extension,
     OpenSSL could do a one-byte buffer overread. The most likely result
     would be an erroneous display of the certificate in text format.

     This issue was reported to OpenSSL by the OSS-Fuzz project.
     (CVE-2017-3735)
     [Rich Salz]

 Changes between 1.0.2k and 1.0.2l [25 May 2017]

  *) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the target
     platform rather than 'mingw'.
     [Richard Levitte]

 Changes between 1.0.2j and 1.0.2k [26 Jan 2017]

  *) Truncated packet could crash via OOB read

     If one side of an SSL/TLS path is running on a 32-bit host and a specific
     cipher is being used, then a truncated packet can cause that host to
     perform an out-of-bounds read, usually resulting in a crash.

     This issue was reported to OpenSSL by Robert Święcki of Google.
     (CVE-2017-3731)
     [Andy Polyakov]

  *) BN_mod_exp may produce incorrect results on x86_64

     There is a carry propagating bug in the x86_64 Montgomery squaring
     procedure. No EC algorithms are affected. Analysis suggests that attacks
     against RSA and DSA as a result of this defect would be very difficult to
     perform and are not believed likely. Attacks against DH are considered just
     feasible (although very difficult) because most of the work necessary to
     deduce information about a private key may be performed offline. The amount
     of resources required for such an attack would be very significant and
     likely only accessible to a limited number of attackers. An attacker would
     additionally need online access to an unpatched system using the target
     private key in a scenario with persistent DH parameters and a private
     key that is shared between multiple clients. For example this can occur by
     default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
     similar to CVE-2015-3193 but must be treated as a separate problem.

     This issue was reported to OpenSSL by the OSS-Fuzz project.
     (CVE-2017-3732)
     [Andy Polyakov]

  *) Montgomery multiplication may produce incorrect results

     There is a carry propagating bug in the Broadwell-specific Montgomery
     multiplication procedure that handles input lengths divisible by, but
     longer than 256 bits. Analysis suggests that attacks against RSA, DSA
     and DH private keys are impossible. This is because the subroutine in
     question is not used in operations with the private key itself and an input
     of the attacker's direct choice. Otherwise the bug can manifest itself as
     transient authentication and key negotiation failures or reproducible
     erroneous outcome of public-key operations with specially crafted input.
     Among EC algorithms only Brainpool P-512 curves are affected and one
     presumably can attack ECDH key negotiation. Impact was not analyzed in
     detail, because pre-requisites for attack are considered unlikely. Namely
     multiple clients have to choose the curve in question and the server has to
     share the private key among them, neither of which is default behaviour.
     Even then only clients that chose the curve will be affected.

     This issue was publicly reported as transient failures and was not
     initially recognized as a security issue. Thanks to Richard Morgan for
     providing reproducible case.
     (CVE-2016-7055)
     [Andy Polyakov]

  *) OpenSSL now fails if it receives an unrecognised record type in TLS1.0
     or TLS1.1. Previously this only happened in SSLv3 and TLS1.2. This is to
     prevent issues where no progress is being made and the peer continually
     sends unrecognised record types, using up resources processing them.
     [Matt Caswell]

 Changes between 1.0.2i and 1.0.2j [26 Sep 2016]

  *) Missing CRL sanity check

     A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
     but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
     CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.

     This issue only affects the OpenSSL 1.0.2i
     (CVE-2016-7052)
     [Matt Caswell]

 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

     A MITM attacker can use a padding oracle attack to decrypt traffic
     when the connection uses an AES CBC cipher and the server support
     AES-NI.

     This issue was introduced as part of the fix for Lucky 13 padding
     attack (CVE-2013-0169). The padding check was rewritten to be in
     constant time by making sure that always the same bytes are read and
     compared against either the MAC or padding bytes. But it no longer
     checked that there was enough data to have both the MAC and padding
     bytes.

     This issue was reported by Juraj Somorovsky using TLS-Attacker.
     (CVE-2016-2107)
     [Kurt Roeckx]

  *) Fix EVP_EncodeUpdate overflow

     An overflow can occur in the EVP_EncodeUpdate() function which is used for
     Base64 encoding of binary data. If an attacker is able to supply very large
     amounts of input data then a length check can overflow resulting in a heap
     corruption.

     Internally to OpenSSL the EVP_EncodeUpdate() function is primarly used by
     the PEM_write_bio* family of functions. These are mainly used within the
     OpenSSL command line applications, so any application which processes data
     from an untrusted source and outputs it as a PEM file should be considered
     vulnerable to this issue. User applications that call these APIs directly
     with large amounts of untrusted data may also be vulnerable.

     This issue was reported by Guido Vranken.
     (CVE-2016-2105)
     [Matt Caswell]

  *) Fix EVP_EncryptUpdate overflow

     An overflow can occur in the EVP_EncryptUpdate() function. 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. Following an analysis of all OpenSSL
     internal usage of the EVP_EncryptUpdate() function all usage is one of two
     forms. The first form is where the EVP_EncryptUpdate() call is known to be
     the first called function after an EVP_EncryptInit(), and therefore that
     specific call must be safe. The second form is where the length passed to
     EVP_EncryptUpdate() can be seen from the code to be some small value and
     therefore there is no possibility of an overflow. Since all instances are
     one of these two forms, it is believed that there can be no overflows in
     internal code due to this problem. It should be noted that
     EVP_DecryptUpdate() can call EVP_EncryptUpdate() in certain code paths.
     Also EVP_CipherUpdate() is a synonym for EVP_EncryptUpdate(). All instances
     of these calls have also been analysed too and it is believed there are no
     instances in internal usage where an overflow could occur.

     This issue was reported by Guido Vranken.
     (CVE-2016-2106)
     [Matt Caswell]

  *) Prevent ASN.1 BIO excessive memory allocation

     When ASN.1 data is read from a BIO using functions such as d2i_CMS_bio()
     a short invalid encoding can casuse allocation of large amounts of memory
     potentially consuming excessive resources or exhausting memory.

     Any application parsing untrusted data through d2i BIO functions is
     affected. The memory based functions such as d2i_X509() are *not* affected.
     Since the memory based functions are used by the TLS library, TLS
     applications are not affected.

     This issue was reported by Brian Carpenter.
     (CVE-2016-2109)
     [Stephen Henson]

  *) EBCDIC overread

     ASN1 Strings that are over 1024 bytes can cause an overread in applications
     using the X509_NAME_oneline() function on EBCDIC systems. This could result
     in arbitrary stack data being returned in the buffer.

     This issue was reported by Guido Vranken.
     (CVE-2016-2176)
     [Matt Caswell]

  *) Modify behavior of ALPN to invoke callback after SNI/servername
     callback, such that updates to the SSL_CTX affect ALPN.
     [Todd Short]

  *) Remove LOW from the DEFAULT cipher list.  This removes singles DES from the
     default.
     [Kurt Roeckx]

  *) Only remove the SSLv2 methods with the no-ssl2-method option. When the
     methods are enabled and ssl2 is disabled the methods return NULL.
     [Kurt Roeckx]

 Changes between 1.0.2f and 1.0.2g [1 Mar 2016]

  * Disable weak ciphers in SSLv3 and up in default builds of OpenSSL.
    Builds that are not configured with "enable-weak-ssl-ciphers" will not
    provide any "EXPORT" or "LOW" strength ciphers.
    [Viktor Dukhovni]

  * Disable SSLv2 default build, default negotiation and weak ciphers.  SSLv2
    is by default disabled at build-time.  Builds that are not configured with
    "enable-ssl2" will not support SSLv2.  Even if "enable-ssl2" is used,
    users who want to negotiate SSLv2 via the version-flexible SSLv23_method()
    will need to explicitly call either of:

        SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
    or
        SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

    as appropriate.  Even if either of those is used, or the application
    explicitly uses the version-specific SSLv2_method() or its client and
    server variants, SSLv2 ciphers vulnerable to exhaustive search key
    recovery have been removed.  Specifically, the SSLv2 40-bit EXPORT
    ciphers, and SSLv2 56-bit DES are no longer available.
    (CVE-2016-0800)
    [Viktor Dukhovni]

  *) Fix a double-free in DSA code

     A double free bug was discovered when OpenSSL parses malformed DSA private
     keys and could lead to a DoS attack or memory corruption for applications
     that receive DSA private keys from untrusted sources.  This scenario is
     considered rare.

     This issue was reported to OpenSSL by Adam Langley(Google/BoringSSL) using
     libFuzzer.
     (CVE-2016-0705)
     [Stephen Henson]

  *) Disable SRP fake user seed to address a server memory leak.

     Add a new method SRP_VBASE_get1_by_user that handles the seed properly.

     SRP_VBASE_get_by_user had inconsistent memory management behaviour.
     In order to fix an unavoidable memory leak, SRP_VBASE_get_by_user
     was changed to ignore the "fake user" SRP seed, even if the seed
     is configured.

     Users should use SRP_VBASE_get1_by_user instead. Note that in
     SRP_VBASE_get1_by_user, caller must free the returned value. Note
     also that even though configuring the SRP seed attempts to hide
     invalid usernames by continuing the handshake with fake
     credentials, this behaviour is not constant time and no strong
     guarantees are made that the handshake is indistinguishable from
     that of a valid user.
     (CVE-2016-0798)
     [Emilia Käsper]

  *) Fix BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption

     In the BN_hex2bn function the number of hex digits is calculated using an
     int value |i|. Later |bn_expand| is called with a value of |i * 4|. For
     large values of |i| this can result in |bn_expand| not allocating any
     memory because |i * 4| is negative. This can leave the internal BIGNUM data
     field as NULL leading to a subsequent NULL ptr deref. For very large values
     of |i|, the calculation |i * 4| could be a positive value smaller than |i|.
     In this case memory is allocated to the internal BIGNUM data field, but it
     is insufficiently sized leading to heap corruption. A similar issue exists
     in BN_dec2bn. This could have security consequences if BN_hex2bn/BN_dec2bn
     is ever called by user applications with very large untrusted hex/dec data.
     This is anticipated to be a rare occurrence.

     All OpenSSL internal usage of these functions use data that is not expected
     to be untrusted, e.g. config file data or application command line
     arguments. If user developed applications generate config file data based
     on untrusted data then it is possible that this could also lead to security
     consequences. This is also anticipated to be rare.

     This issue was reported to OpenSSL by Guido Vranken.
     (CVE-2016-0797)
     [Matt Caswell]

  *) Fix memory issues in BIO_*printf functions

     The internal |fmtstr| function used in processing a "%s" format string in
     the BIO_*printf functions could overflow while calculating the length of a
     string and cause an OOB read when printing very long strings.

     Additionally the internal |doapr_outch| function can attempt to write to an
     OOB memory location (at an offset from the NULL pointer) in the event of a
     memory allocation failure. In 1.0.2 and below this could be caused where
     the size of a buffer to be allocated is greater than INT_MAX. E.g. this
     could be in processing a very long "%s" format string. Memory leaks can
     also occur.

     The first issue may mask the second issue dependent on compiler behaviour.
     These problems could enable attacks where large amounts of untrusted data
     is passed to the BIO_*printf functions. If applications use these functions
     in this way then they could be vulnerable. OpenSSL itself uses these
     functions when printing out human-readable dumps of ASN.1 data. Therefore
     applications that print this data could be vulnerable if the data is from
     untrusted sources. OpenSSL command line applications could also be
     vulnerable where they print out ASN.1 data, or if untrusted data is passed
     as command line arguments.

     Libssl is not considered directly vulnerable. Additionally certificates etc
     received via remote connections via libssl are also unlikely to be able to
     trigger these issues because of message size limits enforced within libssl.

     This issue was reported to OpenSSL Guido Vranken.
     (CVE-2016-0799)
     [Matt Caswell]

  *) Side channel attack on modular exponentiation

     A side-channel attack was found which makes use of cache-bank conflicts on
     the Intel Sandy-Bridge microarchitecture which could lead to the recovery
     of RSA keys.  The ability to exploit this issue is limited as it relies on
     an attacker who has control of code in a thread running on the same
     hyper-threaded core as the victim thread which is performing decryptions.

     This issue was reported to OpenSSL by Yuval Yarom, The University of
     Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv University, and
     Nadia Heninger, University of Pennsylvania with more information at
     http://cachebleed.info.
     (CVE-2016-0702)
     [Andy Polyakov]

  *) Change the req app to generate a 2048-bit RSA/DSA key by default,
     if no keysize is specified with default_bits. This fixes an
     omission in an earlier change that changed all RSA/DSA key generation
     apps to use 2048 bits by default.
     [Emilia Käsper]

 Changes between 1.0.2e and 1.0.2f [28 Jan 2016]

  *) DH small subgroups

     Historically OpenSSL only ever generated DH parameters based on "safe"
     primes. More recently (in version 1.0.2) support was provided for
     generating X9.42 style parameter files such as those required for RFC 5114
     support. The primes used in such files may not be "safe". Where an
     application is using DH configured with parameters based on primes that are
     not "safe" then an attacker could use this fact to find a peer's private
     DH exponent. This attack requires that the attacker complete multiple
     handshakes in which the peer uses the same private DH exponent. For example
     this could be used to discover a TLS server's private DH exponent if it's
     reusing the private DH exponent or it's using a static DH ciphersuite.

     OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in
     TLS. It is not on by default. If the option is not set then the server
     reuses the same private DH exponent for the life of the server process and
     would be vulnerable to this attack. It is believed that many popular
     applications do set this option and would therefore not be at risk.

     The fix for this issue adds an additional check where a "q" parameter is
     available (as is the case in X9.42 based parameters). This detects the
     only known attack, and is the only possible defense for static DH
     ciphersuites. This could have some performance impact.

     Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by
     default and cannot be disabled. This could have some performance impact.

     This issue was reported to OpenSSL by Antonio Sanso (Adobe).
     (CVE-2016-0701)
     [Matt Caswell]

  *) SSLv2 doesn't block disabled ciphers

     A malicious client can negotiate SSLv2 ciphers that have been disabled on
     the server and complete SSLv2 handshakes even if all SSLv2 ciphers have
     been disabled, provided that the SSLv2 protocol was not also disabled via
     SSL_OP_NO_SSLv2.

     This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram
     and Sebastian Schinzel.
     (CVE-2015-3197)
     [Viktor Dukhovni]

  *) Reject DH handshakes with parameters shorter than 1024 bits.
     [Kurt Roeckx]

 Changes between 1.0.2d and 1.0.2e [3 Dec 2015]

  *) BN_mod_exp may produce incorrect results on x86_64

     There is a carry propagating bug in the x86_64 Montgomery squaring
     procedure. No EC algorithms are affected. Analysis suggests that attacks
     against RSA and DSA as a result of this defect would be very difficult to
     perform and are not believed likely. Attacks against DH are considered just
     feasible (although very difficult) because most of the work necessary to
     deduce information about a private key may be performed offline. The amount
     of resources required for such an attack would be very significant and
     likely only accessible to a limited number of attackers. An attacker would
     additionally need online access to an unpatched system using the target
     private key in a scenario with persistent DH parameters and a private
     key that is shared between multiple clients. For example this can occur by
     default in OpenSSL DHE based SSL/TLS ciphersuites.

     This issue was reported to OpenSSL by Hanno Böck.
     (CVE-2015-3193)
     [Andy Polyakov]

  *) Certificate verify crash with missing PSS parameter

     The signature verification routines will crash with a NULL pointer
     dereference if presented with an ASN.1 signature using the RSA PSS
     algorithm and absent mask generation function parameter. Since these
     routines are used to verify certificate signature algorithms this can be
     used to crash any certificate verification operation and exploited in a
     DoS attack. Any application which performs certificate verification is
     vulnerable including OpenSSL clients and servers which enable client
     authentication.

     This issue was reported to OpenSSL by Loïc Jonas Etienne (Qnective AG).
     (CVE-2015-3194)
     [Stephen Henson]

  *) X509_ATTRIBUTE memory leak

     When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
     memory. This structure is used by the PKCS#7 and CMS routines so any
     application which reads PKCS#7 or CMS data from untrusted sources is
     affected. SSL/TLS is not affected.

     This issue was reported to OpenSSL by Adam Langley (Google/BoringSSL) using
     libFuzzer.
     (CVE-2015-3195)
     [Stephen Henson]

  *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
     This changes the decoding behaviour for some invalid messages,
     though the change is mostly in the more lenient direction, and
     legacy behaviour is preserved as much as possible.
     [Emilia Käsper]

  *) In DSA_generate_parameters_ex, if the provided seed is too short,
     use a random seed, as already documented.
     [Rich Salz and Ismo Puustinen <ismo.puustinen@intel.com>]

 Changes between 1.0.2c and 1.0.2d [9 Jul 2015]

  *) Alternate chains certificate forgery

     During certificate verfification, OpenSSL will attempt to find an
     alternative certificate chain if the first attempt to build such a chain
     fails. An error in the implementation of this logic can mean that an
     attacker could cause certain checks on untrusted certificates to be
     bypassed, such as the CA flag, enabling them to use a valid leaf
     certificate to act as a CA and "issue" an invalid certificate.

     This issue was reported to OpenSSL by Adam Langley/David Benjamin
     (Google/BoringSSL).
     (CVE-2015-1793)
     [Matt Caswell]

  *) Race condition handling PSK identify hint

     If PSK identity hints are received by a multi-threaded client then
     the values are wrongly updated in the parent SSL_CTX structure. This can
     result in a race condition potentially leading to a double free of the
     identify hint data.
     (CVE-2015-3196)
     [Stephen Henson]

 Changes between 1.0.2b and 1.0.2c [12 Jun 2015]

  *) Fix HMAC ABI incompatibility. The previous version introduced an ABI
     incompatibility in the handling of HMAC. The previous ABI has now been
     restored.

 Changes between 1.0.2a and 1.0.2b [11 Jun 2015]

  *) Malformed ECParameters causes infinite loop

     When processing an ECParameters structure OpenSSL enters an infinite loop
     if the curve specified is over a specially malformed binary polynomial
     field.

     This can be used to perform denial of service against any
     system which processes public keys, certificate requests or
     certificates.  This includes TLS clients and TLS servers with
     client authentication enabled.

     This issue was reported to OpenSSL by Joseph Barr-Pixton.
     (CVE-2015-1788)
     [Andy Polyakov]

  *) Exploitable out-of-bounds read in X509_cmp_time

     X509_cmp_time does not properly check the length of the ASN1_TIME
     string and can read a few bytes out of bounds. In addition,
     X509_cmp_time accepts an arbitrary number of fractional seconds in the
     time string.

     An attacker can use this to craft malformed certificates and CRLs of
     various sizes and potentially cause a segmentation fault, resulting in
     a DoS on applications that verify certificates or CRLs. TLS clients
     that verify CRLs are affected. TLS clients and servers with client
     authentication enabled may be affected if they use custom verification
     callbacks.

     This issue was reported to OpenSSL by Robert Swiecki (Google), and
     independently by Hanno Böck.
     (CVE-2015-1789)
     [Emilia Käsper]

  *) PKCS7 crash with missing EnvelopedContent

     The PKCS#7 parsing code does not handle missing inner EncryptedContent
     correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs
     with missing content and trigger a NULL pointer dereference on parsing.

     Applications that decrypt PKCS#7 data or otherwise parse PKCS#7
     structures from untrusted sources are affected. OpenSSL clients and
     servers are not affected.

     This issue was reported to OpenSSL by Michal Zalewski (Google).
     (CVE-2015-1790)
     [Emilia Käsper]

  *) CMS verify infinite loop with unknown hash function

     When verifying a signedData message the CMS code can enter an infinite loop
     if presented with an unknown hash function OID. This can be used to perform
     denial of service against any system which verifies signedData messages using
     the CMS code.
     This issue was reported to OpenSSL by Johannes Bauer.
     (CVE-2015-1792)
     [Stephen Henson]

  *) Race condition handling NewSessionTicket

     If a NewSessionTicket is received by a multi-threaded client when attempting to
     reuse a previous ticket then a race condition can occur potentially leading to
     a double free of the ticket data.
     (CVE-2015-1791)
     [Matt Caswell]

  *) Removed support for the two export grade static DH ciphersuites
     EXP-DH-RSA-DES-CBC-SHA and EXP-DH-DSS-DES-CBC-SHA. 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.
     [Matt Caswell]

  *) Only support 256-bit or stronger elliptic curves with the
     'ecdh_auto' setting (server) or by default (client). Of supported
     curves, prefer P-256 (both).
     [Emilia Kasper]

  *) Reject DH handshakes with parameters shorter than 768 bits.
     [Kurt Roeckx and Emilia Kasper]

 Changes between 1.0.2 and 1.0.2a [19 Mar 2015]

  *) ClientHello sigalgs DoS fix

     If a client connects to an OpenSSL 1.0.2 server and renegotiates with an
     invalid signature algorithms extension a NULL pointer dereference will
     occur. This can be exploited in a DoS attack against the server.

     This issue was was reported to OpenSSL by David Ramos of Stanford
     University.
     (CVE-2015-0291)
     [Stephen Henson and Matt Caswell]

  *) Multiblock corrupted pointer fix

     OpenSSL 1.0.2 introduced the "multiblock" performance improvement. This
     feature only applies on 64 bit x86 architecture platforms that support AES
     NI instructions. A defect in the implementation of "multiblock" can cause
     OpenSSL's internal write buffer to become incorrectly set to NULL when
     using non-blocking IO. Typically, when the user application is using a
     socket BIO for writing, this will only result in a failed connection.
     However if some other BIO is used then it is likely that a segmentation
     fault will be triggered, thus enabling a potential DoS attack.

     This issue was reported to OpenSSL by Daniel Danner and Rainer Mueller.
     (CVE-2015-0290)
     [Matt Caswell]

  *) Segmentation fault in DTLSv1_listen fix

     The DTLSv1_listen function is intended to be stateless and processes the
     initial ClientHello from many peers. It is common for user code to loop
     over the call to DTLSv1_listen until a valid ClientHello is received with
     an associated cookie. A defect in the implementation of DTLSv1_listen means
     that state is preserved in the SSL object from one invocation to the next
     that can lead to a segmentation fault. Errors processing the initial
     ClientHello can trigger this scenario. An example of such an error could be
     that a DTLS1.0 only client is attempting to connect to a DTLS1.2 only
     server.

     This issue was reported to OpenSSL by Per Allansson.
     (CVE-2015-0207)
     [Matt Caswell]

  *) Segmentation fault in ASN1_TYPE_cmp fix

     The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is
     made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check
     certificate signature algorithm consistency this can be used to crash any
     certificate verification operation and exploited in a DoS attack. Any
     application which performs certificate verification is vulnerable including
     OpenSSL clients and servers which enable client authentication.
     (CVE-2015-0286)
     [Stephen Henson]

  *) Segmentation fault for invalid PSS parameters fix

     The signature verification routines will crash with a NULL pointer
     dereference if presented with an ASN.1 signature using the RSA PSS
     algorithm and invalid parameters. Since these routines are used to verify
     certificate signature algorithms this can be used to crash any
     certificate verification operation and exploited in a DoS attack. Any
     application which performs certificate verification is vulnerable including
     OpenSSL clients and servers which enable client authentication.

     This issue was was reported to OpenSSL by Brian Carpenter.
     (CVE-2015-0208)
     [Stephen Henson]

  *) ASN.1 structure reuse memory corruption fix

     Reusing a structure in ASN.1 parsing may allow an attacker to cause
     memory corruption via an invalid write. Such reuse is and has been
     strongly discouraged and is believed to be rare.

     Applications that parse structures containing CHOICE or ANY DEFINED BY
     components may be affected. Certificate parsing (d2i_X509 and related
     functions) are however not affected. OpenSSL clients and servers are
     not affected.
     (CVE-2015-0287)
     [Stephen Henson]

  *) PKCS7 NULL pointer dereferences fix

     The PKCS#7 parsing code does not handle missing outer ContentInfo
     correctly. An attacker can craft malformed ASN.1-encoded PKCS#7 blobs with
     missing content and trigger a NULL pointer dereference on parsing.

     Applications that verify PKCS#7 signatures, decrypt PKCS#7 data or
     otherwise parse PKCS#7 structures from untrusted sources are
     affected. OpenSSL clients and servers are not affected.

     This issue was reported to OpenSSL by Michal Zalewski (Google).
     (CVE-2015-0289)
     [Emilia Käsper]

  *) DoS via reachable assert in SSLv2 servers fix

     A malicious client can trigger an OPENSSL_assert (i.e., an abort) in
     servers that both support SSLv2 and enable export cipher suites by sending
     a specially crafted SSLv2 CLIENT-MASTER-KEY message.

     This issue was discovered by Sean Burford (Google) and Emilia Käsper
     (OpenSSL development team).
     (CVE-2015-0293)
     [Emilia Käsper]

  *) Empty CKE with client auth and DHE fix

     If client auth is used then a server can seg fault in the event of a DHE
     ciphersuite being selected and a zero length ClientKeyExchange message
     being sent by the client. This could be exploited in a DoS attack.
     (CVE-2015-1787)
     [Matt Caswell]

  *) Handshake with unseeded PRNG fix

     Under certain conditions an OpenSSL 1.0.2 client can complete a handshake
     with an unseeded PRNG. The conditions are:
     - The client is on a platform where the PRNG has not been seeded
     automatically, and the user has not seeded manually
     - A protocol specific client method version has been used (i.e. not
     SSL_client_methodv23)
     - A ciphersuite is used that does not require additional random data from
     the PRNG beyond the initial ClientHello client random (e.g. PSK-RC4-SHA).

     If the handshake succeeds then the client random that has been used will
     have been generated from a PRNG with insufficient entropy and therefore the
     output may be predictable.

     For example using the following command with an unseeded openssl will
     succeed on an unpatched platform:

     openssl s_client -psk 1a2b3c4d -tls1_2 -cipher PSK-RC4-SHA
     (CVE-2015-0285)
     [Matt Caswell]

  *) Use After Free following d2i_ECPrivatekey error fix

     A malformed EC private key file consumed via the d2i_ECPrivateKey function
     could cause a use after free condition. This, in turn, could cause a double
     free in several private key parsing functions (such as d2i_PrivateKey
     or EVP_PKCS82PKEY) and could lead to a DoS attack or memory corruption
     for applications that receive EC private keys from untrusted
     sources. This scenario is considered rare.

     This issue was discovered by the BoringSSL project and fixed in their
     commit 517073cd4b.
     (CVE-2015-0209)
     [Matt Caswell]

  *) X509_to_X509_REQ NULL pointer deref fix

     The function X509_to_X509_REQ will crash with a NULL pointer dereference if
     the certificate key is invalid. This function is rarely used in practice.

     This issue was discovered by Brian Carpenter.
     (CVE-2015-0288)
     [Stephen Henson]

  *) Removed the export ciphers from the DEFAULT ciphers
     [Kurt Roeckx]

 Changes between 1.0.1l and 1.0.2 [22 Jan 2015]

  *) Change RSA and DH/DSA key generation apps to generate 2048-bit
     keys by default.
     [Kurt Roeckx]

  *) Facilitate "universal" ARM builds targeting range of ARM ISAs, e.g.
     ARMv5 through ARMv8, as opposite to "locking" it to single one.
     So far those who have to target multiple plaforms would compromise
     and argue that binary targeting say ARMv5 would still execute on
     ARMv8. "Universal" build resolves this compromise by providing
     near-optimal performance even on newer platforms.
     [Andy Polyakov]

  *) Accelerated NIST P-256 elliptic curve implementation for x86_64
     (other platforms pending).
     [Shay Gueron & Vlad Krasnov (Intel Corp), Andy Polyakov]

  *) Add support for the SignedCertificateTimestampList certificate and
     OCSP response extensions from RFC6962.
     [Rob Stradling]

  *) Fix ec_GFp_simple_points_make_affine (thus, EC_POINTs_mul etc.)
     for corner cases. (Certain input points at infinity could lead to
     bogus results, with non-infinity inputs mapped to infinity too.)
     [Bodo Moeller]

  *) Initial support for PowerISA 2.0.7, first implemented in POWER8.
     This covers AES, SHA256/512 and GHASH. "Initial" means that most
     common cases are optimized and there still is room for further
     improvements. Vector Permutation AES for Altivec is also added.
     [Andy Polyakov]

  *) Add support for little-endian ppc64 Linux target.
     [Marcelo Cerri (IBM)]

  *) Initial support for AMRv8 ISA crypto extensions. This covers AES,
     SHA1, SHA256 and GHASH. "Initial" means that most common cases
     are optimized and there still is room for further improvements.
     Both 32- and 64-bit modes are supported.
     [Andy Polyakov, Ard Biesheuvel (Linaro)]

  *) Improved ARMv7 NEON support.
     [Andy Polyakov]

  *) Support for SPARC Architecture 2011 crypto extensions, first
     implemented in SPARC T4. This covers AES, DES, Camellia, SHA1,
     SHA256/512, MD5, GHASH and modular exponentiation.
     [Andy Polyakov, David Miller]

  *) Accelerated modular exponentiation for Intel processors, a.k.a.
     RSAZ.
     [Shay Gueron & Vlad Krasnov (Intel Corp)]

  *) Support for new and upcoming Intel processors, including AVX2,
     BMI and SHA ISA extensions. This includes additional "stitched"
     implementations, AESNI-SHA256 and GCM, and multi-buffer support
     for TLS encrypt.

     This work was sponsored by Intel Corp.
     [Andy Polyakov]

  *) Support for DTLS 1.2. This adds two sets of DTLS methods: DTLS_*_method()
     supports both DTLS 1.2 and 1.0 and should use whatever version the peer
     supports and DTLSv1_2_*_method() which supports DTLS 1.2 only.
     [Steve Henson]

  *) Use algorithm specific chains in SSL_CTX_use_certificate_chain_file():
     this fixes a limiation in previous versions of OpenSSL.
     [Steve Henson]

  *) Extended RSA OAEP support via EVP_PKEY API. Options to specify digest,
     MGF1 digest and OAEP label.
     [Steve Henson]

  *) Add EVP support for key wrapping algorithms, to avoid problems with
     existing code the flag EVP_CIPHER_CTX_WRAP_ALLOW has to be set in
     the EVP_CIPHER_CTX or an error is returned. Add AES and DES3 wrap
     algorithms and include tests cases.
     [Steve Henson]

  *) Add functions to allocate and set the fields of an ECDSA_METHOD
     structure.
     [Douglas E. Engert, Steve Henson]

  *) New functions OPENSSL_gmtime_diff and ASN1_TIME_diff to find the
     difference in days and seconds between two tm or ASN1_TIME structures.
     [Steve Henson]

  *) Add -rev test option to s_server to just reverse order of characters
     received by client and send back to server. Also prints an abbreviated
     summary of the connection parameters.
     [Steve Henson]

  *) New option -brief for s_client and s_server to print out a brief summary
     of connection parameters.
     [Steve Henson]

  *) Add callbacks for arbitrary TLS extensions.
     [Trevor Perrin <trevp@trevp.net> and Ben Laurie]

  *) New option -crl_download in several openssl utilities to download CRLs
     from CRLDP extension in certificates.
     [Steve Henson]

  *) New options -CRL and -CRLform for s_client and s_server for CRLs.
     [Steve Henson]

  *) New function X509_CRL_diff to generate a delta CRL from the difference
     of two full CRLs. Add support to "crl" utility.
     [Steve Henson]

  *) New functions to set lookup_crls function and to retrieve
     X509_STORE from X509_STORE_CTX.
     [Steve Henson]

  *) Print out deprecated issuer and subject unique ID fields in
     certificates.
     [Steve Henson]

  *) Extend OCSP I/O functions so they can be used for simple general purpose
     HTTP as well as OCSP. New wrapper function which can be used to download
     CRLs using the OCSP API.
     [Steve Henson]

  *) Delegate command line handling in s_client/s_server to SSL_CONF APIs.
     [Steve Henson]

  *) SSL_CONF* functions. These provide a common framework for application
     configuration using configuration files or command lines.
     [Steve Henson]

  *) SSL/TLS tracing code. This parses out SSL/TLS records using the
     message callback and prints the results. Needs compile time option
     "enable-ssl-trace". New options to s_client and s_server to enable
     tracing.
     [Steve Henson]

  *) New ctrl and macro to retrieve supported points extensions.
     Print out extension in s_server and s_client.
     [Steve Henson]

  *) New functions to retrieve certificate signature and signature
     OID NID.
     [Steve Henson]

  *) Add functions to retrieve and manipulate the raw cipherlist sent by a
     client to OpenSSL.
     [Steve Henson]

  *) New Suite B modes for TLS code. These use and enforce the requirements
     of RFC6460: restrict ciphersuites, only permit Suite B algorithms and
     only use Suite B curves. The Suite B modes can be set by using the
     strings "SUITEB128", "SUITEB192" or "SUITEB128ONLY" for the cipherstring.
     [Steve Henson]

  *) New chain verification flags for Suite B levels of security. Check
     algorithms are acceptable when flags are set in X509_verify_cert.
     [Steve Henson]

  *) Make tls1_check_chain return a set of flags indicating checks passed
     by a certificate chain. Add additional tests to handle client
     certificates: checks for matching certificate type and issuer name
     comparison.
     [Steve Henson]

  *) If an attempt is made to use a signature algorithm not in the peer
     preference list abort the handshake. If client has no suitable
     signature algorithms in response to a certificate request do not
     use the certificate.
     [Steve Henson]

  *) If server EC tmp key is not in client preference list abort handshake.
     [Steve Henson]

  *) Add support for certificate stores in CERT structure. This makes it
     possible to have different stores per SSL structure or one store in
     the parent SSL_CTX. Include distint stores for certificate chain
     verification and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN
     to build and store a certificate chain in CERT structure: returing
     an error if the chain cannot be built: this will allow applications
     to test if a chain is correctly configured.

     Note: if the CERT based stores are not set then the parent SSL_CTX
     store is used to retain compatibility with existing behaviour.

     [Steve Henson]

  *) New function ssl_set_client_disabled to set a ciphersuite disabled
     mask based on the current session, check mask when sending client
     hello and checking the requested ciphersuite.
     [Steve Henson]

  *) New ctrls to retrieve and set certificate types in a certificate
     request message. Print out received values in s_client. If certificate
     types is not set with custom values set sensible values based on
     supported signature algorithms.
     [Steve Henson]

  *) Support for distinct client and server supported signature algorithms.
     [Steve Henson]

  *) Add certificate callback. If set this is called whenever a certificate
     is required by client or server. An application can decide which
     certificate chain to present based on arbitrary criteria: for example
     supported signature algorithms. Add very simple example to s_server.
     This fixes many of the problems and restrictions of the existing client
     certificate callback: for example you can now clear an existing
     certificate and specify the whole chain.
     [Steve Henson]

  *) Add new "valid_flags" field to CERT_PKEY structure which determines what
     the certificate can be used for (if anything). Set valid_flags field 
     in new tls1_check_chain function. Simplify ssl_set_cert_masks which used
     to have similar checks in it.

     Add new "cert_flags" field to CERT structure and include a "strict mode".
     This enforces some TLS certificate requirements (such as only permitting
     certificate signature algorithms contained in the supported algorithms
     extension) which some implementations ignore: this option should be used
     with caution as it could cause interoperability issues.
     [Steve Henson]

  *) Update and tidy signature algorithm extension processing. Work out
     shared signature algorithms based on preferences and peer algorithms
     and print them out in s_client and s_server. Abort handshake if no
     shared signature algorithms.
     [Steve Henson]

  *) Add new functions to allow customised supported signature algorithms
     for SSL and SSL_CTX structures. Add options to s_client and s_server
     to support them.
     [Steve Henson]

  *) New function SSL_certs_clear() to delete all references to certificates
     from an SSL structure. Before this once a certificate had been added
     it couldn't be removed.
     [Steve Henson]

  *) Integrate hostname, email address and IP address checking with certificate
     verification. New verify options supporting checking in opensl utility.
     [Steve Henson]

  *) Fixes and wildcard matching support to hostname and email checking
     functions. Add manual page.
     [Florian Weimer (Red Hat Product Security Team)]

  *) New functions to check a hostname email or IP address against a
     certificate. Add options x509 utility to print results of checks against
     a certificate.
     [Steve Henson]

  *) Fix OCSP checking.
     [Rob Stradling <rob.stradling@comodo.com> and Ben Laurie]

  *) Initial experimental support for explicitly trusted non-root CAs. 
     OpenSSL still tries to build a complete chain to a root but if an
     intermediate CA has a trust setting included that is used. The first
     setting is used: whether to trust (e.g., -addtrust option to the x509
     utility) or reject.
     [Steve Henson]

  *) Add -trusted_first option which attempts to find certificates in the
     trusted store even if an untrusted chain is also supplied.
     [Steve Henson]

  *) MIPS assembly pack updates: support for MIPS32r2 and SmartMIPS ASE,
     platform support for Linux and Android.
     [Andy Polyakov]

  *) Support for linux-x32, ILP32 environment in x86_64 framework.
     [Andy Polyakov]

  *) Experimental multi-implementation support for FIPS capable OpenSSL.
     When in FIPS mode the approved implementations are used as normal,
     when not in FIPS mode the internal unapproved versions are used instead.
     This means that the FIPS capable OpenSSL isn't forced to use the
     (often lower perfomance) FIPS implementations outside FIPS mode.
     [Steve Henson]

  *) Transparently support X9.42 DH parameters when calling
     PEM_read_bio_DHparameters. This means existing applications can handle
     the new parameter format automatically.
     [Steve Henson]

  *) Initial experimental support for X9.42 DH parameter format: mainly
     to support use of 'q' parameter for RFC5114 parameters.
     [Steve Henson]

  *) Add DH parameters from RFC5114 including test data to dhtest.
     [Steve Henson]

  *) Support for automatic EC temporary key parameter selection. If enabled
     the most preferred EC parameters are automatically used instead of
     hardcoded fixed parameters. Now a server just has to call:
     SSL_CTX_set_ecdh_auto(ctx, 1) and the server will automatically
     support ECDH and use the most appropriate parameters.
     [Steve Henson]

  *) Enhance and tidy EC curve and point format TLS extension code. Use
     static structures instead of allocation if default values are used.
     New ctrls to set curves we wish to support and to retrieve shared curves.
     Print out shared curves in s_server. New options to s_server and s_client
     to set list of supported curves.
     [Steve Henson]

  *) New ctrls to retrieve supported signature algorithms and 
     supported curve values as an array of NIDs. Extend openssl utility
     to print out received values.
     [Steve Henson]

  *) Add new APIs EC_curve_nist2nid and EC_curve_nid2nist which convert
     between NIDs and the more common NIST names such as "P-256". Enhance
     ecparam utility and ECC method to recognise the NIST names for curves.
     [Steve Henson]

  *) Enhance SSL/TLS certificate chain handling to support different
     chains for each certificate instead of one chain in the parent SSL_CTX.
     [Steve Henson]

  *) Support for fixed DH ciphersuite client authentication: where both
     server and client use DH certificates with common parameters.
     [Steve Henson]

  *) Support for fixed DH ciphersuites: those requiring DH server
     certificates.
     [Steve Henson]

  *) New function i2d_re_X509_tbs for re-encoding the TBS portion of
     the certificate.
     Note: Related 1.0.2-beta specific macros X509_get_cert_info,
     X509_CINF_set_modified, X509_CINF_get_issuer, X509_CINF_get_extensions and
     X509_CINF_get_signature were reverted post internal team review.

 Changes between 1.0.1k and 1.0.1l [15 Jan 2015]

  *) Build fixes for the Windows and OpenVMS platforms
     [Matt Caswell and Richard Levitte]

 Changes between 1.0.1j and 1.0.1k [8 Jan 2015]

  *) Fix DTLS segmentation fault in dtls1_get_record. A carefully crafted DTLS
     message can cause a segmentation fault in OpenSSL due to a NULL pointer
     dereference. This could lead to a Denial Of Service attack. Thanks to
     Markus Stenberg of Cisco Systems, Inc. for reporting this issue.
     (CVE-2014-3571)
     [Steve Henson]

  *) Fix DTLS memory leak in dtls1_buffer_record. A memory leak can occur in the
     dtls1_buffer_record function under certain conditions. In particular this
     could occur if an attacker sent repeated DTLS records with the same
     sequence number but for the next epoch. The memory leak could be exploited
     by an attacker in a Denial of Service attack through memory exhaustion.
     Thanks to Chris Mueller for reporting this issue.
     (CVE-2015-0206)
     [Matt Caswell]

  *) Fix issue where no-ssl3 configuration sets method to NULL. When openssl is
     built with the no-ssl3 option and a SSL v3 ClientHello is received the ssl
     method would be set to NULL which could later result in a NULL pointer
     dereference. Thanks to Frank Schmirler for reporting this issue.
     (CVE-2014-3569)
     [Kurt Roeckx]

  *) Abort handshake if server key exchange message is omitted for ephemeral
     ECDH ciphersuites.

     Thanks to Karthikeyan Bhargavan of the PROSECCO team at INRIA for
     reporting this issue.
     (CVE-2014-3572)
     [Steve Henson]

  *) Remove non-export ephemeral RSA code on client and server. This code
     violated the TLS standard by allowing the use of temporary RSA keys in
