Skip to content
  1. Jan 31, 2018
  2. Jan 30, 2018
  3. Jan 29, 2018
  4. Jan 28, 2018
  5. Jan 26, 2018
  6. 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