Skip to content
  1. Oct 26, 2018
  2. Oct 25, 2018
    • Richard Levitte's avatar
      Windows: Produce a static version of the public libraries, always · 85299451
      Richard Levitte authored
      
      
      When building shared libraries on Windows, we had a clash between
      'libcrypto.lib' the static routine library and 'libcrypto.lib' the
      import library.
      
      We now change it so the static versions of our libraries get '_static'
      appended to their names.  These will never get installed, but can
      still be used for our internal purposes, such as internal tests.
      
      When building non-shared, the renaming mechanism doesn't come into
      play.  In that case, the static libraries 'libcrypto.lib' and
      'libssl.lib' are installed, just as always.
      
      Fixes #7492
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7496)
      
      (cherry picked from commit b3023ced6b6a4aece6f4d4ec1f6a93b1c03712b6)
      85299451
  3. Oct 23, 2018
  4. Oct 22, 2018
    • Dr. Matthias St. Pierre's avatar
      RAND_add(): fix heap corruption in error path · ece482ff
      Dr. Matthias St. Pierre authored
      
      
      This bug was introduced by #7382 which enhanced RAND_add() to
      accept large buffer sizes. As a consequence, RAND_add() now fails
      for buffer sizes less than 32 bytes (i.e. less than 256 bits).
      In addition, rand_drbg_get_entropy() forgets to reset the attached
      drbg->pool in the case of an error, which leads to the heap corruption.
      
      The problem occurred with RAND_load_file(), which reads the file in
      chunks of 1024 bytes each. If the size of the final chunk is less than
      32 bytes, then RAND_add() fails, whence RAND_load_file() fails
      silently for buffer sizes n = k * 1024 + r with r = 1,...,31.
      
      This commit fixes the heap corruption only. The other issues will
      be addressed in a separate pull request.
      
      Thanks to Gisle Vanem for reporting this issue.
      
      Fixes #7449
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7455)
      
      (cherry picked from commit 5b4cb385)
      ece482ff
  5. Oct 21, 2018
    • Richard Levitte's avatar
      build file templates: have targets for all shared library names · 132fd512
      Richard Levitte authored
      
      
      We only had targets for the "simple" shared library names (libfoo.so
      and not libfoo.so.x.y on Unix, import library libfoo.lib but not
      libfoo.dll on Windows).  This has created some confusion why it wasn't
      possible to rebuild the less "simple" name directly (just as an
      example, someone who mistook the import library on Windows for a
      static library, removed the DLL and then found it was difficult to
      rebuild directly), so we change the target to include all possible
      names.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7451)
      
      (cherry picked from commit d8cac50b023be249cdaba054f43acecf17025ce4)
      132fd512
  6. Oct 19, 2018
  7. Oct 18, 2018
    • armfazh's avatar
      Fix tls_cbc_digest_record is slow using SHA-384 and short messages · aa519853
      armfazh authored
      
      
      The formula used for this is now
      
      kVarianceBlocks = ((255 + 1 + md_size + md_block_size - 1) / md_block_size) + 1
      
      Notice that md_block_size=64 for SHA256, which results on the
      magic constant kVarianceBlocks = 6.
      However, md_block_size=128 for SHA384 leading to kVarianceBlocks = 4.
      
      CLA:trivial
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7342)
      
      (cherry picked from commit cb8164b05e3bad5586c2a109bbdbab1ad65a1a6f)
      aa519853
    • Viktor Dukhovni's avatar
      Apply self-imposed path length also to root CAs · a190ea8a
      Viktor Dukhovni authored
      
      
      Also, some readers of the code find starting the count at 1 for EE
      cert confusing (since RFC5280 counts only non-self-issued intermediate
      CAs, but we also counted the leaf).  Therefore, never count the EE
      cert, and adjust the path length comparison accordinly.  This may
      be more clear to the reader.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (cherry picked from commit dc5831da)
      a190ea8a
    • Viktor Dukhovni's avatar
      Only CA certificates can be self-issued · bb692394
      Viktor Dukhovni authored
      At the bottom of https://tools.ietf.org/html/rfc5280#page-12 and
      top of https://tools.ietf.org/html/rfc5280#page-13 (last paragraph
      of above https://tools.ietf.org/html/rfc5280#section-3.3), we see:
      
         This specification covers two classes of certificates: CA
         certificates and end entity certificates.  CA certificates may be
         further divided into three classes: cross-certificates, self-issued
         certificates, and self-signed certificates.  Cross-certificates are
         CA certificates in which the issuer and subject are different
         entities.  Cross-certificates describe a trust relationship between
         the two CAs.  Self-issued certificates are CA certificates in which
         the issuer and subject are the same entity.  Self-issued certificates
         are generated to support changes in policy or operations.  Self-
         signed certificates are self-issued certificates where the digital
         signature may be verified by the public key bound into the
         certificate.  Self-signed certificates are used to convey a public
         key for use to begin certification paths.  End entity certificates
         are issued to subjects that are not authorized to issue certificates.
      
      that the term "self-issued" is only applicable to CAs, not end-entity
      certificates.  In https://tools.ietf.org/html/rfc5280#section-4.2.1.9
      
      
      the description of path length constraints says:
      
         The pathLenConstraint field is meaningful only if the cA boolean is
         asserted and the key usage extension, if present, asserts the
         keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
         maximum number of non-self-issued intermediate certificates that may
         follow this certificate in a valid certification path.  (Note: The
         last certificate in the certification path is not an intermediate
         certificate, and is not included in this limit.  Usually, the last
         certificate is an end entity certificate, but it can be a CA
         certificate.)
      
      This makes it clear that exclusion of self-issued certificates from
      the path length count applies only to some *intermediate* CA
      certificates.  A leaf certificate whether it has identical issuer
      and subject or whether it is a CA or not is never part of the
      intermediate certificate count.  The handling of all leaf certificates
      must be the same, in the case of our code to post-increment the
      path count by 1, so that we ultimately reach a non-self-issued
      intermediate it will be the first one (not zeroth) in the chain
      of intermediates.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (cherry picked from commit ed422a2d)
      bb692394
  8. Oct 17, 2018
  9. Oct 16, 2018
    • Dr. Matthias St. Pierre's avatar
      DRBG: fix reseeding via RAND_add()/RAND_seed() with large input · dbf0a496
      Dr. Matthias St. Pierre authored
      
      
      In pull request #4328 the seeding of the DRBG via RAND_add()/RAND_seed()
      was implemented by buffering the data in a random pool where it is
      picked up later by the rand_drbg_get_entropy() callback. This buffer
      was limited to the size of 4096 bytes.
      
      When a larger input was added via RAND_add() or RAND_seed() to the DRBG,
      the reseeding failed, but the error returned by the DRBG was ignored
      by the two calling functions, which both don't return an error code.
      As a consequence, the data provided by the application was effectively
      ignored.
      
      This commit fixes the problem by a more efficient implementation which
      does not copy the data in memory and by raising the buffer the size limit
      to INT32_MAX (2 gigabytes). This is less than the NIST limit of 2^35 bits
      but it was chosen intentionally to avoid platform dependent problems
      like integer sizes and/or signed/unsigned conversion.
      
      Additionally, the DRBG is now less permissive on errors: In addition to
      pushing a message to the openssl error stack, it enters the error state,
      which forces a reinstantiation on next call.
      
      Thanks go to Dr. Falko Strenzke for reporting this issue to the
      openssl-security mailing list. After internal discussion the issue
      has been categorized as not being security relevant, because the DRBG
      reseeds automatically and is fully functional even without additional
      randomness provided by the application.
      
      Fixes #7381
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7382)
      
      (cherry picked from commit 3064b55134434a0b2850f07eff57120f35bb269a)
      dbf0a496
  10. Oct 15, 2018
  11. Oct 13, 2018
  12. Oct 12, 2018
  13. Oct 11, 2018
  14. Oct 10, 2018
  15. Oct 08, 2018
  16. Oct 05, 2018