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 6月, 2020 1 次提交
  5. 25 5月, 2020 1 次提交
  7. 25 3月, 2020 1 次提交
  9. 17 3月, 2020 1 次提交
  11. 14 3月, 2020 3 次提交
    • 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
    • B
      Fix whitespace nit in ssl_generate_master_secret() · a666af9f
      由 Benjamin Kaduk 提交于 
      Use a space after a comma.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)

(cherry picked from commit 1866a0d380fc361d9be2ca0509de0f2281505db5)
      a666af9f
  13. 27 2月, 2020 1 次提交
  15. 21 2月, 2020 1 次提交
  17. 19 2月, 2020 1 次提交
  19. 16 2月, 2020 1 次提交
  21. 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
  23. 25 1月, 2020 1 次提交
    • K
      Check that the default signature type is allowed · cc7c6eb8
      由 Kurt Roeckx 提交于 
      TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the
others. TLS 1.2 sends a list of supported ciphers, but allows not sending
it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory.

When we didn't receive a list from the client, we always used the
defaults without checking that they are allowed by the configuration.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
GH: #10784
(cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5)
      cc7c6eb8
  25. 21 1月, 2020 1 次提交
  27. 02 1月, 2020 1 次提交
  29. 15 12月, 2019 1 次提交
  31. 12 12月, 2019 1 次提交
  33. 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
  35. 12 11月, 2019 2 次提交
  37. 11 11月, 2019 1 次提交
  39. 08 11月, 2019 1 次提交
  41. 10 10月, 2019 1 次提交
  43. 07 10月, 2019 1 次提交
    • M
      Send bad_record_mac instead of decryption_failed · f1fd279c
      由 Matt Caswell 提交于 
      The decryption failed alert was deprecated a long time ago. It can
provide an attacker too much information to be able to distinguish between
MAC failures and decryption failures and can lead to oracle attacks.
Instead we should always use the bad_record_mac alert for these issues.
This fixes one instance that still exists. It does not represent a
security issue in this case because it is only ever sent if the record is
publicly invalid, i.e. we have detected it is invalid without using any
secret material.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10093)

(cherry picked from commit 37133290832ac2d1389926eba7325125fdacbe8d)
      f1fd279c
  45. 03 10月, 2019 2 次提交
  47. 28 9月, 2019 2 次提交
  49. 10 9月, 2019 1 次提交
  51. 06 9月, 2019 1 次提交
  53. 04 9月, 2019 2 次提交
  55. 14 8月, 2019 2 次提交
  57. 06 8月, 2019 1 次提交
    • M
      Fix SSL_MODE_RELEASE_BUFFERS functionality · f2bb79a7
      由 Matt Caswell 提交于 
      At some point in the past do_ssl3_write() used to return the number of
bytes written, or a value <= 0 on error. It now just returns a success/
error code and writes the number of bytes written to |tmpwrit|.

The SSL_MODE_RELEASE_BUFFERS code was still looking at the return code
for the number of bytes written rather than |tmpwrit|. This has the effect
that the buffers are not released when they are supposed to be.

Fixes #9490
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/9505)

(cherry picked from commit 8bbf63e48f27c5edaa03e6d87d969c9b6a207f3c)
      f2bb79a7
  59. 01 8月, 2019 1 次提交
  61. 26 7月, 2019 1 次提交