Live data from Hacker News

Why does SSH send 100 packets per keystroke?

eieio.games

291–300 of 375 posts

Re: Why does SSH send 100 packets per keystroke?

#291

I don't see how Claude helped the debugging at all. It seemed like the author knew what to do and it was more telling Claude to think about that. I've used Claude a bit and it never speaks to me like that either, "Holy Cow!" etc. It sounds more annoying than interacting with real people. Perhaps AIs are good at sensing personalities from input text and doesn't act this way with my terse prompts..

Even if the chatbot served only as a Rubber Ducky [1], that's already valuable. I've used Claude for debugging system behavior, and I kind of agree with the author. While Claude isn't always directly helpful (hallucinations remain, or at least outdated information), it helps me 1) spell out my understanding of the system (see [1]) and 2) help me keep momentum by supplying tasks. [1] https://en.wikipedia.org/wiki/Rubb…

Rubber Ducky is a terrific name for a GPT.

Also, always reminds me of Kermit singing "...you make bath time so much fun!..."

Re: Why does SSH send 100 packets per keystroke?

#292

Earlier quoted context omitted.

I think the point they're making is that "I, a seasoned network security and red-team-type person, could have done this in Wireshark without AI assistance" is neither surprising nor interesting. That'd be like saying "I, an emergency room doctor, do not need AI assistance to interpret an EKG" Consider that your expertise is atypical.

Sure, but that is aside from my original point. If somebody: a) Has the knowledge to run tcpdump or similar from the command line b) Has the ambition to document and publish their effort on the internet c) Has the ability identify and patch the target behaviors in code I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently, and would have learned more along the way. Forg…

> I argue that, had they not run to an LLM, they likely would have solved this problem more efficiently

This is just expert blindness, and objectively, measurably wrong.

Re: Why does SSH send 100 packets per keystroke?

#293

Earlier quoted context omitted.

Just think of the trees burnt in the name of security!

Each of our devices spents a lot of energy dedicated to encryption. By now, all disks you did not set up manually are most likely encrypted and hardly any unencrypted package will travel out of your network. That's not to mention the tons of load and dedicated hardware we have just to terminate https and scan traffic for suspicious activity or the hardware being replaced because it's internal security triggered/broke…

Shouldn't we sacrifice some security for convenience? And shouldn't we at least have a public discussion where to draw the line?

I already don't encrypt my Pinebook storage, because the device is low-powered.

I now disabled ObscureKeystrokeTiming on the ssh clients where it does not matter. And it should not matter in 99.9999% of cases.

P.S. There's a good reason airline frequencies are unencrypted AM and I hope IT "security" mindset does not reach its dirty hands up the air.

Re: Why does SSH send 100 packets per keystroke?

#294

Earlier quoted context omitted.

How? You can't average out the noise here because the attack involves discriminating the different types of events from one another based on the thing you'd be averaging.

One clue is that you cannot predict what key user is going to press next reliably, so the jitter would always be added to actual key press. You can minimise that by adding constant latency, so that you could simulate pulling events back in time, but still this is going to get complex quick and still could be filtered out. As for methods, it depends on the jitter. Think of things like noise removal in audio and adapti…

Okay I think I see the issue (and slight misunderstanding). I believe the problem is actually latency. I was assuming the jitter interval would be noticeably larger than the gap between typical (say 95%) of key presses. Any smaller than that and you start to need cover traffic.

Such an interval would still face correlation issues due to the varying nature of the overlap between the jitter intervals, however it seems like that should be trivial to address. That said, just throwing in some cover traffic is bound to be simpler.

But a jitter interval long enough that keystroke packets can change order is going to be noticeable to a human typing quickly on what should be a solid connection - my WiFi is only at 3 to 6 ms RTT and I already notice that versus a wired connection. That doesn't sound so trivial to fix, and once again just throwing in some cover traffic completely solves the issue.

So just do what's simple.

My next question was going to be, why on the order of 100 extra packets instead of just 1 or 2? But of course an attacker could attempt to search some set of permutations for recognizable words. So either you drown everything out (simple) or you hook a multilingual dictionary up to a key stroke delay model for your cover traffic generator (complex).

But really shouldn't this feature be implemented as some constant (low) background level of cover traffic that scales up as your typing frequency increases but caps out at some (still fairly low) rate? That seems both less likely to suffer from inadvertent leaks as well as not running afoul of the issue in the article.

Re: Why does SSH send 100 packets per keystroke?

#295

Earlier quoted context omitted.

Just think of the trees burnt in the name of security!

Each of our devices spents a lot of energy dedicated to encryption. By now, all disks you did not set up manually are most likely encrypted and hardly any unencrypted package will travel out of your network. That's not to mention the tons of load and dedicated hardware we have just to terminate https and scan traffic for suspicious activity or the hardware being replaced because it's internal security triggered/broke…

That's the judgement made with all consumption of energy. The benefits weighed against the costs.

Because of the harms of environmental change, there should be pressure placed to avoid damaging ways to generate that energy.

When people complain about the amount of energy being used, they are making the judgement on the benefits. This is subjective and people do not agree on the benefits. The argument you shouldn't do this because of the energy consumed is implicitly saying "My judgement on the worth of this supercedes yours"

Pretty soon it devolves into criticizing the energy use of things you just don't like.

A society has to accept that people have different opinions on things. That includes what it is worth using energy for.

Producing clean energy is something everyone should be able to get behind. There is a solid consensus that it would make a better world.

Re: Why does SSH send 100 packets per keystroke?

#296
post #268

Wait, go back to the first sentence: > I am working on a high-performance game that runs over ssh. The TUI for the game is created in bubbletea 1 and sent over ssh via wish. > The game is played in an 80x60 window that I update 10 times a second. I’m targeting at least 2,000 concurrent players, which means updating ~100 million cells a second. I care about performance. High performance with ssh and wish? For sure not…

The author wanted people to be able to just "ssh mygame", no? In that sense, ssh was a design requirement.

I didn't think about such throwback to the 80ies. Could be, yes. But then he cannot control the ssh option, and with 2000 users, maybe 10 would set it. I don't think so.

Re: Why does SSH send 100 packets per keystroke?

#298

Earlier quoted context omitted.

Each of our devices spents a lot of energy dedicated to encryption. By now, all disks you did not set up manually are most likely encrypted and hardly any unencrypted package will travel out of your network. That's not to mention the tons of load and dedicated hardware we have just to terminate https and scan traffic for suspicious activity or the hardware being replaced because it's internal security triggered/broke…

Shouldn't we sacrifice some security for convenience? And shouldn't we at least have a public discussion where to draw the line? I already don't encrypt my Pinebook storage, because the device is low-powered. I now disabled ObscureKeystrokeTiming on the ssh clients where it does not matter. And it should not matter in 99.9999% of cases. P.S. There's a good reason airline frequencies are unencrypted AM and I hope IT "…

Airline isn't about power consumption but rather reliability. You don't introduce failure modes to safety critical systems unless absolutely necessary.

Meanwhile the power consumption of a few extra packets or even AES on your block storage device is approximately nothing relative to the other things the device is doing. Unless the CPU or GPU is going full tilt the screen on a mobile device consumes more power than the rest of the system combined (not sure about a laptop but it's likely a similar story).

It's a bit like worrying about saving a single glass of drinking water, then turning around and hopping in the shower for an hour. Or not flushing the toilet then immediately drawing a bath.

Re: Why does SSH send 100 packets per keystroke?

#300

Well, security is the #1 consideration for SSH, but if the author doesn't need security, why use ssh? For example, "nc" (netcat) is pre-installed on all platforms where ssh is.

Depends on what kind of security. They might care about connection integrity. If a faulty (or malicious) router in-between client and server starts malforming packets, `nc` will display those malformed packets. SSH will only show you what the server intended, or nothing.
Post reply on HN