Re: SNI normalization?
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 : > > 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 > wrote: >> I guess this makes sense to avoid these kind of issues. >> >> Regards >> >> Rüdiger >> >>> -Ursprüngliche Nachricht- >>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >>> Gesendet: Mittwoch, 11. April 2018 11:49 >>> An: dev@httpd.apache.org >>> 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
Re: SNI normalization?
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 wrote: > I guess this makes sense to avoid these kind of issues. > > Regards > > Rüdiger > >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] >> Gesendet: Mittwoch, 11. April 2018 11:49 >> An: dev@httpd.apache.org >> 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
AW: SNI normalization?
I guess this makes sense to avoid these kind of issues. Regards Rüdiger > -Ursprüngliche Nachricht- > Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de] > Gesendet: Mittwoch, 11. April 2018 11:49 > An: dev@httpd.apache.org > 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
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
