1. 31 8月, 2017 1 次提交
  2. 30 8月, 2017 1 次提交
  3. 18 8月, 2017 1 次提交
  4. 15 8月, 2017 1 次提交
    • B
      Move ALPN handling from finalizer to delayed call · 5626f634
      Benjamin Kaduk 提交于
      Commit 02f0274e moved ALPN processing
      into an extension finalization function, as the only documented ordering
      requirement from previous commits was that ALPN processing occur after
      SNI processing, and SNI processing is performed before the extension
      finalization step.  However, it is useful for applications'
      alpn_select callbacks to run after ciphersuite selection as well -- at
      least one application protocol specification (HTTP/2) imposes restrictions
      on which ciphersuites are usable with that protocol.  Since it is generally
      more preferrable to have a successful TLS connection with a default application
      protocol than to fail the TLS connection and not be able to have the preferred
      application protocol, it is good to give the alpn_select callback information
      about the ciphersuite to be used, so that appropriate restrctions can be
      enforced in application code.
      
      Accordingly, split the ALPN handling out into a separate tls_handl_alpn()
      function akin to tls_handle_status_request(), called from
      tls_post_process_client_hello().  This is an alternative to resuscitating
      ssl_check_clienthello_tlsext_late(), something of an awkwward name itself.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4070)
      5626f634
  5. 11 8月, 2017 1 次提交
  6. 01 8月, 2017 1 次提交
  7. 18 7月, 2017 1 次提交
  8. 07 7月, 2017 2 次提交
  9. 21 6月, 2017 2 次提交
  10. 12 6月, 2017 1 次提交
  11. 10 6月, 2017 1 次提交
  12. 19 5月, 2017 1 次提交
    • M
      Try to be more consistent about the alerts we send · fb34a0f4
      Matt Caswell 提交于
      We are quite inconsistent about which alerts get sent. Specifically, these
      alerts should be used (normally) in the following circumstances:
      
      SSL_AD_DECODE_ERROR = The peer sent a syntactically incorrect message
      SSL_AD_ILLEGAL_PARAMETER = The peer sent a message which was syntactically
      correct, but a parameter given is invalid for the context
      SSL_AD_HANDSHAKE_FAILURE = The peer's messages were syntactically and
      semantically correct, but the parameters provided were unacceptable to us
      (e.g. because we do not support the requested parameters)
      SSL_AD_INTERNAL_ERROR = We messed up (e.g. malloc failure)
      
      The standards themselves aren't always consistent but I think the above
      represents the best interpretation.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/3480)
      fb34a0f4
  13. 17 5月, 2017 3 次提交
  14. 11 5月, 2017 1 次提交
  15. 10 5月, 2017 1 次提交
  16. 08 5月, 2017 1 次提交
  17. 04 5月, 2017 1 次提交
  18. 26 4月, 2017 3 次提交
  19. 10 4月, 2017 1 次提交
    • B
      Allow an ALPN callback to pretend to not exist · 8313a787
      Benjamin Kaduk 提交于
      RFC 7301 mandates that the server SHALL respond with a fatal
      "no_application_protocol" alert when there is no overlap between
      the client's supplied list and the server's list of supported protocols.
      In commit 06217867 we changed from
      ignoring non-success returns from the supplied alpn_select_cb() to
      treating such non-success returns as indicative of non-overlap and
      sending the fatal alert.
      
      In effect, this is using the presence of an alpn_select_cb() as a proxy
      to attempt to determine whether the application has configured a list
      of supported protocols.  However, there may be cases in which an
      application's architecture leads it to supply an alpn_select_cb() but
      have that callback be configured to take no action on connections that
      do not have ALPN configured; returning SSL_TLSEXT_ERR_NOACK from
      the callback would be the natural way to do so.  Unfortunately, the
      aforementioned behavior change also treated SSL_TLSEXT_ERR_NOACK as
      indicative of no overlap and terminated the connection; this change
      supplies special handling for SSL_TLSEXT_ERR_NOACK returns from the
      callback.  In effect, it provides a way for a callback to obtain the
      behavior that would have occurred if no callback was registered at
      all, which was not possible prior to this change.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/2570)
      8313a787
  20. 07 4月, 2017 3 次提交
  21. 04 4月, 2017 2 次提交
  22. 29 3月, 2017 1 次提交
  23. 21 3月, 2017 1 次提交
    • M
      Fix resumption after HRR · 77815a02
      Matt Caswell 提交于
      Commit 6b1bb98f moved the processing of ClientHello extensions into the
      state machine post-processing stage. After processing s->init_num is reset
      to 0, so by post-processing we cannot rely on its value. Unfortunately we
      were using it to handle the PSK extension. This causes the handshake to
      fail.
      
      We were using init_num to figure out the length of ClientHello2 so we can
      remove it from the handshake_buffer. The handshake_buffer holds the
      transcript of all the messages sent so far. For PSK processing though we
      only want to add in a partial ClientHello2. This commit changes things so
      we just work out where ClientHello2 starts, working forward from the
      beginning of handshake_buffer.
      
      Fixes #2983
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/2996)
      77815a02
  24. 18 3月, 2017 2 次提交
  25. 16 3月, 2017 2 次提交
  26. 15 3月, 2017 1 次提交
  27. 10 3月, 2017 1 次提交
  28. 05 3月, 2017 2 次提交