1. 27 7月, 2015 1 次提交
    • M
      Remove support for SSL3_FLAGS_DELAY_CLIENT_FINISHED · 57787ac8
      Matt Caswell 提交于
      This flag was not set anywhere within the codebase (only read). It could
      only be set by an app reaching directly into s->s3->flags and setting it
      directly. However that method became impossible when libssl was opaquified.
      
      Even in 1.0.2/1.0.1 if an app set the flag directly it is only relevant to
      ssl3_connect(), which calls SSL_clear() during initialisation that clears
      any flag settings. Therefore it could take effect if the app set the flag
      after the handshake has started but before it completed. It seems quite
      unlikely that any apps really do this (especially as it is completely
      undocumented).
      
      The purpose of the flag is suppress flushing of the write bio on the client
      side at the end of the handshake after the client has written the Finished
      message whilst resuming a session. This enables the client to send
      application data as part of the same flight as the Finished message.
      
      This flag also controls the setting of a second flag SSL3_FLAGS_POP_BUFFER.
      There is an interesting comment in the code about this second flag in the
      implementation of ssl3_write:
      
      	/* This is an experimental flag that sends the
      	 * last handshake message in the same packet as the first
      	 * use data - used to see if it helps the TCP protocol during
      	 * session-id reuse */
      
      It seems the experiment did not work because as far as I can tell nothing
      is using this code. The above comment has been in the code since SSLeay.
      
      This commit removes support for SSL3_FLAGS_DELAY_CLIENT_FINISHED, as well
      as the associated SSL3_FLAGS_POP_BUFFER.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      57787ac8
  2. 23 7月, 2015 3 次提交
  3. 21 7月, 2015 4 次提交
  4. 20 7月, 2015 1 次提交
    • R
      Rewrite crypto/ex_data · 7e5363ab
      Rich Salz 提交于
      Removed ability to set ex_data impl at runtime.  This removed these
      three functions:
          const CRYPTO_EX_DATA_IMPL *CRYPTO_get_ex_data_implementation(void);
          int CRYPTO_set_ex_data_implementation(const CRYPTO_EX_DATA_IMPL *i);
          int CRYPTO_ex_data_new_class(void);
      It is no longer possible to change the ex_data implementation at
      runtime.  (Luckily those functions were never documented :)
      
      Also removed the ability to add new exdata "classes."  We don't believe
      this received much (if any) use, since you can't add it to OpenSSL objects,
      and there are probably better (native) methods for developers to add
      their own extensible data, if they really need that.
      
      Replaced the internal hash table (of per-"class" stacks) with a simple
      indexed array.  Reserved an index for "app" application.
      
      Each API used to take the lock twice; now it only locks once.
      
      Use local stack storage for function pointers, rather than malloc,
      if possible (i.e., number of ex_data items is under a dozen).
      
      Make CRYPTO_EX_DATA_FUNCS opaque/internal.
      
      Also fixes RT3710; index zero is reserved.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      7e5363ab
  5. 18 7月, 2015 1 次提交
  6. 16 7月, 2015 1 次提交
  7. 15 7月, 2015 4 次提交
  8. 14 7月, 2015 4 次提交
  9. 13 7月, 2015 1 次提交
  10. 11 7月, 2015 1 次提交
  11. 10 7月, 2015 3 次提交
  12. 09 7月, 2015 4 次提交
  13. 08 7月, 2015 6 次提交
    • 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
      Add help text for some verify options · a64ba70d
      Matt Caswell 提交于
      Fills in the help text for a number of options to verify that were blank.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      a64ba70d
    • M
      Add documentation for some missing verify options · 79a55b1f
      Matt Caswell 提交于
      Fills in a couple of verify options that were lacking documentation.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      79a55b1f
    • 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
      Add test for CVE-2015-1793 · 593e9c63
      Matt Caswell 提交于
      This adds a test for CVE-2015-1793. This adds a new test file
      verify_extra_test.c, which could form the basis for additional
      verification tests.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      593e9c63
    • 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
  14. 07 7月, 2015 3 次提交
  15. 06 7月, 2015 1 次提交
  16. 30 6月, 2015 2 次提交