1. 23 5月, 2018 1 次提交
    • V
      Limit scope of CN name constraints · d02d80b2
      Viktor Dukhovni 提交于
      Don't apply DNS name constraints to the subject CN when there's a
      least one DNS-ID subjectAlternativeName.
      
      Don't apply DNS name constraints to subject CN's that are sufficiently
      unlike DNS names.  Checked name must have at least two labels, with
      all labels non-empty, no trailing '.' and all hyphens must be
      internal in each label.  In addition to the usual LDH characters,
      we also allow "_", since some sites use these for hostnames despite
      all the standards.
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      d02d80b2
  2. 20 3月, 2018 1 次提交
  3. 05 3月, 2018 1 次提交
  4. 16 11月, 2017 2 次提交
  5. 12 11月, 2017 1 次提交
  6. 23 9月, 2017 1 次提交
    • D
      Guard against DoS in name constraints handling. · 8545051c
      David Benjamin 提交于
      This guards against the name constraints check consuming large amounts
      of CPU time when certificates in the presented chain contain an
      excessive number of names (specifically subject email names or subject
      alternative DNS names) and/or name constraints.
      
      Name constraints checking compares the names presented in a certificate
      against the name constraints included in a certificate higher up in the
      chain using two nested for loops.
      
      Move the name constraints check so that it happens after signature
      verification so peers cannot exploit this using a chain with invalid
      signatures. Also impose a hard limit on the number of name constraints
      check loop iterations to further mitigate the issue.
      
      Thanks to NCC for finding this issue. Fix written by Martin Kreichgauer.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4393)
      8545051c
  7. 20 9月, 2017 1 次提交
  8. 01 7月, 2017 1 次提交
  9. 21 6月, 2017 2 次提交
  10. 07 6月, 2017 1 次提交
  11. 31 5月, 2017 1 次提交
  12. 26 4月, 2017 2 次提交
  13. 13 4月, 2017 1 次提交
  14. 15 3月, 2017 1 次提交
  15. 25 2月, 2017 2 次提交
  16. 18 2月, 2017 2 次提交
  17. 17 2月, 2017 1 次提交
  18. 15 1月, 2017 1 次提交
  19. 12 7月, 2016 1 次提交
  20. 23 6月, 2016 2 次提交
  21. 21 6月, 2016 2 次提交
  22. 13 6月, 2016 1 次提交
  23. 08 6月, 2016 1 次提交
  24. 03 6月, 2016 1 次提交
  25. 03 4月, 2016 1 次提交
    • V
      Move peer chain security checks into x509_vfy.c · fbb82a60
      Viktor Dukhovni 提交于
      A new X509_VERIFY_PARAM_set_auth_level() function sets the
      authentication security level.  For verification of SSL peers, this
      is automatically set from the SSL security level.  Otherwise, for
      now, the authentication security level remains at (effectively) 0
      by default.
      
      The new "-auth_level" verify(1) option is available in all the
      command-line tools that support the standard verify(1) options.
      
      New verify(1) tests added to check enforcement of chain signature
      and public key security levels.  Also added new tests of enforcement
      of the verify_depth limit.
      
      Updated documentation.
      Reviewed-by: NDr. Stephen Henson <steve@openssl.org>
      fbb82a60
  26. 30 3月, 2016 1 次提交
  27. 02 3月, 2016 1 次提交
  28. 26 2月, 2016 1 次提交
  29. 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
  30. 01 2月, 2016 3 次提交
  31. 21 1月, 2016 1 次提交