1. 14 3月, 2020 1 次提交
    • B
      Code to thread-safety in ChangeCipherState · 44bad9cb
      Benjamin Kaduk 提交于
      The server-side ChangeCipherState processing stores the new cipher
      in the SSL_SESSION object, so that the new state can be used if
      this session gets resumed.  However, writing to the session is only
      thread-safe for initial handshakes, as at other times the session
      object may be in a shared cache and in use by another thread at the
      same time.  Reflect this invariant in the code by only writing to
      s->session->cipher when it is currently NULL (we do not cache sessions
      with no cipher).  The code prior to this change would never actually
      change the (non-NULL) cipher value in a session object, since our
      server enforces that (pre-TLS-1.3) resumptions use the exact same
      cipher as the initial connection, and non-abbreviated renegotiations
      have produced a new session object before we get to this point.
      Regardless, include logic to detect such a condition and abort the
      handshake if it occurs, to avoid any risk of inadvertently using
      the wrong cipher on a connection.
      Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
      (Merged from https://github.com/openssl/openssl/pull/10943)
      
      (cherry picked from commit 2e3ec2e1578977fca830a47fd7f521e290540e6d)
      44bad9cb
  2. 11 3月, 2020 1 次提交
  3. 06 3月, 2020 2 次提交
  4. 05 3月, 2020 1 次提交
  5. 28 2月, 2020 1 次提交
  6. 21 2月, 2020 2 次提交
  7. 17 2月, 2020 1 次提交
  8. 15 2月, 2020 1 次提交
  9. 12 2月, 2020 1 次提交
  10. 07 2月, 2020 2 次提交
  11. 06 2月, 2020 2 次提交
  12. 21 1月, 2020 2 次提交
  13. 17 1月, 2020 1 次提交
  14. 15 1月, 2020 1 次提交
  15. 07 1月, 2020 2 次提交
  16. 05 1月, 2020 8 次提交
  17. 02 1月, 2020 1 次提交
  18. 24 12月, 2019 5 次提交
  19. 23 12月, 2019 1 次提交
  20. 21 12月, 2019 4 次提交