It's clever. It tries to defeat attacks against one of the tougher parts of VPN connections to reliably obfuscate, and the effort's commendable, but I'll stop short of saying it's a good solution for one big reason: with VPNs and censorship circumvention, the data often speaks for itself.
A VPN provider working in this space will often have aggregate (and obviously anonymized, if they're working in good faith) stats about success rates and failure classes encountered from clients connecting to their nodes. Where I worked, we didn't publish this information. I'm not sure where Mullvad stands on this right now.
In any case -- some VPN providers deploying new technology like this will partner with the research community (because there's a small, but passionate formal research community in this space!) and publish papers, studies, and other digests of their findings. Keep an eye out for this sort of stuff. UMD's Breakerspace in the US in particular had some extremely clever people working on this stuff when I was involved in the industry.
The way they describe it makes it sort of sound like split tunneling and geotunneling can be done with DNS.
Of course, https://xkcd.com/538/ applies in full force, and I don't have any background in the space to make this a recommendation!
Your solution could technically work over any kind of open connection / data transfer protocol that isn't blocked by the provider but it would be an absolute pain to browse the web that way and there are probably better solutions out there.
It's also probably more useful to just have a connection be fully dedicated to a VPN, and have the traffic volume over time mimic what you'd see in a video, rather than embedding it in a video -- thanks to letsencrypt, much of the web's served over TLS these days (asterisks for countries like KZ and TM which force the use of a state-sponsored CA), so going to great lengths to embed your VPN in a video isn't really practical.
- Host on a piece of infrastructure that's so big that you can't effectively block it without causing a major internet outage (think: S3, Cloudflare R2, etc). Bonus points if you can leverage something like ECH (ex-ESNI) to make it harder to identify a single bucket or subdomain.
- Keep spawning new domains and subdomains to distribute your binaries.
There are complications with both approaches. Some countries block ECH outright. Some have no problem shutting the internet down wholesale for a little bit. The domain-hopping approach presents challenges w/r/t establishing trust (though not insurmountable ones, much of the time).
These are thing that have to be judged and balanced on a case-by-case basis, and having partners on the ground in these places really helps reduce risk to users trying to connect from these places, but then you have to be very careful talking to then since they could themselves get in trouble for trying to organize a VPN distribution network with you. It's layers on layers, and at some point it helps to just have someone on the team with a background in working with people in vulnerable sectors and someone else from a global affairs and policy background to try and keep things as safe as they can be for people living under these regimes.
> - Host on a piece of infrastructure that's so big that you can't effectively block it without causing a major internet outage (think: S3, Cloudflare R2, etc).
How can one bounce VPN traffic through S3? Or are you just talking about hosting client software, ingress IP address lists, etc?
There are some more niche techniques that are _really_ cool but haven't gained widespread adoption, too, like refractive routing. The logistics of getting that working are particularly challenging since you need a willing partner who'll undermine some of their trustworthiness with some actors to support (what is, normally, to them) your project.
hopefully ECH will catch on. I suspect the corporate backlash over domain fronting was them not wanting to be caught in the crossfire if their domain was used as a front. if e.g. Signal used "giphy.com" as a front, Russia might block giphy to block Signal. but if Signal is hosted on, say, AWS, and ECH was used, Russia would have no option other than blocking the entirety of AWS, since all TLS handshakes to AWS would look the same.
though cloud providers (other than CloudFlare, respect!) don't seem to care about censorship or surveillance anymore, and might decline to adopt ECH if some lucrative market complains.
for instance AWS hosted things in China are typically just severly throttled and flaky. Github is the best example. it works but webpage assets often either dont load or load incredibly slowly. this pushes people to local services without breaking the web entirely
While access to plaintext is useful, it's not required for other rules which are eg looking at the timing and frequency of packets.
The main one is called an Eclipse Attack in cyber circles, and it can be done at any entity operating at the ASN layer so long as they can position themselves to relay your traffic.
The adversary can invisibly (to victim PoV) modify traffic if they have a cooperating rootPKI cert (anywhere in the ecosystem) that isn't the originating content provider, so long as they recognize the network signature (connection handshake); solely by terminating encryption early.
Without a cert, you can still listen in with traffic analysis, the fetched traffic that's already been encrypted with their key (bit for bit), as known plaintext the math quickly reduces. SNI and a few other artifacts referencing the resources/sites are not part of the encrypted payload.
Its more commonly known in a crypto context, but that kind of attack can happen anywhere. It even works against TOR. One of the first instances (afaik) was disclosed by Princeton researches in 2015, under the Raptor paper.
plus an MITM attack, if I understand correctly.
It was explained to me that its just another version of MITM, the only difference is the number of resilient paths that need to be compromised. Eclipse type of attacks focus on compromising multiple nodes and most deal with breaking consensus algorithmic based software, which is quite common of blockchain, but that isn't the only place.
TL;DR In a single path graph you have MITM, in a N-path graph of connectivity you have Eclipse. Two heads of the same coin.
Loosely I guess it would be considered an adversarial network partition at the ASN/BGP level. For active attacks you'd have to broadcast improperly, but for regional attacks at the ASN level you just have to be positioned correctly passively. That's why the whole AT&T room for the NSA back in the day was such a big deal. A lot of these attacks have been known about for a long time.
For instance, the same kind of attack could easily be done by compromising firmware within 1-step away from edge devices (Modems/Routers/ISP TFTP servers).
Quite a lot of what was in the nationstate war-chest 10 years ago has been leaked, and is actively being used by non-state actors at this point.
Its mad how sophisticated things are now. On some campuses, its not unheard of to see drones flying by to hack the radio logitech keyboards of campus computers; where they try to drop malware OTA through a powershell or tty keyboard spawned terminal prompt. Crazy stuff.
This is actually crazy indeed. At least you can still use corded keyboards or BT ones (until the day there is some 0-day on BT pairing...)
Early versions of BT that's already true. AFAIK, 4.2, 5, 6 are still safe. Though there has been a lot of activity I haven't followed this year wrt 4.2, so that may be dated.
It would be nice if one of the big shortwave operators could datacast these packages to the world as a public service.
But either way both truecrypt and veracrypt were independently audited and no major flaws were found. Not sure when the last veracrypt audit was done.
What could go wrong.
If you're not and they're still allowing your planes to fly through their airspace then this is a great way to ensure that they lock your (and your friends') planes out.
If you've already got a Linux system, the Debian openvpn package is under 1 MB and at 50 kb/s would take under 3 minutes to download. I don't know if openvpn in particular is suitable for people who are trying to evade their government, but would whatever features it is missing add substantially more size?
Seems like it was used way back in the cold war (and even then not blocked/jammed) and I'd guess that current authoritarian regimes would perhaps not bother considering how few could use it.
But they recently switched to a much cheaper and more effective jamming program: Trump [1].
[1] https://apnews.com/article/voa-radio-trump-media-cuts-5f87df...
These broadcasts were shut down in the early '10s but ironically one of the masts is still in use by Radio Caroline, the former pirate who broke the BBC's radio monopoly by putting their station just outside of UK territorial waters. Their 4 kW goes pretty far given the site's previous role, heard them as far away as the Lake District.
(1) It's usually around 11500Khz
(2) 4625 Khz
I'm not saying that makes the problem easy, but I'll say that jamming isn't a very strong defense.
Though the bigger issue here is probably bandwith. It's hard to be both long range and data dense. There's probably easier ways to distribute this. Hell, both Koreas are known to transport different things via balloons.
[0] https://en.wikipedia.org/wiki/Radio_Free_Asia
[1] It is also why projects like Tor and Signal get funding from RFA. Maybe the US doesn't want encrypted services here, but if anything, it's for the same reason they do want encrypted services in other countries.
Get your own VPS server (VPS in EU/US with 2GB of ram, 40GB of disk space and TBs/month of traffic go for $10 a year, it's that cheap). Never get anything in the UK and even USA is weird. I'd stick with EU.
Install your software (wireguard + obsfuscation or even tailscale with your own DERP server)
Another simpler alternative is just `ssh -D port` and use it as a SOCKS server. It's usually not blocked but very obvious.
Another method that usually worked was ProtonVPN with protocol set to Wireguard. Not sure why this worked, it’s definitely a lot more detectable than other methods I tried. But as long as I rotated which US server I used every few days, this worked fine.
No luck with shadowsocks, ProtonVPN “stealth” mode, Outline+Digital Ocean, or even Jump / Remote Desktop. Jump worked the longest at several hours before it became unbearably slow, I’m still not sure if I was actually throttled or my home computer started misbehaving.
I didn’t get around to setting up a pure TLS proxy, or proxying traffic through a domain that serves “legitimate” traffic, so no idea if that still works.
https://www.itnews.com.au/news/travel-esims-secretly-route-t...
IP blocks are routinely bought and sold, and hence their geo location database entries are not reliable.
If you’re physically in the EU or the UK and your traffic is routed through China it would be unusably slow and immediately noticeable to non-technical users.
Organic Maps app can download all maps for offile and works OK in China.
It uses openstreetmap data.
1024 bit RSA keys is laughable. I'm inclined to think this was not by accident.
Idea 1 and 2 are basically the same.
Can recommend. Always a little crazy, always insanely cheap. If it doesn't work out, you can just switch to another provider.
https://my.servitro.com/cart.php?a=view
https://manager.ouiheberg.com/cart.php?a=confproduct&i=0
1GB or even 512MB and 10GB of storage is very easy and completely doable to use for a VPN + HTTPS server
Traffic is super cheap nowadays.
Your real issue will be IP reputation.
https://lowendtalk.com/categories/offers
Is a good source.
Since OP is in Southeast Asia, a VPS in JP or SG will probably hit a decent balance between latency and censorship avoidance.
i know a US based tech firm i worked for around 2020 had a simple HTTPS proxy for chinese clients to download content updates. worked really well. it was hosted on some cloud provider and accessible via DNS name. so its not like it wasn't easy to block it. they just didn't bother or it was lost in a sea of other similar activities.
that all being said, regarding oppressive regimes and political turmoil situations: if your health or freedom is at risk, don't rely on internet people's 'guesswork' (hard to tell where ppl get their info from, and what its based on etc.). be careful. if you are not confident, don't go forward with it. Try to get advice from local experts instead, who are familiar in the specific context you are dealing with.
Has any government ever done that? Seems like it would just break everything (because the world is full of devices that use custom protocols!) at great computational expense.
Discussion: https://news.ycombinator.com/item?id=44958621
It's used for a lot of legitimate traffic as well, so a bit harder to block.
In which case you use stenography, but I believe even the Great Firewall of China doesn't block HTTPS completely.
I encourage you and anyone else here to read into the GFW if you're interested. It's more like the Great Firewalls -- there's regional fragmentation with different vendors, operators, implementations and rules between different parts of the country.
Predictably this means there's no one-size-fits-all solution to circumventing censorship on the Chinese internet, and research into this area's difficult since China has both the technical means to identify violations very efficiently as well as the bureaucratic infrastructure to carry out enforcement actions against a considerable portion of those people who violate the GFW rules (with enforcement action being anything from a "cooldown period" on your internet connection where you can't make any connections for some amount of time between minutes and days, fines, or imprisonment depending on the type of content you were trying to access).
So, the ethics of digging into this get very muddy, very fast.
"Nothing special" in this case was meant to describe the fact that it's random data with no identifiable patterns inherent to the data; you're absolutely right that that's what obfs4 does. I understand the confusion though, this phrasing could be better.
> your government can decide to block unknown protocols
> you should trick DPI into thinking it sees HTTPS. Unless your government decides to block HTTPS
I will say though, Operator's Replicant does something similar to what you're describing in that it can mimic unrelated protocols. It's a clever approach, unfortunately it was a bit immature when I was working in that area so the team didn't adopt it while I was around.
A github repo would be ideal really
https://mullvad.net/en/help?Feature=censorship-circumvention
https://web.archive.org/web/20250807131341/https://mullvad.n...
"Dame Rachel told BBC Newsnight: "Of course, we need age verification on VPNs - it's absolutely a loophole that needs closing and that's one of my major recommendations." - https://www.bbc.com/news/articles/cn438z3ejxyo
They phrase it as age verification, but what they mean is the VPN provider needs to provide them the client list...
But I’m curious - from your experience - how do you know the OP isn’t pretending in order to learn about new avenues to block or attack or to track down people who are trying to circumvent?
I don’t mean that as a “be careful”. You’re the expert compared to me and for all I know these are unblockable. Or maybe those doing the blocking would already know about them? So I’m interested in just understanding more.
- First things first, you have to get your hands on actual VPN software and configs. Many providers who are aware of VPN censorship and cater to these locales distribute their VPNs through hard-to-block channels and in obfuscated packages. S3 is a popular option but by no means the only one, and some VPN providers partner with local orgs who can figure out the safest and most efficient ways to distribute a VPN package in countries at risk of censorship or undergoing censorship.
- Once you've got the software, you should try to use it with an obfuscation layer.
Obfs4proxy is a popular tool here, and relies on a pre-shared key to make traffic look like nothing special. IIRC it also hides the VPN handshake. This isn't a perfectly secure model, but it's good enough to defeat most DPI setups.
Another option is Shapeshifter, from Operator (https://github.com/OperatorFoundation). Or, in general, anything that uses pluggable transports. While it's a niche technology, it's quite useful in your case.
In both cases, the VPN provider must provide support for these protocols.
- The toughest step long term is not getting caught using a VPN. By its nature, long-term statistical analysis will often reveal a VPN connection regardless of obfuscation and masking (and this approach can be cheaper to support than DPI by a state actor). I don't know the situation on the ground in Indonesia, so I won't speculate about what the best way to avoid this would be, long-term.
I will endorse Mullvad as a trustworthy and technically competent VPN provider in this niche (n.b., I do not work for them, nor have I worked for them; they were a competitor to my employer and we always respected their approach to the space).