Unify TLS configuration

[jhl221123]

• Introduced TlsConfiguration interface
• Defaulted verifyHostname to true
• Repurposed Http.verifyHostname as a toggle for backward compatibility

Related to #2792

[vy]

@jhl221123, thanks so much for the PR! 🙇 I've a question: In @ppkarwasz's original proposal, there is also the following item:

Currently if the user configures an SSL element, all the log4j2.ssl* configuration properties are ignored. I think those properties should still be used to provide default values for SSL.

@jhl221123, do you plan to update this PR to reflect this too?

@ppkarwasz, I'm not able to see the value of a new TlsConfiguration interface here. The fact that it contains a getSslContext method (note the Ssl in the name!) makes it even more clumsy. I know that SSL keyword is superseded by TLS, but from an API point of view in the Java ecosystem, is it really? What will be the benefit of introducing TlsFoo as long as we will have SslFoo and SslBar around for functionality, backward compatibility, etc. reasons?

[jhl221123]

@vy Thanks for the feedback!

@jhl221123, do you plan to update this PR to reflect this too?

Absolutely! But I noticed in #2792 you mentioned that it might be better to handle this in a separate PR. Which approach would you prefer: should I continue updating this PR, or would it be better to open a separate one for it?

[ppkarwasz]

I'm not able to see the value of a new TlsConfiguration interface here. The fact that it contains a getSslContext method (note the Ssl in the name!) makes it even more clumsy. I know that SSL keyword is superseded by TLS, but from an API point of view in the Java ecosystem, is it really? What will be the benefit of introducing TlsFoo as long as we will have SslFoo and SslBar around for functionality, backward compatibility, etc. reasons?

I don't see the point in calling it TlsConfiguration instead of SslConfiguration either, except the fact that the SslConfiguration name is already used.

Where I do see value, though, is in introducing an interface rather than tying everything to the concrete SslConfiguration class. That opens the door for third-party Log4j Core plugins to provide their own TLS material without having to subclass Log4j internals.

Most popular Java HTTP clients (HttpsURLConnection, Java 11+ HttpClient, OkHttp, Apache HttpClient) can all be configured with essentially three knobs:

public interface TlsConfiguration {
    SSLContext getSslContext();
    HostnameVerifier getHostnameVerifier();
    /** Optional **/
    SSLParameters getSslParameters();
}

Jakarta Mail is the only outlier that still needs an isVerifyHostName() flag.

With such an abstraction, you could, for example, plug in Spring Boot’s SslBundle to supply the key/trust material. That would make it straightforward to integrate Log4j into environments where TLS credentials are managed externally (e.g. centralized config via Spring Cloud).

Each host would only need to declare which SslBundle to use, and Log4j could obtain everything else through the interface.

@rgoers: does this kind of abstraction line up with what you’d find useful in practice?

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	❌
build-ubuntu-latest	clean install	3.9.8	❌
build-windows-latest	clean install	3.9.8	❌

Generated by gradle/develocity-actions

[vy]

@ppkarwasz, thanks for clarifying the use case in mind. That certainly helps with setting the feature's intended context.

Where I do see value, though, is in introducing an interface rather than tying everything to the concrete SslConfiguration class.

I understand and share your preference for an interface, yet given the current state of the code, wouldn't it be less intrusive to provide a similar adapter pattern support by adding a sufficient SslConfiguration.create(SSLContext, HostnameVerifier, SSLParameters) factory method?