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 1 次提交
  3. 15 3月, 2018 2 次提交
  5. 14 3月, 2018 1 次提交
  7. 13 3月, 2018 1 次提交
  9. 12 3月, 2018 1 次提交
  11. 09 3月, 2018 2 次提交
  13. 13 2月, 2018 1 次提交
  15. 02 2月, 2018 1 次提交
    • T
      Add TLSv1.3 post-handshake authentication (PHA) · 9d75dce3
      由 Todd Short 提交于 
      Add SSL_verify_client_post_handshake() for servers to initiate PHA

Add SSL_force_post_handshake_auth() for clients that don't have certificates
initially configured, but use a certificate callback.

Update SSL_CTX_set_verify()/SSL_set_verify() mode:

* Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
the initial handshake.

* Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
of when the certificate authentication takes place; either initial handshake,
re-negotiation, or post-handshake authentication.

Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options

Add support to s_client:
* Enabled automatically when cert is configured
* Can be forced enabled via -force_pha

Add support to s_server:
* Use 'c' to invoke PHA in s_server
* Remove some dead code

Update documentation

Update unit tests:
* Illegal use of PHA extension
* TLSv1.3 certificate tests

DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
implemented, it's PHA support state machine may need to be different.
Add a TODO and a #error

Update handshake context to deal with PHA.

The handshake context for TLSv1.3 post-handshake auth is up through the
ClientFinish message, plus the CertificateRequest message. Subsequent
Certificate, CertificateVerify, and Finish messages are based on this
handshake context (not the Certificate message per se, but it's included
after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
Request messages are not included in post-handshake authentication.

After the ClientFinished message is processed, save off the digest state
for future post-handshake authentication. When post-handshake auth occurs,
copy over the saved handshake context into the "main" handshake digest.
This effectively discards the any KeyUpdate or NewSessionTicket messages
and any prior post-handshake authentication.

This, of course, assumes that the ID-22 did not mean to include any
previous post-handshake authentication into the new handshake transcript.
This is implied by section 4.4.1 that lists messages only up to the
first ClientFinished.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
      9d75dce3
  17. 26 1月, 2018 1 次提交
    • B
      Add support for the TLS 1.3 signature_algorithms_cert extension · c589c34e
      由 Benjamin Kaduk 提交于 
      The new extension is like signature_algorithms, but only for the
signature *on* the certificate we will present to the peer (the
old signature_algorithms extension is still used for signatures that
we *generate*, i.e., those over TLS data structures).

We do not need to generate this extension, since we are the same
implementation as our X.509 stack and can handle the same types
of signatures, but we need to be prepared to receive it, and use the received
information when selecting what certificate to present.

There is a lot of interplay between signature_algorithms_cert and
signature_algorithms, since both affect what certificate we can
use, and thus the resulting signature algorithm used for TLS messages.
So, apply signature_algorithms_cert (if present) as a filter on what
certificates we can consider when choosing a certificate+sigalg
pair.

As part of this addition, we also remove the fallback code that let
keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the
new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled
the key type into what is covered by the signature algorithm, so
we should not apply this sort of compatibility workaround.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      c589c34e
  19. 25 1月, 2018 5 次提交
  21. 18 12月, 2017 1 次提交
  23. 14 12月, 2017 2 次提交
  25. 06 12月, 2017 1 次提交
  27. 04 12月, 2017 4 次提交
  29. 06 11月, 2017 1 次提交
  31. 06 10月, 2017 2 次提交
  33. 26 9月, 2017 3 次提交
  35. 23 9月, 2017 1 次提交
  37. 31 8月, 2017 2 次提交
  39. 11 8月, 2017 1 次提交
  41. 10 8月, 2017 1 次提交
    • B
      Don't modify resumed session objects · e3743355
      由 Benjamin Kaduk 提交于 
      If s->hit is set, s->session corresponds to a session created on
a previous connection, and is a data structure that is potentially
shared across other SSL objects.  As such, there are thread-safety
issues with modifying the structure without taking its lock (and
of course all corresponding read accesses would also need to take
the lock as well), which have been observed to cause double-frees.

Regardless of thread-safety, the resumed session object is intended
to reflect parameters of the connection that created the session,
and modifying it to reflect the parameters from the current connection
is confusing.  So, modifications to the session object during
ClientHello processing should only be performed on new connections,
i.e., those where s->hit is not set.

The code mostly got this right, providing such checks when processing
SNI and EC point formats, but the supported groups (formerly
supported curves) extension was missing it, which is fixed by this commit.

However, TLS 1.3 makes the suppported_groups extension mandatory
(when using (EC)DHE, which is the normal case), checking for the group
list in the key_share extension processing.  But, TLS 1.3 only [0] supports
session tickets for session resumption, so the session object in question
is the output of d2i_SSL_SESSION(), and will not be shared across SSL
objects.  Thus, it is safe to modify s->session for TLS 1.3 connections.

[0] A psk_find_session callback can also be used, but the restriction that
each callback execution must produce a distinct SSL_SESSION structure
can be documented when the psk_find_session callback documentation is
completed.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4123)
      e3743355
  43. 18 7月, 2017 1 次提交
  45. 07 7月, 2017 1 次提交
  47. 21 6月, 2017 2 次提交
  49. 16 6月, 2017 1 次提交