Skip to content

T
Third Party Openssl

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

通知 9
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 04 9月, 2018 7 次提交
  3. 03 9月, 2018 7 次提交
  5. 01 9月, 2018 3 次提交
  7. 31 8月, 2018 1 次提交
  9. 30 8月, 2018 2 次提交
  11. 29 8月, 2018 1 次提交
  13. 26 8月, 2018 2 次提交
  15. 25 8月, 2018 1 次提交
  17. 24 8月, 2018 7 次提交
  19. 23 8月, 2018 5 次提交
  21. 22 8月, 2018 4 次提交
    • M
      Ignore the digest in req app if using EdDSA · f112dc82
      由 Matt Caswell 提交于 
      This follows on from the previous commit, and makes the same change to
ignore the digest if we are using EdDSA.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6901)
      f112dc82
    • M
      Improve the usability of the ca app using EdDSA · aabbc24e
      由 Matt Caswell 提交于 
      Previously you had to supply "null" as the digest to use EdDSA. This changes
things so that any digest is ignored.
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6901)
      aabbc24e
    • M
      Fix BoringSSL external test failures · 2fe3e2b6
      由 Matt Caswell 提交于 
      We recently turned on the TLSv1.3 downgrade sentinels by default.
Unfortunately we are using a very old version of the BoringSSL test
runner which uses an old draft implementation of TLSv1.3 that also
uses the downgrade sentinels by default. The two implementations do
not play well together and were causing spurious test failures. Until
such time as we update the BoringSSL test runner we disable the failing
tests:

SendFallbackSCSV

In this test the client is OpenSSL and the server is the boring test runner.
The client and server fail to negotiate TLSv1.3 because the test runner is
using an old draft TLSv1.3 version. The server does however add the
TLSv1.3->TLSv1.2 downgrade sentinel in the ServerHello random. Since we
recently turned on checking of the downgrade sentinels on the client side
this causes the connection to fail.

VersionNegotiationExtension-TLS11

In this test the test runner is the client and OpenSSL is the server. The
test modifies the supported_versions extension sent by the client to only
include TLSv1.1 (and some other spurious versions), even though the client
does actually support TLSv1.2. The server successfully selects TLSv1.1, but
adds the TLSv1.3->TLSv1.1 downgrade sentinel. This behaviour was recently
switched on by default. The test runner then checks the downgrade sentinel
and aborts the connection because it knows that it really supports TLSv1.2.

VersionNegotiationExtension-TLS1
VersionNegotiationExtension-SSL3

The same as VersionNegotiationExtension-TLS11 but for TLSv1 and SSLv3.

ConflictingVersionNegotiation

In this test the client is the test runner, and OpenSSL is the server. The
client offers TLSv1.2 in ClientHello.version, but also adds a
supported_versions extension that only offers TLSv1.1. The
supported_versions extension takes precedence and the server (correctly)
selects TLSv1.1. However it also adds the TLSv1.3->TLSv1.1 downgrade
sentinel. On the client side it knows it actually offered TLSv1.2 and so the
downgrade sentinel check fails.

[extended tests]
Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7013)
      2fe3e2b6
    • M
      Don't detect a downgrade where the server has a protocol version hole · 5627f9f2
      由 Matt Caswell 提交于 
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7013)
      5627f9f2