Uniformize TLS configuration

[ppkarwasz]

Many Log4j components have a configuration attribute to enable the verification of the TLS server certificate:

• Network appenders (Socket, SMTP) use the verifyHostname attribute of the SSL nested component to provide the same feature. Its default value is false.

• The HTTP Appender has a configuration attribute verifyHostname. The value defaults to true. Note that the HTTP Appender can also have a nested SSL component, but the value of SSL.verifyHostname is ignored.

• We also have a log4j2.sslVerifyHostName configuration property that is used if the SSL component is absent.

I understand that in the past only HTTP servers had a X509 certificate issued by a public CA. However nowadays most SMTP servers have also publicly verifiable X509 certificates, so we can switch both defaults to true.

Besides that a public X509 certificate was never required by our appenders: they only connect to a single host.

Proposed changes

• Let us deprecate HTTP.verifyHostname in 2.x. In 3.x we can still keep it, but set its default value to SSL.verifyHostname.
• We can switch the default value of SSL.verifyHostname to true. This might require some additional work: the SMTP and HTTP appenders only connect to the host, when there is a log event to send. In the case of SMTP this happens only for ERROR log events by default, so users might realize that they have a configuration problem much later.
• 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.

[vy]

@ppkarwasz, good examination. Agreed with the proposal. Some remarks:

Let us deprecate HTTP.verifyHostname in 2.x. In 3.x we can still keep it, but set its default value to SSL.verifyHostname.

I'd be in favor of removing HTTP.verifyHostname in 3.x.

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.

This is a good improvement anyway. I would rather implement this in a separate PR and avoid unnecessarily involving it in the discussions we will have for other proposed changes in this PR.

[ppkarwasz]

Let us deprecate HTTP.verifyHostname in 2.x. In 3.x we can still keep it, but set its default value to SSL.verifyHostname.

I'd be in favor of removing HTTP.verifyHostname in 3.x.

I guess we have to agree how many breaking changes do we allow in the configuration format.

We recommend users to use ConfigurationBuilder instead of directly instantiating Log4j Plugins as a protection against breaking code changes. Maybe it would be wiser to keep HTTP.verifyHostname at least in 3.x.

For a similar change Tomcat introduced a new SSL configuration format in 8.5, deprecated the old one and removed the old one in 10.0.

[jhl221123]

Hi @ppkarwasz and @vy,

Has a decision been made on how to handle HTTP.verifyHostname in 3.x? If so, I'd be happy to start working on consolidating it into SSL.verifyHostname.

[jvz]

Yeah, let's work on that. My preference is that we use the term "TLS" over "SSL" where possible for accuracy (since SSL hasn't been used in HTTPS and other secure protocols for a long time now), but that's just a preference. In 3.x, it should be simple enough to have an interface to be implemented as a dependency injection as with the other extensions that used to be supplied as class names in properties.

[vy]

@jhl221123, before writing any code, would you mind sharing a list of things that you plan to deliver grouped by target branch (i.e., 2.x and main), please?

we use the term "TLS" over "SSL" where possible

Agreed.