Skip to content
  1. Jan 30, 2018
  3. Jan 29, 2018
  5. Jan 28, 2018
  7. Jan 26, 2018
  9. Jan 25, 2018
    • Benjamin Kaduk's avatar
      Add TLSProxy tests for signature_algorithms_cert · 3e524bf2
      Benjamin Kaduk authored 
      

We don't need to send this extension in normal operation since
we are our own X.509 library, but add some test cases that force
the extension to be sent and exercise our code to process the extension.

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      3e524bf2
    • Benjamin Kaduk's avatar
      Add support for the TLS 1.3 signature_algorithms_cert extension · c589c34e
      Benjamin Kaduk authored 
      

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: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      c589c34e
    • Benjamin Kaduk's avatar
      Update documentation for SSL_set1_sigalgs() · a6419d1e
      Benjamin Kaduk authored 
      

These functions can now take both "sig+hash" strings and
algorithm-specific identifiers like "rsa_pss_pss_sha256" that
indicate a particular entry from the TLS signature algorithm
registry.

Also clarify that only the "_list" form allows for the new-style names
(the non-"list" interfaces take sig and hasn NIDs, which cannot
access all of the new-style schemes).

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      a6419d1e
    • Benjamin Kaduk's avatar
      Propagate TLS 1.3 sigalgs through tls1_set_sigalgs() · fd5e1a8c
      Benjamin Kaduk authored 
      

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: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      fd5e1a8c
    • Benjamin Kaduk's avatar
      Add TLS 1.3 draft-23 PSS signature algorithms · f55e99f7
      Benjamin Kaduk authored 
      

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: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      f55e99f7
    • Benjamin Kaduk's avatar
      Renumber TLSEXT_TYPE_key_share for draft-23 · f27f5cd4
      Benjamin Kaduk authored 
      

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5068)
      f27f5cd4