How can ssh defend against timing analysis attacks?

Question

Along the lines of electrical usage revealing what TV show is playing, ssh timing attacks could reveal kinds of traffic, such as streaming video or even what specific video is being streamed. This has already been mentioned in the context of leaking information about keystrokes. I would assume the principle applies to other categories of traffic as well.

How can ssh defend against timing analysis attacks for arbitrary traffic?

Answer 1

It is true, by analyzing the timing and size of packets, one can roughly determine whether those packets were keystrokes -vs- output.

This might give some (very rough) clues as to what you were doing when signed in to that server's SSH. For example, you might be able to guess if I was using vim -vs- analyzing logs -vs- running basic commands.

But what's the benefit to the attacker? I'm not seeing much here, but it is possible.

Related: ssh login failure detection at packet level

How to defend?

1. Do you really need to?

2. Use a VPN, which provides some protection by masking whether you are connecting to SSH at all, and which SSH you are connecting to.

3. The protocol could be modified to constantly stream data so that keystrokes no longer produce a spike in packet frequency.

Answer 2

This is a huge problem with no clear resolution.

A paper published by The University of Texas at Austin covers some scenarios with mix networks (like Tor). It suggests using adaptive padding but it's not a bullet proof solution. It's still prone to analysis attacks and isn't necessarily suitable for many types of traffic because of potentially high latency costs. Adaptive padding also doesn't address weaknesses against active attackers who can, for example, watermark traffic.

Another great article published by the InfoSec Institute regarding timing analysis attacks in mix networks suggests countermeasure which don't appear bullet proof for applications like ssh.

Timing Analysis of Keystrokes and Timing Attacks on SSH lists three countermeasures for keystroke traffic specifically:

1. Send dummy packets when users are typing password
   • Signature attack will fail
   • Inter-keystroke timing information is still available to the user
   • For every keystroke, delay random time before sending out the packet
2. Randomize the timing information of the keystrokes
   • Won’t work if the attacker can monitor the user login many times and compute the average of the latencies
3. Send packets at constant rate
   • Breaks the responsiveness

For arbitrary traffic option 3 appears to be the most secure and potentially fool proof choice although it still would have high (maybe too high) costs.

End of the story appears that anything other than a uniform stream can potentially leak data about traffic.

I can't find any documentation on ssh implementing any countermeasure against timing analysis attacks.