reality blocked !

[ghost]

Reality can be detected by something like tls sniffing in xray core, the filtering system resets the destination of the connection and if the domain in reality was an address like discord.com it connects to one of the Cloudflare's ips instead of connecting to my reality server ip . this happens for all reality addresses. The address section in the configuration is not important because it is reset by the filtering system and the new address is given based on the dns of the filtering system.

So this means goodbye reality ...

[reza04899]

i'm experiencing this too in Iran

[us254]

changing the destination of a connection would require a man-in-the-middle attack, which is a different type of interference. the connection destination is determined by the client configuration, not by the TLS handshake or any external factors. The client will establish a connection to the server specified in its configuration, and this cannot be changed by an external party without modifying the client configuration or performing a man-in-the-middle attack.

Reality tunnel is designed to protect against man-in-the-middle attacks.

1. The Reality client can distinguish between temporary trusted certificates, real certificates, and invalid certificates. So it can detect invalid certificates used in MITM attempts.

2. The initial Client Hello is forwarded to the destination website either by:

   • The Reality server rejecting it and redirecting the connection.
   • A MITM attack redirecting it.

3. In both cases, the client will receive the real certificate from the destination website, which it can validate against the configured public key.

4. If an invalid certificate is received at any point, the client will disconnect.

[Argo160]

Many thanks to @RPRX, We have had a great experiences with it for the past months. and sadly its time to say goodbye to Reality :( I believe all Iranian internet providers will follow the MCI soon.

[ghost]

changing the destination of a connection would require a man-in-the-middle attack, which is a different type of interference. the connection destination is determined by the client configuration, not by the TLS handshake or any external factors. The client will establish a connection to the server specified in its configuration, and this cannot be changed by an external party without modifying the client configuration or performing a man-in-the-middle attack.

Reality tunnel is designed to protect against man-in-the-middle attacks.

1. The Reality client can distinguish between temporary trusted certificates, real certificates, and invalid certificates. So it can detect invalid certificates used in MITM attempts.

2. The initial Client Hello is forwarded to the destination website either by:

   • The Reality server rejecting it and redirecting the connection.
   • A MITM attack redirecting it.
3. In both cases, the client will receive the real certificate from the destination website, which it can validate against the configured public key.
4. If an invalid certificate is received at any point, the client will disconnect.

This is not MITM and sniffing in xray core also resets the destination of the connection.

https://xtls.github.io/en/config/inbound.html#sniffingobject

If your ip is 1.2.3.4 and you send a discord.com request to it, filtering system can recognize that the domain is discord.com and change the address to another ip based on the dns of the filtering system (which is Cloudflare's ip for Discord).

But even if it changes to the ip of the filtering system, it is not just MITM. For example, let's say that you created a dokodemo-door on port 443 of your server to a cloudflare ip, if you change the dns result and open discord.com with your own ip, is this MITM ? No, that's what dest does in reality

[amir-devman]

@internetfreedomir @Argo160 Your problem is with configuration, I had that blocking for a few days but after changing everything about my config such as Public Key, Private Key, ShortId, IP address, and SNI fixed everything and no more detection, you should not steal SNI from anyone.

What I mean by "not steal" is that you need to have a website with SSL on port 8443 and use "dest" to your 8443, so that when you use your domain on a browser with port 443 (which is the default) you see your website and when you use reality config with 443 you use reality. I'm pretty sure that this works on MCI and prevents it from getting blocked. you're just using an old configuration which is somehow flagged and detectable by MCI's firewall.

Long story short, change everything, and don't use any public SNI like www.speedtest.net or anyone else's. you don't get blocked anymore. Don't even use graylisted SNIs even once, you need to have a fully fresh configuration.

[ghost]

Exactly, filtering system is sniffing and resetting the destination of the connection.

In this way that you said, reality can be connected to your domain because when the filtering system resets the destination of the connection, the new IP address will be your IP because the DNS record is to your IP even in the DNS of the filtering system.

But this is not what reality was created for, because reality was created to use domains in the whitelist to bypass the restrictions of SNIs that are not in the whitelist.

So goodbye reality ...

[ashad765]

But this is not what reality was created for, because reality was created to use domains in the whitelist to bypass the restrictions of SNIs that are not in the whitelist.

According to official document the main goal of Reality is to eliminate the detectable TLS fingerprint on the server side, while still maintain the forward secrecy and guard against the certificate chain attack. Reality is just a more secure replacement for TLS security layer and it can't replace domain fronting to solve SNI whitelist problem.

[RPRX]

Exactly, filtering system is sniffing and resetting the destination of the connection.

这样做理论上可行，但可能会导致正常应用出问题，并且痕迹会比较明显，截至目前有伊朗 GFW 部署了该策略的迹象吗？

[us254]

the filtering system resets the destination of the connection.

• Leaving Noticeable Traces: This approach leaves traces because when the GFW resets a connection, it typically sends a reset packet (RST) to both the source and destination IP addresses. Network analysts and savvy internet users can identify these unusual reset packets by monitoring their network traffic. These RST packets, especially if they occur frequently and in patterns, can serve as a clear trace of GFW's interference.

[us254]

@internetfreedomir

1. Detection: GFW must first identify that the traffic is using the reality protocol, which may be disguised as normal web traffic.

2. Redirection/Blocking: After the GFW detects the reality traffic, it may then attempt to block or redirect this traffic. Redirection here means sending the traffic to a different destination than intended, which is effectively a form of blocking.

So, in this scenario, detection is the process of the GFW recognizing reality traffic, and the subsequent redirection or rerouting is the GFW taking action to block the detected traffic. The GFW would not reroute all web traffic, only the traffic it has identified as unwanted or non-compliant with its regulations.

The redirection to a Cloudflare IP or any other IP is a step that happens post-detection, as part of the blocking or interference process.

[Fangliding]

dup

[mmmray]

@Fangliding I think despite the generic title, this thread discusses a very specific theory on how IR GFW interferes with REALITY, it is not a general "news" thread about internet in Iran. I suggest to reopen and move to discussion as a separate thread.

@us254

Detection: GFW must first identify that the traffic is using the reality protocol, which may be disguised as normal web traffic.

This proposed attack does not require the censor to detect REALITY traffic at all, the censor can perform the rerouting on suspicion alone. Let's say IR GFW really interferes with all TLS connections in such a way that destination IP is always replaced with the DNS result of the sniffed SNI:

• for regular websites, this rerouting has a high chance of not breaking the browsing experience at all, because most of the time, dns_lookup(SNI) === dest ip (and when they are not totally equal, the dest ip being substituted with another DNS result is likely fine for the user). There are still a lot of connections where this does not hold true, as RPRX points out, but I would argue that IR GFW has a very high tolerance for collateral damage. For example, I have previously observed that Irancell simply injects RST packets for all TLS connections that do not have an SNI.
• for REALITY servers that steal somebody else's website, this rerouting is almost guaranteed to break the tunnel.

Still, there is no indication that this attack is actually implemented, and it would still be fairly obvious to researchers if it was done indiscriminately.

[Fangliding]

@Fangliding I think despite the generic title, this thread discusses a very specific theory on how IR GFW interferes with REALITY, it is not a general "news" thread about internet in Iran. I suggest to reopen and move to discussion as a separate thread.

@us254

Detection: GFW must first identify that the traffic is using the reality protocol, which may be disguised as normal web traffic.

This proposed attack does not require the censor to detect REALITY traffic at all, the censor can perform the rerouting on suspicion alone. Let's say IR GFW really interferes with all TLS connections in such a way that destination IP is always replaced with the DNS result of the sniffed SNI:

• for regular websites, this rerouting has a high chance of not breaking the browsing experience at all, because most of the time, dns_lookup(SNI) === dest ip (and when they are not totally equal, the dest ip being substituted with another DNS result is likely fine for the user). There are still a lot of connections where this does not hold true, as RPRX points out, but I would argue that IR GFW has a very high tolerance for collateral damage. For example, I have previously observed that Irancell simply injects RST packets for all TLS connections that do not have an SNI.
• for REALITY servers that steal somebody else's website, this rerouting is almost guaranteed to break the tunnel.

Still, there is no indication that this attack is actually implemented, and it would still be fairly obvious to researchers if it was done indiscriminately.

I( and many other people ) were noticed this issue since reality or even earlier projects with similar ideas were proposed. The answer is, this question is inevitable, so I don't think it's necessary to continue discussing it