Skip to content
  1. Feb 01, 2018
  2. Jan 31, 2018
  3. Jan 30, 2018
    • Matt Caswell's avatar
    • Matt Caswell's avatar
      Add the SSL_OP_NO_RENEGOTIATION option to 1.1.0 · 6e127fdd
      Matt Caswell authored
      This is based on a heavily modified version of commit db0f35dd
      
       by Todd
      Short from the master branch.
      
      We are adding this because it used to be possible to disable reneg using
      the flag SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS in 1.0.2. This is no longer
      possible because of the opacity work.
      
      A point to note about this is that if an application built against new
      1.1.0 headers (that know about the new option SSL_OP_NO_RENEGOTIATION
      option) is run using an older version of 1.1.0 (that doesn't know about
      the option) then the option will be accepted but nothing will happen, i.e.
      renegotiation will not be prevented. There's probably not much we can do
      about that.
      
      Fixes #4739
      
      Reviewed-by: default avatarBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/4901)
      6e127fdd
    • Matt Caswell's avatar
      Make sure we check an incoming reneg ClientHello in DTLS · 12492580
      Matt Caswell authored
      
      
      In TLS we have a check to make sure an incoming reneg ClientHello is
      acceptable. The equivalent check is missing in the DTLS code. This means
      that if a client does not signal the ability to handle secure reneg in the
      initial handshake, then a subsequent reneg handshake should be rejected by
      the server. In the DTLS case the reneg was being allowed if the the 2nd
      ClientHello had a renegotiation_info extension. This is incorrect.
      
      While incorrect, this does not represent a security issue because if
      the renegotiation_info extension is present in the second ClientHello it
      also has to be *correct*. Therefore this will only work if both the client
      and server believe they are renegotiating, and both know the previous
      Finished result. This is not the case in an insecure rengotiation attack.
      
      I have also tidied up the check in the TLS code and given a better check
      for determining whether we are renegotiating or not.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5191)
      12492580
  4. Jan 29, 2018
  5. Jan 28, 2018
  6. Jan 26, 2018
  7. Jan 25, 2018
  8. Jan 24, 2018
  9. Jan 23, 2018
  10. Jan 22, 2018
  11. Jan 21, 2018
  12. Jan 20, 2018
  13. Jan 19, 2018
  14. Jan 18, 2018
  15. Jan 17, 2018