Skip to content
  1. Nov 09, 2018
  3. Nov 02, 2018
  5. Nov 01, 2018
  7. Oct 29, 2018
  9. Oct 28, 2018
  11. Oct 18, 2018
    • Dr. Matthias St. Pierre's avatar
      md_rand.c: don't stop polling until properly initialized · 896e8c57
      Dr. Matthias St. Pierre authored 
      

Previously, the RNG sets `initialized=1` after the first call to
RAND_poll(), although its criterion for being initialized actually
is whether condition `entropy >= ENTROPY_NEEDED` is true.

This commit now assigns `initialized=(entropy >= ENTROPY_NEEDED)`,
which has the effect that on the next call, RAND_poll() will be
called again, if it previously failed to obtain enough entropy.

Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7439)
      896e8c57
    • Viktor Dukhovni's avatar
      Apply self-imposed path length also to root CAs · 35cf781c
      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)
      35cf781c
    • Viktor Dukhovni's avatar
      Only CA certificates can be self-issued · c8ce9e50
      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)
      c8ce9e50
  13. Oct 12, 2018
  15. Oct 02, 2018
  17. Sep 26, 2018
  19. Sep 24, 2018
  21. Sep 21, 2018
  23. Sep 20, 2018
    • Dr. Matthias St. Pierre's avatar
      drbg_get_entropy: force a reseed before calling ssleay_rand_bytes() · f58001c3
      Dr. Matthias St. Pierre authored 
      Fixes #7240

In FIPS mode, the default FIPS DRBG uses the drbg_get_entropy()
callback to reseed itself, which is provided by the wrapping
libcrypto library. This callback in turn uses ssleay_rand_bytes()
to generate random bytes.

Now ssleay_rand_bytes() calls RAND_poll() once on first call to
seed itself, but RAND_poll() is never called again (unless the
application calls RAND_poll() explicitely). This implies that
whenever the DRBG reseeds itself (which happens every 2^14
generate requests) this happens without obtaining fresh random
data from the operating system's entropy sources.

This patch forces a reseed from system entropy sources on every
call to drbg_get_entropy(). In contrary to the automatic reseeding
of the DRBG in master, this reseeding does not break applications
running in a chroot() environment (see c7504aeb

), because the
SSLEAY PRNG does not maintain an error state. (It does not even
check the return value of RAND_poll() on its instantiation.)

In the worst case, if no random device is available for reseeding,
no fresh entropy will be added to the SSLEAY PRNG but it will happily
continue to generate random bytes as 'entropy' input for the DRBG's
reseeding, which is just as good (or bad) as before this patch.

To prevent ssleay_rand_bytes_from_system() (and hence RAND_poll())
from being called twice during instantiation, a separate
drbg_get_nonce() callback has been introduced, which is identical
with the previous implementation of drbg_get_entropy().

Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
Reviewed-by: default avatarBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/7259)
      f58001c3
    • Richard Levitte's avatar
      crypto/ui/ui_openssl.c: make sure to recognise ENXIO and EIO too · 79951b1d
      Richard Levitte authored 
      

These both indicate that the file descriptor we're trying to use as a
terminal isn't, in fact, a terminal.

Fixes #7271

Reviewed-by: default avatarMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7272)

(cherry picked from commit 276bf862)
(cherry picked from commit ad173035)
      79951b1d
  25. Sep 11, 2018
  27. Sep 10, 2018
  29. Sep 04, 2018
  31. Sep 03, 2018
  33. Sep 02, 2018
  35. Aug 28, 2018
  37. Aug 27, 2018
  39. Aug 17, 2018
  41. Aug 14, 2018