Skip to content

T
Third Party Openssl

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

通知 8
Star 18
Fork 1
T
Third Party Openssl

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

切换分支/标签
  1. 10 3月, 2018 2 次提交
    • B
      Reuse extension_is_relevant() in should_add_extension() · ee36b963
      由 Benjamin Kaduk 提交于 
      At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtensions,
etc., and sometimes only for a specific protocol or protocol range;
we want to enforce that we only parse or generate extensions in the
context(s) for which they are defined.  There is some subtlety here,
in that the protocol version in use is not known when generating the
ClientHello (but it is known when the ClientHello extensions are
being parsed!), so the SSL_IS_TLS13() macro must be used with caution.
Nonetheless, by making assertions about whether we are acting in a
server role and whether the current context is (not) a ClientHello,
we can consolidate almost all of the logic for determining whether
an extension is permitted in a given protocol message, whether we
are generating or parsing that message.

The only logic that remains separate relates to generating the ClientHello,
as it depends on an external factor (the maximum permitted TLS version) that
is not defined in the parsing context.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2945)
      ee36b963
    • T
      Add SSL/SSL_CTX_use_cert_and_key() · 37933acb
      由 Todd Short 提交于 
      Add functions that will do the work of assigning certificate, privatekey
and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the
publickey. This will permit the keys to pass validation for both ECDSA
and RSA. If a private key has already been set for the certificate, it
is discarded. A real private key can be set later.

This is an all-or-nothing setting of these parameters. Unlike the
SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions,
the existing cert or privatekey is not modified (i.e. parameters copied).
This permits the existing cert/privatekey to be replaced.

It replaces the sequence of:
* SSL_use_certificate()
* SSL_use_privatekey()
* SSL_set1_chain()
And may actually be faster, as multiple checks are consolidated.

The private key can be NULL, if so an ENGINE module needs to contain the
actual private key that is to be used.

Note that ECDH (using the certificate's ECDSA key) ciphers do not work
without the private key being present, based on how the private key is
used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead.
Reviewed-by: NTim Hudson <tjh@openssl.org>
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/1130)
      37933acb
  3. 09 3月, 2018 3 次提交
  5. 08 3月, 2018 1 次提交
  7. 05 3月, 2018 3 次提交
  9. 01 3月, 2018 2 次提交
    • 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
    • K
      Tell the ciphers which DRBG to use for generating random bytes. · d91f4568
      由 Kurt Roeckx 提交于 
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
GH: #4672
      d91f4568
  11. 26 2月, 2018 1 次提交
  13. 24 2月, 2018 1 次提交
  15. 23 2月, 2018 1 次提交
  17. 21 2月, 2018 1 次提交
  19. 19 2月, 2018 1 次提交
  21. 15 2月, 2018 1 次提交
  23. 14 2月, 2018 2 次提交
    • M
      Ignore an s_client psk in TLSv1.3 if not TLSv1.3 suitable · 6e99ae58
      由 Matt Caswell 提交于 
      The s_client psk_use_session_cb callback has a comment stating that we
should ignore a key that isn't suitable for TLSv1.3. However we were
actually causing the connection to fail. Changing the return value fixes
the issue.

Also related to this is that the early_data extension was not marked as
TLSv1.3 only which it should be.

Fixes #5202
Reviewed-by: NBen Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5205)
      6e99ae58
    • D
      DRBG: make the derivation function the default for ctr_drbg · 8164d91d
      由 Dr. Matthias St. Pierre 提交于 
      The NIST standard presents two alternative ways for seeding the
CTR DRBG, depending on whether a derivation function is used or not.
In Section 10.2.1 of NIST SP800-90Ar1 the following is assessed:

  The use of the derivation function is optional if either an
  approved RBG or an entropy source provides full entropy output
  when entropy input is requested by the DRBG mechanism.
  Otherwise, the derivation function shall be used.

Since the OpenSSL DRBG supports being reseeded from low entropy random
sources (using RAND_POOL), the use of a derivation function is mandatory.
For that reason we change the default and replace the opt-in flag
RAND_DRBG_FLAG_CTR_USE_DF with an opt-out flag RAND_DRBG_FLAG_CTR_NO_DF.
This change simplifies the RAND_DRBG_new() calls.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5294)
      8164d91d
  25. 13 2月, 2018 1 次提交
  27. 12 2月, 2018 2 次提交
  29. 10 2月, 2018 1 次提交
  31. 09 2月, 2018 1 次提交
    • M
      Don't calculate the Finished MAC twice · 5d671101
      由 Matt Caswell 提交于 
      In <= TLSv1.2 a Finished message always comes immediately after a CCS
except in the case of NPN where there is an additional message between
the CCS and Finished. Historically we always calculated the Finished MAC
when we processed the CCS. However to deal with NPN we also calculated it
when we receive the Finished message. Really this should only have been
done if we hand negotiated NPN.

This simplifies the code to only calculate the MAC when we receive the
Finished. In 1.1.1 we need to do it this way anyway because there is no
CCS (except in middlebox compat mode) in TLSv1.3.

Coincidentally, this commit also fixes the fact that no-nextprotoneg does
not currently work in master.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5285)
      5d671101
  33. 03 2月, 2018 3 次提交
  35. 02 2月, 2018 3 次提交
    • 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
      Free pha_dgst in SSL_clear() · 88834998
      由 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)
      88834998
    • 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
  37. 01 2月, 2018 1 次提交
  39. 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
  41. 29 1月, 2018 1 次提交
  43. 26 1月, 2018 5 次提交
    • B
      Fix ssl-trace with TLS 1.3 draft-23 PSS sigalgs · 36c91d13
      由 Benjamin Kaduk 提交于 
      The latest TLS 1.3 draft split the RSA-PSS signature schemes into
two versions that indicate the OID of the RSA key being used.
This forced us to rename the preprocessor defines for the sigalg
values, and the ssl-trace code was not adopted to match, since
it was not enabled int the default build.

Belatedly update the ssl_sigalg_tbl in the trace code to match.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5174)
      36c91d13
    • B
      Fix uninitialized read in sigalg parsing code · c1acef92
      由 Benjamin Kaduk 提交于 
      The check for a duplicate value was reading one entry past
where it was supposed to, getting an uninitialized value.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5172)
      c1acef92
    • 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
    • B
      Propagate TLS 1.3 sigalgs through tls1_set_sigalgs() · fd5e1a8c
      由 Benjamin Kaduk 提交于 
      Our historical SSL{,_CTX}_set_sigalgs() APIs take an array of
NID pairs (hash and signature), and our parser for manually
specifying unified sigalgs (that do not necessarily correspond
to an actual signature+hash pair) was transiting via (the implementation
of) this historical API.  The TLS 1.3 draft-23 has introduced
signature schemes that have identical signature type and hash type,
differing only in the (RSA) public key OID, which prevents
the rsa_pss_pss_* schemes from being properly identified and
sent on the wire.

To fix the issue, parse sigalg strings directly into SIGALG_LOOKUP
objects, and pass around an array of uint16 wire protocol values
instead of NID pairs.  The old interface is retained for API
compatibility but will become less and less useful with time.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      fd5e1a8c
    • B
      Add TLS 1.3 draft-23 PSS signature algorithms · f55e99f7
      由 Benjamin Kaduk 提交于 
      We now have a split in the signature algorithms codepoint space for
whether the certificate's key is for rsaEncryption or a PSS-specific
key, which should let us get rid of some special-casing that we
previously needed to try to coax rsaEncryption keys into performing PSS.
(This will be done in a subsequent commit.)

Send the new PSS-with-PSS-specific key first in our list, so that
we prefer the new technology to the old one.

We need to update the expected certificate type in one test,
since the "RSA-PSS+SHA256" form now corresponds to a public key
of type rsaEncryption, so we should expect the server certificate
type to be just "RSA".  If we want to get a server certificate
type of "RSA-PSS", we need to use a new signature algorithm
that cannot be represented as signature+hash, so add a test for that
as well.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      f55e99f7
  45. 25 1月, 2018 2 次提交