As obfs4 bridges don’t work anymore in Iran (since months ago), can have the circumvention technology of the snowflake in obfs4? or, can we create a snowflake private server which gives us a bridge line? or, can we give a tor snowflake client to use a specif IP instead of requesting one from the broker?
Could it be the problem of fingerprinting in obfs4 that is used for blocking?
I knew that there is a meeklite in obfs4, but I don’t know how to use it to create a server. Also, I don’t see it in tor clients bridge options.
2 Likes
Snowflake appears to be getting blocked in Iran as well.
For what purpose? What is it about conventional obfs4 bridges that is better than it is in Snowflake?
The circumvention technology of Snowflake is that there are much more of them than obfs4 bridges, and that it uses DTLS transport instead of obfs4, and ICE. I think obfs4 in general is better than DTLS, because it should be harder to block. Which is why I think the opposite (using obfs4 transport in Snowflake) would make more sense.
Again, why do you want that? Is the broker blocked?
The Snowflake technology pretty much requires you to use a broker because the proxies are ephemeral (non-static, they change quickly). And because in order to establish a WebRTC connection you and the proxy need to exchange two messages (it’s called signaling in WebRTC), so there needs to be some relatively low latency (we’re talking at most minutes) intermediary, off-band communication channel between you and the proxy.
Not sure what you mean. As far as I’m aware meek is a type of bridge that you connect to through domain-fronting, so I don’t think such bridge can be created by regular individuals. I might be not understanding it fully though.
For more about censorship in Iran you can try lurking the chat.
obfs is blocked, v2ray based/supported methods like VLESS and Trojan can connect, but they are badly throttled and we could not even open a website since a couple of weeks ago; meanwhile, Orbot and Tor with snowflake remained the only option of circumvention specially on the mobile devices.
I don’t have any evidence that Snowflake is blocked in Iran, unless there were a shutdown.
I can’t say anything about prons/cons of the “obfs4” vs “DTLS of snowflake”. What I need is to provide a snowflake private bridge for me and friends so that when the broker or stun services got blocked, we can use our bridge since it has a static IP. Indeed we want to use a private snowflake proxy that we built for ourselves and we consider it very stable and fast (since it is not run by a regular user via browser extension). We would like to take the risk of the fact that our server can be identified and got blocked after a while as we can buy another IP.
Fortunately they are working for now and we thank you all for this.
Honestly I need to rephrase my question/request here:
What is the problem with other technologies that we have here for example, comparing to Tor with Snowflake?
They are using TLS, they are using a chrom or firefox or random TLS fingerprint; but why snowflake connections did not experience and are not experiencing such a throttling?
Seconding @free-the-internet my standalone proxy is still getting 400+ connections/hour at most times except the middle of the night and the vast majority are IR.
2 Likes
Sorry, I meant that it was getting blocked, and it appears that in some cases it works, in others it doesn’t. See this issue, and chat logs: 1, 2.
Yes, it is possible to set up your own broker and make proxies and the client use it, and you can configure your own STUN servers. See The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab - there’s a README in each directory, you can configure that stuff with command line arguments. In the Tor Browser you check how the built-in Snowflake bridge line looks and modify it accordingly (“Add a bridge manually”). And you can set up a broker and a proxy on the same machine as well, if you want to.
What I think would make more sense in case of the broker getting blocked (keep in mind that the connection to it is domain-fronted) is creating a proxy that lets you reach the broker, and modifying the client’s bridge line.
Here’s a discussion about alternative broker/signaling channels.
I haven’t heard of that, so I’ll let someone else answer it. This sounds strange.
As we expected, it was a fingerprinting problem which is resolved by mimicking the Firefox, Chrome, etc ClientHello fingerprint.
Thanks, but I know that we can build the whole ecosystem ourselves, but I would like to use it in front of a VPN, by feeding the Snowflake client the IP of the proxy peer. So this should be something for example:
CLIENT SERVER
┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │
│ ◄─────────────┘ │
│ Wireguard<->Snowflake ┌─────────────► Snowflake <->Wireguard │
│ │ │ │
│ │ │ │
└────────────────────────────┘ └────────────────────────────┘
In this case since we knew the src and dest ports and IPs of the peers, we don’t need a broker, right? Something like Wireguard. Since Wireguard by itself is blocked, the intention to use Snowflake in front as a transport for it. (even we can use pure UDP instead of Wireguard because Snowflake already does encryption with DTLS)
So, in one sentence, you want a VPN-like experience, but with transport that Snowflake uses (which is DTLS (with the help of ICE)), because it’s one of the few that seems to be working alright, is that correct?
Exactly.
Besides, I think one of the good features that we have in Snowflake is the arbitrary UDP ports in both sides (NAT hole punching). So port throttling wont work for the censor and they should have hard time to consider all the ports in their monitoring system. Though I knew that for arbitrary ports, we may need more than ICE.
What I suggested (about building the infrastructure yourself) would work, as long as you can connect to the broker that you set up. The proxy that you set up to use your broker would be the only one in the pool so all the clients that are set up yo use your broker would always be matched with that proxy.
But of course, the traffic would go through Tor first. You’d need extra steps to turn it into a general censorship circumvention tool (see Snowflake as a generic TCP (UDP?) forwarder (like `ssh -L`) (#40168) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab
and Snowflake as a generic TCP (UDP?) forwarder (like `ssh -L`) (#40168) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab).
No, WebRTC (ICE, to be exact) in general doesn’t work that way. As I said:
In Snowflake, the broker is that channel. It is through signaling that the peers get to know each other’s addresses.
Maybe there is some way around it, but I’m not aware of one.
Snowflake is a network, that uses WebRTC as a transport. If you don’t need the whole network, then what you’re left with is just WebRTC, so, besides the self-hosted Snowflake infrastructure that I suggested, you can try looking up something like “WebRTC (proxy|VPN)”, and pipe whatever VPN you’re using through it. For example: GitHub - ailabstw/webrtc-socket-proxy: Peer-to-peer TCP socket proxy using WebRTC. It uses a Centrifugo server for signaling, which at least has a TLS transport.
If you want to get rid of signaling, then your option is looking up something like “DTLS (proxy|VPN)”, e.g. 1 or 2.
The WebRTC library that Snowflake uses is called Pion. Here’s its DTLS library: GitHub - pion/dtls: DTLS 1.2 Server/Client implementation for Go.
Not sure what you meant here. ICE is exactly what’s responsible for ports in WebRTC.
1 Like
Thank you for clarification and links.
This thread maybe can be a starting point for the developers, and also Tor team to focus on the current situation in Iran as new model of censorship; because I believe that this is the most aggressive censorship that ever done (except when they cut the whole Internet).
At current situation, common ports (specially 443) for overseas IPs are externally throttled that people can not even download a small PDF file from a foreign university website! Personally, I think the reason why snowflake is still working today, is the arbitrary ports that it uses for both sides.
Throttling the port 443 means that many of HTTPS/TLS based circumvention tools can not be used anymore on that port, even if you can establish a connection by bypassing TLS fingerprint filter.
Maybe one of the best things to do is to mimic the traffic (perhaps DTLS/SRTP) generated by the government based communication apps (like government based messenger, audio/video call services), which would make it hard for the censor to inspect the packets.
1 Like
I made an issue about this:
1 Like
You could start invest more on guards or relay nodes outside country then to avoid be entire things be banned ?