Skip to content
  1. Jan 30, 2018
    • 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
  2. Jan 29, 2018
  3. Jan 28, 2018
  4. Jan 26, 2018
  5. Jan 25, 2018
  6. Jan 24, 2018
  7. Jan 23, 2018
  8. Jan 22, 2018
  9. Jan 21, 2018
  10. Jan 20, 2018
  11. Jan 19, 2018
  12. Jan 18, 2018
  13. Jan 17, 2018
  14. Jan 16, 2018
    • Matt Caswell's avatar
      Extend timeout for TLSProxy · baa5d0ed
      Matt Caswell authored
      
      
      I received this error from a TLSProxy test:
      
      Failed to start up server (localhost,4443): Transport endpoint is not
      connected
      
      So, extend the timeout before we give up trying to connect to the server.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5088)
      
      (cherry picked from commit 82992a41)
      baa5d0ed
    • Matt Caswell's avatar
      Revert BN_copy() flag copy semantics change · d320e803
      Matt Caswell authored
      Commit 9f944291
      
       changed the semantics of BN_copy() to additionally
      copy the BN_FLG_CONSTTIME flag if it is set. This turns out to be
      ill advised as it has unintended consequences. For example calling
      BN_mod_inverse_no_branch() can sometimes return a result with the flag
      set and sometimes not as a result. This can lead to later failures if we
      go down code branches that do not support constant time, but check for
      the presence of the flag.
      
      The original commit was made due to an issue in BN_MOD_CTX_set(). The
      original PR fixed the problem in that function, but it was changed in
      review to fix it in BN_copy() instead. The solution seems to be to revert
      the BN_copy() change and go back to the originally proposed way.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/5080)
      
      (cherry picked from commit 7d461736)
      d320e803
  15. Jan 15, 2018
  16. Jan 14, 2018