Skip to content

T
Third Party Openssl

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

通知 9
Star 18
Fork 1
T
Third Party Openssl

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 17 5月, 2018 1 次提交
  3. 15 5月, 2018 1 次提交
  5. 11 5月, 2018 6 次提交
  7. 10 5月, 2018 1 次提交
  9. 03 5月, 2018 1 次提交
  11. 20 4月, 2018 2 次提交
  13. 19 4月, 2018 1 次提交
  15. 18 4月, 2018 5 次提交
  17. 17 4月, 2018 1 次提交
  19. 13 4月, 2018 1 次提交
  21. 04 4月, 2018 1 次提交
  23. 20 3月, 2018 1 次提交
  25. 19 3月, 2018 3 次提交
  27. 15 3月, 2018 1 次提交
  29. 14 3月, 2018 1 次提交
    • M
      Split configuration of TLSv1.3 ciphers from older ciphers · f865b081
      由 Matt Caswell 提交于 
      With the current mechanism, old cipher strings that used to work in 1.1.0,
may inadvertently disable all TLSv1.3 ciphersuites causing connections to
fail. This is confusing for users.

In reality TLSv1.3 are quite different to older ciphers. They are much
simpler and there are only a small number of them so, arguably, they don't
need the same level of control that the older ciphers have.

This change splits the configuration of TLSv1.3 ciphers from older ones.
By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
them through your existing config.

Fixes #5359
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5392)
      f865b081
  31. 13 3月, 2018 1 次提交
  33. 09 3月, 2018 2 次提交
  35. 01 3月, 2018 1 次提交
    • B
      Do not set a nonzero default max_early_data · c39e4048
      由 Benjamin Kaduk 提交于 
      When early data support was first added, this seemed like a good
idea, as it would allow applications to just add SSL_read_early_data()
calls as needed and have things "Just Work".  However, for applications
that do not use TLS 1.3 early data, there is a negative side effect.
Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
derived from it) means that when generating a session ticket,
tls_construct_stoc_early_data() will indicate to the client that
the server supports early data.  This is true, in that the implementation
of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
necessarily indicate that the server application supports early data,
when the default value is nonzero.  In this case a well-intentioned
client would send early data along with its resumption attempt, which
would then be ignored by the server application, a waste of network
bandwidth.

Since, in order to successfully use TLS 1.3 early data, the application
must introduce calls to SSL_read_early_data(), it is not much additional
burden to require that the application also calls
SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
so closes this scenario where early data packets would be sent on
the wire but ignored.

Update SSL_read_early_data.pod accordingly, and make s_server and
our test programs into applications that are compliant with the new
requirements on applications that use early data.

Fixes #4725
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5483)
      c39e4048
  37. 27 2月, 2018 1 次提交
  39. 26 2月, 2018 1 次提交
  41. 13 2月, 2018 1 次提交
  43. 10 2月, 2018 1 次提交
  45. 09 2月, 2018 1 次提交
  47. 02 2月, 2018 1 次提交
    • T
      Add TLSv1.3 post-handshake authentication (PHA) · 9d75dce3
      由 Todd Short 提交于 
      Add SSL_verify_client_post_handshake() for servers to initiate PHA

Add SSL_force_post_handshake_auth() for clients that don't have certificates
initially configured, but use a certificate callback.

Update SSL_CTX_set_verify()/SSL_set_verify() mode:

* Add SSL_VERIFY_POST_HANDSHAKE to postpone client authentication until after
the initial handshake.

* Update SSL_VERIFY_CLIENT_ONCE now only sends out one CertRequest regardless
of when the certificate authentication takes place; either initial handshake,
re-negotiation, or post-handshake authentication.

Add 'RequestPostHandshake' and 'RequirePostHandshake' SSL_CONF options that
add the SSL_VERIFY_POST_HANDSHAKE to the 'Request' and 'Require' options

Add support to s_client:
* Enabled automatically when cert is configured
* Can be forced enabled via -force_pha

Add support to s_server:
* Use 'c' to invoke PHA in s_server
* Remove some dead code

Update documentation

Update unit tests:
* Illegal use of PHA extension
* TLSv1.3 certificate tests

DTLS and TLS behave ever-so-slightly differently. So, when DTLS1.3 is
implemented, it's PHA support state machine may need to be different.
Add a TODO and a #error

Update handshake context to deal with PHA.

The handshake context for TLSv1.3 post-handshake auth is up through the
ClientFinish message, plus the CertificateRequest message. Subsequent
Certificate, CertificateVerify, and Finish messages are based on this
handshake context (not the Certificate message per se, but it's included
after the hash). KeyUpdate, NewSessionTicket, and prior Certificate
Request messages are not included in post-handshake authentication.

After the ClientFinished message is processed, save off the digest state
for future post-handshake authentication. When post-handshake auth occurs,
copy over the saved handshake context into the "main" handshake digest.
This effectively discards the any KeyUpdate or NewSessionTicket messages
and any prior post-handshake authentication.

This, of course, assumes that the ID-22 did not mean to include any
previous post-handshake authentication into the new handshake transcript.
This is implied by section 4.4.1 that lists messages only up to the
first ClientFinished.
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
      9d75dce3
  49. 25 1月, 2018 2 次提交
  51. 22 11月, 2017 1 次提交