1. 27 4月, 2018 1 次提交
  2. 03 4月, 2018 1 次提交
  3. 14 3月, 2018 1 次提交
    • M
      Split configuration of TLSv1.3 ciphers from older ciphers · f865b081
      Matt Caswell 提交于
      With the current mechanism, old cipher strings that used to work in 1.1.0,
      may inadvertently disable all TLSv1.3 ciphersuites causing connections to
      fail. This is confusing for users.
      
      In reality TLSv1.3 are quite different to older ciphers. They are much
      simpler and there are only a small number of them so, arguably, they don't
      need the same level of control that the older ciphers have.
      
      This change splits the configuration of TLSv1.3 ciphers from older ones.
      By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
      them through your existing config.
      
      Fixes #5359
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5392)
      f865b081
  4. 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
  5. 09 3月, 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 1 次提交
  9. 14 12月, 2017 5 次提交
  10. 09 12月, 2017 1 次提交
  11. 04 12月, 2017 7 次提交
  12. 06 11月, 2017 1 次提交
  13. 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
  14. 31 8月, 2017 1 次提交
  15. 13 7月, 2017 1 次提交
  16. 21 6月, 2017 1 次提交
  17. 16 6月, 2017 1 次提交
  18. 13 6月, 2017 1 次提交
  19. 08 6月, 2017 1 次提交
    • R
      make error tables const and separate header file · 52df25cf
      Rich Salz 提交于
      Run perltidy on util/mkerr
      Change some mkerr flags, write some doc comments
      Make generated tables "const" when genearting lib-internal ones.
      Add "state" file for mkerr
      Renerate error tables and headers
      Rationalize declaration of ERR_load_XXX_strings
      Fix out-of-tree build
      Add -static; sort flags/vars for options.
      Also tweak code output
      Moved engines/afalg to engines (from master)
      Use -static flag
      Standard engine #include's of errors
      Don't linewrap err string tables unless necessary
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3392)
      52df25cf
  20. 07 6月, 2017 1 次提交
  21. 22 5月, 2017 1 次提交
  22. 17 5月, 2017 1 次提交
  23. 11 5月, 2017 2 次提交
  24. 10 5月, 2017 1 次提交
  25. 08 5月, 2017 1 次提交
  26. 03 5月, 2017 1 次提交
  27. 25 4月, 2017 1 次提交
  28. 18 3月, 2017 2 次提交