1. 04 12月, 2017 3 次提交
  2. 26 9月, 2017 2 次提交
  3. 09 9月, 2017 2 次提交
  4. 01 9月, 2017 1 次提交
  5. 31 8月, 2017 2 次提交
  6. 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
  7. 03 8月, 2017 1 次提交
  8. 18 7月, 2017 1 次提交
  9. 07 7月, 2017 2 次提交
  10. 21 6月, 2017 3 次提交
  11. 20 6月, 2017 1 次提交
  12. 16 6月, 2017 4 次提交
  13. 12 6月, 2017 1 次提交
  14. 07 6月, 2017 1 次提交
  15. 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
  16. 11 5月, 2017 1 次提交
  17. 10 5月, 2017 1 次提交
  18. 03 5月, 2017 1 次提交
  19. 26 4月, 2017 3 次提交
  20. 25 4月, 2017 1 次提交
  21. 07 4月, 2017 1 次提交
  22. 29 3月, 2017 1 次提交
  23. 24 3月, 2017 1 次提交
  24. 18 3月, 2017 2 次提交
  25. 16 3月, 2017 2 次提交