Skip to content

T
Third Party Openssl

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

通知 8
Star 18
Fork 1
T
Third Party Openssl

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 27 5月, 2021 2 次提交
  3. 17 3月, 2020 1 次提交
  5. 27 2月, 2020 1 次提交
  7. 31 1月, 2020 2 次提交
    • M
      Don't acknowledge a servername following warning alert in servername cb · a9a8863b
      由 Matt Caswell 提交于 
      If the servername cb decides to send back a warning alert then the
handshake continues, but we should not signal to the client that the
servername has been accepted.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/10018)

(cherry picked from commit cd624ccd41ac3ac779c1c7a7a1e63427ce9588dd)
      a9a8863b
    • M
      Fix SSL_get_servername() and SNI behaviour · e9cd6e76
      由 Matt Caswell 提交于 
      The SNI behaviour for TLSv1.3 and the behaviour of SSL_get_servername()
was not quite right, and not entirely consistent with the RFC.

The TLSv1.3 RFC explicitly says that SNI is negotiated on each handshake
and the server is not required to associate it with the session. This was
not quite reflected in the code so we fix that.

Additionally there were some additional checks around early_data checking
that the SNI between the original session and this session were
consistent. In fact the RFC does not require any such checks, so they are
removed.

Finally the behaviour of SSL_get_servername() was not quite right. The
behaviour was not consistent between resumption and normal handshakes,
and also not quite consistent with historical behaviour. We clarify the
behaviour in various scenarios and also attempt to make it match historical
behaviour as closely as possible.

Fixes #8822
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/10018)

(cherry picked from commit 7955c1f16e72dc944677fd1dbf4b1300e75f1c84)
      e9cd6e76
  9. 22 11月, 2019 1 次提交
    • B
      Fix a race condition in SNI handling · 328fd883
      由 Benjamin Kaduk 提交于 
      As was done for ciphers, supported groups, and EC point formats in
https://github.com/openssl/openssl/pull/9162, only write the negotiated
SNI hostname value to the session object when not resuming, even for
TLS 1.3 resumptions.  Otherwise, when using a stateful session cache
(as is done by default when 0-RTT data is enabled), we can have multiple
SSLs active using the same in-memory session object, which leads to
double-frees and similar race conditions in the SNI handler prior
to this commit.

Fortunately, since draft-ietf-tls-tls13-22, there is no requirement
that the SNI hostname be preserved across TLS 1.3 resumption, and thus
not a need to continually update the session object with the "current"
value (to be used when producing session tickets, so that the subsequent
resumption can be checked against the current value).  So we can just
relax the logic and only write to the session object for initial handshakes.
This still leaves us in a somewhat inconsistent state, since if the SNI value
does change across handshakes, the session object will continue to record
the initial handshake's value, even if that bears no relation to the
current handshake.  The current SSL_get_servername() implementation
prefers the value from the session if s->hit, but a more complete fix
for that and related issues is underway in
https://github.com/openssl/openssl/pull/10018; there is no need to wait
for the complete fix for SNI name handling in order to close the
race condition and avoid runtime crashes.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10441)

(cherry picked from commit 2a5385511051d33be8d2b20d7669d8b1862fe510)
      328fd883
  11. 12 11月, 2019 1 次提交
  13. 28 9月, 2019 1 次提交
  15. 14 8月, 2019 1 次提交
  17. 01 8月, 2019 1 次提交
  19. 18 6月, 2019 1 次提交
  21. 05 3月, 2019 1 次提交
  23. 26 2月, 2019 1 次提交
  25. 07 1月, 2019 1 次提交
  27. 06 1月, 2019 1 次提交
  29. 05 12月, 2018 1 次提交
  31. 12 11月, 2018 1 次提交
    • M
      Separate ca_names handling for client and server · b4970e8b
      由 Matt Caswell 提交于 
      SSL(_CTX)?_set_client_CA_list() was a server side only function in 1.1.0.
If it was called on the client side then it was ignored. In 1.1.1 it now
makes sense to have a CA list defined for both client and server (the
client now sends it the the TLSv1.3 certificate_authorities extension).
Unfortunately some applications were using the same SSL_CTX for both
clients and servers and this resulted in some client ClientHellos being
excessively large due to the number of certificate authorities being sent.

This commit seperates out the CA list updated by
SSL(_CTX)?_set_client_CA_list() and the more generic
SSL(_CTX)?_set0_CA_list(). This means that SSL(_CTX)?_set_client_CA_list()
still has no effect on the client side. If both CA lists are set then
SSL(_CTX)?_set_client_CA_list() takes priority.

Fixes #7411
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7503)

(cherry picked from commit 98732979001dbb59320803713c4c91ba40234250)
      b4970e8b
  33. 04 11月, 2018 1 次提交
    • B
      Restore sensible "sess_accept" counter tracking · 33a37a61
      由 Benjamin Kaduk 提交于 
      Commit 9ef9088c switched the SSL/SSL_CTX
statistics counters to using Thread-Sanitizer-friendly primitives.
However, it erroneously converted an addition of -1
(for s->session_ctx->stats.sess_accept) to an addition of +1, since that
is the only counter API provided by the internal tsan_assist.h header
until the previous commit.  This means that for each accepted (initial)
connection, the session_ctx's counter would get doubly incremented, and the
(switched) ctx's counter would also get incremented.

Restore the counter decrement so that each accepted connection increments
exactly one counter exactly once (in net effect).
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/7464)

(cherry picked from commit 2aaa0b146b967397a6e61fa8df969e7847f82086)
      33a37a61
  35. 29 10月, 2018 1 次提交
  37. 08 9月, 2018 1 次提交
  39. 07 9月, 2018 1 次提交
    • B
      Restore historical SSL_get_servername() behavior · 2c0267fd
      由 Ben Kaduk 提交于 
      Commit 1c4aa31d modified the state machine
to clean up stale ext.hostname values from SSL objects in the case when
SNI was not negotiated for the current handshake.  This is natural from
the TLS perspective, since this information is an extension that the client
offered but we ignored, and since we ignored it we do not need to keep it
around for anything else.

However, as documented in https://github.com/openssl/openssl/issues/7014 ,
there appear to be some deployed code that relies on retrieving such an
ignored SNI value from the client, after the handshake has completed.
Because the 1.1.1 release is on a stable branch and should preserve the
published ABI, restore the historical behavior by retaining the ext.hostname
value sent by the client, in the SSL structure, for subsequent retrieval.

[extended tests]
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7115)
      2c0267fd
  41. 22 8月, 2018 1 次提交
  43. 07 8月, 2018 1 次提交
  45. 20 7月, 2018 1 次提交
    • B
      Normalize SNI hostname handling for SSL and SSL_SESSION · 1c4aa31d
      由 Benjamin Kaduk 提交于 
      In particular, adhere to the rule that we must not modify any
property of an SSL_SESSION object once it is (or might be) in
a session cache.  Such modifications are thread-unsafe and have
been observed to cause crashes at runtime.

To effect this change, standardize on the property that
SSL_SESSION->ext.hostname is set only when that SNI value
has been negotiated by both parties for use with that session.
For session resumption this is trivially the case, so only new
handshakes are affected.

On the client, the new semantics are that the SSL->ext.hostname is
for storing the value configured by the caller, and this value is
used when constructing the ClientHello.  On the server, SSL->ext.hostname
is used to hold the value received from the client.  Only if the
SNI negotiation is successful will the hostname be stored into the
session object; the server can do this after it sends the ServerHello,
and the client after it has received and processed the ServerHello.

This obviates the need to remove the hostname from the session object
in case of failed negotiation (a change that was introduced in commit
9fb6cb81 in order to allow TLS 1.3
early data when SNI was present in the ClientHello but not the session
being resumed), which was modifying cached sessions in certain cases.
(In TLS 1.3 we always produce a new SSL_SESSION object for new
connections, even in the case of resumption, so no TLS 1.3 handshakes
were affected.)
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
      1c4aa31d
  47. 02 7月, 2018 1 次提交
  49. 11 6月, 2018 1 次提交
  51. 07 6月, 2018 1 次提交
  53. 31 5月, 2018 1 次提交
  55. 15 3月, 2018 2 次提交
  57. 14 3月, 2018 1 次提交
  59. 10 3月, 2018 1 次提交
    • 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
  61. 09 3月, 2018 1 次提交
  63. 05 3月, 2018 1 次提交
    • M
      Fix status_request and SCT extensions · 5de683d2
      由 Matt Caswell 提交于 
      They are valid for use in a CertificateRequest message, but we did not
allow it. If a server sent such a message using either of those two
extensions then the handshake would abort.

This corrects that error, but does not add support for actually processing
the extensions. They are simply ignored, and a TODO is inserted to add
support at a later time.

This was found during interoperability testing with btls:
https://gitlab.com/ilari_l/btls

Prompted by these errors I reviewed the complete list of extensions and
compared them with the latest table in draft-24 to confirm there were no
other errors of a similar type. I did not find any.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5490)
      5de683d2
  65. 15 2月, 2018 1 次提交
  67. 14 2月, 2018 1 次提交
  69. 02 2月, 2018 2 次提交
    • T
      Fix some minor code nits · e43e6b19
      由 Todd Short 提交于 
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
      e43e6b19
    • 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
  71. 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