Skip to content

T
Third Party Openssl

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

通知 10
Star 18
Fork 1
T
Third Party Openssl
切换分支/标签
  1. 26 2月, 2020 1 次提交
  3. 21 2月, 2020 3 次提交
  5. 19 2月, 2020 1 次提交
  7. 17 2月, 2020 1 次提交
  9. 16 2月, 2020 2 次提交
  11. 15 2月, 2020 3 次提交
  13. 14 2月, 2020 1 次提交
  15. 12 2月, 2020 2 次提交
  17. 07 2月, 2020 3 次提交
  19. 06 2月, 2020 6 次提交
  21. 02 2月, 2020 1 次提交
  23. 31 1月, 2020 4 次提交
    • 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
      Provide better documentation for SSL_get_servername() · 721eb8f6
      由 Matt Caswell 提交于 
      The behaviour of SSL_get_servername() is quite complicated and depends on
numerous factors such as whether it is called on the client or the server,
whether it is called before or after the handshake, what protocol version
was negotiated, and whether a resumption was attempted or was successful.

We attempt to document the behavior more clearly.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/10018)

(cherry picked from commit 0dc7c8e8314f27ac093b2d7bc8f13d0dfd302bdb)
      721eb8f6
    • M
      Test that SSL_get_servername returns what we expect · f6f81b2d
      由 Matt Caswell 提交于 
      Test this on both the client and the server after a normal handshake,
and after a resumption handshake. We also test what happens if an
inconsistent SNI is set between the original handshake and the resumption
handshake. Finally all of this is also tested in TLSv1.2 and TLSv1.3.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/10018)

(cherry picked from commit 49ef3d0719f132629ab76d4bcb4ab0c1e016277a)
      f6f81b2d
    • 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
  25. 30 1月, 2020 1 次提交
  27. 27 1月, 2020 1 次提交
    • R
      OpenSSL::Test: bring back the relative paths · c8943eb0
      由 Richard Levitte 提交于 
      Because there was a bug in File::Spec::Unix' abs2rel when it was given
relative paths as both PATH and BASE arguments, the directories we
deal with were made to be all absolute.  Unfortunately, this meant
getting paths in our verbose test output which are difficult to use
anywhere else (such as a separate test build made for comparison), due
to the constant need to edit all the paths all the time.

We're therefore getting back the relative paths, by doing an extra
abs2rel() in __srctop_file, __srctop_dir, __bldtop_file and
__bldtop_dir, with a 'Cwd::getcwd' call as BASE argument.

Fixes #10628
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10913)

(cherry picked from commit 612539e8a678c6099131dfd0e5e4b85fa774eb1a)
      c8943eb0
  29. 25 1月, 2020 3 次提交
    • 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
    • B
      openssl-config: add example libssl system-defaults · 59f92fa2
      由 Benjamin Kaduk 提交于 
      Provide a "simple" example for affecting the systemwide default behavior
of libssl.  The large number of mandatory nested sections makes this
less simple than the main description might suggest.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10937)

(cherry picked from commit 3472082b4b6d73e0803a7c47f03e96ec0a69f77b)
      59f92fa2
  31. 21 1月, 2020 3 次提交
  33. 17 1月, 2020 2 次提交
  35. 15 1月, 2020 2 次提交