National Anti-Fraud Center based plugins allegedly found in residential FTTR modem in China. about bbs HOT 3 OPEN

Related to matching an SNI with an expected IP address, this is a recent (2022) patent from the Chinese firewall company Venustech (启明星辰). It is about building a database of expected IP addresses for hostnames through passive observation of natural DNS, HTTP, and HTTPS traffic. The database can be used to filter/block connections that use an unexpected IP address for the hostname.

基于局部敏感哈希算法的伴随域名检测方法
Companion domain name detection method based on locality-sensitive hash algorithm
https://patents.google.com/patent/CN115051845
Chinese PDF
English PDF (machine translation)

The database consists of (hostname, source IP, dest IP) records. For DNS, the hostname comes from the DNS response; for HTTP, it comes from the Host header; and for HTTPS, it comes from the TLS SNI. For each unique (hostname, dest IP), the number of unique source IP accessing it is counted and compared to a "rarity threshold" (potentially a different threshold for each protocol).

The text of the patent shows that it is intended against domain fronting–like techniques:

[0002] 在网络的信号安全领域中 ，网络攻击的发起者为更好地隐藏自己 ，往往会使用HTTP(超文本传输协议)或HTTPS(超文本安全传输协议)的一些特性将自身伪装成大站流量以躲避检测。由于恶意流量和网络正常访问的流量具有非常高的相似性，非常容易绕过常规检测设备的流量预处理机制，造成大量的漏报产生。如何实现对可疑流量高效精准的识别，已经成为了亟需解决的技术问题。

[0002] In the field of signaling security of networks, the initiators of network attacks, in order to hide themselves better, often use some features of HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol Secure) to disguise themselves as large site traffic to avoid detection. Due to the high similarity between malicious traffic and normal network access traffic, it is very easy to bypass the traffic pre-processing mechanism of conventional detection devices, resulting in a large number of missed reports. How to realize efficient and accurate identification of suspicious traffic has become an urgent technical problem.

It also mentions domain borrowing by name:

[0090] 本发明上述实施例所提供的可疑流量识别方法、装置、设备和存储介质，在白名单过滤机制中，不是单纯IP或域名过滤，而是使用域名以及返回(对应的)IP地址为对象进行过滤，有效避免了伪装HTTP HOST或者Domain Borrowing等类型的恶意流量绕过流量预过滤系统。

[0090] The method, apparatus, device, and storage medium for recognizing suspicious traffic provided in the above embodiments of the present invention, in the whitelist filtering mechanism, instead of pure IP or domain name filtering, the domain name as well as the returned (corresponding) IP address are used as objects to be filtered, which effectively avoids the bypassing of malicious traffic of the type of masquerading as HTTP HOST or Domain Borrowing, etc., by the traffic pre-filtering system.

from bbs.

The workflow of SNI Proxy is roughly as follows:

    Parse the TLS/SSL handshake messages in the incoming connection to obtain the SNI domain name information sent by the client.

    Check whether the domain name is in the allowed list (or enable_all_hosts). If not, the connection will be interrupted. Otherwise, continue.

    Use system DNS to resolve the SNI domain name to obtain the IP address (that is, the origin server IP address of the domain name).
    Forward traffic to the origin site of the domain name

    IP:443, for data transmission between the client and the origin server (i.e. TCP relay/port forwarding).

Do we have any evidence supporting the hypothesis on sniproxyv3?

In our research paper on shadow-tls we did an experiments on almost the exact attack described above. Our data shows that out of 472K <SNI,IP> tuples (from 27M TLS connections over 24 hours), SNI of 6K of them does not resolve, and 325K of them is connecting to IPs that are not in the A record. Among these 325K, 4K failed TLS handshake with original IP and 2K failed TLS handshake with resolved IP. Their intersections contains 1K SNIs which made up 315K out of 27M (1.1%). Based on which we conclude this attack will be introducing too much collateral damage and is therefore not feasible.

On the other hand, it should be easy to verify. But I wouldn't be surprised to learn they are really doing this to crackdown ShadowTLS-like SNI-masked circumvention tools, since censors often have different tolerance on collateral damages from ours (in academia). It is completely possible for censors to see all TLS connections to "hidden servers" as illegal.

from bbs.

Thank you. That's an interesting detail about the SNI proxy. Forcing a connection to an IP address actually associated with the external SNI could defeat some forms of TLS-based circumvention.

I and some colleagues wrote about SNI proxies discovered in the wild in 2016.

from bbs.