1. 25 1月, 2018 5 次提交
  2. 19 1月, 2018 1 次提交
  3. 11 1月, 2018 1 次提交
  4. 29 12月, 2017 2 次提交
  5. 18 12月, 2017 1 次提交
  6. 16 12月, 2017 1 次提交
  7. 14 12月, 2017 1 次提交
  8. 08 12月, 2017 1 次提交
  9. 04 12月, 2017 2 次提交
  10. 06 11月, 2017 1 次提交
  11. 30 10月, 2017 1 次提交
  12. 27 10月, 2017 1 次提交
  13. 25 10月, 2017 1 次提交
  14. 18 10月, 2017 3 次提交
    • K
      Remove parentheses of return. · 26a7d938
      KaoruToda 提交于
      Since return is inconsistent, I removed unnecessary parentheses and
      unified them.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4541)
      26a7d938
    • B
      Add missing RAND_DRBG locking · 2139145b
      Benjamin Kaduk 提交于
      The drbg's lock must be held across calls to RAND_DRBG_generate()
      to prevent simultaneous modification of internal state.
      
      This was observed in practice with simultaneous SSL_new() calls attempting
      to seed the (separate) per-SSL RAND_DRBG instances from the global
      rand_drbg instance; this eventually led to simultaneous calls to
      ctr_BCC_update() attempting to increment drbg->bltmp_pos for their
      respective partial final block, violating the invariant that bltmp_pos < 16.
      The AES operations performed in ctr_BCC_blocks() makes the race window
      quite easy to trigger.  A value of bltmp_pos greater than 16 induces
      catastrophic failure in ctr_BCC_final(), with subtraction overflowing
      and leading to an attempt to memset() to zero a very large range,
      which eventually reaches an unmapped page and segfaults.
      
      Provide the needed locking in get_entropy_from_parent(), as well as
      fixing a similar issue in RAND_priv_bytes().  There is also an
      unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the
      requisite serialization is already guaranteed by the requirements on
      the application's usage of SSL objects, and no further locking is
      needed for correct behavior.  In that case, leave a comment noting
      the apparent discrepancy and the reason for its safety (at present).
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4328)
      2139145b
    • D
      Fix reseeding issues of the public RAND_DRBG · c16de9d8
      Dr. Matthias St. Pierre 提交于
      Reseeding is handled very differently by the classic RAND_METHOD API
      and the new RAND_DRBG api. These differences led to some problems when
      the new RAND_DRBG was made the default OpenSSL RNG. In particular,
      RAND_add() did not work as expected anymore. These issues are discussed
      on the thread '[openssl-dev] Plea for a new public OpenSSL RNG API'
      and in Pull Request #4328. This commit fixes the mentioned issues,
      introducing the following changes:
      
      - Replace the fixed size RAND_BYTES_BUFFER by a new RAND_POOL API which
        facilitates collecting entropy by the get_entropy() callback.
      - Don't use RAND_poll()/RAND_add() for collecting entropy from the
        get_entropy() callback anymore. Instead, replace RAND_poll() by
        RAND_POOL_acquire_entropy().
      - Add a new function rand_drbg_restart() which tries to get the DRBG
        in an instantiated state by all means, regardless of the current
        state (uninstantiated, error, ...) the DRBG is in. If the caller
        provides entropy or additional input, it will be used for reseeding.
      - Restore the original documented behaviour of RAND_add() and RAND_poll()
        (namely to reseed the DRBG immediately) by a new implementation based
        on rand_drbg_restart().
      - Add automatic error recovery from temporary failures of the entropy
        source to RAND_DRBG_generate() using the rand_drbg_restart() function.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/4328)
      c16de9d8
  15. 09 10月, 2017 1 次提交
  16. 29 9月, 2017 1 次提交
  17. 28 9月, 2017 1 次提交
  18. 23 9月, 2017 2 次提交
  19. 22 9月, 2017 1 次提交
  20. 20 9月, 2017 1 次提交
  21. 15 9月, 2017 1 次提交
  22. 14 9月, 2017 1 次提交
  23. 09 9月, 2017 1 次提交
  24. 31 8月, 2017 1 次提交
  25. 30 8月, 2017 2 次提交
  26. 29 8月, 2017 1 次提交
  27. 15 8月, 2017 1 次提交
    • B
      Add SSL_get_pending_cipher() · 0aed6e44
      Benjamin Kaduk 提交于
      The existing function SSL_get_current_cipher() queries the
      current session for the ciphersuite in use, but there is no way
      for application code to determine what ciphersuite has been
      negotiated and will be used in the future, prior to ChangeCipherState
      (or the TLS 1.3 equivalent) causing the new cipher to take effect and
      become visible in the session information.  Expose this information
      to appropriate application callbacks to use during the handshake.
      
      The name SSL_get_pending_cipher() was chosen for compatibility with
      BoringSSL's routine of that name.
      
      Improve the note on macro implementations in SSL_get_current_cipher.pod
      while here.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4070)
      0aed6e44
  28. 03 8月, 2017 2 次提交
  29. 01 8月, 2017 1 次提交