Hacker News Reader

Comment by tiatia | Hacker News Reader

China does a good job in what it intends to do.

Most non-Chinese IP websites are not blocked but traffic gets slowed down by factor 40. I have an offshore webserver. A ping suggests a 50% packet loss.

Often you can access foreign websites. At least sometimes. Some days even gmail does work. Everything works sometimes or a little bit and or is unbelievable slow.

What I never understood with my self build SSH proxy VPN: China seems to be able to sniff on it. Facebook and Google were most of the time not working, even with the proxy. Maybe the 50% packet loss makes their websites non functional.

I just bought Astill VPN and for now I must say they are doing a tremendous job.

View on HN

> A ping suggests a 50% packet loss.

This likely caused by the limited peering arrangements of your host. I rent ~10 virtual private servers outside China, and ping times vary between 90ms ('best' provider) to 500ms ('worst' provider). Packet loss varies over time, but has never been an issue with > half of the providers.

> What I never understood with my self build SSH proxy VPN: China seems to be able to sniff on it.

Were you using an HTTP proxy (e.g. forwarding a local port to squid running on your VPS) or a SOCKS proxy (just using the SSH command to act as a socks proxy)? If the latter, then your DNS queries would still be resolved locally (probably by your ISP's DNS server and, even if using an external DNS server, subject to MITM).

No. I use DNS via my SSH proxy

##Preference Name Status Type Value

network.proxy.socks_remote_dns user set boolean true

Hmm... perhaps malware on the client? I can't imagine your SSH connection is being MITM'd.

> What I never understood with my self build SSH proxy VPN: China seems to be able to sniff on it.

There's two possibilities that I can see; you were letting your DNS requests leak and they were being poisoned, or they were doing a direct MITM hijack of your SSH session. Neither is particularly comforting, but it's fairly easy to work out which if either is going on.

How do I figure this out?

I resolve my DNS through my proxy.

##Preference Name Status Type Value network.proxy.socks_remote_dns user set boolean true

The SSH one is probably easiest to detect. When you first connect to a session the public key fingerprint of the server is saved in your ~/.ssh/known_hosts file. If you can verify this out of band somehow actually is the correct fingerprint (call a friend and ask them to connect and get it), then chances are it's not being tampered with. Essentially it would have had to have happened the first time you connected to the server, and every single time afterwards else OpenSSH makes it very, very clear you've been hijacked.

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
    @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!  @
    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
     
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Yeah. So if you don't remember seeing that and the fingerprint is correct, probably nobody has been tampering with the connection. Which would imply that they've either cracked the cipher and are tampering with it anyway (unlikely as hell), that your DNS requests are somehow leaking (somewhat likely) or maybe it's some sort of nocebo effect. Hard to say for certain, wireshark might be the place to go in order to find out some more about your outgoing DNS requests though.

If a person with Wireshark can figure out what you are doing, so can a nation-scale signature detection system.

Things like custom protocol handshakes will give the underlying application away. It doesn't matter if the traffic itself is encrypted.

I am from China and SSH tunnelling works perfect for me.

Where's your server? I also have issues tunneling to a UK based server

My experience is that routes to UK and Europe (at least to budget VPS providers) have high latency and often have low throughput. Try servers in Singapore, Tokyo or the USA. Even these vary in performance, depending on the peering arrangements in place. Try to find an overseas host with direct peering with PCCW or China Unicom.

Playing with the ports may help. Try 443 instead of 22

Reply on news.ycombinator.com