Wait. That doesn’t matter though because I was using the ‘Spoof SNI’ feature in InviZble Pro, which automatically accepts any certificate. And I mentioned that that configuration did work in places where there was no throttling:
But I’ll test it using the addr command (+ some sni spoofing software, I don’t think that lyrebird supports the new SNI spoofing feature yet..) anyways, I think it’ll have the same effect…
You seem to like the idea that all is throttled and blocked by IP address.
I leave you alone with it. 
Ofc not, it just seems like the most logical explanation for this.
Hmmmmm, nm then, here is how literally any internet request to ‘not-whitelisted-IPs’ (not whitelisted as in the sense of they’re definitely not “prioritized“ to work without issues, however I still think that it’s some sort of throttling mechanism) looks like (so you get a better understanding of the situation…) on the whitelist-network(the ‘length’ is the byte-size, so you can see what requests go through, and which ones get blocked (requests larger than x amount, mostly, you can notice that there are 2 huge packets that somehow still come through, the first SNI packets come through, even if they’re large)):
I also tested the SNI-spoofing again and it unfortunately didn’t work… Both, IPv4 and IPv6, and also trying to cache the dns request, it didn’t make a difference, so I don’t think that the system works that way.
Have you tried setting network interface MTU to some low value and testing if it works?
Yes, it doesn’t help, too…
Hi, i apologies for a noob question, but how to properly configure sni spoofing for web tunnel bridge?
Does a regular tor browser allows this?
I was looking for the manual, but couldn’t find it anywhere
SNI spoofing isn’t yet available in the Tor Browser, it is in the main branch of lyrebird though, you can compile and use the latest version of lyrebird (This might be a bit challenging if you aren’t familiar with doing this! lyrebird is an executable that stores most of Tor’s pluggable transports) yourself to use the feature on the desktop version of Tor Browser. For it to work, after compiling, you have to add a bridge like this:
webtunnel [xxxxxx]:443 xxxxxxxxxxx url=(leave the original bridge url) ver=0.0.1 servername=(the hostname that you want to ‘pose’ as, such as google.com, etc.) utls-authority=(the original bridge hostname/url i.e. x.com) utls=hellorandomizednoalpn
Leave the original bridge line the same, add the utls, utls-authority and the servername as shown there.
To ‘compile’ and use the latest lyrebird, you have to follow the instructions to clone and compile it, as described in the repository readme. Then you have to set the ClientTransportPlugin to the lyrebird executable that you compiled in the Tor Browser torrc. You can find out where the torrc file is here (depending on your platform if it isn’t Android), add this line there:
ClientTransportPlugin obfs4 exec (the dir where you have the lyrebird executable, remove the ‘()’, too) managed
Not all bridges support SNI spoofing.
Or you can wait for the Tor Browser to officially include it in the future releases.
Have tor team considered using dnstt as transport? The software already supports tor chaining.
I believe the future of censorship evasion will be to never expose destination ip to censors, there has to be something in between, think like dnstt, xhttp, or even i2p to hide destination
All 3 softwares have one thing in common, there is a field of major obsticle between censor and destination: dns provider, cdn provider, and entire p2p darknet.
Wouldn’t it be quite suspicious if you suddenly were sending huge amounts of traffic via dns?
Don’t know about using i2p for that…
For now using domain-based bridges could be beneficial because Roskomnadzor, when it sees a circumvention connection use domains, it blocks the domain by SNI without touching the IP.
Snowflake might be the closest thing to using too-big-to-fail services (CDNs) already available for Tor, but it also uses very random IP addresses, not requiring the bridge operators to open their ports and it masks as WebRTC calling, perfect!
The Tor Project is looking into implementing Proteus, because you can tinker around with the protocol without requiring a client library update or deployment of new bridges, the one part I don’t get is how would it look. Would it be possible for users to customize the protocol themselves to connect to the bridge server? Or would you only be able to connect using the bridge operator’s set configuration?
Private bridges are probably the most reliable way to ensure that your connection to Tor won’t be blocked because of a block of manually-selected bridge lines.
I wouldn’t say so. During the big drone attack, when most of internet got throttled even on wired, my private vless self-steal server got unusable too. And it was meant to look like firesharing site, very legit looking (I wrote the site myself). That didn’t stop it from getting destroyed during that attack when censors “flipped the switch”. Only thing that fixed it was zapret with sni from whitelist (which completely defeats the point of owning your own domain or making a site to begin with)… or changing software to dnstt altogether. Vless died like it was nothing, so would webtunnel under same circumstances since it uses same core
My point is that even when something is super private and even legit looking, it’s not very stable and still susceptible to collateral damage. I don’t see future in that
Tor’s meek was closest thing to xhttp before that existed, but correct me if I’m wrong, meek is deprecated now and no longer developed?
Edit: also regarding i2p and why I think it’s viable to look into putting bunch of tor guards or bridges inside the network itself. I run i2p floodfill for nearly 5 years now and not a single time it let me down.
When tor got banned, i2p worked.
When vpns were getting banned by protocol, i2p worked.
When xray/vless/tls/https throttled into unusable state, i2p worked flawlessly.
When whitelists appeared on mobile and outside connections were severed, i2p worked too because there was something or someone who was in whitelist locally found.
Hello. So you mean there is a way to configure your network to use i2p as entry then connect through this entry to the regular Tor network? Could you share or create a manual how you do this? I use Qubes + Whonix set-up. It would be interesting if it’s possibile to implement in Qubes. I think I once saw a manual “out of the corner of my eye” on how to create i2p qube in it but unlikely that was about how to connect this qube to sys-whonix after and use it as i2p entry + Tor middle – exit nodes. Unfortunately, I am just a regular user so have no specific knowledge or skills to be able to do something like this myself.
To be clear, I2P puts almost no effort into obfuscation. The only reason it works is because it’s not very popular. If you want it to keep working, you probably want to avoid mentioning it in public. 
No, there is just way to restore vanilla tor like any other proxy which would follow into tor, it’s not practical and huge overhead and strain on few outproxies there are. What I meant is putting tor nodes inside i2p darknet so you create custom tunnel, node’s sysadmin is the one who’d have to chain it further into tor as normal after that point
My point is that even when something is super private and even legit looking, it’s not very stable and still susceptible to collateral damage.
Oh, that. Yes. A private bridge might be useful here:
Setting up private bridges just gives you more customization options. But then you also can set up a self-hosted VPN (which you can customize as you want, the VPN connection) through which you then connect to Tor, might that be less private though?
Well, it’s still supported and works, it by itself was last updated a year ago.
Sorry for intruding, IMO connecting to a private VPN then connect to Tor should have the same effect as connecting to a private Tor bridge (except from the perspective of local ISP you’re connecting to a VPN or a random data stream/HTTPS website)? Why do you consider it less private?
I don’t think you did, this is a public chat after all and it doesn’t seem like we’re getting anywhere. 
(as in finding solutions for this ticket that others couldn’t find)
Wait. The title of this ticket is: how to bypass the Russian mobile internet shutdown.
Let me list the options:
Some other options may come up or maybe I missed something. That said, if you can, it’s easier to use a wi-fi connection (public or private, you’re still using Tor though).
Wait, do Tor bridges replace the guard nodes (running as a private guard with a pluggable transport) or do they connect to guards? Getting an answer to that question would make things more clear, I don’t know about it, didn’t find it in the docs… @meskio Can you please answer this question? Thanks.
This is about VPNs in general (the following text), but the effect is-well, it depends on whether the bridge acts as a guard or does it further connect to Tor as a regular client:
It’s just that using Tor with a VPN adds an additional third party, because more parties are involved in your connection to Tor: the VPN sees your traffic (to Tor), your ISP - lots of metadata of your connection to your VPN. You’re still leaking metadata to your ISP. Having a VPN-connection with random padding might help there. Anyone who knows stuff in this field - please correct me here if I’m wrong somewhere. It depends on many factors - whether it does you more good or harm. (using Tor via a VPN or connecting directly or via a bridge, here are official docs btw)
Why? What difference between connection directly to Tor bridge and connection to Tor over VPN? Why with the last variant your ISP can get more info about your connection than when you connect to Tor directly through your ISP? On the contrary - people use a VPN before Tor to hide the fact of connection to Tor and the details of this connection. Yeah I heard that it’s better to use just bridge instead of VPN, if you can, but why connection through VPN is more dangerous than direct connection to Tor over your ISP?
Some risks are discussed here.
We first have to find out how bridges work. ↓
I can say that all of this I knew before, except the fact that VPN with its encryption cannot hide what site you’re visiting (revealing this due to patterns in encrypted traffic). But for this “adversary” should either assume what site you can visit to check what patterns this site generates or initially have a list of sites with their patterns detected. Anyway, initially, for both variants it should have both: ability and desire to do all this.
Ahh… yes, just tested tor with a bridge and it seems it would replace the guard node, so the bridge is essentially a private guard node with traffic obfuscation, and you still hop throught 3 nodes (1 bridge, 1 middle and 1 exit) before leaving tor network.
These mostly applies to consumer VPN services like Proton VPN or Mullvad, which is not what we’re discussing here, right? Since our VPN is selfhosted, VPN server seeing traffic is less of a concern, since we directly control the VPN server’s OS kernel and software… unless you mean the VPN server’s network operator (BGP AS and server hardware operators) playing dirty like what happened to jabber.ru.
Anyway I don’t think there’s a disadvantage compared to running bridge on the same server (your traffic is still routed via the same server anyway).
It might be (I’m not knowledgeable enought to comment on this matter, either), but I have not seen many VPN software with padding function. Mullvad’s DAITA, an anti traffic analysis effort that allegedly used the traffic analysis defense framework Maybenot, is the closest I can think of, but it is vendor-specific (could be different for Maybenot) and the threat model they have in mind might be different from what we need.
