Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
11 个月 前同步成功

通知 8
Star 18
Fork 1
T
Third Party Openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 3月, 2018 6 次提交
  3. 18 3月, 2018 1 次提交
  5. 17 3月, 2018 3 次提交
  7. 16 3月, 2018 1 次提交
  9. 15 3月, 2018 3 次提交
  11. 14 3月, 2018 4 次提交
  13. 13 3月, 2018 3 次提交
  15. 12 3月, 2018 1 次提交
  17. 10 3月, 2018 2 次提交
    • B
      Reuse extension_is_relevant() in should_add_extension() · ee36b963
      由 Benjamin Kaduk 提交于 
      At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtensions,
etc., and sometimes only for a specific protocol or protocol range;
we want to enforce that we only parse or generate extensions in the
context(s) for which they are defined.  There is some subtlety here,
in that the protocol version in use is not known when generating the
ClientHello (but it is known when the ClientHello extensions are
being parsed!), so the SSL_IS_TLS13() macro must be used with caution.
Nonetheless, by making assertions about whether we are acting in a
server role and whether the current context is (not) a ClientHello,
we can consolidate almost all of the logic for determining whether
an extension is permitted in a given protocol message, whether we
are generating or parsing that message.

The only logic that remains separate relates to generating the ClientHello,
as it depends on an external factor (the maximum permitted TLS version) that
is not defined in the parsing context.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2945)
      ee36b963
    • 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
  19. 09 3月, 2018 3 次提交
  21. 08 3月, 2018 1 次提交
  23. 05 3月, 2018 3 次提交
  25. 01 3月, 2018 2 次提交
    • B
      Do not set a nonzero default max_early_data · c39e4048
      由 Benjamin Kaduk 提交于 
      When early data support was first added, this seemed like a good
idea, as it would allow applications to just add SSL_read_early_data()
calls as needed and have things "Just Work".  However, for applications
that do not use TLS 1.3 early data, there is a negative side effect.
Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
derived from it) means that when generating a session ticket,
tls_construct_stoc_early_data() will indicate to the client that
the server supports early data.  This is true, in that the implementation
of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
necessarily indicate that the server application supports early data,
when the default value is nonzero.  In this case a well-intentioned
client would send early data along with its resumption attempt, which
would then be ignored by the server application, a waste of network
bandwidth.

Since, in order to successfully use TLS 1.3 early data, the application
must introduce calls to SSL_read_early_data(), it is not much additional
burden to require that the application also calls
SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
so closes this scenario where early data packets would be sent on
the wire but ignored.

Update SSL_read_early_data.pod accordingly, and make s_server and
our test programs into applications that are compliant with the new
requirements on applications that use early data.

Fixes #4725
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5483)
      c39e4048
    • K
      Tell the ciphers which DRBG to use for generating random bytes. · d91f4568
      由 Kurt Roeckx 提交于 
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
GH: #4672
      d91f4568
  27. 26 2月, 2018 1 次提交
  29. 24 2月, 2018 1 次提交
  31. 23 2月, 2018 1 次提交
  33. 21 2月, 2018 1 次提交
  35. 19 2月, 2018 1 次提交
  37. 15 2月, 2018 1 次提交
  39. 14 2月, 2018 1 次提交