Difference between the Host header and SNI in network requests

What is a Host?

The Host header is an HTTP header with the format `Host: `. Other common HTTP headers include Location, User-Agent, and Connection. The Host header is defined in RFC 7230 and specifies the hostname for an HTTP request. You can view this header in the Network tab of a web browser's developer tools.

In HTTP/1.x, the Host header specifies the host and port number of the request target. You might not see a port number in the Host header for standard HTTP or HTTPS requests. This is because HTTP uses the default port 80 and HTTPS uses the default port 443. If you use a custom port, you must add the port to the request, for example, `https://my.example.com:8443/get`.

HTTP/2 uses the :authority pseudo-header field to specify the host and port number of the request target, which is similar to the Host header in HTTP/1.x. HTTP/2 replaces the Host header with :authority to identify the request target. Other important pseudo-header fields in HTTP/2 include :method for the HTTP method, :path for the resource path, and :scheme for the protocol, such as HTTP or HTTPS.

Cloud-native gateway access logs use the :authority field to record the hostname of a request, as shown in the following figure.

What is SNI?

SNI is a TLS extension defined in RFC 6066. It allows the client to indicate the fully qualified domain name (FQDN) it is attempting to connect to during the TLS handshake. A TLS handshake is similar to a TCP three-way handshake. However, a TCP handshake establishes a TCP connection, whereas a TLS handshake begins after the TCP connection is established. This places TLS at a higher layer in the OSI model. You must use a packet capture tool to view the SNI. You cannot find it in a browser's developer tools.

The following image shows a packet capture from a client accessing Microsoft documentation. After the TCP three-way handshake (highlighted in blue), the client sends a Client Hello packet (highlighted in red). This packet includes the Server Name Indication extension, which contains the value `docs.microsoft.com` (highlighted in green).

The web server uses the SNI to check the FQDN against its certificates. It then selects the correct certificate to perform the TLS handshake. After the TLS handshake is complete, encrypted communication can begin.

If a request does not include an SNI, the Client Hello packet will not have a `server_name` extension, as shown in the following figure.

How does SNI work in an HTTPS request?

The following figure shows the process of opening a website in a browser.

• In step 5, the client sends the Server Name Indication (SNI).

• In step 6, the client sends the Host header and retrieves the webpage. In this figure, www.contoso.com is used as both the SNI and the Host header, and the web service responds with the webpage that matches the FQDN.

The figure shows that during an HTTPS transaction, the SNI is used first to establish a secure TLS connection. Then, the HTTP request, which includes the Host header, is sent.

Must the SNI and Host header be the same in an HTTPS request?

In an HTTPS request, the Server Name Indication (SNI) and the Host header should usually match, but they are not required to be identical.

1. Server Name Indication (SNI): The client sends the SNI during the TLS handshake to tell the server which hostname the client wants to access. SNI is an extension at the TLS layer that indicates which domain name the server must process. It is crucial for environments where multiple virtual hosts share one IP address because it allows the server to select the correct certificate during the handshake.

2. Host header: This is a header field in an HTTP request that specifies the hostname the client wants to access. This field is used in the HTTP protocol to tell the server which virtual host must handle the request.

In most cases, the SNI and Host header are the same, especially in virtual host environments. Browsers and clients typically use the same hostname for both fields. However, they are not technically required to be identical and might differ in special cases, such as in a staging environment or during a migration.

If the SNI and Host header do not match, it can cause security risks and other problems, including the following:

1. Incorrect server response: The server may select a certificate and configuration based on the SNI. If the SNI and Host header do not match, the server might return the wrong certificate. This can cause the client to establish an invalid HTTPS connection due to a certificate mismatch.

2. Increased risk of man-in-the-middle attacks: A mismatch can be the result of a malicious attack. For example, an attacker might intentionally create a mismatch between the SNI and Host header to trick the server or client into behaving incorrectly.

3. Privacy leaks: If the SNI is exposed and does not match the expected Host header, it can leak information about the service type or destination that the user is trying to access.

4. Server configuration errors: A mismatch between the SNI and Host header can cause the server to select the wrong virtual host, which can expose sensitive information or cause application errors.

What problems occur in a cloud-native gateway when the SNI and Host header do not match?

A 404 error appears in the gateway access log. You can query for this error using response_code:404, as shown in the following figure:

In which scenarios do the SNI and Host header typically not match?

Connections that are made to an origin server, either directly or
through a tunnel created using the CONNECT method (Section 8.3), MAY
be reused for requests with multiple different URI authority
components. A connection can be reused as long as the origin server
is authoritative (Section 10.1). For TCP connections without TLS,
this depends on the host having resolved to the same IP address.