Regarding this, I wrote the attached patch that adds a new method AP_DECLARE(apr_status_t) ap_normalize_hostname(conn_rec *c, const char **phostname);
to http_vhost.h with some internal rewiring so that request_rec fix_hostname() and this method have a common base.
sni_fixup_hostname.patch
Description: Binary data
If this looks ok, mod_ssl should invoke that on SNI names before further processing. Cheers, Stefan > Am 11.04.2018 um 12:22 schrieb Yann Ylavic <[email protected]>: > > ISTR that the RFC about SNI forbids port numbers (I find it > unfortunate as a matter of fact, given that host names may contain > ports...). > Just to say that normalization may come with ports handling/relaxing > in several places, which I support! > > On Wed, Apr 11, 2018 at 11:52 AM, Plüm, Rüdiger, Vodafone Group > <[email protected]> wrote: >> I guess this makes sense to avoid these kind of issues. >> >> Regards >> >> Rüdiger >> >>> -----Ursprüngliche Nachricht----- >>> Von: Stefan Eissing [mailto:[email protected]] >>> Gesendet: Mittwoch, 11. April 2018 11:49 >>> An: [email protected] >>> Betreff: SNI normalization? >>> >>> Feedback desired: >>> >>> Checking my server logs, I regularly see clients using SNI with port >>> identifier, >>> as in: test.example.org:443 >>> >>> I am not sure what client that is, but we do not identify the vhost that >>> is >>> (probably) intended. Then the request comes in, and there we have magic >>> that >>> finds the correct r->server. Then we mod_ssl sees that sslconn->server >>> != r->server >>> and does some compatibility checks. If the base server and vhost have >>> incompatible >>> settings (e.g. other certs/ciphers etc.), the request fails. >>> >>> This seems to be wrong. Do we need the same normalization that we have >>> in Host: header >>> parsing in SNI? >>> >>> -Stefan
