1. 23 2月, 2018 1 次提交
  2. 20 2月, 2018 1 次提交
  3. 15 2月, 2018 1 次提交
    • D
      DRBG: make locking api truly private · 812b1537
      Dr. Matthias St. Pierre 提交于
      In PR #5295 it was decided that the locking api should remain private
      and used only inside libcrypto. However, the locking functions were added
      back to `libcrypto.num` by `mkdef.pl`, because the function prototypes
      were still listed in `internal/rand.h`. (This header contains functions
      which are internal, but shared between libcrypto and libssl.)
      
      This commit moves the prototypes to `rand_lcl.h` and changes the names
      to lowercase, following the convention therein. It also corrects an
      outdated documenting comment.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5375)
      812b1537
  4. 14 2月, 2018 1 次提交
    • D
      DRBG: add locking api · 3ce1c27b
      Dr. Matthias St. Pierre 提交于
      This commit adds three new accessors to the internal DRBG lock
      
         int RAND_DRBG_lock(RAND_DRBG *drbg)
         int RAND_DRBG_unlock(RAND_DRBG *drbg)
         int RAND_DRBG_enable_locking(RAND_DRBG *drbg)
      
      The three shared DRBGs are intended to be used concurrently, so they
      have locking enabled by default. It is the callers responsibility to
      guard access to the shared DRBGs by calls to RAND_DRBG_lock() and
      RAND_DRBG_unlock().
      
      All other DRBG instances don't have locking enabled by default, because
      they are intendended to be used by a single thread. If it is desired,
      locking can be enabled by using RAND_DRBG_enable_locking().
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5294)
      3ce1c27b
  5. 11 2月, 2018 1 次提交
  6. 02 2月, 2018 1 次提交
    • T
      Add TLSv1.3 post-handshake authentication (PHA) · 9d75dce3
      Todd Short 提交于
      Add SSL_verify_client_post_handshake() for servers to initiate PHA
      
      Add SSL_force_post_handshake_auth() for clients that don't have certificates
      initially configured, but use a certificate callback.
      
      Update SSL_CTX_set_verify()/SSL_set_verify() mode:
      
      * Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
      the initial handshake.
      
      * Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
      of when the certificate authentication takes place; either initial handshake,
      re-negotiation, or post-handshake authentication.
      
      Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
      add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options
      
      Add support to s_client:
      * Enabled automatically when cert is configured
      * Can be forced enabled via -force_pha
      
      Add support to s_server:
      * Use 'c' to invoke PHA in s_server
      * Remove some dead code
      
      Update documentation
      
      Update unit tests:
      * Illegal use of PHA extension
      * TLSv1.3 certificate tests
      
      DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
      implemented, it's PHA support state machine may need to be different.
      Add a TODO and a #error
      
      Update handshake context to deal with PHA.
      
      The handshake context for TLSv1.3 post-handshake auth is up through the
      ClientFinish message, plus the CertificateRequest message. Subsequent
      Certificate, CertificateVerify, and Finish messages are based on this
      handshake context (not the Certificate message per se, but it's included
      after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
      Request messages are not included in post-handshake authentication.
      
      After the ClientFinished message is processed, save off the digest state
      for future post-handshake authentication. When post-handshake auth occurs,
      copy over the saved handshake context into the "main" handshake digest.
      This effectively discards the any KeyUpdate or NewSessionTicket messages
      and any prior post-handshake authentication.
      
      This, of course, assumes that the ID-22 did not mean to include any
      previous post-handshake authentication into the new handshake transcript.
      This is implied by section 4.4.1 that lists messages only up to the
      first ClientFinished.
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4964)
      9d75dce3
  7. 26 1月, 2018 1 次提交
    • B
      Add support for the TLS 1.3 signature_algorithms_cert extension · c589c34e
      Benjamin Kaduk 提交于
      The new extension is like signature_algorithms, but only for the
      signature *on* the certificate we will present to the peer (the
      old signature_algorithms extension is still used for signatures that
      we *generate*, i.e., those over TLS data structures).
      
      We do not need to generate this extension, since we are the same
      implementation as our X.509 stack and can handle the same types
      of signatures, but we need to be prepared to receive it, and use the received
      information when selecting what certificate to present.
      
      There is a lot of interplay between signature_algorithms_cert and
      signature_algorithms, since both affect what certificate we can
      use, and thus the resulting signature algorithm used for TLS messages.
      So, apply signature_algorithms_cert (if present) as a filter on what
      certificates we can consider when choosing a certificate+sigalg
      pair.
      
      As part of this addition, we also remove the fallback code that let
      keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the
      new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled
      the key type into what is covered by the signature algorithm, so
      we should not apply this sort of compatibility workaround.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5068)
      c589c34e
  8. 25 1月, 2018 2 次提交
  9. 24 1月, 2018 1 次提交
  10. 19 1月, 2018 1 次提交
  11. 08 1月, 2018 1 次提交
  12. 04 1月, 2018 1 次提交
    • D
      crypto/rand: restore the generic DRBG implementation · 8212d505
      Dr. Matthias St. Pierre 提交于
      The DRGB concept described in NIST SP 800-90A provides for having different
      algorithms to generate random output. In fact, the FIPS object module used to
      implement three of them, CTR DRBG, HASH DRBG and HMAC DRBG.
      
      When the FIPS code was ported to master in #4019, two of the three algorithms
      were dropped, and together with those the entire code that made RAND_DRBG
      generic was removed, since only one concrete implementation was left.
      
      This commit restores the original generic implementation of the DRBG, making it
      possible again to add additional implementations using different algorithms
      (like RAND_DRBG_CHACHA20) in the future.
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4998)
      8212d505
  13. 15 12月, 2017 1 次提交
  14. 14 12月, 2017 5 次提交
  15. 09 12月, 2017 1 次提交
  16. 04 12月, 2017 7 次提交
  17. 25 11月, 2017 1 次提交
  18. 21 11月, 2017 1 次提交
    • P
      Support multi-prime RSA (RFC 8017) · 665d899f
      Paul Yang 提交于
      * Introduce RSA_generate_multi_prime_key to generate multi-prime
        RSA private key. As well as the following functions:
          RSA_get_multi_prime_extra_count
          RSA_get0_multi_prime_factors
          RSA_get0_multi_prime_crt_params
          RSA_set0_multi_prime_params
          RSA_get_version
      * Support EVP operations for multi-prime RSA
      * Support ASN.1 operations for multi-prime RSA
      * Support multi-prime check in RSA_check_key_ex
      * Support multi-prime RSA in apps/genrsa and apps/speed
      * Support multi-prime RSA manipulation functions
      * Test cases and documentation are added
      * CHANGES is updated
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/4241)
      665d899f
  19. 20 11月, 2017 1 次提交
  20. 06 11月, 2017 1 次提交
  21. 31 10月, 2017 1 次提交
  22. 18 10月, 2017 1 次提交
    • 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
  23. 12 10月, 2017 2 次提交
  24. 04 10月, 2017 1 次提交
    • T
      Session resume broken switching contexts · a84e5c9a
      Todd Short 提交于
      When an SSL's context is swtiched from a ticket-enabled context to
      a ticket-disabled context in the servername callback, no session-id
      is generated, so the session can't be resumed.
      
      If a servername callback changes the SSL_OP_NO_TICKET option, check
      to see if it's changed to disable, and whether a session ticket is
      expected (i.e. the client indicated ticket support and the SSL had
      tickets enabled at the time), and whether we already have a previous
      session (i.e. s->hit is set).
      
      In this case, clear the ticket-expected flag, remove any ticket data
      and generate a session-id in the session.
      
      If the SSL hit (resumed) and switched to a ticket-disabled context,
      assume that the resumption was via session-id, and don't bother to
      update the session.
      
      Before this fix, the updated unit-tests in 06-sni-ticket.conf would
      fail test #4 (server1 = SNI, server2 = no SNI).
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/1529)
      a84e5c9a
  25. 15 9月, 2017 1 次提交
  26. 14 9月, 2017 1 次提交
  27. 09 9月, 2017 1 次提交
  28. 31 8月, 2017 1 次提交