Differences

This shows you the differences between two versions of the page.

--- pfsense:suricata:alerts:suricata_http_host_header_invalid [2021/01/15 09:27] – [PFSense - Suricata - Alerts - SURICATA HTTP Host header invalid] 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 ======
-[[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.
+A client sent a bad hostname (or none at all) through SNI or the HTTP Host header.
+----
+[[https://tools.ietf.org/html/rfc6066|RFC 6066]] does not 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.
@@ Line 7: / Line 11: @@
 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.
+  * 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: