Skip to content
  1. Oct 28, 2018
  3. Oct 27, 2018
    • Fraser Tweedale's avatar
      Support GeneralSubtrees with minimum = 0 · c23e497d
      Fraser Tweedale authored 
      

The Name Constraints extension contains GeneralSubtree values
indicating included or excluded subtrees.  It is defined as:

  GeneralSubtree ::= SEQUENCE {
    base                    GeneralName,
    minimum         [0]     BaseDistance DEFAULT 0,
    maximum         [1]     BaseDistance OPTIONAL }

RFC 5280 further specifies:

  Within this profile, the minimum and maximum fields are not used with
  any name forms, thus, the minimum MUST be zero, and maximum MUST be
  absent.

Because the minimum fields has DEFAULT 0, and certificates should be
encoded using DER, the situation where minimum = 0 occurs in a
certificate should not arise.  Nevertheless, it does arise.  For
example, I have seen certificates issued by Microsoft programs that
contain GeneralSubtree values encoded thus.

Enhance the Name Constraints matching routine to handle the case
where minimum is specified.  If present, it must be zero.  The
maximum field remains prohibited.

Reviewed-by: default avatarPaul Yang <yang.yang@baishancloud.com>
Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7039)
      c23e497d
  5. Oct 26, 2018
  7. Oct 25, 2018
    • Richard Levitte's avatar
      Windows: Produce a static version of the public libraries, always · b3023ced
      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)
      b3023ced
  9. Oct 23, 2018
  11. Oct 22, 2018
    • Pauli's avatar
      RSA security bits calculation · 97b0b713
      Pauli authored 
      

NIST has updated their guidelines in appendix D of SP 800-56B rev2 (draft)
providing a formula for the number of security bits it terms of the length
of the RSA key.

This is an implementation of this formula using fixed point arithmetic.
For integers 1 .. 100,000 it rounds down to the next smaller 8 bit strength
270 times.  It never errs to the high side.  None of the rounded values occur
near any of the commonly selected lengths.

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7352)
      97b0b713
    • Dr. Matthias St. Pierre's avatar
      RAND_add(): fix heap corruption in error path · 5b4cb385
      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)
      5b4cb385
  13. Oct 21, 2018
  15. Oct 19, 2018
  17. Oct 18, 2018
    • armfazh's avatar
      Fix tls_cbc_digest_record is slow using SHA-384 and short messages · cb8164b0
      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)
      cb8164b0
    • Viktor Dukhovni's avatar
      Apply self-imposed path length also to root CAs · dc5831da
      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>
      dc5831da
    • Viktor Dukhovni's avatar
      Only CA certificates can be self-issued · ed422a2d
      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>
      ed422a2d
  19. Oct 17, 2018
  21. Oct 16, 2018
    • Dr. Matthias St. Pierre's avatar
      DRBG: fix reseeding via RAND_add()/RAND_seed() with large input · 3064b551
      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)
      3064b551
  23. Oct 13, 2018
  25. Oct 12, 2018