Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Squid - Alerts - SURICATA HTTP missing Host header ======

[[https://tools.ietf.org/html/rfc6066|RFC 6066]] doesn't specify or even recommend any particular HTTP error in the case that the hostname sent via SNI (Server Name Indication) doesn't match the HTTP Host header.

It does recommend that the server abort the TLS handshake if the SNI hostname is not one that it provides service for. From [[https://tools.ietf.org/html/rfc6066#section-3|section 3]]:

  * If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake.

Since such a malformed request can get past the TLS handshake and need to be rejected in HTTP, an HTTP response code is necessary.  Of all those that exist, only one really fits the situation:

  * [[https://tools.ietf.org/html/rfc7231#section-6.5.1|6.5.1. 400 Bad Request]]
    * The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

This is, in fact, the response that RFC 7230 specifies. From [[https://tools.ietf.org/html/rfc7230#section-5.4|section 5.4]] describing the Host header:

  * A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than one Host header field or a Host header field with an invalid field-value.

I'm going to recommend strongly against using 502 for this. Its semantics indicate that something is wrong on the server side and that the request would succeed if tried later.