Skip to content
  1. Apr 08, 2015
  2. Mar 25, 2015
    • Matt Caswell's avatar
      Deprecate RAND_pseudo_bytes · 302d38e3
      Matt Caswell authored
      
      
      The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
      is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
      the default implementation both end up calling ssleay_rand_bytes. Both may
      return -1 in an error condition. If there is insufficient entropy then
      both will return 0, but RAND_bytes will additionally add an error to the
      error queue. They both return 1 on success.
      Therefore the fundamental difference between the two is that one will add an
      error to the error queue with insufficient entory whilst the other will not.
      Frequently there are constructions of this form:
      
      if(RAND_pseudo_bytes(...) <= 1)
      	goto err;
      
      In the above form insufficient entropy is treated as an error anyway, so
      RAND_bytes is probably the better form to use.
      
      This form is also seen:
      if(!RAND_pseudo_bytes(...))
      	goto err;
      
      This is technically not correct at all since a -1 return value is
      incorrectly handled - but this form will also treat insufficient entropy as
      an error.
      
      Within libssl it is required that you have correctly seeded your entropy
      pool and so there seems little benefit in using RAND_pseudo_bytes.
      Similarly in libcrypto many operations also require a correctly seeded
      entropy pool and so in most interesting cases you would be better off
      using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
      being incorrectly used in scenarios where security can be compromised by
      insufficient entropy.
      
      If you are not using the default implementation, then most engines use the
      same function to implement RAND_bytes and RAND_pseudo_bytes in any case.
      
      Given its misuse, limited benefit, and potential to compromise security,
      RAND_pseudo_bytes has been deprecated.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      302d38e3
  3. Mar 24, 2015
  4. Mar 19, 2015
  5. Mar 11, 2015
  6. Feb 03, 2015
  7. Feb 02, 2015
  8. Jan 31, 2015
  9. Jan 24, 2015
    • Rich Salz's avatar
      ifdef cleanup, part 4a: '#ifdef undef' · a2b18e65
      Rich Salz authored
      
      
      This removes all code surrounded by '#ifdef undef'
      One case is left: memmove() replaced by open-coded for loop,
      in crypto/stack/stack.c  That needs further review.
      
      Also removed a couple of instances of /* dead code */ if I saw them
      while doing the main removal.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      a2b18e65
  10. Jan 23, 2015
  11. Jan 22, 2015
  12. Jan 14, 2015
    • Rich Salz's avatar
      Cleanup OPENSSL_NO_xxx, part 1 · 4b618848
      Rich Salz authored
      
      
      OPENSSL_NO_RIPEMD160, OPENSSL_NO_RIPEMD merged into OPENSSL_NO_RMD160
      OPENSSL_NO_FP_API merged into OPENSSL_NO_STDIO
      Two typo's on #endif comments fixed:
      	OPENSSL_NO_ECB fixed to OPENSSL_NO_OCB
      	OPENSSL_NO_HW_SureWare fixed to OPENSSL_NO_HW_SUREWARE
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      4b618848
  13. Jan 12, 2015
  14. Jan 06, 2015
  15. Jan 05, 2015
    • Dr. Stephen Henson's avatar
      ECDH downgrade bug fix. · b15f8769
      Dr. Stephen Henson authored
      
      
      Fix bug where an OpenSSL client would accept a handshake using an
      ephemeral ECDH ciphersuites with the server key exchange message omitted.
      
      Thanks to Karthikeyan Bhargavan for reporting this issue.
      
      CVE-2014-3572
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      b15f8769
    • Adam Langley's avatar
    • Dr. Stephen Henson's avatar
      Fix various certificate fingerprint issues. · 684400ce
      Dr. Stephen Henson authored
      
      
      By using non-DER or invalid encodings outside the signed portion of a
      certificate the fingerprint can be changed without breaking the signature.
      Although no details of the signed portion of the certificate can be changed
      this can cause problems with some applications: e.g. those using the
      certificate fingerprint for blacklists.
      
      1. Reject signatures with non zero unused bits.
      
      If the BIT STRING containing the signature has non zero unused bits reject
      the signature. All current signature algorithms require zero unused bits.
      
      2. Check certificate algorithm consistency.
      
      Check the AlgorithmIdentifier inside TBS matches the one in the
      certificate signature. NB: this will result in signature failure
      errors for some broken certificates.
      
      3. Check DSA/ECDSA signatures use DER.
      
      Reencode DSA/ECDSA signatures and compare with the original received
      signature. Return an error if there is a mismatch.
      
      This will reject various cases including garbage after signature
      (thanks to Antti Karjalainen and Tuomo Untinen from the Codenomicon CROSS
      program for discovering this case) and use of BER or invalid ASN.1 INTEGERs
      (negative or with leading zeroes).
      
      CVE-2014-8275
      Reviewed-by: default avatarEmilia Käsper <emilia@openssl.org>
      684400ce
  16. Dec 28, 2014
  17. Dec 25, 2014
  18. Dec 22, 2014
  19. Dec 20, 2014
  20. Dec 18, 2014
  21. Dec 17, 2014
  22. Dec 08, 2014
  23. Dec 04, 2014
  24. Nov 20, 2014
  25. Oct 28, 2014
    • Emilia Kasper's avatar
      Tighten session ticket handling · d663df23
      Emilia Kasper authored
      
      
      Tighten client-side session ticket handling during renegotiation:
      ensure that the client only accepts a session ticket if the server sends
      the extension anew in the ServerHello. Previously, a TLS client would
      reuse the old extension state and thus accept a session ticket if one was
      announced in the initial ServerHello.
      
      Reviewed-by: default avatarBodo Moeller <bodo@openssl.org>
      d663df23
  26. Oct 27, 2014