RE: minor nit in mod_ssl
> One would need something like "SSLNameIndicator x.internal.net" to make that disconnect clear, it seems.
If going so far as to add a new directive, I would personally prefer disabling the check rather than adding another to get around this. That could be done with a Boolean directive.
For a more flexible approach going forward in 2.6, what do you all think about the idea of adding a new directive to re-define a log statement's level at runtime? This would have made both these log issues a minor inconvenience for end users and easily addressable via the documentation for my specific case. Something like this:
LogMessageReduce <APLOGNO> <LEVEL>
If such directives are present, log entries would consult a table and substitute the logging level inside ap_log_error for any matches. I can't see this working without an interface change in ap_log_error to get directly at the number, however.
Obviously, this function is called a LOT, so there is potential for slowdown depending on how it's written. I would personally write this as a reduce only function, so the lookup checks never happen unless a log message would have been written, in which case it would be overshadowed by the log write itself.
> -----Original Message-----
> From: Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx>
> Sent: Thursday, September 20, 2018 09:57
> To: dev@xxxxxxxxxxxxxxxx
> Subject: Re: minor nit in mod_ssl
> EXTERNAL EMAIL
> > Am 20.09.2018 um 15:31 schrieb Houser, Rick <rick.houser@xxxxxxxxxxx>:
> >> Envision a TCP load balancer routing TLS-crypted traffic across a number
> >> of internal hosts, with each of the named virtual hosts presenting the
> >> certificate, and known to httpd by their ServerAlias on the outer-facing
> >> Not terminated at the edge balancer.
> > We are using IP/port based vhosts and ServerName directive, but yes,
> that's one example. In our current config, the load balancer is talking to a lot
> of vhosts using TLS with a single host-specific certificate.
> > From my perspective, the underlying problem is merely attempting to
> associate the ServerName with the certificate at all, since they belong at
> different places in the protocol stack. The ServerName needs to be set to
> the externally facing endpoint of the infrastructure (the encapsulated HTTP
> traffic), and the certificate needs to be correct for the local TLS link. I know of
> no reason from a technical/protocol perspective that there couldn't be a
> dozen different hops in between (ex. application-layer firewalls, virus
> scanner, reverse proxies, etc.).
> > My understanding is that using ServerAlias instead of ServerName would
> potentially leak information about the host, via server generated content.
> The documentation seems to reinforce this
> (https://httpd.apache.org/docs/2.4/mod/core.html#servername ).
> You are correct. Using the externally visible name for ServerName seems
> best in your scenario. Thanks for explaining your setup.
> > From a pragmatic approach, lay users will not be encountering this type of
> configuration, so keeping the message at a more verbose level still makes
> some sense and could help identify a legitimate misconfiguration. IMO, a
> production system should be able to run with info level logs without blowing
> up on false positives, however.
> Totally agree. When using local TLS links between balancers/terminators and
> httpd boxes, it seems not possible to map that onto the existing
> configuration concepts that easily.
> Basically, the TLS is not end-to-end, but a tunnel to a "worker" httpd host
> that has its own name and own certificate which is used to serve requests for
> another hostname. In this scenario, the normally desired link between
> certificate alt names and servername gets in the way.
> One would need something like "SSLNameIndicator x.internal.net" to make
> that disconnect clear, it seems.