1. 18 6月, 2019 3 次提交
  2. 07 8月, 2018 1 次提交
  3. 20 7月, 2018 1 次提交
    • B
      Normalize SNI hostname handling for SSL and SSL_SESSION · 1c4aa31d
      Benjamin Kaduk 提交于
      In particular, adhere to the rule that we must not modify any
      property of an SSL_SESSION object once it is (or might be) in
      a session cache.  Such modifications are thread-unsafe and have
      been observed to cause crashes at runtime.
      
      To effect this change, standardize on the property that
      SSL_SESSION->ext.hostname is set only when that SNI value
      has been negotiated by both parties for use with that session.
      For session resumption this is trivially the case, so only new
      handshakes are affected.
      
      On the client, the new semantics are that the SSL->ext.hostname is
      for storing the value configured by the caller, and this value is
      used when constructing the ClientHello.  On the server, SSL->ext.hostname
      is used to hold the value received from the client.  Only if the
      SNI negotiation is successful will the hostname be stored into the
      session object; the server can do this after it sends the ServerHello,
      and the client after it has received and processed the ServerHello.
      
      This obviates the need to remove the hostname from the session object
      in case of failed negotiation (a change that was introduced in commit
      9fb6cb81 in order to allow TLS 1.3
      early data when SNI was present in the ClientHello but not the session
      being resumed), which was modifying cached sessions in certain cases.
      (In TLS 1.3 we always produce a new SSL_SESSION object for new
      connections, even in the case of resumption, so no TLS 1.3 handshakes
      were affected.)
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/6378)
      1c4aa31d
  4. 27 6月, 2018 1 次提交
  5. 21 6月, 2018 1 次提交
  6. 07 6月, 2018 2 次提交
  7. 25 5月, 2018 1 次提交
  8. 11 5月, 2018 1 次提交
  9. 28 3月, 2018 2 次提交
  10. 20 3月, 2018 1 次提交
  11. 19 3月, 2018 3 次提交
  12. 13 3月, 2018 1 次提交
  13. 12 3月, 2018 1 次提交
  14. 08 12月, 2017 1 次提交
  15. 04 12月, 2017 1 次提交
  16. 30 10月, 2017 1 次提交
  17. 18 10月, 2017 1 次提交
  18. 09 10月, 2017 1 次提交
  19. 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
  20. 29 9月, 2017 1 次提交
  21. 31 8月, 2017 2 次提交
  22. 30 8月, 2017 2 次提交
  23. 25 8月, 2017 1 次提交
  24. 09 8月, 2017 1 次提交
  25. 03 8月, 2017 3 次提交
  26. 07 7月, 2017 2 次提交
  27. 29 6月, 2017 1 次提交
  28. 21 6月, 2017 2 次提交