1. 18 Dec, 2013 2 commits
  2. 10 Dec, 2013 2 commits
  3. 09 Dec, 2013 1 commit
  4. 08 Dec, 2013 2 commits
    • Dr. Stephen Henson's avatar
      make update · 60df657b
      Dr. Stephen Henson authored
      60df657b
    • Dr. Stephen Henson's avatar
      Avoid multiple locks in FIPS mode. · 17a2d080
      Dr. Stephen Henson authored
      PR: 3176.
      
      In FIPS mode ssleay_rand_bytes is only used for PRNG seeding and is
      performed in either a single threaded context (when the PRNG is first
      initialised) or under a lock (reseeding). To avoid multiple locks disable
      use of CRYPTO_LOCK_RAND in FIPS mode in ssleay_rand_bytes.
      (cherry picked from commit 53142f72c9b9c9bad2f39ca6200a4f04f5c8001c)
      17a2d080
  5. 03 Dec, 2013 1 commit
  6. 27 Nov, 2013 1 commit
  7. 12 Nov, 2013 3 commits
  8. 11 Nov, 2013 2 commits
  9. 10 Nov, 2013 1 commit
  10. 09 Nov, 2013 2 commits
  11. 08 Nov, 2013 2 commits
  12. 06 Nov, 2013 2 commits
  13. 03 Nov, 2013 1 commit
  14. 01 Nov, 2013 2 commits
    • Robin Seggelmann's avatar
      DTLS/SCTP Finished Auth Bug · 025f7dbd
      Robin Seggelmann authored
      PR: 2808
      
      With DTLS/SCTP the SCTP extension SCTP-AUTH is used to protect DATA and
      FORWARD-TSN chunks. The key for this extension is derived from the
      master secret and changed with the next ChangeCipherSpec, whenever a new
      key has been negotiated. The following Finished then already uses the
      new key.  Unfortunately, the ChangeCipherSpec and Finished are part of
      the same flight as the ClientKeyExchange, which is necessary for the
      computation of the new secret. Hence, these messages are sent
      immediately following each other, leaving the server very little time to
      compute the new secret and pass it to SCTP before the finished arrives.
      So the Finished is likely to be discarded by SCTP and a retransmission
      becomes necessary. To prevent this issue, the Finished of the client is
      still sent with the old key.
      (cherry picked from commit 9fb523ad)
      (cherry picked from commit b9ef52b0)
      025f7dbd
    • Robin Seggelmann's avatar
      DTLS/SCTP struct authchunks Bug · 44f4934b
      Robin Seggelmann authored
      PR: 2809
      
      DTLS/SCTP requires DATA and FORWARD-TSN chunks to be protected with
      SCTP-AUTH.  It is checked if this has been activated successfully for
      the local and remote peer. Due to a bug, however, the
      gauth_number_of_chunks field of the authchunks struct is missing on
      FreeBSD, and was therefore not considered in the OpenSSL implementation.
      This patch sets the corresponding pointer for the check correctly
      whether or not this bug is present.
      (cherry picked from commit f596e3c4)
      (cherry picked from commit b8140811)
      44f4934b
  15. 20 Oct, 2013 2 commits
    • Nick Mathewson's avatar
      453ca706
    • Dr. Stephen Henson's avatar
      Don't use RSA+MD5 with TLS 1.2 · 5e1ff664
      Dr. Stephen Henson authored
      Since the TLS 1.2 supported signature algorithms extension is less
      sophisticaed in OpenSSL 1.0.1 this has to be done in two stages.
      
      RSA+MD5 is removed from supported signature algorithms extension:
      any compliant implementation should never use RSA+MD5 as a result.
      
      To cover the case of a broken implementation using RSA+MD5 anyway
      disable lookup of MD5 algorithm in TLS 1.2.
      5e1ff664
  16. 19 Oct, 2013 3 commits
  17. 13 Oct, 2013 1 commit
  18. 12 Oct, 2013 1 commit
  19. 09 Oct, 2013 2 commits
  20. 03 Oct, 2013 1 commit
  21. 01 Oct, 2013 1 commit
  22. 30 Sep, 2013 1 commit
  23. 22 Sep, 2013 2 commits
  24. 16 Sep, 2013 2 commits
    • Nick Mathewson's avatar
      Do not include a timestamp in the ServerHello Random field. · f4c93b46
      Nick Mathewson authored
      Instead, send random bytes.
      f4c93b46
    • Nick Mathewson's avatar
      Do not include a timestamp in the ClientHello Random field. · 4af79303
      Nick Mathewson authored
      Instead, send random bytes.
      
      While the gmt_unix_time record was added in an ostensible attempt to
      mitigate the dangers of a bad RNG, its presence leaks the host's view
      of the current time in the clear.  This minor leak can help
      fingerprint TLS instances across networks and protocols... and what's
      worse, it's doubtful thet the gmt_unix_time record does any good at
      all for its intended purpose, since:
      
          * It's quite possible to open two TLS connections in one second.
          * If the PRNG output is prone to repeat itself, ephemeral
          * handshakes (and who knows what else besides) are broken.
      4af79303