Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
大约 1 年 前同步成功

通知 9
Star 18
Fork 1
T
Third Party Openssl

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

切换分支/标签
  1. 22 8月, 2018 2 次提交
  3. 20 8月, 2018 2 次提交
  5. 15 8月, 2018 2 次提交
  7. 14 8月, 2018 1 次提交
  9. 09 8月, 2018 1 次提交
  11. 08 8月, 2018 4 次提交
  13. 07 8月, 2018 2 次提交
  15. 06 8月, 2018 1 次提交
  17. 31 7月, 2018 1 次提交
  19. 27 7月, 2018 1 次提交
    • B
      Improve backwards compat for SSL_get_servername() · a75be9fd
      由 Benjamin Kaduk 提交于 
      Commit 1c4aa31d changed how we process
and store SNI information during the handshake, so that a hostname is
only saved in the SSL_SESSION structure if that SNI value has actually
been negotiated.  SSL_get_servername() was adjusted to match, with a new
conditional being added to handle the case when the handshake processing
is ongoing, and a different location should be consulted for the offered
SNI value.  This was done in an attempt to preserve the historical
behavior of SSL_get_servername(), a function whose behavior only mostly
matches its documentation, and whose documentation is both lacking and
does not necessarily reflect the actual desired behavior for such an
API.  Unfortunately, sweeping changes that would bring more sanity to
this space are not possible until OpenSSL 1.2.0, for ABI compatibility
reasons, so we must attempt to maintain the existing behavior to the
extent possible.

The above-mentioned commit did not take into account the behavior
of SSL_get_servername() during resumption handshakes for TLS 1.2 and
prior, where no SNI negotiation is performed.  In that case we would
not properly parse the incoming SNI and erroneously return NULL as
the servername, when instead the logical session is associated with
the SNI value cached in the SSL_SESSION.  (Note that in some cases an
SNI callback may not need to do anything in a TLS 1.2 or prior resumption
flow, but we are calling the callbacks and did not provide any guidance
that they should no-op if the connection is being resumed, so we must
handle this case in a usable fashion.)  Update our behavior accordingly to
return the session's cached value during the handshake, when resuming.
This fixes the boringssl tests.

[extended tests]
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6792)
      a75be9fd
  21. 20 7月, 2018 4 次提交
    • B
      Add TODO comment for a nonsensical public API · c5d1fb78
      由 Benjamin Kaduk 提交于 
      The API used to set what SNI value to send in the ClientHello
can also be used on server SSL objects, with undocumented and
un-useful behavior.  Unfortunately, when generic SSL_METHODs
are used, s->server is still set, prior to the start of the
handshake, so we cannot prevent this nonsensical usage at the
present time.  Leave a note to revisit this when ABI-breaking
changes are permitted.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
      c5d1fb78
    • 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
    • B
      const-ify some input SSL * arguments · 4cc968df
      由 Benjamin Kaduk 提交于 
      These tiny functions only read from the input SSL, and we are
about to use them from functions that only have a const SSL* available,
so propagate const a bit further.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6378)
      4cc968df
    • M
      Validate legacy_version · d8434cf8
      由 Matt Caswell 提交于 
      The spec says that a client MUST set legacy_version to TLSv1.2, and
requires servers to verify that it isn't SSLv3.

Fixes #6600
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6747)
      d8434cf8
  23. 19 7月, 2018 1 次提交
  25. 18 7月, 2018 1 次提交
  27. 17 7月, 2018 3 次提交
  29. 14 7月, 2018 3 次提交
  31. 06 7月, 2018 1 次提交
    • M
      Introduce the recv_max_early_data setting · 4e8548e8
      由 Matt Caswell 提交于 
      Previoulsy we just had max_early_data which controlled both the value of
max early_data that we advertise in tickets *and* the amount of early_data
that we are willing to receive from clients. This doesn't work too well in
the case where we want to reduce a previously advertised max_early_data
value. In that case clients with old, stale tickets may attempt to send us
more early data than we are willing to receive. Instead of rejecting the
early data we abort the connection if that happens.

To avoid this we introduce a new "recv_max_early_data" value. The old
max_early_data becomes the value that is advertised in tickets while
recv_max_early_data is the maximum we will tolerate from clients.

Fixes #6647
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/6655)
      4e8548e8
  33. 03 7月, 2018 2 次提交
  35. 02 7月, 2018 5 次提交
  37. 29 6月, 2018 1 次提交
  39. 27 6月, 2018 2 次提交