SNI (Server Name Indication) is an optional extension in TLS/QUIC that contains the symbolic host name we’re connecting to. For instance, during the TLS handshake, the SNI allows the server to identify the correct TLS certificate of a server hosting multiple websites. nDPI reports SNIs in order to make it possible to detect name-based services deployed on the same server IP address. Below you can see an example of how nDPI reports SNIs in encrypted traffic.
TCP 192.168.1.29:52663 <-> 116.203.142.127:443 [proto: 91.26/TLS.ntop][Stack: TLS.ntop][IP: 0/Unknown][Encrypted][Confidence: DPI][FPC: 0/Unknown, Confidence: Unknown][DPI packets: 8][cat: Network/14][Breed: Safe][23 pkts/4503 bytes <-> 24 pkts/25933 bytes][Goodput ratio: 66/94][0.36 sec][Hostname/SNI: www.ntop.org][(Advertised) ALPNs: h2;http/1.1][TLS Supported Versions: GREASE;TLSv1.3;TLSv1.2][bytes ratio: -0.704 (Download)][IAT c2s/s2c min/avg/max/stddev: 0/0 20/16 263/219 60/49][Pkt Len c2s/s2c min/avg/max/stddev: 66/66 196/1081 1506/1506 363/627][nDPI Fingerprint: 09a4ff6a891e0364e7cd1b08c0825fc3][TCP Fingerprint: 194_64_65535_d29295416479/macOS][TLSv1.3][JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd][JA3S: f4febc55ea12b31ae17cfb7e614afda8][ECH: version 0xfe0d][Chrome][Cipher: TLS_AES_128_GCM_SHA256][Plen Bins: 0,0,12,0,0,4,0,0,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,0,0,0,4,0,0,0,0,0,0,0,0,0,0,71,0,0]Client applications use the SNI to verify that the website it is connecting to matches the symbolic website, and in case this is not happening errors such as ‘Your connection is not private’ are reported. This said, it is not wise to assume that clients will always check name mismatches. In fact there are many applications that do not check them at all as this allows them to bypass network security policies. For instance, there are many VPN-like applications that connect to malicious IPs using popular SNIs (e.g. www.google.com) to hide their activities. While passively monitoring traffic, assuming that SNI maps.google.com means Google Maps isn’t safe without checking it.
As in TLS 1.3, the server certificate exchange is encrypted, in order to passively validate a connection, we have introduced in nDPI a DNS cache. Such cache keeps track of DNS resolution <numeric IP>:<symbolic hostname> in order to detect
- Connections to SNIs that have not been previously DNS-resolved.
- Mismatches numeric vs symbolic IP address
Below you can see an example of nDPI flow risk NDPI_UNRESOLVED_HOSTNAME reported by ntopng when a mismatch is detected.
In order to reduce cache memory size, we hash values in a bloom-filter-like data structure, so enabling this feature has a limited computational cost. Note that when DoH/DoT is in use, nDPI can report false positives as it has not observed the query, so enable this feature only on networks where it can be safely used.
In nEdge, host pools use the above feature to create a dynamic blacklist whenever a mismatch is reported. This means that hosts relying on SNI mismatch to bypass network policies can be spotted and blocked automatically.
Bottom line: trusting SNIs is not a good idea as some malicious applications can use them to overcome network security measures. nDPI (hence all ntop applications) implements a mechanism to detect malicious SNI usage and eventually (in nEdge) block this traffic. Now you can safely monitor network traffic and trust SNIs again.
Enjoy !