Skip to content
  1. Mar 21, 2018
    • Matt Caswell's avatar
      Don't wait for dry at the end of a handshake · 329aa341
      Matt Caswell authored
      
      
      For DTLS/SCTP we were waiting for a dry event during the call to
      tls_finish_handshake(). This function just tidies up various internal
      things, and after it completes the handshake is over. I can find no good
      reason for waiting for a dry event here, and nothing in RFC6083 suggests
      to me that we should need to. More importantly though it seems to be
      wrong. It is perfectly possible for a peer to send app data/alerts/new
      handshake while we are still cleaning up our handshake. If this happens
      then we will never get the dry event and so we cannot continue.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5085)
      329aa341
    • Matt Caswell's avatar
      Check for alerts while waiting for a dry event · 041ddc36
      Matt Caswell authored
      
      
      At a couple of points in a DTLS/SCTP handshake we need to wait for a dry
      event before continuing. However if an alert has been sent by the peer
      then we will never receive that dry event and an infinite loop results.
      
      This commit changes things so that we attempt to read a message if we
      are waiting for a dry event but haven't got one yet. This should never
      succeed, but any alerts will be processed.
      
      Fixes #4763
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5085)
      041ddc36
    • Benjamin Kaduk's avatar
      Do not cache sessions with zero sid_ctx_length when SSL_VERIFY_PEER · 8e405776
      Benjamin Kaduk authored
      
      
      The sid_ctx is something of a "certificate request context" or a
      "session ID context" -- something from the application that gives
      extra indication of what sort of thing this session is/was for/from.
      Without a sid_ctx, we only know that there is a session that we
      issued, but it could have come from a number of things, especially
      with an external (shared) session cache.  Accordingly, when resuming,
      we will hard-error the handshake when presented with a session with
      zero-length sid_ctx and SSL_VERIFY_PEER is set -- we simply have no
      information about the peer to verify, so the verification must fail.
      
      In order to prevent these future handshake failures, proactively
      decline to add the problematic sessions to the session cache.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5175)
      
      (cherry picked from commit d316cdcf)
      8e405776
  2. Mar 20, 2018
  3. Mar 19, 2018
  4. Mar 17, 2018
  5. Mar 15, 2018
  6. Mar 12, 2018
  7. Mar 11, 2018
  8. Mar 10, 2018
  9. Mar 09, 2018
  10. Mar 08, 2018
  11. Mar 07, 2018
  12. Mar 06, 2018
  13. Mar 04, 2018
  14. Mar 03, 2018