Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

Post reply on HN
Print view View original

371–375 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#371

Post by josephcsible »

danudey wrote: post #116
ycombinatrix wrote: post #3

You can also use TCP_CORK to reduce the number of packets without any increased latency. Disabling TCP_NODELAY would also reduce number of packets + be portable & simpler to implement - but would incur a latency penalty.

Haven't heard of TCP_CORK, very interesting. For people who don't feel like googling it: 1. You TCP_CORK a socket 2. You put data into it and the kernel buffers it 3. If you uncork the socket, or if the buffer hits MSS, the kernel sends the packet Basically, the kernel waits until it has a full packet worth of data, or until you say you don't have any more data to send, and then it sends. Sort of an extreme TCP_YESDE…

With one extra caveat. From `man 7 tcp`: "As currently implemented, there is a 200 millisecond ceiling on the time for which output is corked by TCP_CORK. If this ceiling is reached, then queued data is automatically transmitted."

Re: Why does SSH send 100 packets per keystroke?

#372

Post by OneDeuxTriSeiGo »

Romario77 wrote: post #83
OneDeuxTriSeiGo wrote: post #56

Earlier quoted context omitted.

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…

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)

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.

Re: Why does SSH send 100 packets per keystroke?

#374

Post by tracker1 »

pseudohadamard wrote: post #361
tracker1 wrote: post #328

Earlier quoted context omitted.

Serious question, why not just use websockets? AFAIK, it's effectively a TLS socket with a little bit of handshake overhead when starting. I'm literally working on a web interface I want to use for classic BBS door play... currently working on a DOS era EGA interface, and intend to do similar for PETSCII/Comodore64/128 play as well. I've got a couple rendering bugs to explore for ansis submitted that messed up in the…

Websockets is just another layer on top of TLS, so you've got the size explosion and complexity/latency of TLS and then another layer on top of that. The OP hasn't provided additional info on what the requirements are but if it's a realtime game then they'll probably be "as close to zero latency and size increase as possible (compared to unencrypted messaging)", which websockets over TLS isn't.

Unless I'm completely misunderstanding, once you "upgrade" the connection to a websocket connection, it's pretty much a bog standard TLS socket... I'm not sure what you mean by a size explosion, compared to what? As to latency or overhead, yeah there's some, but generally very minimal on anything resembling modern hardware, there are literally trillions of bytes transported over HTTPS/TLS every day from watches to super computers.

Beyond this, there are libraries and tunnels for everything under the sun, and it's one of the least likely options to see mass breakages in general given it handshakes over 443 (https). Assuming you want encryption... if you don't then use raw sockets, or websockets without https and/or raw sockets... You can use whatever you like.

Post reply on HN