Domain fronting is a technique that was used in 2010s by mobile apps to attempt to bypass censorship. The technique relies on a “front” legitimate domain that basically acts as a pivot for the forbidden domain. In essence an attacker performs a HTTPS connection where in the DNS (used to resolve the domain name) and TLS SNI the legitimate domain name is used, whereas inside the HTTP connection in the “Host” HTTP header it specifies the forbidden domain
Recently at DEF CON 28 a new tool named Noctilucent has been demonstrated. This tool revamped the domain fronting technique by exploiting TLS 1.3 ESNI (Encrypted SNI) for bypassing censorship. This new tool used ESNI (that is encrypted, contrary to the SNI that is in clear text) to specify a domain name different from the SNI. Example: SNI contains allowed.example, while ESNI (and the HTTP Host header) contains forbidden.example. In essence the ESNI obfuscates the real domain of an HTTPS connection and thus it can be used to circumvent security policies
As the use of ESNI is not yet standard and still experimental, and as nDPI already supports the concept of security risk used to report potentially dangerous activities (e.g. a suspicious DGA domain or malformed HTTP header), it has been recently enhanced by adding a new security risk (NDPI_TLS_SUSPICIOUS_ESNI_USAGE) whenever TLS 1.3 flows use ESNI, as it can potentially hide information or potential attacks. Thanks for this security risk mechanism, all applications using nDPI (e.g. ntopng) can immediately detect this problem by simply recompiling them with the latest nDPI library without doing any code change. Of course if your application is used in inline mode, it can also block TLS 1.3 connections using ESNI.
Enjoy!