The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.
Why does SSH send 100 packets per keystroke?
271–280 of 375 posts
Re: Why does SSH send 100 packets per keystroke?
#272It's wonderful to see LLM's being used to increase the programming community's general quality level of work, as more things become worth doing.
Re: Why does SSH send 100 packets per keystroke?
#273The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.
Just think of the trees burnt in the name of security!
Re: Why does SSH send 100 packets per keystroke?
#274Earlier quoted context omitted.
Can you explain how TCP_CORK helps here? The chaff packets are spaced 20ms apart and sent per socket, so I don’t see how TCP_CORK could help unless it coalesced across 20ms intervals? But coalescing is clearly not an option for the intended obfuscation effect of the original feature.
It is unrelated to SSH, it is a generic TCP thing. "hello world" fits in a single TCP packet, but the kernel might end up sending one packet containing "hello" and another packet containing " world". It is completely opaque to userspace. TCP_CORK lets userspace decide when packets are dispatched. You get to control whether "hello world" is sent across 1 packet or 11 packets.
I’m aware what TCP_CORK does. I’m not seeing how it helps the situation in the post.
Ah, maybe you are saying it doesn’t help the situation in the post. That’s what I misunderstood.
Re: Why does SSH send 100 packets per keystroke?
#275Earlier quoted context omitted.
And thats a huge downside when people howl about "Encryption everywhere! ". Try debugging that shit. Thats right, debugging interfaces aren't safe, by some wellakshually security goon. You want a real fun one to debug, is a SAML login to a webapp, with internal Oauth passthrough between multiple servers. Sure, I can decrypt client-server stuff with tools, but server-server is damn near impossible. The tools that work…
I used to share that opinion but after decades in industrial automation I find myself coming down much more on the "yeah, encryption everywhere" because while many vendors do not provide good tools for debugging, that's really the problem, and we've been covering for them by being able to snoop the traffic. Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted…
Problem is, security people don't want you to MITM connections, because it's insecure (mostly to business interests). Hence stuff like certificate pinning, HSTS, DoH...
Re: Why does SSH send 100 packets per keystroke?
#276Earlier quoted context omitted.
> several 56k baud modems These were almost definitely 8k baud.
Yes, because at that time, a modem didn't actually talk to a modem over a switched analog line. Instead, line cards digitized the analog phone signal, the digital stream was then routed through the telecom network, and the converted back to analog. So the analog path was actually two short segments. The line cards digitized at 8kHz (enough for 4kHz analog bandwidth), using a logarithmic mapping (u-law? a-law?), and t…
56k relied on the TX modem to be digitally wired to the DAC that fed the analog segment of the line.
Re: Why does SSH send 100 packets per keystroke?
#277Earlier quoted context omitted.
Yes! While this post was written entirely by me, I wouldn't be surprised if I had "smoking gun" ready to go because I spent so much time debugging with Claude last night.
Serious question though, since AI seems to be so all capable and intelligent. Why wouldn't it be able to tell you the exact reason that I could tell you just by reading the title of this post on HN? It is failing even at the one thing it could probably do decently, is being a search engine.
Direct answers are often useless without building up context for them.
Re: Why does SSH send 100 packets per keystroke?
#278Earlier quoted context omitted.
Fellow old here, I had several 56k baud modems but even my USR (the best of the bunch) never got more than half way to 56k throughput. Took forever to download shit over BBS...
> several 56k baud modems These were almost definitely 8k baud.
Confusing baud and bit rates is consistent with actually being there, though.
Re: Why does SSH send 100 packets per keystroke?
#279Earlier quoted context omitted.
I used to share that opinion but after decades in industrial automation I find myself coming down much more on the "yeah, encryption everywhere" because while many vendors do not provide good tools for debugging, that's really the problem, and we've been covering for them by being able to snoop the traffic. Having to MITM a connection to snoop it is annoying, but the alternative appears to be still using unencrypted…
Problem is, security people don't want you to MITM connections, because it's insecure (mostly to business interests). Hence stuff like certificate pinning, HSTS, DoH...
If you're debugging your own equipment you should have the certificates or keys to make it work. I'm not saying that's easy in a lot of scenarios, in fact it's frequently tedious as hell. But for example there are debug tools for like DNP3 or RPC over TLS, etc that can watch the whole exchange if provided the keys and parse the SCADA traffic or JSON objects as if it was plaintext.
But this goes back to the vendors not providing better tools in the first place. We shouldn't NEED to be picking apart packet streams to prove to some jackass tech support ticket that their code is FUBAR. They're basically outsourcing support to their customer or userbase and we tolerated it because it was more expedient.
Re: Why does SSH send 100 packets per keystroke?
#280Earlier quoted context omitted.
The real analog copper lines were kind of limited to approx 28K - more or less the nyquist limit. However, the lines at the time were increasingly replaced with digital 64Kbit lines that sampled the analog tone. So, the 56k standard aligned itself to the actual sample times, and that allowed it to reach a 56k bps rate (some time/error tolerance still eats away at your bandwidth) If you never got more than 24-28k, you…
Yeah 28k sounds more closer to what I got when things were going well. I also forget if they were tracking in lower case 'k' (x1000) or upper case 'K' (x1024) units/s which obviously has an effect as well.
The lower case "k" vs upper case "K" is an abomination. The official notation is lower case "k" for 1000 and lower case "ki" for 1024. It's an abomination too, but it's the correct abomination.