Skip to content

T
Third Party Openssl

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

通知 9
Star 18
Fork 1
T
Third Party Openssl

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

切换分支/标签
  1. 05 3月, 2018 1 次提交
  3. 21 2月, 2018 1 次提交
  5. 12 2月, 2018 1 次提交
  7. 26 1月, 2018 4 次提交
    • 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
  9. 09 1月, 2018 3 次提交
  11. 04 12月, 2017 1 次提交
  13. 13 11月, 2017 1 次提交
  15. 06 11月, 2017 1 次提交
  17. 21 10月, 2017 1 次提交
    • K
      Various clean-ups · b2555168
      由 KaoruToda 提交于 
      Add a check for NULL return in t1_lib.c.
    Since return type of ssl_cert_lookup_by_idx is pointer and unify coding
    style, I changed from zero to NULL in ssl_cert.c.

Remove unnecessary space for ++.

Fix incorrect condition
    Expression is always false because 'else if' condition matches previous
    condition.  SInce the next line of 'else if' condition has substituted
    TLSEXT_ECPOINTFORMAT_ansiX962_compressed_char2, the 'else if'
    condition should compare with NID_X9_62_characteristic_two_field.
Reviewed-by: NAndy Polyakov <appro@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4562)
      b2555168
  19. 07 10月, 2017 1 次提交
  21. 06 10月, 2017 2 次提交
  23. 26 9月, 2017 8 次提交
  25. 23 9月, 2017 2 次提交
  27. 22 9月, 2017 1 次提交
  29. 20 9月, 2017 2 次提交
  31. 30 8月, 2017 1 次提交
  33. 13 7月, 2017 4 次提交
  35. 29 6月, 2017 1 次提交
  37. 25 6月, 2017 1 次提交
    • B
      Disallow DSA/SHA1/etc. for pure TLS 1.3 ClientHellos · 6ffeb269
      由 Benjamin Kaduk 提交于 
      In draft-ietf-tls-tls13-20 Appendix B we find that:

   This section describes protocol types and constants.  Values listed
   as _RESERVED were used in previous versions of TLS and are listed
   here for completeness.  TLS 1.3 implementations MUST NOT send them
   but might receive them from older TLS implementations.

Similarly, in section 4.2.3 we see:

   Legacy algorithms  Indicates algorithms which are being deprecated
      because they use algorithms with known weaknesses, specifically
      SHA-1 which is used in this context with either with RSA using
      RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to
      signatures which appear in certificates (see Section 4.4.2.2) and
      are not defined for use in signed TLS handshake messages.
      Endpoints SHOULD NOT negotiate these algorithms but are permitted
      to do so solely for backward compatibility.  Clients offering
      these values MUST list them as the lowest priority (listed after
      all other algorithms in SignatureSchemeList).  TLS 1.3 servers
      MUST NOT offer a SHA-1 signed certificate unless no valid
      certificate chain can be produced without it (see
      Section 4.4.2.2).

However, we are currently sending the SHA2-based DSA signature schemes
and many SHA1-based schemes, which is in contradiction with the specification.

Because TLS 1.3 support will appear in OpenSSL 1.1, we are bound by
stability requirements to continue to offer the DSA signature schemes
and the deprecated hash algorithms.  at least until OpenSSL 1.2.
However, for pure TLS 1.3 clients that do not offer lower TLS versions,
we can be compliant.  Do so, and leave a note to revisit the issue when
we are permitted to break with sacred historical tradition.
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3326)
      6ffeb269
  39. 21 6月, 2017 3 次提交