5 ms·

That raw keyboard events are not delivered through SSH connection is entirely expected. At its core, it is a text-only communication protocol. At the discretion

That raw keyboard events are not delivered through SSH connection is entirely expected. At its core, it is a text-only communication protocol. At the discretion of the client terminal, there could be an ANSI escape to enter mode where raw key events are delivered, akin to unbuffered input. But that is nevertheless beyond the scope of what SSH offers.

kurthr 8y ago
Yes, delivering timed key events would be a security issue.
- mehrdadn 8y ago
  Huh, why?
  - chrisseaton 8y ago
    If each interactive key stroke is sent in its own packet, then you may be able to guess which keys the user is pressing based on just the timing of packets coming in, and so guess what they are typing without decrypting the stream. https://www.usenix.org/legacy/events/sec01/full_papers/song/song.pdf https://www.usenix.org/legacy/events/sec01/full_papers/song/...
    - mehrdadn 8y ago
      But what does timestamping have to do with sending each thing in its own packet? Did you mean something else by 'timed'?
      - cryptonector 8y ago
        Exposing timing of typing in an SSH connection is pretty fatal to security. That means that ssh clients should send individual characters no more often than, e.g., 10ms, and preferably in multiples of 10ms up to 150ms (say). And they should use SSH2_MSG_IGNORE messages to pad out those packets so that attackers cannot observe the number of characters typed (I forget the details as to whether this last is workable). Including timing information in the protocol, encrypted of course, would be just fine... But the channel that carries tty session data doesn't have a protocol for conveying timing and other metadata out of band.. A protocol would have to be developed for that, or for carrying that metadata in-band, and all of that would require changes on the server side and in the pty drivers.
      - noselasd 8y ago
        You, as a malicious 3. party, captures the encrypted packets between a client and a server. You can't decrypt those packets. However if each keystroke is sent in its own packet, you note the timestamp of the packets and then you can infer which keys the user has pressed from the difference in time between the packets.
        mehrdadn 8y ago
        I get that, it's just not what I originally read the comment to mean. It sounds like you guys say "timed" to mean "sent in real-time", whereas I read it to mean "includes timestamps", that's why I was confused. (Because in my mind I think of things like "timed automata" which are automata accompanied with time variables, not automata that execute in real-time.) But otherwise yeah, that makes sense.
- Retr0spectrum 8y ago
  It is a security issue. https://www.usenix.org/conference/10th-usenix-security-symposium/timing-analysis-keystrokes-and-timing-attacks-ssh https://www.usenix.org/conference/10th-usenix-security-sympo...

kurthr 8y ago

Yes, delivering timed key events would be a security issue.

mehrdadn 8y ago
Huh, why?
- chrisseaton 8y ago
  If each interactive key stroke is sent in its own packet, then you may be able to guess which keys the user is pressing based on just the timing of packets coming in, and so guess what they are typing without decrypting the stream. https://www.usenix.org/legacy/events/sec01/full_papers/song/song.pdf https://www.usenix.org/legacy/events/sec01/full_papers/song/...
  - mehrdadn 8y ago
    But what does timestamping have to do with sending each thing in its own packet? Did you mean something else by 'timed'?
    - cryptonector 8y ago
      Exposing timing of typing in an SSH connection is pretty fatal to security. That means that ssh clients should send individual characters no more often than, e.g., 10ms, and preferably in multiples of 10ms up to 150ms (say). And they should use SSH2_MSG_IGNORE messages to pad out those packets so that attackers cannot observe the number of characters typed (I forget the details as to whether this last is workable). Including timing information in the protocol, encrypted of course, would be just fine... But the channel that carries tty session data doesn't have a protocol for conveying timing and other metadata out of band.. A protocol would have to be developed for that, or for carrying that metadata in-band, and all of that would require changes on the server side and in the pty drivers.
    - noselasd 8y ago
      You, as a malicious 3. party, captures the encrypted packets between a client and a server. You can't decrypt those packets. However if each keystroke is sent in its own packet, you note the timestamp of the packets and then you can infer which keys the user has pressed from the difference in time between the packets.
      - mehrdadn 8y ago
        I get that, it's just not what I originally read the comment to mean. It sounds like you guys say "timed" to mean "sent in real-time", whereas I read it to mean "includes timestamps", that's why I was confused. (Because in my mind I think of things like "timed automata" which are automata accompanied with time variables, not automata that execute in real-time.) But otherwise yeah, that makes sense.
Retr0spectrum 8y ago
It is a security issue. https://www.usenix.org/conference/10th-usenix-security-symposium/timing-analysis-keystrokes-and-timing-attacks-ssh https://www.usenix.org/conference/10th-usenix-security-sympo...