Skip to content
  1. Dec 19, 2015
  2. Dec 18, 2015
  3. Dec 16, 2015
  4. Dec 14, 2015
  5. Dec 10, 2015
  6. Dec 09, 2015
  7. Dec 08, 2015
  8. Dec 07, 2015
  9. Dec 03, 2015
  10. Dec 02, 2015
  11. Nov 30, 2015
    • Matt Caswell's avatar
      Return errors even if the cookie validation has succeeded · 41d049e1
      Matt Caswell authored
      
      
      In the DTLS ClientHello processing the return value is stored in |ret| which
      by default is -1. We wish to return 1 on success or 2 on success *and* we
      have validated the DTLS cookie. Previously on successful validation of the
      cookie we were setting |ret| to 2. Unfortunately if we later encounter an
      error then we can end up returning a successful (positive) return code from
      the function because we already set |ret| to a positive value.
      
      This does not appear to have a security consequence because the handshake
      just fails at a later point.
      
      Reviewed-by: default avatarAndy Polyakov <appro@openssl.org>
      41d049e1
  12. Nov 24, 2015
  13. Nov 22, 2015
  14. Nov 21, 2015
  15. Nov 20, 2015
  16. Nov 18, 2015
  17. Nov 13, 2015
  18. Nov 10, 2015
    • Matt Caswell's avatar
      Stop DTLS servers asking for unsafe legacy renegotiation · 78b9d134
      Matt Caswell authored
      
      
      If a DTLS client that does not support secure renegotiation connects to an
      OpenSSL DTLS server then, by default, renegotiation is disabled. If a
      server application attempts to initiate a renegotiation then OpenSSL is
      supposed to prevent this. However due to a discrepancy between the TLS and
      DTLS code, the server sends a HelloRequest anyway in DTLS.
      
      This is not a security concern because the handshake will still fail later
      in the process when the client responds with a ClientHello.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      (cherry picked from commit d40ec4ab)
      78b9d134