1. 19 3月, 2018 3 次提交
  2. 17 3月, 2018 1 次提交
  3. 16 3月, 2018 5 次提交
  4. 15 3月, 2018 8 次提交
  5. 14 3月, 2018 6 次提交
  6. 13 3月, 2018 1 次提交
  7. 12 3月, 2018 1 次提交
  8. 10 3月, 2018 2 次提交
    • D
      RAND_DRBG: add a function for setting the reseeding defaults · 4917e911
      Dr. Matthias St. Pierre 提交于
      The introduction of thread local public and private DRBG instances (#5547)
      makes it very cumbersome to change the reseeding (time) intervals for
      those instances. This commit provides a function to set the default
      values for all subsequently created DRBG instances.
      
       int RAND_DRBG_set_reseed_defaults(
                                         unsigned int master_reseed_interval,
                                         unsigned int slave_reseed_interval,
                                         time_t master_reseed_time_interval,
                                         time_t slave_reseed_time_interval
                                         );
      
      The function is intended only to be used during application initialization,
      before any threads are created and before any random bytes are generated.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5576)
      4917e911
    • T
      Add SSL/SSL_CTX_use_cert_and_key() · 37933acb
      Todd Short 提交于
      Add functions that will do the work of assigning certificate, privatekey
      and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the
      publickey. This will permit the keys to pass validation for both ECDSA
      and RSA. If a private key has already been set for the certificate, it
      is discarded. A real private key can be set later.
      
      This is an all-or-nothing setting of these parameters. Unlike the
      SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions,
      the existing cert or privatekey is not modified (i.e. parameters copied).
      This permits the existing cert/privatekey to be replaced.
      
      It replaces the sequence of:
      * SSL_use_certificate()
      * SSL_use_privatekey()
      * SSL_set1_chain()
      And may actually be faster, as multiple checks are consolidated.
      
      The private key can be NULL, if so an ENGINE module needs to contain the
      actual private key that is to be used.
      
      Note that ECDH (using the certificate's ECDSA key) ciphers do not work
      without the private key being present, based on how the private key is
      used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
      (Merged from https://github.com/openssl/openssl/pull/1130)
      37933acb
  9. 07 3月, 2018 1 次提交
  10. 26 2月, 2018 1 次提交
  11. 23 2月, 2018 4 次提交
  12. 21 2月, 2018 1 次提交
    • M
      Remove a spurious TLSProxy byte in TLSv1.3 · 6c61b274
      Matt Caswell 提交于
      When the proxy re-encrypted a TLSv1.3 record it was adding a spurious
      byte onto the end. This commit removes that.
      
      The "extra" byte was intended to be the inner content type of the record.
      However, TLSProxy was actually adding the original encrypted data into the
      record (which already has the inner content type in it) and then adding
      the spurious additional content type byte on the end (and adjusting the
      record length accordingly).
      
      It is interesting to look at why this didn't cause a failure:
      
      The receiving peer first attempts to decrypt the data. Because this is
      TLSProxy we always use a GCM based ciphersuite with a 16 byte tag. When
      we decrypt this it actually gets diverted to the ossltest engine. All this
      does is go through the motions of encrypting/decrypting but just passes
      back the original data. Crucially it will never fail because of a bad tag!
      The receiving party thinks the spurious additional byte is part of the
      tag and the ossltest engine ignores it.
      
      This means the data that gets passed back to the record layer still has
      an additional spurious byte on it - but because the 16 byte tag has been
      removed, this is actually the first byte of the original tag. Again
      because we are using ossltest engine we aren't actually creating "real"
      tags - we only ever emit 16, 0 bytes for the tag. So the spurious
      additional byte always has the value 0. The TLSv1.3 spec says that records
      can have additional 0 bytes on the end of them - this is "padding". So the
      record layer interprets this 0 byte as padding and strips it off to end up
      with the originally transmitted record data - which it can now process
      successfully.
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/5370)
      6c61b274
  13. 20 2月, 2018 2 次提交
  14. 19 2月, 2018 1 次提交
  15. 15 2月, 2018 2 次提交
  16. 14 2月, 2018 1 次提交