1. 26 1月, 2018 1 次提交
    • 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
  2. 25 1月, 2018 9 次提交
  3. 23 1月, 2018 1 次提交
  4. 19 1月, 2018 1 次提交
  5. 11 1月, 2018 1 次提交
  6. 10 1月, 2018 1 次提交
    • M
      Tolerate DTLS alerts with an incorrect version number · 08455bc9
      Matt Caswell 提交于
      In the case of a protocol version alert being sent by a peer the record
      version number may not be what we are expecting. In DTLS records with an
      unexpected version number are silently discarded. This probably isn't
      appropriate for alerts, so we tolerate a mismatch in the minor version
      number.
      
      This resolves an issue reported on openssl-users where an OpenSSL server
      chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version
      alert with a 1.2 record number. This was silently ignored by the server.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/5018)
      08455bc9
  7. 09 1月, 2018 4 次提交
  8. 06 1月, 2018 1 次提交
  9. 03 1月, 2018 1 次提交
    • B
      Permit the "supported_groups" extension in ServerHellos · 7bc2bddb
      Benjamin Kaduk 提交于
      Although this is forbidden by all three(!) relevant specifications,
      there seem to be multiple server implementations in the wild that
      send it.  Since we didn't check for unexpected extensions in any
      given message type until TLS 1.3 support was added, our previous
      behavior was to silently accept these extensions and pass them over
      to the custom extension callback (if any).  In order to avoid
      regression of functionality, relax the check for "extension in
      unexpected context" for this specific case, but leave the protocol
      enforcment mechanism unchanged for other extensions and in other
      extension contexts.
      
      Leave a detailed comment to indicate what is going on.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4463)
      7bc2bddb
  10. 02 1月, 2018 2 次提交
  11. 29 12月, 2017 2 次提交
  12. 27 12月, 2017 1 次提交
  13. 26 12月, 2017 1 次提交
  14. 18 12月, 2017 3 次提交
  15. 16 12月, 2017 1 次提交
  16. 14 12月, 2017 10 次提交