1. 21 Mar, 2018 4 commits
    • Bernd Edlinger's avatar
      Cleanup the s_time command. · 178a2a6f
      Bernd Edlinger authored
      
      
      Various code-cleanups.
      Use SSL_CTX_set_mode(ctx, SSL_MODE_AUTO_RETRY) insead of handling
      SSL_ERROR_WANT_READ everywhere.
      Turn off the linger option on connected sockets to avoid failure.
      Add BIO_set_conn_mode(conn, BIO_SOCK_NODELAY) to improve thruput.
      Continue test even without -cipher option as in 1.0.2.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5698)
      178a2a6f
    • 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. 20 Mar, 2018 2 commits
  3. 19 Mar, 2018 6 commits
  4. 17 Mar, 2018 3 commits
  5. 15 Mar, 2018 6 commits
  6. 12 Mar, 2018 3 commits
  7. 11 Mar, 2018 1 commit
  8. 10 Mar, 2018 2 commits
  9. 09 Mar, 2018 1 commit
  10. 08 Mar, 2018 3 commits
  11. 07 Mar, 2018 2 commits
  12. 06 Mar, 2018 4 commits
  13. 04 Mar, 2018 2 commits
  14. 03 Mar, 2018 1 commit