Hacker News new | past | comments | ask | show | jobs | submit login

I'm interested to see how they go about filtering VPN traffic. AFAIK, running openvpn over port 443 is pretty much indistinguishable from normal TLS traffic.



China's gotten pretty good at it.

OpenVPN running over port 443 is generally going to be using a CA that is not a public CA, and issues certificates directly rather than through an intermediate.

Even if you tunnel something over normal TLS, the type of traffic can potentially be determined by analyzing how much data flows in which direction and when.

If circumvention is seen as too widely spread, Uganda may simply decide that all TLS traffic leaving the country must be intercepted by a MitM proxy, and require everyone to trust their CA.

I'm sure there are plenty of companies that would be happy to get the contract to provide this service.

These blocks can often be circumvented by methods that do not scale, but if only tech savvy people who can afford to run their own VPN server on a VPS somewhere can circumvent the block, it's "mission accomplished".


OpenVPN traffic over TCP 443 will still be distinguishable as OpenVPN traffic, it's just a little harder.

Normal TLS handshakes over TCP typically look very similar, so if OpenVPN did those, it would be tough. But OpenVPN's TCP mode is basically just a TCP encapsulation of the UDP mode messages, and even with the new tls-crypt option enabled, the packets still contain unencrypted parts that could easily identify them as OpenVPN traffic.

As far as I can tell, if you're looking for your TCP port 443 traffic to look just like normal web traffic, you'll need to use a different protocol.


If circumvention is seen as too widely spread, Uganda may simply decide that all TLS traffic leaving the country must be intercepted by a MitM proxy, and require everyone to trust their CA.

In which case you start using stego. All you need is a tunnel to the "free world". Good luck trying to figure out whether someone's packets are saying what they're actually saying, or something else.

There is a hidden message in the above paragraph. ;-)


I feel like China is good about public/shared VPN's. If you set up your own and keep the details to yourself I was under the impression that it'd work just fine. That being said I love to travel and can work wherever but haven't been to CN yet for this reason in particular.


From what I've heard second-hand (my SO has a friend who frequently travels to China), they do actually block people's private one-off VPN servers quite effectively.

Have a look at https://www.cs.tufts.edu/comp/116/archive/fall2016/ctang.pdf - it talks about GFW using machine learning with flow analysis to do this.


Indeed they do. It starts off working fine, but then eventually it stops. I assume they're running some AI/ML against the traffic pattern to determine if it's a VPN. I think they're light-years beyond simple traffic blocking and shaping.


I took that class (comp 116) a few years ago! Just had some fun finding and rereading my own final paper from the archives (the one you linked to makes mine seem way less interesting). Ming is a really awesome and unique lecturer.


If I may ask, why pass the perfectly appropriate opportunity to... link it here?


basically, netflow analysis tools feeding into an automated pattern matching system. 100% crypto traffic no matter what looks different than usual usage patterns. The netflow tools need some time to gather enough flow statistics between your outside-china VPN endpoint and your domestic IP, but once that's gathered, it's pretty hard to get around.

tools like obfsproxy for openvpn can help.


Why do they not outright block encrypted connections which they fail to bruteforce?


That blocks a large percentage of the websites out there now.

It's probably easier to just block all AWS/Azure/Linode/DigitalOcean/etc... blocks.


If you are just visiting, the Great Firewall is not really a problem, as foreign SIM cards route directly to the internet. Just make sure you have a reasonable international plan with your carrier before you go.


This is true. My phone connected to 4g when I turned it on but then upon my first search using google now it disconnected and then reconnected to an H+ network and completed the search. It was pretty cool how they made a completely separate network for it.


With the caveat that in some countries the way data roaming works is all the data is routed back to your home before actually being routed to its destination - for example, if I visit Canada with a US T-Mobile SIM, all my traffic first has to travel to the US, even if I'm pinging a Canadian server.

If you end up with this sort of data configuration in China, you'll be having a bad time using it for anything performance-sensitive. Good enough for email though, I bet.


>OpenVPN running over port 443 is generally going to be using a CA that is not a public CA, and issues certificates directly rather than through an intermediate.

nothing preventing you from using letsencrypt.

>Even if you tunnel something over normal TLS, the type of traffic can potentially be determined by analyzing how much data flows in which direction and when.

true, but only if you're doing packets-over-TCP. if you think beyond a VPN, like a https proxy (http proxy, but over TLS), it's indistinguishable from regular https traffic.


that's until tech-savvy people make a simple script/installer for the common folk. something like what happened with the LOIC. it's a cat & mouse game and i'm willing to bet there are far more hackers outside of goverment than inside it.


How about a thought experiment, assuming you had multiple domains, obfsproxy and Let's Encrypt going how are they going to be able to tell if everything is over 443?


> analyzing how much data flows in which direction and when

Encapsulated TCP SYN packets, for example, smaller than any HTTP request inside TLS would be.

Want to beat that by padding? Everything always being the same size is an anomaly too.


So then we randomize the padding, what's next?

How else do they figure it out? My mind jumps directly to funny traffic patterns like a single person using the domain or maybe a non-normal looking website that doesn't serve static assets to non-vpn users or other normal things, etc. Can they probe the server somehow and and figure out it's a vpn?

Does the user need to visit other sites unrelated to the vpn in order to mask their own usage and appear normal?


It would be quite laborious to figure out "normal" user traffic patterns and then adjust to those. You would have to collect data on a bunch of users and then shape your own traffic to match.

Only makes sense if you are doing it for a bunch of people and at that point you are another VPN provider.


As others have said, that's not true. It's actually pretty hard to hide VPN traffic from DPI solutions. And judging by bgp.he.net, ISP market in Uganda is monopolized and censorship friendly, the government can just ask the ISPs to install DPI equipment for censorship and they will comply no questions asked.


Some VPNs go through extraordinary length for VPN over HTTP(S). It is not so trivial. Assuming that Uganda is likely buying blocking equipment from China.


Probably more like silicon valley. Bluecoat vars have been known to sell equipment to sanctioned countries and those that violate human rights.



Sure, but Iran is under embargo from the west. Uganda is not, and thus can freely buy censorship tech on the open market.


Not sure why this gets downvoted. Good luck trying OpenVPN over 80 or 443 in China.

If you want to build your own, use at least VPN that was developed in Japan. (Google)


By blocking a known set of IP addresses that belong to the most popular VPN providers or identifying these providers by traffic patterns? Surely a list of these IP addresses or technology to identify them must be floating around between the authoritarian governments.


My college Wi-Fi manages to do it... so I doubt that it can be too hard.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: