Hi Mate, I've looked after it and hostname verification has been disabled for several years (since July 2018). This long standing bug made no hostname check the established, expected behavior for existing Flink deployments.
So +1 on dropping `security.ssl.verify-hostname` and adding the suggested new flag. - `security.ssl.rest.verify-hostname` is needed with default `false`. Setting it to default `true` would break several workloads. - `security.ssl.internal.verify-hostname` is pretty clear, there are no use-cases for it so we can abandon it unless there is an exact need (Self-signed certificates, IP addresses instead of hostnames, Kubernetes/containerized environments with dynamic hostnames/service names don't indicate that) However I think we should notify users in migration guide. I'm pretty sure there are cases where they thought that it's working. In places where security is essential the new flag must be set to true manually. BR, G On Sat, Jan 17, 2026 at 9:29 AM Mate Czagany <[email protected]> wrote: > Hi everyone, > > When upgrading flink-shaded to the newest version in the Flink repository, > Netty is also upgraded from 4.1.x to 4.2.x, which will also enable hostname > verification by default for client TLS connections [1]. > > This broke a few tests, as hostname verification was disabled by default so > far. The confusing part is that there is a configuration in Flink > `security.ssl.verify-hostname` that is true by default, but this > configuration option is not used anywhere in the codebase, probably since > commit 30c4bc8 [2]. As the configuration name does not suggest whether this > is for internal or external connectivity, I think there are two decisions > to be made: > > 1. Should we keep the configuration option `security.ssl.verify-hostname`? > I think an argument can be made that with the current mTLS solution of > internal communication, hostname verification is not that useful. > 2. Should we create a new configuration option > `security.ssl.rest.verify-hostname` that only affects external > connectivity? > > My proposal is to drop the option `security.ssl.verify-hostname` and > instead add a new option `security.ssl.rest.verify-hostname` with default > value of `false` that only affects REST connections, but I would love the > hear the community's opinion on this. > > Best regards, > Mate > > [1] > > https://github.com/netty/netty/wiki/Netty-4.2-Migration-Guide#compatibility-highlights > [2] > > https://github.com/apache/flink/commit/30c4bc847ade8cf0ae5c3ef6a6f8debdf72ddd61#diff-659981ee1b5263cef2478bd413c1e4b5122c9a636ef76bc0d4aafc9633274644 >
