3 ms·

> 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 en

> 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.

lazypenguin 9mo ago
They literally explain the mechanism in the post and then explain why the security tradeoff made sense for their ssh game………
shadowgovt 9mo ago
But they'd have to be on the same network as me to do that attack, right?
- benlivengood 9mo ago
  Yep, like ECHELON and friends are. The metadata recorded about your (all of our) traffic is probably enough to perform the timing attack.
  - shadowgovt 9mo ago
    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).
advisedwang 9mo ago
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 https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf
- Mystery-Machine 9mo ago
  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 9mo ago
    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 https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf
eikenberry 9mo ago
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 9mo ago
  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).
  - eikenberry 9mo ago
    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.
  - Romario77 9mo ago
    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)
    - OneDeuxTriSeiGo 9mo ago
      Well not necessarily. That's the thing. It's not the timing attack that makes data leak for automated/noninteractive tunnels. Well technically there is still some potential leak but the issue is more about if the data being transferred is predictable then you have the plaintext. So for a contrived example: Say I know a tunnel is transferring a sizeable dataset starting at a specific time before performing some other tasks (say a data sync before doing XYZ). I know when the connection started and I have snooped on the entire connection. I know the initial handshake and I know the exact plaintext being transferred. That's a lot of information that can be used to grind the keys being used. That then risks that you can extract whatever information that follows after your initial dataset and potentially impersonate a participant and inject your own messages. It's unlikely to be exploited in practice because it requires a very particular set of circumstances but it's essentially a modern, more expensive version of the attacks used on the enigma machines back in the day. It's unlikely to be exploited on random people but it isn't out of the realm of possibilities for targeted attacks on particularly juicy adversaries or between nation state actors.
simplicio 9mo ago
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 9mo ago
  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 9mo ago
  SSH has no way of knowing when a password is being typed. It can happen any time within the session after SSH auth.

lazypenguin 9mo ago

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

shadowgovt 9mo ago

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

benlivengood 9mo ago
Yep, like ECHELON and friends are. The metadata recorded about your (all of our) traffic is probably enough to perform the timing attack.
- shadowgovt 9mo ago
  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).

advisedwang 9mo ago

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 https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

Mystery-Machine 9mo ago
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 9mo ago
  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 https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf

eikenberry 9mo ago

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 9mo ago
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).
- eikenberry 9mo ago
  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.
- Romario77 9mo ago
  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)
  - OneDeuxTriSeiGo 9mo ago
    Well not necessarily. That's the thing. It's not the timing attack that makes data leak for automated/noninteractive tunnels. Well technically there is still some potential leak but the issue is more about if the data being transferred is predictable then you have the plaintext. So for a contrived example: Say I know a tunnel is transferring a sizeable dataset starting at a specific time before performing some other tasks (say a data sync before doing XYZ). I know when the connection started and I have snooped on the entire connection. I know the initial handshake and I know the exact plaintext being transferred. That's a lot of information that can be used to grind the keys being used. That then risks that you can extract whatever information that follows after your initial dataset and potentially impersonate a participant and inject your own messages. It's unlikely to be exploited in practice because it requires a very particular set of circumstances but it's essentially a modern, more expensive version of the attacks used on the enigma machines back in the day. It's unlikely to be exploited on random people but it isn't out of the realm of possibilities for targeted attacks on particularly juicy adversaries or between nation state actors.

simplicio 9mo ago

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 9mo ago
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 9mo ago
SSH has no way of knowing when a password is being typed. It can happen any time within the session after SSH auth.