Skip to content

T
Third Party Openssl

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

通知 8
Star 18
Fork 1
T
Third Party Openssl

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

切换分支/标签
  1. 27 5月, 2021 2 次提交
  3. 17 3月, 2020 1 次提交
  5. 14 3月, 2020 2 次提交
    • B
      Code to thread-safety in ChangeCipherState · 44bad9cb
      由 Benjamin Kaduk 提交于 
      The server-side ChangeCipherState processing stores the new cipher
in the SSL_SESSION object, so that the new state can be used if
this session gets resumed.  However, writing to the session is only
thread-safe for initial handshakes, as at other times the session
object may be in a shared cache and in use by another thread at the
same time.  Reflect this invariant in the code by only writing to
s->session->cipher when it is currently NULL (we do not cache sessions
with no cipher).  The code prior to this change would never actually
change the (non-NULL) cipher value in a session object, since our
server enforces that (pre-TLS-1.3) resumptions use the exact same
cipher as the initial connection, and non-abbreviated renegotiations
have produced a new session object before we get to this point.
Regardless, include logic to detect such a condition and abort the
handshake if it occurs, to avoid any risk of inadvertently using
the wrong cipher on a connection.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)

(cherry picked from commit 2e3ec2e1578977fca830a47fd7f521e290540e6d)
      44bad9cb
    • B
      Don't write to the session when computing TLS 1.3 keys · 910c8ffa
      由 Benjamin Kaduk 提交于 
      TLS 1.3 maintains a separate keys chedule in the SSL object, but
was writing to the 'master_key_length' field in the SSL_SESSION
when generating the per-SSL master_secret.  (The generate_master_secret
SSL3_ENC_METHOD function needs an output variable for the master secret
length, but the TLS 1.3 implementation just uses the output size of
the handshake hash function to get the lengths, so the only natural-looking
thing to use as the output length was the field in the session.
This would potentially involve writing to a SSL_SESSION object that was
in the cache (i.e., resumed) and shared with other threads, though.

The thread-safety impact should be minimal, since TLS 1.3 requires the
hash from the original handshake to be associated with the resumption
PSK and used for the subsequent connection.  This means that (in the
resumption case) the value being written would be the same value that was
previously there, so the only risk would be on architectures that can
produce torn writes/reads for aligned size_t values.

Since the value is essentially ignored anyway, just provide the
address of a local dummy variable to generate_master_secret() instead.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)

(cherry picked from commit d74014c4b8740f28a54b562f799ad1e754b517b9)
      910c8ffa
  7. 27 2月, 2020 1 次提交
  9. 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
  11. 15 12月, 2019 1 次提交
  13. 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
  15. 12 11月, 2019 1 次提交
  17. 08 11月, 2019 1 次提交
  19. 10 10月, 2019 1 次提交
  21. 03 10月, 2019 1 次提交
  23. 28 9月, 2019 1 次提交
  25. 06 9月, 2019 1 次提交
  27. 14 8月, 2019 1 次提交
  29. 01 8月, 2019 1 次提交
  31. 26 7月, 2019 1 次提交
  33. 27 6月, 2019 1 次提交
  35. 18 6月, 2019 3 次提交
  37. 03 6月, 2019 1 次提交
    • M
      Defer sending a KeyUpdate until after pending writes are complete · 6c2f347c
      由 Matt Caswell 提交于 
      If we receive a KeyUpdate message (update requested) from the peer while
we are in the middle of a write, we should defer sending the responding
KeyUpdate message until after the current write is complete. We do this
by waiting to send the KeyUpdate until the next time we write and there is
no pending write data.

This does imply a subtle change in behaviour. Firstly the responding
KeyUpdate message won't be sent straight away as it is now. Secondly if
the peer sends multiple KeyUpdates without us doing any writing then we
will only send one response, as opposed to previously where we sent a
response for each KeyUpdate received.

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

(cherry picked from commit feb9e31c40c49de6384dd0413685e9b5a15adc99)
      6c2f347c
  39. 30 5月, 2019 1 次提交
  41. 28 5月, 2019 2 次提交
  43. 27 5月, 2019 1 次提交
  45. 28 3月, 2019 1 次提交
  47. 05 3月, 2019 1 次提交
  49. 26 2月, 2019 1 次提交
  51. 23 2月, 2019 1 次提交
  53. 15 2月, 2019 1 次提交
    • M
      Don't signal SSL_CB_HANDSHAKE_START for TLSv1.3 post-handshake messages · 37857e9b
      由 Matt Caswell 提交于 
      The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message
exchange in TLSv1.3. Unfortunately experience has shown that this confuses
some applications who mistake it for a TLSv1.2 renegotiation. This means
that KeyUpdate messages are not handled properly.

This commit removes the use of SSL_CB_HANDSHAKE_START and
SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake
message exchange. Individual post-handshake messages are still signalled in
the normal way.

This is a potentially breaking change if there are any applications already
written that expect to see these TLSv1.3 events. However, without it,
KeyUpdate is not currently usable for many applications.

Fixes #8069
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8096)

(cherry picked from commit 4af5836b55442f31795eff6c8c81ea7a1b8cf94b)
      37857e9b
  55. 01 2月, 2019 1 次提交
  57. 24 1月, 2019 1 次提交
  59. 09 1月, 2019 1 次提交
    • M
      Don't artificially limit the size of the ClientHello · bbcfd60e
      由 Matt Caswell 提交于 
      We were setting a limit of SSL3_RT_MAX_PLAIN_LENGTH on the size of the
ClientHello. AFAIK there is nothing in the standards that requires this
limit.

The limit goes all the way back to when support for extensions was first
added for TLSv1.0. It got converted into a WPACKET max size in 1.1.1. Most
likely it was originally added to avoid the complexity of having to grow
the init_buf in the middle of adding extensions. With WPACKET this is
irrelevant since it will grow automatically.

This issue came up when an attempt was made to send a very large
certificate_authorities extension in the ClientHello.

We should just remove the limit.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7424)

(cherry picked from commit 7835e97b6ff5cd94a10c5aeac439f4aa145a77b2)
      bbcfd60e
  61. 07 1月, 2019 1 次提交
  63. 06 1月, 2019 1 次提交
  65. 05 12月, 2018 1 次提交
  67. 27 11月, 2018 1 次提交