1. 10 Nov, 2016 14 commits
  2. 09 Nov, 2016 2 commits
  3. 08 Nov, 2016 3 commits
  4. 07 Nov, 2016 7 commits
    • FdaSilvaYY's avatar
      Allow null in X509_CRL_METHOD_free · 6fa4d63d
      FdaSilvaYY authored
      
      
      and fix documentation.
      
      Reviewed-by: default avatarTim Hudson <tjh@openssl.org>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/1634)
      (cherry picked from commit 7cb1ecec)
      6fa4d63d
    • Andrea Grandi's avatar
      Improve PRF documentation · 28304b12
      Andrea Grandi authored
      
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      
      GH: #1834
      (cherry picked from commit 27ed73a9)
      28304b12
    • David Benjamin's avatar
      Improve RSA test coverage. · b9ddc5fd
      David Benjamin authored
      MD5/SHA1 and MDC-2 have special-case logic beyond the generic DigestInfo
      wrapping. Test that each of these works, including hash and length
      mismatches (both input and signature). Also add VerifyRecover tests. It
      appears 5824cc29
      
       added support for
      VerifyRecover, but forgot to add the test data.
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      
      GH: #1474
      (cherry picked from commit f3205557)
      b9ddc5fd
    • David Benjamin's avatar
      Make RSA_sign.pod less confusing. · 439530bc
      David Benjamin authored
      
      
      PKCS #1 v2.0 is the name of a document which specifies an algorithm
      RSASSA-PKCS1-v1_5, often referred to as "PKCS #1 v1.5" after an earlier
      document which specified it. This gets further confusing because the
      document PKCS #1 v2.1 specifies two signature algorithms,
      RSASSA-PKCS1-v1_5 and RSASSA-PSS. RSA_sign implements RSASSA-PKCS1-v1_5.
      
      Refer to the document using the RFC number which is easier to find
      anyway, and refer to the algorithm by its name.
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      
      GH: #1474
      (cherry picked from commit aa90ca11)
      439530bc
    • David Benjamin's avatar
      Implement RSASSA-PKCS1-v1_5 as specified. · b71079a3
      David Benjamin authored
      RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
      the DigestInfo struct and then compare the result against the public key
      operation result. This implies that one and only one encoding is legal.
      
      OpenSSL instead parses with crypto/asn1, then checks that the encoding
      round-trips, and allows some variations for the parameter. Sufficient
      laxness in this area can allow signature forgeries, as described in
      https://www.imperialviolet.org/2014/09/26/pkcs1.html
      
      Although there aren't known attacks against OpenSSL's current scheme,
      this change makes OpenSSL implement the algorithm as specified. This
      avoids the uncertainty and, more importantly, helps grow a healthy
      ecosystem. Laxness beyond the spec, particularly in implementations
      which enjoy wide use, risks harm to the ecosystem for all. A signature
      producer which only tests against OpenSSL may not notice bugs and
      accidentally become widely deployed. Thus implementations have a
      responsibility to honor the specification as tightly as is practical.
      
      In some cases, the damage is permanent and the spec deviation and
      security risk becomes a tax all implementors must forever pay, but not
      here. Both BoringSSL and Go successfully implemented and deployed
      RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
      this change should be compatible enough to pin down in future OpenSSL
      releases.
      
      See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
      
      
      
      As a bonus, by not having to deal with sign/verify differences, this
      version is also somewhat clearer. It also more consistently enforces
      digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
      wasn't quite doing this right.
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      
      GH: #1474
      (cherry picked from commit 608a0264)
      b71079a3
    • Matt Caswell's avatar
      Partial revert of "Fix client verify mode to check SSL_VERIFY_PEER" · 929cc3fa
      Matt Caswell authored
      This partially reverts commit c636c1c4
      
      . It also tweaks the documentation
      and comments in this area. On the client side the documented interface for
      SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag
      SSL_VERIFY_PEER causes verfication of the server certificate to take place.
      Previously what was implemented was that if *any* flag was set then
      verification would take place. The above commit improved the semantics to
      be as per the documented interface.
      
      However, we have had a report of at least one application where an
      application was incorrectly using the interface and used *only*
      SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to
      the above commit this still caused verification of the server certificate
      to take place. After this commit the application silently failed to verify
      the server certificate.
      
      Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate
      if invalid flags were being used. However these are void functions!
      
      The simplest short term solution is to revert to the previous behaviour
      which at least means we "fail closed" rather than "fail open".
      
      Thanks to Cory Benfield for reporting this issue.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (cherry picked from commit c8e2f98c)
      929cc3fa
    • Matt Caswell's avatar
      Always ensure that init_msg is initialised for a CCS · 992b3740
      Matt Caswell authored
      
      
      We read it later in grow_init_buf(). If CCS is the first thing received in
      a flight, then it will use the init_msg from the last flight we received. If
      the init_buf has been grown in the meantime then it will point to some
      arbitrary other memory location. This is likely to result in grow_init_buf()
      attempting to grow to some excessively large amount which is likely to
      fail. In practice this should never happen because the only time we receive
      a CCS as the first thing in a flight is in an abbreviated handshake. None
      of the preceding messages from the server flight would be large enough to
      trigger this.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      (cherry picked from commit c4377574)
      992b3740
  5. 06 Nov, 2016 3 commits
  6. 04 Nov, 2016 3 commits
  7. 03 Nov, 2016 8 commits