all i know is if i browse to http://the-ip-of-my-site i hit the vhost that matches the name the-ip-of-my-site not the default vhost for 'empty hostname'
so i know that no http1.1 browser seen yet sends empty host header when browsing to an ip (as the empty/unmatched host header vhost responds with a page offering http1.0 links to all the sites, and http1.0 compatible links to download http1.1 compatible clients (amazingly few browsers can be downloaded with a http1.0 client btw) (tested with ncsa mosaic v1 ish) and gets extremely few hits ever but the ip as name vhost sees hundreds of hits an hour from probes/bots/attackers and logs/redirects or blacklists them based on attack type seen At 07:34 29/03/2017 Wednesday, Niklas Keller wrote: >From RFC 2616: > >A client MUST include a Host header field in all HTTP/1.1 request messages . >If the requested URI does not include an Internet host name for the service >being requested, then the Host header field MUST be given with an empty value. > >I guess an IP address is not considered an Internet host name and thus the >Host header must be empty. > >Regards, Niklas > >Richard Barnes <[email protected]> schrieb am Di., 28. März 2017, 21:13: >On Tue, Mar 28, 2017 at 3:08 PM, Ilari Liusvaara ><<mailto:[email protected]>[email protected]> wrote: >On Mon, Mar 27, 2017 at 07:28:53PM -0400, Richard Barnes wrote: >> Thanks, Roland. Interesting draft. >> >> Couple of first reactions: >> >> - Why use the target of the PTR instead of just provisioning the TXT record >> directly in the reverse DNS. (Is there some restriction in the spec for >> reverse DNS that says it's only PTR?) It seems like by using the PTR >> target, your security analysis gets much more complicated. > >Reading proposed IP validation rules in CABForum, using PTR target would >certainly qualify, whereas putting TXT record on the name probably does >not. > >The proposed rules have nothing on DNS apart from PTR lookups. > >(The current rules have "other equivalent method" clause.) > >So my reading is, that one has to do the PTR lookup in order to remain >compliant with BRs after the proposed tighening of IP validation goes >through (I expect it to). > >> - For the re-use of "http-01", you should probably specify the contents of >> the Host header. (Main ACME should probably clarify that for DNS, if it's >> not clear already.) > >Reading the proposed and current rules, the challenge is either invoked >on IP address itself, or on reverse-DNS lookup of it. So if you don't >do rDNS lookup, then the validation is invoked on IP address itself, >which I think leads to empty Host-header. > > >Au contraire! > >rbarnes$ nc -l 8080 >/dev/null & >rbarnes$ curl -v <http://127.0.0.1:8080>http://127.0.0.1:8080 >* Rebuilt URL to: <http://127.0.0.1:8080/>http://127.0.0.1:8080/ >*  Trying 127.0.0.1... >* TCP_NODELAY set >* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0) >> GET / HTTP/1.1 >> Host: <http://127.0.0.1:8080>127.0.0.1:8080 >> User-Agent: curl/7.51.0 >> Accept: */* >> > >Guess this is good evidence that we should document this :) > > >TLS-SNI-02 would work as usual (the proposed rules explicitly list >method 10, which is what TLS-SNI-02 falls under). Existing rules don't >say anything (but again, equivalent method clause exists). > > > > > >-Ilari > >_______________________________________________ >Acme mailing list ><mailto:[email protected]>[email protected] >https://www.ietf.org/mailman/listinfo/acme > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
