Skip to content
  1. Feb 14, 2018
    • Viktor Dukhovni's avatar
      Avoid fragile aliasing of SHA224/384 update/final · 144724c7
      Viktor Dukhovni authored
      
      
      This is purported to save a few cycles, but makes the code less
      obvious and more brittle, and in fact breaks on platforms where for
      ABI continuity reasons there is a SHA2 implementation in libc, and
      so EVP needs to call those to avoid conflicts.
      
      A sufficiently good optimizer could simply generate the same entry
      points for:
      
              foo(...) { ... }
          and
              bar(...) { return foo(...); }
      
      but, even without that, the different is negligible, with the
      "winner" varying from run to run (openssl speed -evp sha384):
      
          Old:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           28864.28k   117362.62k   266469.21k   483258.03k   635144.87k 649123.16k
      
          New:
          type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes 16384 bytes
          sha384           30055.18k   120725.98k   272057.26k   482847.40k   634585.09k 650308.27k
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      144724c7
  2. Feb 13, 2018
  3. Feb 12, 2018
  4. Feb 10, 2018
  5. Feb 09, 2018
  6. Feb 08, 2018
  7. Feb 07, 2018
  8. Feb 06, 2018
  9. Feb 01, 2018
    • David Benjamin's avatar
      Fix timing leak in BN_from_montgomery_word. · db91094a
      David Benjamin authored
      BN_from_montgomery_word doesn't have a constant memory access pattern.
      Replace the pointer trick with a constant-time select. There is, of
      course, still the bn_correct_top leak pervasive in BIGNUM itself.
      
      See also https://boringssl-review.googlesource.com/22904
      
       from BoringSSL.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/5228)
      
      (cherry picked from commit f345b1f3)
      db91094a
    • David Benjamin's avatar
      Don't leak the exponent bit width in BN_mod_exp_mont_consttime. · 723183b5
      David Benjamin authored
      
      
      The exponent here is one of d, dmp1, or dmq1 for RSA. This value and its
      bit length are both secret. The only public upper bound is the bit width
      of the corresponding modulus (RSA n, p, and q, respectively).
      
      Although BN_num_bits is constant-time (sort of; see bn_correct_top notes
      in preceding patch), this does not fix the root problem, which is that
      the windows are based on the minimal bit width, not the upper bound. We
      could use BN_num_bits(m), but BN_mod_exp_mont_consttime is public API
      and may be called with larger exponents. Instead, use all top*BN_BITS2
      bits in the BIGNUM. This is still sensitive to the long-standing
      bn_correct_top leak, but we need to fix that regardless.
      
      This may cause us to do a handful of extra multiplications for RSA keys
      which are just above a whole number of words, but that is not a standard
      RSA key size.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      
      (cherry picked from commit 39eeb64f)
      723183b5
    • David Benjamin's avatar
      Make BN_num_bits_word constant-time. · 0b9373ce
      David Benjamin authored
      
      
      (This patch was written by Andy Polyakov. I only wrote the commit
      message. Mistakes in the analysis are my fault.)
      
      BN_num_bits, by way of BN_num_bits_word, currently leaks the
      most-significant word of its argument via branching and memory access
      pattern.
      
      BN_num_bits is called on RSA prime factors in various places. These have
      public bit lengths, but all bits beyond the high bit are secret. This
      fully resolves those cases.
      
      There are a few places where BN_num_bits is called on an input where the
      bit length is also secret. This does *not* fully resolve those cases as
      we still only look at the top word. Today, that is guaranteed to be
      non-zero, but only because of the long-standing bn_correct_top timing
      leak. Once that is fixed, a constant-time BN_num_bits on such inputs
      must count bits on each word.
      
      Instead, those cases should not call BN_num_bits at all. In particular,
      BN_mod_exp_mont_consttime uses the exponent bit width to pick windows,
      but it should be using the maximum bit width. The next patch will fix
      this.
      
      Thanks to Dinghao Wu, Danfeng Zhang, Shuai Wang, Pei Wang, and Xiao Liu
      for reporting this issue.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5154)
      
      (cherry picked from commit 972c87df)
      0b9373ce
    • Michael Richardson's avatar
      Add OPENSSL_VERSION_AT_LEAST · d8adfdcd
      Michael Richardson authored
      
      
      added macro to create version number
      use the macro to build OPENSSL_VERSION_AT_LEAST(maj,min,fix) so that
      customers of libssl (such as ruby-openssl) do not need to be so aware of
      openssl version numbers.
      includes updates to ssl(7) and OPENSSL_VERSION_NUMBER(3) man page
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5212)
      (cherry picked from commit 3c5a61dd)
      d8adfdcd
  10. Jan 31, 2018
  11. Jan 30, 2018
    • Matt Caswell's avatar
    • Matt Caswell's avatar
      Add the SSL_OP_NO_RENEGOTIATION option to 1.1.0 · 6e127fdd
      Matt Caswell authored
      This is based on a heavily modified version of commit db0f35dd
      
       by Todd
      Short from the master branch.
      
      We are adding this because it used to be possible to disable reneg using
      the flag SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS in 1.0.2. This is no longer
      possible because of the opacity work.
      
      A point to note about this is that if an application built against new
      1.1.0 headers (that know about the new option SSL_OP_NO_RENEGOTIATION
      option) is run using an older version of 1.1.0 (that doesn't know about
      the option) then the option will be accepted but nothing will happen, i.e.
      renegotiation will not be prevented. There's probably not much we can do
      about that.
      
      Fixes #4739
      
      Reviewed-by: default avatarBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/4901)
      6e127fdd
    • Matt Caswell's avatar
      Make sure we check an incoming reneg ClientHello in DTLS · 12492580
      Matt Caswell authored
      
      
      In TLS we have a check to make sure an incoming reneg ClientHello is
      acceptable. The equivalent check is missing in the DTLS code. This means
      that if a client does not signal the ability to handle secure reneg in the
      initial handshake, then a subsequent reneg handshake should be rejected by
      the server. In the DTLS case the reneg was being allowed if the the 2nd
      ClientHello had a renegotiation_info extension. This is incorrect.
      
      While incorrect, this does not represent a security issue because if
      the renegotiation_info extension is present in the second ClientHello it
      also has to be *correct*. Therefore this will only work if both the client
      and server believe they are renegotiating, and both know the previous
      Finished result. This is not the case in an insecure rengotiation attack.
      
      I have also tidied up the check in the TLS code and given a better check
      for determining whether we are renegotiating or not.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5191)
      12492580
  12. Jan 29, 2018
  13. Jan 28, 2018
  14. Jan 26, 2018
  15. Jan 25, 2018
  16. Jan 24, 2018
  17. Jan 23, 2018