1. 09 3月, 2016 1 次提交
  2. 11 2月, 2016 1 次提交
  3. 09 2月, 2016 1 次提交
    • V
      Suppress DANE TLSA reflection when verification fails · c0a445a9
      Viktor Dukhovni 提交于
      As documented both SSL_get0_dane_authority() and SSL_get0_dane_tlsa()
      are expected to return a negative match depth and nothing else when
      verification fails.  However, this only happened when verification
      failed during chain construction.  Errors in verification of the
      constructed chain did not have the intended effect on these functions.
      
      This commit updates the functions to check for verify_result ==
      X509_V_OK, and no longer erases any accumulated match information
      when chain construction fails.  Sophisticated developers can, with
      care, use SSL_set_verify_result(ssl, X509_V_OK) to "peek" at TLSA
      info even when verification fail.  They must of course first check
      and save the real error, and restore the original error as quickly
      as possible.  Hiding by default seems to be the safer interface.
      
      Introduced X509_V_ERR_DANE_NO_MATCH code to signal failure to find
      matching TLSA records.  Previously reported via X509_V_ERR_CERT_UNTRUSTED.
      
      This also changes the "-brief" output from s_client to include
      verification results and TLSA match information.
      
      Mentioned session resumption in code example in SSL_CTX_dane_enable(3).
      Also mentioned that depths returned are relative to the verified chain
      which is now available via SSL_get0_verified_chain(3).
      
      Added a few more test-cases to danetest, that exercise the new
      code.
      
      Resolved thread safety issue in use of static buffer in
      X509_verify_cert_error_string().
      
      Fixed long-stating issue in apps/s_cb.c which always sets verify_error
      to either X509_V_OK or "chain to long", code elsewhere (e.g.
      s_time.c), seems to expect the actual error.  [ The new chain
      construction code is expected to correctly generate "chain
      too long" errors, so at some point we need to drop the
      work-arounds, once SSL_set_verify_depth() is also fixed to
      propagate the depth to X509_STORE_CTX reliably. ]
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      c0a445a9
  4. 06 2月, 2016 3 次提交
  5. 01 2月, 2016 2 次提交
  6. 27 1月, 2016 1 次提交
    • R
      Remove /* foo.c */ comments · 34980760
      Rich Salz 提交于
      This was done by the following
              find . -name '*.[ch]' | /tmp/pl
      where /tmp/pl is the following three-line script:
              print unless $. == 1 && m@/\* .*\.[ch] \*/@;
              close ARGV if eof; # Close file to reset $.
      
      And then some hand-editing of other files.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      34980760
  7. 21 1月, 2016 1 次提交
    • V
      Check Suite-B constraints with EE DANE records · 6e328256
      Viktor Dukhovni 提交于
      When DANE-EE(3) matches or either of DANE-EE/PKIX-EE fails, we don't
      build a chain at all, but rather succeed or fail with just the leaf
      certificate.  In either case also check for Suite-B violations.
      
      As unlikely as it may seem that anyone would enable both DANE and
      Suite-B, we should do what the application asks.
      
      Took the opportunity to eliminate the "cb" variables in x509_vfy.c,
      just call ctx->verify_cb(ok, ctx)
      Reviewed-by: NDr. Stephen Henson <steve@openssl.org>
      6e328256
  8. 19 1月, 2016 1 次提交
  9. 16 1月, 2016 1 次提交
  10. 15 1月, 2016 3 次提交
  11. 08 1月, 2016 1 次提交
  12. 06 1月, 2016 1 次提交
  13. 04 1月, 2016 2 次提交
  14. 15 12月, 2015 1 次提交
  15. 02 12月, 2015 1 次提交
  16. 27 11月, 2015 1 次提交
  17. 10 11月, 2015 1 次提交
  18. 15 10月, 2015 1 次提交
  19. 06 9月, 2015 2 次提交
  20. 04 9月, 2015 1 次提交
    • D
      Revert "OPENSSL_NO_xxx cleanup: RFC3779" · 47bbaa5b
      David Woodhouse 提交于
      This reverts the non-cleanup parts of commit c73ad690. We do actually
      have a reasonable use case for OPENSSL_NO_RFC3779 in the EDK2 UEFI
      build, since we don't have a strspn() function in our runtime environment
      and we don't want the RFC3779 functionality anyway.
      
      In addition, it changes the default behaviour of the Configure script so
      that RFC3779 support isn't disabled by default. It was always disabled
      from when it was first added in 2006, right up until the point where
      OPENSSL_NO_RFC3779 was turned into a no-op, and the code in the
      Configure script was left *trying* to disable it, but not actually
      working.
      Signed-off-by: NRich Salz <rsalz@akamai.com>
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      47bbaa5b
  21. 03 9月, 2015 2 次提交
  22. 02 9月, 2015 1 次提交
    • V
      Better handling of verify param id peername field · a0724ef1
      Viktor Dukhovni 提交于
      Initialize pointers in param id by the book (explicit NULL assignment,
      rather than just memset 0).
      
      In x509_verify_param_zero() set peername to NULL after freeing it.
      
      In x509_vfy.c's internal check_hosts(), avoid potential leak of
      possibly already non-NULL peername.  This is only set when a check
      succeeds, so don't need to do this repeatedly in the loop.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      a0724ef1
  23. 01 9月, 2015 2 次提交
  24. 28 8月, 2015 1 次提交
  25. 14 8月, 2015 1 次提交
  26. 11 8月, 2015 1 次提交
  27. 08 7月, 2015 3 次提交
    • M
      Extend -show_chain option to verify to show more info · 7f3f41d8
      Matt Caswell 提交于
      The -show_chain flag to the verify command line app shows information about
      the chain that has been built. This commit adds the text "untrusted" against
      those certificates that have been used from the untrusted list.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      7f3f41d8
    • M
      Reject calls to X509_verify_cert that have not been reinitialised · aae41f8c
      Matt Caswell 提交于
      The function X509_verify_cert checks the value of |ctx->chain| at the
      beginning, and if it is NULL then it initialises it, along with the value
      of ctx->untrusted. The normal way to use X509_verify_cert() is to first
      call X509_STORE_CTX_init(); then set up various parameters etc; then call
      X509_verify_cert(); then check the results; and finally call
      X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
      |ctx->chain| to NULL. The only place in the OpenSSL codebase  where
      |ctx->chain| is set to anything other than a non NULL value is in
      X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
      non NULL on entry to X509_verify_cert is if one of the following occurs:
      1) An application calls X509_verify_cert() twice without re-initialising
      in between.
      2) An application reaches inside the X509_STORE_CTX structure and changes
      the value of |ctx->chain| directly.
      
      With regards to the second of these, we should discount this - it should
      not be supported to allow this.
      
      With regards to the first of these, the documentation is not exactly
      crystal clear, but the implication is that you must call
      X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
      to do this then, at best, the results would be undefined.
      
      Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
      likely to have unexpected results, and could be dangerous. This commit
      changes the behaviour of X509_verify_cert() so that it causes an error if
      |ctx->chain| is anything other than NULL (because this indicates that we
      have not been initialised properly). It also clarifies the associated
      documentation. This is a follow up commit to CVE-2015-1793.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      aae41f8c
    • M
      Fix alternate chains certificate forgery issue · 2aacec8f
      Matt Caswell 提交于
      During certificate verfification, OpenSSL will attempt to find an
      alternative certificate chain if the first attempt to build such a chain
      fails. An error in the implementation of this logic can mean that an
      attacker could cause certain checks on untrusted certificates to be
      bypassed, such as the CA flag, enabling them to use a valid leaf
      certificate to act as a CA and "issue" an invalid certificate.
      
      This occurs where at least one cert is added to the first chain from the
      trust store, but that chain still ends up being untrusted. In that case
      ctx->last_untrusted is decremented in error.
      
      Patch provided by the BoringSSL project.
      
      CVE-2015-1793
      Reviewed-by: NStephen Henson <steve@openssl.org>
      2aacec8f
  28. 11 6月, 2015 1 次提交
  29. 14 5月, 2015 1 次提交