14 ms·
Keystroke timing obfuscation added to ssh(1)
- kbknapp 3y agoThis makes me wonder about newer terminal emulators on maccOS like Warp[1], and if they're for example taking all input locally, and then sending it over the remote host in a single blob or not? I imagine doing so would possibly break any sort of raw-mode input being done on remote host but I'd also imagine that is a detectable situation in which you could switch into a raw keystroke feed as well. [1]: https://warp.dev https://warp.dev
- dgl 3y agoIn general once you’re connecting over SSH the connection itself is always in raw mode and then the remote host deals with its pty normally (which can be in line or raw mode). Terminals with special shell integrations usually need them installed on the remote host too (some have support that does that somewhat transparently though). This is why mosh can have better behaviour than pure SSH over high latency connections. However this feature isn’t going to apply to mosh.
- hedora 3y agoI wonder if SSH can honor line-buffered mode. It should be able to detect it, but then if it incorrectly switches to line buffering then random stuff might deadlock.
- greggsy 3y agoIf they’re designed to take in data at some baud rate, wouldn’t the blob feed in at that rate too?
- chaxor 3y agoIt's really hard for me to imagine that an app that markets "AI for your terminal" is going to be "more secure and private" than some standard Unix tool. Perhaps some very specific example of a security feature (such as protecting against timing attacks) could be protected against in a new tool, and not in the older more standard one. But it seems far more likely that many other security features would get forgotten in the newer tool, and by adding "AI" so many more attack vectors would be added. It's honestly hard to even believe in the privacy claims of warp. Almost all NLP tools in today's age seem to fall towards cloud solutions, which almost immediately makes that likelihood of privacy close to nil.
- raverbashing 3y agoIt's a nice security feature, true Though I'm curious how does the project keep working with CVS in $year, I wonder if everybody just uses git cvsimport and just forgets about CVS most of the time
- heffer 3y agoHere's an explanation: https://cvs.afresh1.com/~andrew/o/why-cvs.html https://cvs.afresh1.com/~andrew/o/why-cvs.html
- rvnx 3y agoIt seems you know the project, do you have an idea how they are financed for so many years ?
- arp242 3y agoMostly donations. https://www.openbsdfoundation.org https://www.openbsdfoundation.org has some overviews. It's a fairly small project and doesn't have too many costs, relatively speaking. Previously the main income was from selling CD sets (they intentionally limited the web download options), but they stopped doing that about 15 years ago orso.
- rvnx 3y agoThanks, very clear :)
- oofbey 3y agoThe explanation all makes sense. But the key line of “we all know cvs” is effectively exclusionary to all the other developers in the world who don’t use cvs. At some point they will need new talent which will be harder to get.
- SoftTalker 3y agoCVS isn't hard to learn; it's not a barrier for someone who's interested in working on OpenBSD in the first place.
- pipo234 3y agoMakes you wonder: why do people still use password authentication with SSH?
- eppp 3y agoWhen I ssh to a device it asks me for a user name and password. Thats probably why.
- PartiallyTyped 3y agoThey are saying, "why don't you use public key cryptograph to create an identity on the remote machine?".
- eppp 3y agoI dont see that option when I ssh to a machine. If you want better defaults then offer them. I was being deliberately obtuse but barely.
- silviot 3y agoI recommend you do set up key authentication. You'll get more convenient logins and better security. This page should document how to do it: https://www.ssh.com/academy/ssh/copy-id https://www.ssh.com/academy/ssh/copy-id
- numpad0 3y agoI suppose what the parent is saying is that's not the default. Fresh install of anything is still password and GitHub key import isn't a panacea.
- PartiallyTyped 3y agoI don't see how ssh-copy-id has anything to do with Github.
- baggy_trough 3y agoSending a packet every 20ms seems like a lot of extra traffic.
- capableweb 3y agoGuess that'd depend on how big the packet ends up being.
- gruez 3y agoTCP has an overhead of 20 bytes. I'm not sure how much openssh adds, but if it's just a keystroke I can't imagine it'd be over 64 bytes. Add those together and multiply by 50 packets per second (20ms between each packet), and it works out to a whopping 4.2kB/s.
- toast0 3y agoFortge chaff packets, sure. But aggregating keystrokes for 20 ms into one packet may save data.
- Goz3rr 3y agoI can type pretty fast (100+ WPM) but I'm sure as hell not getting multiple keystrokes into a 20ms window
- Ensorceled 3y agoOnly while you are typing and for a random time period after you stop. 50 packets per second, while I'm typing, doesn't seem like too many packets.
- baggy_trough 3y agoOK, it wasn't very clear if this was all the time or what.
- ajsnigrutin 3y agoI didn't read the code, but as I understood it, it was more like a frame rule ("imagine a bus stop..."), where your keystrokes will be delayed/buffered for a few milliseconds and then sent in regular 20ms interval bursts
- spenczar5 3y agoWhat is the threat that this mitigates?
- dharmab 3y agoAn eavesdropper cannot see the content of your keystrokes, but (previous to this feature) they could see when each keystroke is sent. If you know the target's typing patterns, you could use that data to recover their content. You could collect the target's typing patterns by getting them to type into a website you control with a Javascript enabled browsers, or from an audio recording of their typing. (Some online streamers have been hacked as of late using AI models trained to steal their passwords using the sounds of them typing on their keyboards).
- 5e92cb50239222b 3y agohttps://github.com/ggerganov/kbd-audio https://github.com/ggerganov/kbd-audio It's quite good at decoding my own typing, although I am a quite aggressive typist and that may help. I haven't tried it on others, though (honest, officer).
- donatj 3y agoI gave that a bunch of tries over the last half an hour with longer and longer training data and it never got better than random chance.
- jonchurch_ 3y agoI didnt find an article about actual hacks carried out with that technique, but here’s a HN discussion [1] from this month about a paper on the topic. From that discussion it sounds like you need to train on data captured from the actual target. Same physical keyboard in the same physical space with the same typer. Pretty wild despite those specific conditions. Very interested to know if people have actually been attacked in the wild with this and if the attackers were able to generalize it down to just make and model of a keyboard, or if they could gather enough data from a stream. [1]: https://news.ycombinator.com/item?id=37013704 https://news.ycombinator.com/item?id=37013704
- some_random 3y agoI know some people do network monitoring for hands-on-keyboard shells (presumably) by measuring packet timing, I wonder if this will mess with those detections and if so by how much.
- gcoakes 3y agoWhat non-malicious use case is there for this?
- some_random 3y agoNetwork monitoring for unauthorized/unusual access, reading more into how this works I don't think this would actually change anything, you can probably still discern scripted vs manual shells it would just be a bit harder.
- eli 3y agopresumably for checking compliance with a policy that forbids it
- cyrnel 3y agoI hope that kind of thing goes the way of other corporate efforts to break/backdoor encryption for the sake of "security". IMO, it's really the wrong way to go about security. Sure it would be nice to know if some automated script is being used to log into a machine, but better design can mean that information isn't important.
- some_random 3y agoThis has nothing to do with breaking encryption and of all the sketchy corporate surveillance tooling that's deployed for security purposes (so say nothing of HR purposes) monitoring for shells on the network seems about as benign as it comes.
- cyrnel 3y agoIt's only benign if we don't see new policies that say "everyone must disable keystroke obfuscation so we can still spy on traffic". If a company's security strategy relies on the ability to tell if a given stream of encrypted bytes is shell traffic, and that it can be fooled by timing obfuscation, they need a better strategy. Attackers won't care to follow a "no timing obfuscation" policy.
- luckystarr 3y agoSome day we have to use packets which are pre-filled by random data to hide our keystrokes in. Not quite steganography, but close. Could also be used to make traffic-analysis harder/impossible even?
- predictabl3 3y agoNym?
- DisgracePlacard 3y agohttps://nymtech.net/ https://nymtech.net/
- vngzs 3y agoSo Tor with a blockchain, and you have to pay for it? > Users pay a fee in NYM to send their data through the mixnet.
- suck-my-spez 3y agoCan’t get on board with a privacy tool if the first thing they ask you to do is to join their Telegram channel
- predictabl3 3y agoSince I'm the one that said it originally, I tend to strongly agree. I really can't stand it. Its such an absolute, unnecessary respect killer.
- pessimizer 3y agoThis reminds me of professional Bridge. They split the teams with a wall and pass their cards through a window at the same time to prevent communication through timing. https://youtube.com/watch?v=RVZLNRmO3vo https://youtube.com/watch?v=RVZLNRmO3vo
- ilc 3y agoAnd yet they cheat through the screens. https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_and_Controversies https://en.wikipedia.org/wiki/Blue_Team_(bridge)#Cheating_an... https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_scandal https://en.wikipedia.org/wiki/Fantoni_and_Nunes_cheating_sca... https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_scandal https://en.wikipedia.org/wiki/Fisher_and_Schwartz_cheating_s... And those are the ones we know about. :) As far as actually using bridge in a job interview once. I did. In bridge there's a rule where if your partner gives you a hint not via the bidding, you must take the opposite approach if logically possible. It is called "Active Ethics". I had an interviewer try to lead me by the nose to the answer way too hard, in a debugging interview. So I'd stop and check EVERYTHING I could think of first before doing what he said. I told him I was doing it after the interview, and to look up active ethics if he needed a further explanation. Got the job.
- dmazzoni 3y agoWhile I admire your ethics, I feel like a lot of technical job interviews are structured such that you're supposed to actively collaborate with the interviewer. The interviewer is allowed to give you hints or suggestions, and they're very interested in how well the candidate takes hints. And sometimes the hint can be a trick! I recently did an interview where the interviewer asked if I should use a shortcut to compare two strings, one that assumed there's only one way to normalize a string. I almost fell for it, but then I hesitated and mentioned that I was concerned about some languages where that assumption wouldn't hold. They agreed and were happy that I chose the safer approach.
- lowdest 3y agoAlso many interviews are structured so there simply won't be time to finish the exercise if you're going slow.
- PaulHoule 3y agoHow much latency does this add? Latency, particularly unpredictable latency, is one of the greatest stressors in software development work.
- TonyTrapp 3y agoIt's right there. > ...by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent...
- deleted 3y ago[deleted]
- nwsm 3y agoThis latency is predictable by design though, no?
- xpe 3y ago> Latency, particularly unpredictable latency, is one of the greatest stressors in software development work. It took me a second, but I'm pretty sure the comment above is referring to latency in the user experience; namely, the delay between a keypress and perceived result. [1] FWIW, tools like Mosh [2] go a long way towards reducing perceived latency. Mosh displays the user keypress as soon as it is registered locally (which happens without a perceptable delay). To indicate that it has not round-tripped, the character is shown in a washed-out color, last I checked. (Or maybe underlined?) After the round-trip completes, the character is displayed normally. [1] If you greatest stressor in software development is the latency of your keypresses, you sound very lucky to me. [2]: https://mosh.org https://mosh.org
- colmmacc 3y agoKeystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. Most terminal applications use buffered I/O for password entry, which is still an important security feature. In that mode, nothing is sent to the other end until the user presses return. A MiTM only "sees" one packet no matter what, and with padding they can't even infer the password length. For a time, there was rich pickings in applications that accepted passwords in unbuffered mode. Many of them doing it so that they could echo "*" symbols, character by character, as the user typed. That simple feature looks cool, and does give the user feedback ... but would leak the keystroke rate, which is the last thing you want on password entry. I hope we preserve buffered I/O for password entry, because it's still better than what ssh can do with some obfuscation. But it's great to see ssh add this, and will help protect content that can't be buffered, like shell and editor input.
- darkclouds 3y ago> Keystroke timing has been a concern for terminal I/O since the 1980s and folks were using primitive encryption with stelnet and kerberos. I had a visual basic AI addon in the 1990's that could work out who was typing at the keyboard from their typing pattern within a few minutes of typing, which kind of rendered the logon process mute. Today, that can applied to touchscreen logons by tying finger pressure patterns ie size and shape of finger contact with the touchscreen to a user, and when incorporating swipes or mouse movements in the desktop OS context, its possible to have a security app which can lock a system if someone is using a device and user account which is not theirs. At the very least you can log every time one's GF/missus has gone through your phone.
- archgoon 3y agoSpiffy! Do you remember what were you using as your model? (Btw, 'moot' not 'mute' :) )
- darkclouds 3y agoI dont know, I dont think we even had that much access to tune it so to speak, this was VB4 (1991) back then, I dont think it was a VB extension but an OCX (1994) which is OLE2/ActiveX technology. I think I got it from a 3.5" disc on the front of a computer mag from memory in the UK but it was a US company that wrote it. So there might be a copy of it in the wayback machine. It was quite simple to use, so alot of their AI decisions or tuning was probably already made for us in order for it to be put out there as an addon. But I have never seen anything since for an addon, and it seemed such a good idea in the scheme of things when it comes to computer security with all the hacking that is in the press today.
- monocasa 3y agoDoes mosh do something similar? It seems like that'd be way more effective in a protocol that's already much more tolerant of random latency spikes already.
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- Zamicol 3y agoHere's a 2008 article about a 2001(!) paper noting such timing attacks: https://lwn.net/Articles/298833/ https://lwn.net/Articles/298833/ >This weakness was outlined in a 2001 paper entitled Timing analysis of keystrokes and timing attacks on SSH" [PDF] which looked specifically at the timing-based attack: >In this paper we study users' keyboard dynamics and show that the timing information of keystrokes does leak information about the key sequences typed. Through more detailed analysis we show that the timing information leaks about 1 bit of information about the content per keystroke pair. Because the entropy of passwords is only 4-8 bits per character, this 1 bit per keystroke pair information can reveal significant information about the content typed. I thought this was fixed a long time ago and I thought there was a fix pushed around the 2012 time period. I'm totally shocked this has not been previously address.
- omeid2 3y agoLink to the actual commit: https://github.com/openssh/openssh-portable/commit/7603ba71264e7fa938325c37eca993e2fa61272f https://github.com/openssh/openssh-portable/commit/7603ba712...
- djmdjm 3y agoIt also depends on the previous one for the PING/PONG messages used to simulate keystrokes and terminal echo: https://github.com/openssh/openssh-portable/commit/dce6d80d2ed3cad2c516082682d5f6ca877ef714 https://github.com/openssh/openssh-portable/commit/dce6d80d2...