> Keystroke obfuscation can be disabled client-side.

please never do that (in production)

if anyone half way serious tries they _will_ be able to break you encryption end find what you typed

this isn't a hypothetical niche case obfuscation mechanism, it's a people broke SSH then a fix was found case. I don't even know why you can disable it tbh.

▲

advisedwang 6 hours ago | parent | next [-]

That doesn't sound right to me. This obfuscation isn't about a side-channel on a crypto implementation, this is about literally when your keystrokes happen. In the right circumstances, keystroke timing can reduce the search space for bruteforcing a password [1] but it's overstating to describe that as broken encryption.

[1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

▲

Mystery-Machine 3 hours ago | parent [-]

THANK YOU!

I'm baffled about this "security feature". Besides from this only being relevant to timing keystrokes during the SSH session, not while typing the SSH password, I really don't understand how can someone eavesdrop on this? They'd have to have access to the client or server shell (root?) in order to be able to get the keystrokes typing speed. I've also never heard of keystroke typing speed hacking/guessing keystrokes. The odds are very low IMO to get that right.

I'd be much more scared of someone literally watching me type on my computer, where you can see/record the keys being pressed.

	▲	advisedwang 3 hours ago \| parent [-]
		Anyone who can spy on the network between the client and server can see the timing. This includes basically anyone on the same LAN as you, anyone who sets up a WiFi access point with a SSID you auto-connect to, anyone at your ISP or VPN provider, the NSA and god knows who else. And the timing is still sensitive. [1] does suggest that it can be used to significantly narrow the possible passwords you have, which could lead to a compromise. Not only that, but timing can be sensitive in other ways --- it can lead to de-anonymization by correlating with other events, it can lead to profiling of what kind of activity you are doing over ssh. So this does solve a potentially sensitive issue, it's just nuanced and not a complete security break. [1] https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

▲

lazypenguin 6 hours ago | parent | prev | next [-]

They literally explain the mechanism in the post and then explain why the security tradeoff made sense for their ssh game………

▲

eikenberry 6 hours ago | parent | prev | next [-]

It is to prevent timing attacks but there are many ssh use cases where it is 100% computer to computer communications where there is no key based timing attack possible.

▲

OneDeuxTriSeiGo 5 hours ago | parent | next [-]

There is an argument that if:

- you are listening to an SSH session between devices

- and you know what protocol is being talked over the connection (i.e. what they are talking about)

- and the protocol is reasonably predictable

then you gain enough information about the plaintext to start extracting information about the cipher and keys.

It's a non-trivial attack by all means but it's totally feasible. Especially if there's some amount of observable state about the participants being leaked by a third party source (i.e. other services hosted by the participants involved in the same protocol).

	▲	Romario77 5 hours ago \| parent \| next [-]
		this only works for manually typed text, not computer to computer communication where you can't deduce much from what is being "typed" as it's not typed but produced by a program to which every letter is the same and there is no different delay in sending some letters (as people have when typing by hand)
	▲	eikenberry 5 hours ago \| parent \| prev \| next [-]
		I agree it is more nuanced than a simple 'good for computer-to-computer' and 'bad for person-to-computer'. I'm sure there are cases where both are wrong but I don't think that necessarily changes that it makes a reasonable baseline heuristic.
	▲	Mystery-Machine 3 hours ago \| parent \| prev [-]
		I'd love to hear more about this kind of attack being exploited in the wild. I understand it's theoretically possible, but...good luck! :) You're guessing a cipher key by guessing typed characters with the only information being number of packets sent and the time they were sent at. Good luck. :)

▲

PhilipRoman 5 hours ago | parent | prev [-]

I haven't given this more than 5 seconds of thought, but wouldn't it make sense to only enable the timing attack prevention for pseudo-terminal sessions (-t)?

▲

simplicio 5 hours ago | parent | prev | next [-]

The fix seems kind of crazy though, adding so much traffic overhead to every ssh session. I assume there's a reason they didn't go that route, but on a first pass seems weird they didn't just buffer password strokes to be sent in one packet, or just add some artificial timing jitter to each keystroke.

	▲	bot403 5 hours ago \| parent \| next [-]
		I'm just guessing but this chaff sounds like it wouldn't actually change the latency or delivery of your actual keystrokes while buffering or jitter would. So the "real" keystrokes are 100% the same but the fake ones which are never seen except as network packets are what is randomized. It's actually really clever.
	▲	kevin_thibedeau 5 hours ago \| parent \| prev [-]
		SSH has no way of knowing when a password is being typed. It can happen any time within the session after SSH auth.

▲

shadowgovt 6 hours ago | parent | prev [-]

But they'd have to be on the same network as me to do that attack, right?

▲

benlivengood 5 hours ago | parent [-]

Yep, like ECHELON and friends are. The metadata recorded about your (all of our) traffic is probably enough to perform the timing attack.

	▲	shadowgovt 4 hours ago \| parent [-]
		Hey, if ECHELON snuck a listener into my house, where six devices hang out on a local router... Good for them, they're welcome to my TODO lists and vast collection of public-domain 1950s informational videos. (I wouldn't recommend switching the option off for anything that could transit the Internet or be on a LAN with untrusted devices. I am one of those old sods who doesn't believe in the max-paranoia setting for things like "my own house," especially since if I dial that knob all the way up the point is moot; they've already compromised every individual device at the max-knob setting, so a timing attack on my SSH packet speed is a waste of effort).