Skip to content

T
Third Party Openssl

OpenHarmony / Third Party Openssl
接近 2 年 前同步成功

通知 12
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 09 2月, 2022 1 次提交
  3. 02 9月, 2021 1 次提交
  5. 10 8月, 2021 1 次提交
  7. 11 3月, 2021 1 次提交
  9. 09 9月, 2020 1 次提交
  11. 17 3月, 2020 2 次提交
  13. 14 3月, 2020 1 次提交
    • B
      Add test that changes ciphers on CCS · 2f0dab7e
      由 Benjamin Kaduk 提交于 
      The TLS (pre-1.3) ChangeCipherState message is usually used to indicate
the switch from the unencrypted to encrypted part of the handshake.
However, it can also be used in cases where there is an existing
session (such as during resumption handshakes) or when changing from
one cipher to a different one (such as during renegotiation when the
cipher list offered by the client has changed).  This test serves
to exercise such situations, allowing us to detect whether session
objects are being modified in cases when they must remain immutable
for thread-safety purposes.
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10943)

(cherry picked from commit 3cd14e5e65011660ad8e3603cf871c8366b565fd)
      2f0dab7e
  15. 11 3月, 2020 2 次提交
  17. 27 2月, 2020 1 次提交
  19. 16 2月, 2020 2 次提交
  21. 12 2月, 2020 1 次提交
  23. 06 2月, 2020 3 次提交
  25. 31 1月, 2020 1 次提交
  27. 25 1月, 2020 2 次提交
    • 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
    • K
      Replace apps/server.pem with certificate with a sha256 signature. · 2dbcdb69
      由 Kurt Roeckx 提交于 
      It replaces apps/server.pem that used a sha1 signature with a copy of
test/certs/servercert.pem that is uses sha256.

This caused the dtlstest to start failing. It's testing connection
sbetween a dtls client and server. In particular it was checking that if
we drop a record that the handshake recovers and still completes
successfully. The test iterates a number of times. The first time
through it drops the first record. The second time it drops the second
one, and so on. In order to do this it has a hard-coded value for the
expected number of records it should see in a handshake. That's ok
because we completely control both sides of the handshake and know what
records we expect to see. Small changes in message size would be
tolerated because that is unlikely to have an impact on the number of
records. Larger changes in message size however could increase or
decrease the number of records and hence cause the test to fail.

This particular test uses a mem bio which doesn't have all the CTRLs
that the dgram BIO has. When we are using a dgram BIO we query that BIO
to determine the MTU size. The smaller the MTU the more fragmented
handshakes become. Since the mem BIO doesn't report an MTU we use a
rather small default value and get quite a lot of records in our
handshake. This has the tendency to increase the likelihood of the
number of records changing in the test if the message size changes.

It so happens that the new server certificate is smaller than the old
one. AFAICT this is probably because the DNs for the Subject and Issuer
are significantly shorter than previously. The result is that the number
of records used to transmit the Certificate message is one less than it
was before. This actually has a knock on impact for subsequent messages
and how we fragment them resulting in one less ServerKeyExchange record
too (the actual size of the ServerKeyExchange message hasn't changed,
but where in that message it gets fragmented has). In total the number
of records used in the handshake has decreased by 2 with the new
server.pem file.
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
GH: #10784
(cherry picked from commit 5fd72d96a592c3c4ef28ff11c6ef334a856b0cd1)
      2dbcdb69
  29. 21 1月, 2020 1 次提交
  31. 07 1月, 2020 1 次提交
    • M
      Don't store an HMAC key for longer than we need · 16d92fa8
      由 Matt Caswell 提交于 
      The HMAC_CTX structure stores the original key in case the ctx is reused
without changing the key.

However, HMAC_Init_ex() checks its parameters such that the only code path
where the stored key is ever used is in the case where HMAC_Init_ex is
called with a NULL key and an explicit md is provided which is the same as
the md that was provided previously. But in that case we can actually reuse
the pre-digested key that we calculated last time, so we can refactor the
code not to use the stored key at all.

With that refactor done it is no longer necessary to store the key in the
ctx at all. This means that long running ctx's will not keep the key in
memory for any longer than required. Note though that the digested key
*is* still kept in memory for the duration of the life of the ctx.

Fixes #10743
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10763)
      16d92fa8
  33. 23 12月, 2019 1 次提交
  35. 16 12月, 2019 1 次提交
  37. 06 12月, 2019 1 次提交
  39. 29 11月, 2019 1 次提交
  41. 20 11月, 2019 1 次提交
  43. 15 11月, 2019 1 次提交
  45. 14 11月, 2019 1 次提交
  47. 13 11月, 2019 1 次提交
  49. 10 11月, 2019 1 次提交
  51. 08 11月, 2019 1 次提交
  53. 02 11月, 2019 1 次提交
  55. 17 10月, 2019 1 次提交
  57. 15 10月, 2019 1 次提交
  59. 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
  61. 10 9月, 2019 2 次提交