Slashdot Mirror

Many people don't seem to think this would work. However, it definitely will in the future if it doesn't now.

Most terminal connections transmit one character per typed letter. This would be true of an ssh connection.

The main objection seems to be that the attacker doesn't know the user's typing cadence. The keyboard itself can correct for typing cadence, delaying characters slightly to create slop that can be used to make cadence irrelevant. Human typists don't get much faster than 0.2 seconds per character. A few are slightly faster, but not much. So, the keyboard just needs to hold every keypress and release it on an even tenth of a second, modified by the key specific hundredths or thousandths of a second. So, 'a' = 0.n01 seconds, 'b' = 0.n02 seconds, 'c' = 0.n03 seconds, and so on. So, each packet will be emitted at 0.n?? seconds, where the ?? provides the key that the user pressed. If the time-to-packet is consistent to the thousandths of a second then the actual message can be hacked out of the character stream by solving a simple rot-n cipher.

This just takes a high precision timer in the keyboard. It's not tough to get something working that's accurate to ten-thousandths of a second.

A normal ping of my local gateway is consistent to ten-thousandths of a second right now.

It's just a matter of time before the packet transmission delay between hitting a key and sending the key out of the network card makes this type of attack possible, if it isn't already. The article's "1 bit" of information is just a proof of concept. It would certainly be possible to tack on 8 bits of information through packet delay, as machine speeds improve.

SSH claims that they are not vulnerable to the attack largely because of the cadence issue.

http://www.ssh.org/company/newsroom/article/204/

Their analysis is unimaginative. If SSH is not vulnerable now, it will be in the future. And it's not just vulnerable to password attacks. All information typed through the terminal would be hackable.

Fortunately, there are solutions, like re-randomizing the network traffic release time at the network card. Or, randomizing single-character packet release times in the ssh code.

Ah, and yes, I could walk into my local internet cafe or library and perform a quick keyboard switch without a problem. No one's watching. No one cares.

SSH already went through the debate of timing style attacks and came out fine: http://www.ssh.org/company/newsroom/article/204/. Additionally, web forms aren't transmitted until you hit submit. So you need some interractive session to monitor to detect something like this. The article mentions telnet, which, if you're going to sniff to detect packet timing, you might as well watch the packets themselves. When you get into something that is encrypted and interractive, wouldn't there be enough random jitter from the encrypting and other data, like mouse position updates when you have remote GUI's, to make this very difficult without creating so much jitter to be obvious to the user that the keyboard is screwed up?

Implementation wise, the article lacked detail, so it's time to guess what's involved. You can't simply add a fixed number of ms to each key. What you need to do is have a timer that you are always offsetting from. Otherwise, the time that the user takes to type a key would be added on to the keystroke jitter, making it useless. Say you only watch 90 keys, giving you up to 90X, where X is some measurable time. The timer would also need to be 90X, meaning that you really have a maximum possible delay of 180X. With a CPU context switch (this is an interactive user), encryption processing, and physical network delays, I'm guessing that X would have to be several ms to be detectable. That would make the maximum time, even with only a 3ms X, over a half second in the worst case, which a user will certainly notice. Of course you can reduce the number of keys that you monitor, I picked 90 because it made the math easy and eliminated the F1-F12 keys. But anything over a couple 1/10s of a second will be noticable.

Whenever anyone asks me for a hosting recommendation, I always recommend Seagull.

No, Seagull is not an ISP. While it would be nice to have a secure ISP, you're better off using any random joker for your ISP, owning your own domain name so you can relocate it in the event your service tanks (I discuss this in Market Yourself - Tips for High-Tech Consultants) and accessing the hosting service via SSH and SCP (secure copy). Note that it does no good to only use SSH - you have to use SCP as well.

Here's a sample SCP command line, in case you can't figure it out, it's very simple but I had a hard time from the man page:

scp foo.bar crawford@www.goingware.com:.

The above places file foo.bar in the home directory of user crawford on www.goingware.com.

scp crawford@www.goingware.com:web/index.html stash

This copies index.html from directory "web" on www.goingware.com and places it in directory "stash" on the local machine.

Please read my web page on Why You Should Use Encryption

Besides being a good service, it's a small enough company to offer personal service. I've sent support email to the webmaster at 2am his time and had the problem fixed and the mail answered within the hour.

But even though it's a small service, it's not a low-quality service. They have high-performance machines, they are in a good colo facility with a high-speed connection to the backbone, they upgrade their service regularly and the webmaster, Paul Celestin, is just a damn nice guy.

I'm not sure if he still publishes it but Celestin used to produce a CDROM full of useful free source code for the Macintosh. Some of my own Mac open-source programs were on it.

These are the sites I personally have located there:

• http://www.goingware.com/ - My consulting company, GoingWare Inc. My livelihood depends on the reliability of this site.
• http://www.wordservices.org/ - Seagull hosts this public-service site for free in exchange for me placing a small banner ad on some of the pages
• http://www.geometricvisions.com/

I have a couple tips for you on checking email. I use PGP when I'm trying to be secure, but it's really not that much that I really care for complete security. But I just don't like people snooping on me, mostly I think it's none of their damn business what's in my mailbox even if it's spam.

So mostly I read my email at seagull using elm while logged in via SSH, and when my mailbox gets big, I move it to my home directory and copy it to my home machine via SCP:

goingware$ cp /usr/spool/mail/crawford ~

goingware$ echo "" /usr/spool/mail/crawford

back on my home machine:

C> pscp crawford@www.goingware.com:crawford .

It is also possible to download your email via POP with SSH via port forwarding. I describe this on the BeOS Tip Server. It doesn't seem to be responding right now but if you go to its search and enter "ssh" you'll find the tip I submitted called something like "Secure email download via ssh". The instructions have some BeOS specific items but most of what's there will work on any systems.

Don't have SSH? Try one of these:

• Nifty Telnet/SSH for Macintosh - includes a graphical SCP client!
• putty for Windows (also supports NT/Alpha) and pscp for secure copy
• CygWin - a GNU environment for Win32 - use bash, compile with GCC, a lot of linux code builds right out of the box in Cygwin
• The Secure Shell Community Site
• SSH Communications Security (commercial)

ssh is kinda an encrypted telnet, with extra features see http://www.ssh.org and http://www.openssh.org

secure shell. Here is SSH's website for more info. It encrypts your session with a remote machine.

• SSH
  
• Qt, so the remaining apprehension over KDE can be put to rest and the GNOME and KDE projects can share more code without worries over license conflicts
  
• Mainstream SCM, RAD and UML tools companies
  

i'm not a security expert, but i have had ample opportunity to ponder this and related questions. my (admittedly basic) research has led me to these conclusions.

• ssh 1.x - this is the most common ssh implementation, and when people say "ssh" this is most often what they mean. ssh 1.x clients are common, exist for most major platforms, many are very good, and some are even free.
• ssh 2.x - fixes a lot of the bugs in ssh 1.x, adds some nifty new features (like a secure ftp daemon), but i have never seen a functional ssh2 implementation. i beleive it is because of both the more stringent licensing than ssh 1.x and the fact that ssh 1.x is firmly entrenched.
• openssh uses the ssh 1.x protocols, and is completely compatible with ssh 1.x. you should not notice the difference between the two in regular usage.
• telnet over ssl - the actual telnet connection is still sending passwords in plaintext, and the ssl connection has to be made in a separate step.

some random notes:

• ssh (1.x and 2.x) allow for RSA authentication, where a public/provate keypair are used for authentication rather than passwords. clients can be set up to do authentication automatically using this method from specific hosts, based on signatures. this makes ssh a more attractive option for automated, secure transactions such as regular (up|down)ploads and updates. another useful feature of this type of authentication (as opposed to password authentication) is that other users can be given access to the ssh-protected machine, without having to distribute passwords and accounts, from certain controlled environments.
• ssh 1.x and ssh 2.x are incompatible. if you have ssh1 installed when you install ssh2, the ssh2 client will give you the option to fall back to ssh1 if the server you are connecting to is ssh1. without ssh1, however, ssh2 will complain and die. so, it seems that ssh2 only is not the way to go.
• i haven't used openssh, but it seems like a wonderful alternative to ssh. ssh has licensing issues which make it less attractive if you are a commercial entity, but free for non-commercial and educational use (use for a church's web server would probably qualify as non-commercial).

i'm not a security expert, but i have had ample opportunity to ponder this and related questions. my (admittedly basic) research has led me to these conclusions.

• ssh 1.x - this is the most common ssh implementation, and when people say "ssh" this is most often what they mean. ssh 1.x clients are common, exist for most major platforms, many are very good, and some are even free.
• ssh 2.x - fixes a lot of the bugs in ssh 1.x, adds some nifty new features (like a secure ftp daemon), but i have never seen a functional ssh2 implementation. i beleive it is because of both the more stringent licensing than ssh 1.x and the fact that ssh 1.x is firmly entrenched.
• openssh uses the ssh 1.x protocols, and is completely compatible with ssh 1.x. you should not notice the difference between the two in regular usage.
• telnet over ssl - the actual telnet connection is still sending passwords in plaintext, and the ssl connection has to be made in a separate step.

some random notes:

• ssh (1.x and 2.x) allow for RSA authentication, where a public/provate keypair are used for authentication rather than passwords. clients can be set up to do authentication automatically using this method from specific hosts, based on signatures. this makes ssh a more attractive option for automated, secure transactions such as regular (up|down)ploads and updates. another useful feature of this type of authentication (as opposed to password authentication) is that other users can be given access to the ssh-protected machine, without having to distribute passwords and accounts, from certain controlled environments.
• ssh 1.x and ssh 2.x are incompatible. if you have ssh1 installed when you install ssh2, the ssh2 client will give you the option to fall back to ssh1 if the server you are connecting to is ssh1. without ssh1, however, ssh2 will complain and die. so, it seems that ssh2 only is not the way to go.
• i haven't used openssh, but it seems like a wonderful alternative to ssh. ssh has licensing issues which make it less attractive if you are a commercial entity, but free for non-commercial and educational use (use for a church's web server would probably qualify as non-commercial).