[santaragolabs]

Man, this paper is a classic. I love traffic analysis attacks like this. I did something myself six years back albeit with a somewhat contrived example figuring out what someone is looking at on Google Maps via request and response sizes. Example video here https://www.youtube.com/watch?v=skQNwd9Jij4 and https://ioactive.com/ssl-traffic-analysis-on-google-maps/.

I am speculating that nice traffic analysis attacks can be done on mosh (which is a great tool btw) to, similar to the paper that is in this thread. It's been sort of on my "todo/research" list but haven't been able to sit down for a few days and mess around with it. And I'm sure that QUIC (HTTP/3) will open up some interesting avenues of attack here too.

[dingaling]

It should be fairly straightforward to defeat such analysis using ssh compression. Keystrokes and control signals are batched before transmission.

Certainly I've had 'ssh -C' in finger-memory even on LANs for well over a decade.

[santaragolabs]

Sure. But that's why my point was about mosh (https://mosh.org/). It just uses TCP+SSH for the authentication part and then it sets up an encrypted UDP-tunnel on the server-side with the mosh-client then just sending AES-256-GCM packets back and forth over UDP. To the best of my knowledge it doesn't batch anything.

And compression definitely doesn't always help as some of the attacks on TLS were only able to be done because of compression happening before encryption. Hence why we ended up with the HPACK in HTTP/2 to prevent exactly such type of attacks.

[keithwinstein]

Mosh does include random chaff and (some) timing variation and batching in an effort to weakly frustrate these kinds of keystroke information leakages -- my understanding is that we are at least as strong as SSH in this area, but would love to see any analysis either way. (We have a "frame rate" with a minimum interval in both directions, and a SEND_MINDELAY collection interval. The current values are chosen for performance and minimizing tiny packets, but could be increased or randomized.)

If necessary (or maybe in some optional supersecure mode), Mosh can afford to do much more timing variation, or even a "line-at-a-time" mode, since the client can be more aggressive about showing the predictive local echo (with the ability to correct it later) while waiting to send batches of keystrokes and for the server's reply. Or we could just do a CBR mode.

(BTW Mosh uses AES-128-OCB, not AES-256-GCM.)

[santaragolabs]

Oh wow, thanks Keith, first of all for mosh! I've been using it daily for several years now. It's been great! Second of all for clarifying and correcting me regarding the algorithm-usage. I don't know where I got it from and I must have just misremembered; it's been a while since I spent a bit of time looking at the source code (and walking away very impressed).