Comment by mrinfinitiesx | Hacker News Reader

Comment by mrinfinitiesx | Hacker News Reader

Openvpn / Wireguard service is preferable, but for free: https://github.com/DNSCrypt/dnscrypt-proxy

sudo apt install dnscrypt-proxy

sudo systemctl enable dnscrypt-proxy (or system service dnscrypt-proxy start|enable)

sudo mv /etc/resolv.conf ~/resolv.conf.bak

sudo rm /etc/resolv.conf

sudo nano /etc/resolv.conf

nameserver 127.0.0.1

#back up to dns over plaintext not recomennded if your dnscrypt-proxy service stops for whatever reason (enable in systemd, too lazy to write here)

#nameserver 1.1.1.1

sudo chattr +i /etc/resolv.conf

Always use DoH / DoT (DNS over HTTPS / TLS)

in firefox, settings -> DNS in search select Max protection choose NexDNS, make a NexDNS account for further privacy/setting up your local DNS restrictions like ad/tracker blocks

or use cloudflare.

Cheap VPS proxy:

on a VPS, do said dnscrypt-proxy

ssh -D 8080 -i ~/.ssh/sshkey username@vps.server (always use SSH key auth, no passwords)

in firefox, set up proxy 127.0.0.1 8080 select 'Use DNS through proxy' - can set proxy settings at OS level to use DNS.

There's some options for you. Tailscale works, haven't tried it though.

Both openvpn and wireguard protocols are trivially blocked by DPI. Why do people make custom protocols today? Everybody should use something standard and indistinguishable, like QUIC, DTLS or TLS1.3, for their transport layer.

makes me think of the Harvard kid that called in a bomb threat via Tor -- and was the only one on campus using Tor.

so even though that stream was itself encrypted, it was trivially easy to track down that one guy and tie it to him.

I’ve never heard this story but it made me think of this old XKCD[0].

[0]: https://xkcd.com/1105/

Correct me if I'm wrong but I don't think any ISP does DPI for mass censorship, that would be way to expensive

Russia and China uses DPI, although they often use relatively simple heuristics (like matching a SNI in the beginning of a TLS session).

> wireguard protocols are trivially blocked by DPI

There's at least 2 or more different efforts to make WireGuard DPI resistant. Ex: https://github.com/database64128/swgp-go

Interestingly, Cloudflare (and Apple?) have begun switching to MASQUE: https://blog.cloudflare.com/zero-trust-warp-with-a-masque

> Everybody should use something standard ... like QUIC, DTLS or TLS1.3, for their transport layer.

Very common for anti-censorship tools (V2Ray, XRay, Clash, Hysteria, Trojan, uTLS, Snowflake, SingBox, Outline etc) to use these.

The first project (swgp-go) which makes traffic resemble random noise, can be trivially blocked. The DPI calculates the ratio between number of 0 and 1 bits, and if their amount is approximately equal, and traffic doesn't match allowed protocol (like HTTPS), then the connection is blocked.

If you don't want to stand out you should use steganography and masquerade as a legitimate and popular protocol. It seems that MASQUE does exactly this.

HTTP/3 is QUIC. So you can tunnel whatever you want over a connection that is not reliably distinguishable from HTTPS. (You can do heuristics based on packet sizes and timings)

Much more effective, really. I built one such self-hostable proxy on Cloudflare Workers & Deno Deploy: https://github.com/serverless-proxy/serverless-proxy (http-tunneling only works on Deno Deploy, and requires an enterprise plan on Cloudflare but tunneling with websockets works on the free plan, as well).

My observation is that if you use a tunnel not for VPN (which typically uses one long connection) but for a SOCKS proxy (which requires a new connection for every proxied connection) then the timings strongly resemble real HTTPS timings.

Observation as in observed and tested, or observation as in a speculation?

> something standard and indistinguishable, like QUIC, DTLS or TLS1.3, for their transport layer.

Exactly this does exist, search for xray / xtls-reality.

A node pretends to be a valid web site, with a valid third-party TLS certificate (like a CDN node serving that website), until a correct secret key is presented, then it looks like regular TLS-encrypted web traffic.

E.g. https://github.com/XTLS/Xray-core — most documentation, sadly but expectedly, is in Chinese and Russian, because these folks seem to need this most.

I actually did some fiddling with Wireshark, and it looks to me that it should be easy to make a tunnel masquerading as TLS 1.3 in Python. Firefox's TLS requests mostly look the same except for several fields (like RandomId, SessionId, SNI) and it is easy to write a tunnel in Python that would send similar initial packets (so that they look exactly like the ones sent by the browser), and after pretending to setup a TLS session, incapsulate real traffic as TLS Application Data records. You don't need to implement real TLS protocol, you just need to make several initial packets by template.

The project you mentioned seems to be pretty complicated; I think it is possible to implement the tunnel in a single Python file without any external libraries. But I was not intending to implement any serious crypto, just masquerade traffic.

Yes, I saw that project and even the English documentation is not easy to read.

Yes, Xray does more than just making the traffic look like typical web traffic. It also makes the open VPN server port look exactly like a port serving a legitimate third-party site, with the proper TLS certificate and all. Put it on port 443, make it proxy something like samsung.com or whatever else your censors find inoffensive.

This protects the VPN node from being blocked after a port scan, and gives you plausible deniability: "Yes, I have visited this IP. Let's open it. Ah, I just wanted to look at the newest Samsung phone model."

> Both openvpn and wireguard protocols are trivially blocked by DPI.

Not so trivially as it seems. I use wireguard from Russia despite their efforts to block it. It needs some tricks to connect, but it works. I believe that openvpn will work too with those tricks.

> Everybody should use something standard and indistinguishable, like QUIC, DTLS or TLS1.3, for their transport layer.

Let them first learn how to block wireguard properly. No point to show them the full scale of the problem they face, so they could get more funding. :)

On a more serious note, it is whack-the-mole game, the idea that sounds like "everybody should use X" for some value of X is not a good idea. Everybody should look for their own way to bypass censorship, and they should do it with as much creativity and tech skills as they have.

Could you point me in the direction of said tricks please as I am having trouble getting a connection out of the RF ?

You can start with studying research work about Chinese firewall to get the idea how DPI usually works [1]. Then you can start up a Wireshark and try sending different packets and see which are blocked and which pass through, or experiment with modifying VPN packets to make them pass through.

To experiment with this you need to buy a VPS abroad.

If you don't want to do that then you can search for existing utilities like: GoodbyeDPI, XRay/reality, AmneziaVPN etc.

[1] https://gfw.report/publications/usenixsecurity23/en/

Good paper, thanks for the link.

Wireguard connection starts with an UDP datagram starting with bytes 1, 0, 0, 0 if I am not making a mistake, so it can be easily detected by DPI unless you apply some "tricks". Of course I understand that you can use you own version of protocol where these values are changed.

> Both openvpn and wireguard protocols are trivially blocked by DPI.

I don't understand why this matters, it's not like your ISP will ever block this kind of traffic since every company that has any form of IT department uses some form of VPN making it not only a legitimate kind of traffic but also quite common.

I'd think that companies use commercial grade internet, and normal people use residential internet. If so, then it would be easy to imagine that the ISP blocks some features for the residential subscriptions.

Most companies certainly won't be using "commercial grade internet" in the way that term is usually used. That would usually be reserved for large enterprises, which really only covers a small part of the workforce in practice.

Many businesses don't bother even subscribing to a business package, because something like a static IP is unnecessary for them.

Further, the point regarding VPNs still stands -- think of the chaos it would cause for many people working from home (on residential connections). And that's just one example.

I don't find it plausible for an ISP to block this.

Actually, there is "commercial grade internet" at least in my country. The main difference is that it is several times more expensive, and in the office buildings the owner doesn't allow ISPs with cheaper "residential" plans.

Business, yes, that was the word I was looking for, thanks! So the ISP could just limit the residential packages, limit the business packages to actual businesses, and that's all.

I don't see obscuring DNS queries as that useful when you just go ahead and connect to the server you wanted the address of directly anyway.

> sudo chattr +i /etc/resolv.conf

Why that?

That makes the file immutable - when your network manager tries to rewrite the file because you reconnected to your wifi, it can't.

Reply on news.ycombinator.com