1. 26 4月, 2018 1 次提交
  2. 28 3月, 2018 2 次提交
  3. 19 3月, 2018 2 次提交
  4. 14 3月, 2018 1 次提交
    • M
      Split configuration of TLSv1.3 ciphers from older ciphers · f865b081
      Matt Caswell 提交于
      With the current mechanism, old cipher strings that used to work in 1.1.0,
      may inadvertently disable all TLSv1.3 ciphersuites causing connections to
      fail. This is confusing for users.
      
      In reality TLSv1.3 are quite different to older ciphers. They are much
      simpler and there are only a small number of them so, arguably, they don't
      need the same level of control that the older ciphers have.
      
      This change splits the configuration of TLSv1.3 ciphers from older ones.
      By default the TLSv1.3 ciphers are on, so you cannot inadvertently disable
      them through your existing config.
      
      Fixes #5359
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5392)
      f865b081
  5. 13 2月, 2018 1 次提交
  6. 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
  7. 27 12月, 2017 1 次提交
  8. 16 12月, 2017 1 次提交
  9. 08 12月, 2017 1 次提交
  10. 04 12月, 2017 1 次提交
  11. 30 11月, 2017 2 次提交
  12. 18 10月, 2017 1 次提交
  13. 09 10月, 2017 1 次提交
  14. 26 9月, 2017 3 次提交
  15. 23 9月, 2017 1 次提交
  16. 30 8月, 2017 3 次提交
  17. 07 8月, 2017 1 次提交
  18. 03 8月, 2017 1 次提交
  19. 31 7月, 2017 1 次提交
  20. 21 7月, 2017 1 次提交
  21. 09 7月, 2017 1 次提交
  22. 21 6月, 2017 1 次提交
  23. 20 6月, 2017 1 次提交
  24. 16 6月, 2017 2 次提交
  25. 09 6月, 2017 1 次提交
  26. 22 5月, 2017 2 次提交
  27. 12 4月, 2017 1 次提交
  28. 04 4月, 2017 1 次提交
  29. 24 3月, 2017 2 次提交
  30. 01 3月, 2017 1 次提交