7

Is the Host: header required over SSL even if the request is not HTTP/1.1?

So, if a client connects over SSL, and sends the following request:

GET / HTTP/1.0
  1. Should the web server throw a bad request due to the missing Host: header?
  2. Should the web server respond with an HTTP/1.0 200 OK response?
    (the index.html file always exists, so a request to /, would never lead to 403/404)

Update:

If I disable SNI in openssl s_client, apache works without the Host: header.

Why does it need the Host: header when SNI is on?

4
  • I get an error 400 from Apache, but that persists even with a Host: header, so there may be something else that is required. My expectation would be that when the Host: header is missing, the request is handled by the default server configuration, same as for non-SSL. Apr 13, 2021 at 6:20
  • 1
    @SimonRichter are you using openssl s_client? If so, add the -crlf option to the end of it. Apr 13, 2021 at 6:39
  • @SimonRichter my web server works with the Host: header if I add it. Even httpd.apache.org works if you mention the host header. But, the HTTP/1.0 doesn't need the Host; header. Apr 13, 2021 at 6:40
  • Consider this use case: a load balancer terminates the TLS connection (hence has access to the SNI) but redirect traffic internally over HTTP. The real back-end won't have any TLS related information, only the HTTP traffic. So to know which host was asked for... But, other than out of curiosity, do you really have things using explicitly HTTP/1.0? Besides that, HTTP was created before SNI... Apr 21, 2021 at 17:25

2 Answers 2

18

A HTTP/1.0 request does not need a Host according to the standard, but this header is still usually needed in practice to decide on multi-domain setups which content to serve. But if this header is not present and it is still clear which content to serve, than this content can be served without requiring the header. Note that this has nothing to do with TLS and with the use of SNI.

5
  • 1
    There could be a relationship with TLS and SNI depending on the value of the SSLStrictSNIVHostCheck setting, though I haven't experimented with that to test the various situations.
    – jcaron
    Apr 13, 2021 at 15:38
  • This also means that in a virtualhost setup, GET / without a host header will likely return the default certificate depending on how the server is configured. Chances are this is not the one associated with the site you were looking for. Apr 13, 2021 at 17:09
  • 1
    @Shadur you mean the default vhost? By that time it's too late to choose a certificate
    – user253751
    Apr 13, 2021 at 20:40
  • For extra fun, SNI one host and header another and see if you can discover something odd.
    – joshudson
    Apr 14, 2021 at 3:35
  • @joshudson maybe that will show 421 misredirected request? lemme try Apr 15, 2021 at 9:15
6

To answer the part of the question added in an update,

Why does it need the Host: header when SNI is on?

"Need" is a strong word but it helps to understand that SNI and HTTP headers operate at two different layers and accordingly serve two different purposes.

SNI is primarily used to determine which certificate to give the client. In a setup with multiple virtual hosts, before the payload is decrypted, the server has to present a certificate to the client. Since the certificate contains the name of the site, traditionally in the common name of the certificate subject, but lately in the X.509 extension subject alternative names, presenting the wrong certificate would cause the client to reject the connection before even sending the HTTP request to the server.

Whereas, the Host header is primarily used to determine which resource to serve. In well behaved clients this is redundant with the name in SNI but HTTP/1.1 was developed around the same time as SSL 3.0 and thus well before the TLS-SNI extension even existed. In fact, it was the combination of HTTP/1.1 and SSL/TLS where the need for SNI was discovered in the first place.

It may be worth noting that HTTP/2 does not require the Host header but has a functional equivalent in the form of the :authority pseudo-header. Though the information in that header will still be redundant with TLS-SNI in most cases, it simplifies the implementation to always include it.

Always including the Host (or :authority) header also leaves open the possibility of barebones SSL termination (though in practice there is very little support for HTTP/2 without TLS). However, not validating that the host/authority matches the name in TLS-SNI could open up a security hole in some setups.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .