-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
None
I see UNDERTOW-1032 and this fragment in io.undertow.server.protocol.http.ALPNLimitingSSLEngine#limitCiphers():
for (int cipher : clientCiphers) { if (cipher == 0xC02F) { //TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, required to be offered by spec clientIsCompliant = true; } }
And related https://httpwg.org/specs/rfc7540.html fragment:
To avoid this problem causing TLS handshake failures, deployments of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the P-256 elliptic curve [FIPS186].
However, when using TLSv1.3 on JDK8 (and actually also on JDK11), I can use only these suites:
- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
See sun.security.ssl.CipherSuite and the algorithms that are defined with sun.security.ssl.ProtocolVersion#PROTOCOLS_OF_13 enum.
I checked quickly, but I couldn't determine whether io.undertow.server.protocol.http.ALPNLimitingSSLEngine#limitCiphers() is called too early to check if TLSv1.2 is already negotiated and if it even has to limit the ciphers in the first place (if TLSv1.3 is/will be used).
- is related to
-
UNDERTOW-1032 Inadequate security with Elytron + HTTP2
- Resolved