Skip to content

T
Third Party Openssl

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

通知 9
Star 18
Fork 1
T
Third Party Openssl

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

切换分支/标签
  1. 03 2月, 2018 1 次提交
  3. 02 2月, 2018 2 次提交
    • T
      Fix some minor code nits · e43e6b19
      由 Todd Short 提交于 
      Reviewed-by: NBen Kaduk <kaduk@mit.edu>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4964)
      e43e6b19
    • 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
  5. 01 2月, 2018 1 次提交
  7. 30 1月, 2018 1 次提交
    • M
      Move decisions about whether to accept reneg into the state machine · 3faa07b5
      由 Matt Caswell 提交于 
      If a server receives an unexpected ClientHello then we may or may not
accept it. Make sure all such decisions are made in the state machine
and not in the record layer. This also removes a disparity between the
TLS and the DTLS code. The TLS code was making this decision in the
record layer, while the DTLS code was making it later.

Finally it also solves a problem where a warning alert was being sent
during tls_setup_handshake() and the function was returning a failure
return code. This is problematic because it can be called from a
transition function - which we only allow fatal errors to occur in.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5190)
      3faa07b5
  9. 26 1月, 2018 1 次提交
    • B
      Add support for the TLS 1.3 signature_algorithms_cert extension · c589c34e
      由 Benjamin Kaduk 提交于 
      The new extension is like signature_algorithms, but only for the
signature *on* the certificate we will present to the peer (the
old signature_algorithms extension is still used for signatures that
we *generate*, i.e., those over TLS data structures).

We do not need to generate this extension, since we are the same
implementation as our X.509 stack and can handle the same types
of signatures, but we need to be prepared to receive it, and use the received
information when selecting what certificate to present.

There is a lot of interplay between signature_algorithms_cert and
signature_algorithms, since both affect what certificate we can
use, and thus the resulting signature algorithm used for TLS messages.
So, apply signature_algorithms_cert (if present) as a filter on what
certificates we can consider when choosing a certificate+sigalg
pair.

As part of this addition, we also remove the fallback code that let
keys of type EVP_PKEY_RSA be used to generate RSA-PSS signatures -- the
new rsa_pss_pss_* and rsa_pss_rsae_* signature schemes have pulled
the key type into what is covered by the signature algorithm, so
we should not apply this sort of compatibility workaround.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      c589c34e
  11. 25 1月, 2018 7 次提交
  13. 23 1月, 2018 1 次提交
  15. 09 1月, 2018 1 次提交
  17. 03 1月, 2018 1 次提交
    • B
      Permit the "supported_groups" extension in ServerHellos · 7bc2bddb
      由 Benjamin Kaduk 提交于 
      Although this is forbidden by all three(!) relevant specifications,
there seem to be multiple server implementations in the wild that
send it.  Since we didn't check for unexpected extensions in any
given message type until TLS 1.3 support was added, our previous
behavior was to silently accept these extensions and pass them over
to the custom extension callback (if any).  In order to avoid
regression of functionality, relax the check for "extension in
unexpected context" for this specific case, but leave the protocol
enforcment mechanism unchanged for other extensions and in other
extension contexts.

Leave a detailed comment to indicate what is going on.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4463)
      7bc2bddb
  19. 29 12月, 2017 1 次提交
  21. 26 12月, 2017 1 次提交
  23. 18 12月, 2017 1 次提交
  25. 14 12月, 2017 14 次提交
  27. 09 12月, 2017 1 次提交
  29. 08 12月, 2017 1 次提交
  31. 06 12月, 2017 2 次提交
  33. 04 12月, 2017 3 次提交