1. 18 Sep, 2018 2 commits
  2. 17 Sep, 2018 2 commits
  3. 16 Sep, 2018 4 commits
  4. 15 Sep, 2018 1 commit
  5. 13 Sep, 2018 3 commits
  6. 12 Sep, 2018 5 commits
  7. 11 Sep, 2018 4 commits
  8. 10 Sep, 2018 10 commits
  9. 09 Sep, 2018 2 commits
  10. 08 Sep, 2018 4 commits
  11. 07 Sep, 2018 3 commits
    • Matt Caswell's avatar
      Do not reset SNI data in SSL_do_handshake() · f01344cb
      Matt Caswell authored
      
      
      PR #3783 introduce coded to reset the server side SNI state in
      SSL_do_handshake() to ensure any erroneous config time SNI changes are
      cleared. Unfortunately SSL_do_handshake() can be called mid-handshake
      multiple times so this is the wrong place to do this and can mean that
      any SNI data is cleared later on in the handshake too.
      
      Therefore move the code to a more appropriate place.
      
      Fixes #7014
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
      Reviewed-by: default avatarBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/7149)
      f01344cb
    • Ben Kaduk's avatar
      Simplify SSL_get_servername() to avoid session references · 328a0547
      Ben Kaduk authored
      
      
      Ideally, SSL_get_servername() would do exactly as it is documented
      and return exactly what the client sent (i.e., what we currently
      are stashing in the SSL's ext.hostname), without needing to refer
      to an SSL_SESSION object.  For historical reasons, including the
      parsed SNI value from the ClientHello originally being stored in the
      SSL_SESSION's ext.hostname field, we have had references to the
      SSL_SESSION in this function.  We cannot fully excise them due to
      the interaction between user-supplied callbacks and TLS 1.2 resumption
      flows, where we call all callbacks but the client did not supply an
      SNI value.  Existing callbacks expect to receive a valid SNI value
      in this case, so we must fake one up from the resumed session in
      order to avoid breakage.
      
      Otherwise, greatly simplify the implementation and just return the
      value in the SSL, as sent by the client.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7115)
      328a0547
    • Ben Kaduk's avatar
      Restore historical SSL_get_servername() behavior · 2c0267fd
      Ben Kaduk authored
      Commit 1c4aa31d modified the state machine
      to clean up stale ext.hostname values from SSL objects in the case when
      SNI was not negotiated for the current handshake.  This is natural from
      the TLS perspective, since this information is an extension that the client
      offered but we ignored, and since we ignored it we do not need to keep it
      around for anything else.
      
      However, as documented in https://github.com/openssl/openssl/issues/7014
      
       ,
      there appear to be some deployed code that relies on retrieving such an
      ignored SNI value from the client, after the handshake has completed.
      Because the 1.1.1 release is on a stable branch and should preserve the
      published ABI, restore the historical behavior by retaining the ext.hostname
      value sent by the client, in the SSL structure, for subsequent retrieval.
      
      [extended tests]
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7115)
      2c0267fd