| ▲ | swiftcoder 6 hours ago |
| > Obviously forking go’s crypto library is a little scary, and I’m gonna have to do some thinking about how to maintain my little patch in a safe way This should really be upstreamed as an option on the ssh library. Its good to default to sending chaff in untrusted environments, but there are plenty of places where we might as well save the bandwidth |
|
| ▲ | reincarnate0x14 3 hours ago | parent | next [-] |
| It sort of already is. This behavior is only applied to sessions with a TTY and then the client can disable it, which is a sensible default. This specific use case is tripping it up obviously since the server knows ahead of time that the connection is not important enough to obfuscate and this isn't a typical terminal session, but in almost any other scenario there is no way to make that determination and the client expects its ObscureKeystrokeTiming to be honored. |
| |
| ▲ | CaptainNegative an hour ago | parent [-] | | What's a concrete threat model here? If you're sending data to an ssh server, you already need to trust that it's handling your input responsibly. What's the scenario where it's fine that the client doesn't know if the server is using pastebin for backing up session dumps, but it's problematic that the server tells the client that it's not accepting a certain timing obfuscation technique? | | |
| ▲ | reincarnate0x14 40 minutes ago | parent [-] | | The behavior exists to prevent a 3rd party from inferring keystrokes from active terminal sessions, which is surprisingly easy, particularly with knowledge about the user's typing speed, keyboard type, etc. The old CIA TEMPEST stuff used to make good guesses at keystrokes from the timing of AC power circuit draws for typewriters and real terminals. Someone with a laser and a nearby window can measure the vibrations in the glass from the sound of a keyboard. The problem is real and has been an OPSEC sort of consideration for a long time. The client and server themselves obviously know the contents of the communications anyway, but the client option (and default behavior) expects this protection against someone that can capture network traffic in between. If there was some server side option they'd probably also want to include some sort of warning message that the option was requested but not honored, etc. |
|
|
|
| ▲ | BoppreH 5 hours ago | parent | prev | next [-] |
| Yes, but I wouldn't be surprised if the change is rejected. The crypto library is very opinionated, you're also not allowed to configure the order of TLS cipher suites, for example. |
| |
| ▲ | mystraline 4 hours ago | parent [-] | | [flagged] | | |
| ▲ | throawayonthe 4 hours ago | parent | next [-] | | that's the point of opinionated crypto libraries, yes | |
| ▲ | JTbane 3 hours ago | parent | prev | next [-] | | Personally I like that it's secure by default. | |
| ▲ | otabdeveloper4 4 hours ago | parent | prev [-] | | Those same security guys also think that "just hope that no bad guy ever gets root access, lol" is a valid threat model analysis, so whatever. | | |
| ▲ | anonymous908213 3 hours ago | parent | next [-] | | That is a completely valid threat model analysis, though? "Just hope no bad guy ever gets into the safe" is rather the entire point of a safe. If you have a safe, in which you use the contents of the safe daily, does it make sense to lock everything inside the safe in 100 smaller safes in some kind of nesting doll scheme? Whatever marginal increase in security you might get by doing so is invalidated by the fact that you lose all utility of being able to use the things in the safe, and we already know that overburdensome security is counterproductive because if something is so secure that it becomes impossible to use, those security measures just get bypassed completely in the name of using the thing. At some level of security you have to have the freedom to use the thing you're securing. Anything that could keep a bad guy from doing anything ever would also keep the good guy, ie. you, from doing anything ever. | |
| ▲ | fwip 22 minutes ago | parent | prev [-] | | When the question is "how do I communicate securely with a third party," there's nothing you can do if the third party in question gets possessed by a demon and turns evil. (Which is what happens if an attacker has root.) |
|
|
|
|
| ▲ | gerdesj an hour ago | parent | prev | next [-] |
| "where we might as well save the bandwidth" I come from a world (yesteryear) where a computer had 1KB of RAM (ZX80). I've used links with modems rocking 1200 bps (1200 bits per second). I recall US Robotics modems getting to speeds of 56K - well that was mostly a fib worse than MS doing QA these days. Ooh I could chat with some bloke from Novell on Compuserve. In 1994ish I was asked to look into this fancy new world wide web thing on the internet. I was working at a UK military college as an IT bod, I was 24. I had a Windows 3.1 PC. I telnetted into a local VAX, then onto the X25 PAD. I used JANET to get to somewhere in the US (NIST) and from there to Switzerland to where this www thing started off. I was using telnet and WAIS and Gopher and then I was apparently using something called "www". I described this www thing as "a bit wank", which shows what a visionary I am! |
| |
| ▲ | drzaiusx11 an hour ago | parent | next [-] | | 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... | | |
| ▲ | Jedd 35 minutes ago | parent [-] | | > several 56k baud modems These were almost definitely 8k baud. | | |
| ▲ | tfvlrue 12 minutes ago | parent [-] | | In case anyone else is curious, since this is something I was always confused about until I looked it up just now: "Baud rate" refers to the symbol rate, that is the number of pulses of the analog signal per second. A signal that has two voltage states can convey two bits of information per symbol. "Bit rate" refers to the amount of digital data conveyed. If there are two states per symbol, then the baud rate and bit rate are equivalent. 56K modems used 7 bits per symbol, so the bit rate was 7x the baud rate. |
|
| |
| ▲ | quesera 28 minutes ago | parent | prev [-] | | > I've used links with modems rocking 1200 bps Yo, 300 baud, checking in. Do I hear 110? +++ATH0 |
|
|
| ▲ | Calvin02 5 hours ago | parent | prev | next [-] |
| Threats exist in both trusted and untrusted environments though. This feels like a really niche use case for SSH. Exposing this more broadly could lead to set-it-and-forget-it scenarios and ultimately make someone less secure. |
| |
|
| ▲ | eikenberry 6 hours ago | parent | prev [-] |
| +1... Given how much SSH is used for computer-to-computer communication it seems like there really should be a way to disable this when it isn't necessary. |
| |
| ▲ | mkj 5 hours ago | parent | next [-] | | It looks like it is only applied for PTY sessions, which most computer-computer connections wouldn't be using. https://github.com/openssh/openssh-portable/blob/d7950aca8ea... | |
| ▲ | jacquesm 5 hours ago | parent | prev [-] | | In practice I've never felt this was an issue. But I can see how with extremely low bandwidth devices it might be, for instance LoRa over a 40 km link into some embedded device. | | |
| ▲ | geocar 4 hours ago | parent [-] | | Hah no. Nobody is running TCP on that link, let alone SSH. | | |
| ▲ | Rebelgecko an hour ago | parent | next [-] | | Once upon a time I worked on a project where we SSH'd into a satellite for debugging and updates via your standard electronics hobbiest-tier 915mhz radio. Performance was not great but it worked and was cheap. | | |
| ▲ | jacquesm an hour ago | parent [-] | | This is still done today in the Arducopter community over similar radio links. | | |
| ▲ | drzaiusx11 42 minutes ago | parent [-] | | I haven't heard much about the ArduCopter (and ArduPilot) projects for a decade, are those projects still at it? I used to run a quadroter I made myself a while back until I crashed it in a tree and decided to find cheaper hobbies... |
|
| |
| ▲ | jacquesm 4 hours ago | parent | prev | next [-] | | https://github.com/markqvist/Reticulum and RNode would be a better match. | |
| ▲ | nomel an hour ago | parent | prev | next [-] | | what's wrong with tcp, on a crappy link, when guaranteed delivery is required? wasn't it invented when slow crappy links were the norm? | | |
| ▲ | OhMeadhbh 40 minutes ago | parent | next [-] | | Because TCP interprets packet loss as congestion and slows down. If you're already on a slow, lossy wireless link, bandwidth can rapidly fall below the usability threshold. After decades of DARPA attending IETF meetings to find solutions for this exact problem [turns out there were a lot of V4 connections over microwave links in Iraq] there are somewhat standard ways of setting options on sockets to tell the OS to consider packet loss as packet loss and to avoid slowing down as quickly. But you have to know what these options are, and I'm pretty sure the OP's requirement of having `ssh foo.com` just work be complicated by TCP implementations defaulting to the "packet loss means congestion" behavior. Hmm... now that I think about it, I'm not even sure if the control plane options were integrated into the Linux kernel (or Mac or Wintel) Life is difficult sometimes. | |
| ▲ | direwolf20 26 minutes ago | parent | prev [-] | | It will time out before your packet gets through, or it will retransmit faster than the link can send packets. |
| |
| ▲ | dsrtslnd23 3 hours ago | parent | prev [-] | | In aerial robotics, 900MHz telemetry links (like Microhard) are standard. And running SSH over them is common practice I guess. |
|
|
|
