pfsense:suricata:alerts:suricata_http_host_header_invalid
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| pfsense:suricata:alerts:suricata_http_host_header_invalid [2021/01/15 09:25] – created peter | pfsense:suricata:alerts:suricata_http_host_header_invalid [2021/01/15 09:29] (current) – [PFSense - Suricata - Alerts - SURICATA HTTP Host header invalid] peter | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== PFSense - Suricata - Alerts - SURICATA HTTP Host header invalid ====== | ====== PFSense - Suricata - Alerts - SURICATA HTTP Host header invalid ====== | ||
| - | [[https:// | + | A client sent a bad hostname (or none at all) through SNI or the HTTP Host header. |
| + | |||
| + | ---- | ||
| + | |||
| + | [[https:// | ||
| It does recommend that the server abort the TLS handshake if the SNI hostname is not one that it provides service for. | It does recommend that the server abort the TLS handshake if the SNI hostname is not one that it provides service for. | ||
| Line 7: | Line 11: | ||
| From [[https:// | From [[https:// | ||
| - | * 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. | + | * 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. | * 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: | * Of all those that exist, only one really fits the situation: | ||
| * [[https:// | * [[https:// | ||
| - | * 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). | + | * 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:// | * This is, in fact, the response that RFC 7230 specifies. From [[https:// | ||
| - | * 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. | + | * 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. |
| - | It is recommended strongly against using a 502 for this. | + | It is recommended strongly against using a **502 (Bad Gateway)** |
| * Its semantics indicate that something is wrong on the server side and that the request would succeed if tried later. | * Its semantics indicate that something is wrong on the server side and that the request would succeed if tried later. | ||
pfsense/suricata/alerts/suricata_http_host_header_invalid.1610702718.txt.gz · Last modified: 2021/01/15 09:25 by peter