JDK-8211866 : TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11,12
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2018-10-08
  • Updated: 2020-11-23
  • Resolved: 2018-10-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 8 Other
11.0.6-oracleFixed 12 b16Fixed 8u261Fixed openjdk8u272Fixed
Description
When an SSLSocket or SSLEngine is created and not forced to do only TLS 1.3, even after the TLS 1.3 protocol has been agreed upon there are algorithms in the CertificateRequest message (specifically the signature_algorithms extension) that are disallowed (see RFC 8446, sec 4.2.3 near the end).

A sample CR message sent by a server that will negotiate any TLS version, but has negotiated TLS 1.3 looks like this:

javax.net.ssl|DEBUG|0A|pool-1-thread-1|2018-10-06 23:29:58.515 PDT|CertificateRequest.java:859|Produced CertificateRequest message (
"CertificateRequest": {
  "certificate_request_context": "",
  "extensions": [
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    }
  ]
}

Note the DSA and SHA-224 based algorithms in both the signature_algorithms and signature_algorithms_cert extensions.

If, however, the SSLSocket/Engine is created such that only TLS 1.3 is an allowed protocol, then the signature algorithms do not contain these disallowed schemes:

javax.net.ssl|DEBUG|0A|pool-1-thread-1|2018-10-06 23:46:44.999 PDT|CertificateRequest.java:859|Produced CertificateRequest message (
"CertificateRequest": {
  "certificate_request_context": "",
  "extensions": [
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, ecdsa_sha1, rsa_pkcs1_sha1]
    }
  ]
}




Comments
Fix request (11u) Request backport for Oracle 11.0.6 parity. Patch applies cleanly, no regressions in testing encountered.
11-11-2019

I've marked this as a noreg-hard because the handshake at this stage is encrypted between client and server and there isn't a way from the main JSSE API to test the contents of the message for correctness. It can be verified manually by looking at debug logging though.
16-10-2018