Netty: client TLS silently skips hostname verification when a plain X509TrustManager is supplied

Impact

Netty wraps a user-supplied plain X509TrustManager in a class that extends X509ExtendedTrustManager but throws away the SSLEngine, so neither the JDK nor Netty's own OpenSSL wrapper adds endpoint identification afterwards. A client built with SslContextBuilder.forClient().trustManager(...) therefore validates the certificate chain but never checks that the hostname matches - even in 4.2, where endpoint identification is supposed to be on by default. Anyone able to intercept the connection and present a certificate signed by a CA in the trust store can read and alter the traffic. Netty sits under a large amount of JVM-based control-plane and storage tooling that runs alongside GPU fleets, so the practical exposure is service-to-service TLS between cluster components being downgraded to no-hostname-check.

Who can reach it

A network attacker positioned between a Netty-based TLS client and its server, holding any certificate the client's trust store accepts. No credentials on the target service are required; the flaw is in the client side of the handshake.

What to do

Upgrade Netty to 4.1.135.Final or 4.2.15.Final, or take the Red Hat errata for the affected Quarkus, Camel, Cryostat and Data Grid builds, then restart each JVM service that embeds it. This is a library bump plus a rolling restart of the affected daemons - no node reboot.

References