Skip to content

T
Third Party Openssl

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

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 20 7月, 2023 1 次提交
    • M
      Fix DH_check() excessive time with over sized modulus · 9a81b024
      由 Matt Caswell 提交于 
      The DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus
value even if it is excessively large.

There is already a maximum DH modulus size (10,000 bits) over which
OpenSSL will not generate or derive keys. DH_check() will however still
perform various tests for validity on such a large modulus. We introduce a
new maximum (32,768) over which DH_check() will just fail.

An application that calls DH_check() and supplies a key or parameters
obtained from an untrusted source could be vulnerable to a Denial of
Service attack.

The function DH_check() is itself called by a number of other OpenSSL
functions. An application calling any of those other functions may
similarly be affected. The other functions affected by this are
DH_check_ex() and EVP_PKEY_param_check().

CVE-2023-3446
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21451)

(cherry picked from commit 9e0094e2aa1b3428a12d5095132f133c078d3c3d)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
      9a81b024
  3. 26 4月, 2023 3 次提交
  5. 12 4月, 2023 2 次提交
  7. 10 2月, 2023 2 次提交
  9. 01 7月, 2022 1 次提交
  11. 25 6月, 2022 1 次提交
  13. 02 9月, 2021 1 次提交
  15. 10 8月, 2021 1 次提交
  17. 11 3月, 2021 1 次提交
  19. 31 5月, 2020 1 次提交
  21. 20 5月, 2020 1 次提交
  23. 31 3月, 2020 2 次提交
  25. 25 3月, 2020 1 次提交
  27. 17 3月, 2020 3 次提交
  29. 14 3月, 2020 1 次提交
    • 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
  31. 27 2月, 2020 2 次提交
  33. 21 2月, 2020 1 次提交
  35. 15 2月, 2020 1 次提交
  37. 07 2月, 2020 1 次提交
  39. 06 2月, 2020 1 次提交
  41. 02 1月, 2020 1 次提交
  43. 16 12月, 2019 1 次提交
  45. 15 12月, 2019 1 次提交
  47. 17 11月, 2019 1 次提交
  49. 08 11月, 2019 1 次提交
  51. 15 10月, 2019 2 次提交
  53. 03 10月, 2019 1 次提交
  55. 28 9月, 2019 3 次提交
    • D
      Fix header file include guard names · fbbfd128
      由 Dr. Matthias St. Pierre 提交于 
      Make the include guards consistent by renaming them systematically according
to the naming conventions below

The public header files (in the 'include/openssl' directory) are not changed
in 1.1.1, because it is a stable release.

For the private header files files, the guard names try to match the path
specified in the include directives, with all letters converted to upper case
and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
      fbbfd128
    • D
      Reorganize local header files · b5acbf91
      由 Dr. Matthias St. Pierre 提交于 
      Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like

  '*_lcl.h', '*_local.h', or '*_int.h'

This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
      b5acbf91
    • D
      Reorganize private crypto header files · 0c994d54
      由 Dr. Matthias St. Pierre 提交于 
      Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:

While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.

To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:

  #include "internal/file.h"      # located in 'include/internal'
  #include "internal/file_int.h"  # located in 'crypto/include/internal'

This commit moves the private crypto headers from

  'crypto/include/internal'  to  'include/crypto'

As a result, the include directives become unambiguous

  #include "internal/file.h"       # located in 'include/internal'
  #include "crypto/file.h"         # located in 'include/crypto'

hence the superfluous '_int.h' suffixes can be stripped.

The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
      0c994d54
  57. 15 9月, 2019 1 次提交