-
Bug
-
Resolution: Done
-
Blocker
-
7.1.0.DR14
When I configure Elytron based security and HTTP2, I can see that it works for curl client. Although Chrome or Firefox clients, that are more strict to what ciphersuite is used for created HTTP2 connection, they response with ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY instead.
I think that reason for this is that client offers server both H2 and HTTP/1.1 protocol for communication in ALPN and with that set of ciphersuites that client supports. Although only subset of these offered ciphersuites can be actually utilized with H2 protocol. Server then choose H2 protocol and unsuitable ciphersuite. In response client set ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY.
This seems to be similar as JBEAP-6818 which was filed against 'security-realm' based security subsystem.
One can workaround this issue by explicitelly allowing only secure ciphersuites:
/subsystem=elytron/server-ssl-context=httpsSSC:write-attribute(name=cipher-suite-filter, value=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)
But expected behaviour is that this works rightaway without neccessity of such configuration.
I am attaching packet capture with such unsuccessfull request.
- is cloned by
-
UNDERTOW-1032 Inadequate security with Elytron + HTTP2
- Resolved
- relates to
-
JBEAP-5942 Elytron + https-listener in undertow listener doesn't work with enable-http2 set to "true"
- Closed
-
JBEAP-9866 Elytron SSLContext should not prefer local ciphers
- Closed
-
JBEAP-6818 wildfly-openssl - EAP chooses ciphers that are "unsecure" for Chrome and Firefox for HTTPS
- Closed