Hacker News Reader

Comment by hendzen | Hacker News Reader

Link to the posting of the original discovery with technical details included: http://www.nsc.liu.se/~nixon/sshprobes.html

View on HN

How could such a technique actually give the firewall information pertinent to whether or not the offending site was illegal? It's like a MITM attack where they intercept the outgoing ssh connection, send seemingly arbitrary data to the ssh server on the non-Chinese internet, and then sometimes disrupt the ssh connection or allow it pass through.

What information could the response to garbage possibly convey beyond: "how does this server respond to garbage"?

How would that even help with fingerprinting, which is his suggestion? Would there even be much variation in how different sshds would respond to that? So what could you do with that information? 30% of known Tor servers use sshd version X, so let's ratchet up the frequency of RST packets for connections to servers of version X? Seems like a long shot: that would be both a sophisticated attack and have pretty hamfisted results. And how could this information be used to find open relays? Just guilt by sshd version again, since statistically machines with open relays have a tendency to run version X of sshd?

I'd like to hear a security person come and talk instead of my wild speculations.

TCP uses a 32bit sequence number that should be initially seeded to a _securely generated_ random number. As each packet is sent back and forth between endpoints, this number increments by 1. If an adversary wanted to disrupt the connection (denial of service) they could obtain the sequence number and other numbers such as the source and destination ports and spoof some packets pretending to be the real client. It would then become a race between the real and fake clients as to which packet is accepted first. There is usually over 2^40 bits of entropy that an adversary would need to know to hijack a TCP session.

If the adversary is in the middle (MITM) they can read all your traffic and obtain the required entropy in real time. In this scenario, it doesn't matter how much entropy is contained in each packet because the adversary knows that information in real time. Thus the adversary will be able to inject packets to reset/terminate the TCP session, causing a Denial of Service situation.

Cryptographic protocols including SSH and TLS are designed to solve the majority of problems that MITM adversaries can cause. The notable exception is that these protocols rely on unprotected TCP sessions. MITM adversaries are still able to reset/terminate TCP sessions (when SSH/TLS protocols are detected).

IPSec protects not only the information transmitted, but the IP packet headers as well. An Authentication Header (AH)[1] is appended and verified to ensure that packets haven't been tampered with or forged. MITM session reset/termination attacks are therefore no longer possible because forged packets will be ignored.

[1] https://en.wikipedia.org/wiki/IPsec#Authentication_Header

While IPSec would solve the technical problem using it would make blocking even easier unfortunately.

You can fairly easily spot most common protocols by seeing what they 1) Say to you without you prodding them or 2) Respond when you hit them with random data.

My guess is that they're using it as a cheap way to tell the difference between most of the common protocols. (ie. ssh vs. openvpn vs. https, etc.)

Would an outgoing ssh request be hard to discriminate from an outgoing openvpn request or an outgoing https request? I don't know enough about how the protocols work to understand.

> Would an outgoing ssh request be hard to discriminate from an outgoing openvpn request or an outgoing https request?

No. But the point probably is: it is much easier and more economic to block the receiving end once by figuring out what it is than having to scan every single outgoing connection all the time.

Seems more like a way to answer the question "Is this thing running on an ssh port really a vpn server?".

I'm guessing its not actually garbage, but something that an authorized VPN can respond to, so if you are not authorized, its garbage and you cannot give the correct response and are blocked.

So then you're theorizing that this is a whitelist approach to VPN connections. Again, this would seem really heavy-handed, since it would block the vast majority of VPN traffic. It's certainly not the case for me currently (I'm in China), but it's possible that other cities are taking that approach.

> since it would block the vast majority of VPN traffic

Which would be a problem for the Chinese government HOW?

I think those very blunt ways of identifying "unwelcome" connections and then just blocking them looks like exactly the solution a government makes that doesn't twitch an eye at re-locating thousands because they want to build a dam right there.

So far encrypted traffic was a neat way of circumventing the control, now this could be trying to just plug those holes. Even if the handshake message does not say "OpenSSH xx...." at least the protocol response to random data would give them a clue and it is (sort of) more difficult to fix on a larger scale because they could always fine-tune the finger-printing.

Instead of monitoring and analyzing all outgoing connections all the time, they just figure out where they are going and then block the destination once and for all - sounds logical and neat.

Reply on news.ycombinator.com