1. 02 7月, 2018 2 次提交
  2. 25 6月, 2018 1 次提交
  3. 07 6月, 2018 1 次提交
  4. 17 5月, 2018 1 次提交
  5. 11 5月, 2018 1 次提交
  6. 03 5月, 2018 1 次提交
  7. 20 4月, 2018 1 次提交
  8. 18 4月, 2018 1 次提交
  9. 15 3月, 2018 1 次提交
  10. 14 3月, 2018 2 次提交
  11. 13 3月, 2018 1 次提交
  12. 12 3月, 2018 1 次提交
  13. 10 3月, 2018 1 次提交
    • T
      Add SSL/SSL_CTX_use_cert_and_key() · 37933acb
      Todd Short 提交于
      Add functions that will do the work of assigning certificate, privatekey
      and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the
      publickey. This will permit the keys to pass validation for both ECDSA
      and RSA. If a private key has already been set for the certificate, it
      is discarded. A real private key can be set later.
      
      This is an all-or-nothing setting of these parameters. Unlike the
      SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions,
      the existing cert or privatekey is not modified (i.e. parameters copied).
      This permits the existing cert/privatekey to be replaced.
      
      It replaces the sequence of:
      * SSL_use_certificate()
      * SSL_use_privatekey()
      * SSL_set1_chain()
      And may actually be faster, as multiple checks are consolidated.
      
      The private key can be NULL, if so an ENGINE module needs to contain the
      actual private key that is to be used.
      
      Note that ECDH (using the certificate's ECDSA key) ciphers do not work
      without the private key being present, based on how the private key is
      used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/1130)
      37933acb
  14. 10 2月, 2018 1 次提交
  15. 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
  16. 25 1月, 2018 4 次提交
  17. 11 1月, 2018 1 次提交
  18. 09 1月, 2018 1 次提交
  19. 06 1月, 2018 1 次提交
  20. 14 12月, 2017 2 次提交
  21. 30 11月, 2017 1 次提交
  22. 06 11月, 2017 1 次提交
  23. 29 9月, 2017 1 次提交
  24. 15 9月, 2017 1 次提交
  25. 09 9月, 2017 2 次提交
  26. 06 9月, 2017 1 次提交
  27. 31 8月, 2017 3 次提交
  28. 30 8月, 2017 1 次提交
  29. 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
  30. 09 8月, 2017 1 次提交
  31. 03 8月, 2017 1 次提交