SSH v. SRP

A reader asks, "We've all heard of SSH. My question is whether SSH is really the best option, or the only option? Many security experts and cryptographers believe SSH users may be lulled into a false sense of security, because of some outstanding security issues. An open-source project based at Stanford purports to have solved these problems."

The Stanford group claims SRP to be safe against snooping and immune to reply attacks. SRP exchanges a session key in the process of authentication, provides mutual authentication to resist dictionary attacks, offers what is supposed to be perfect forward secrecy, and does not require the server host to keep any information secure. This comparison of these two technologies should provide food for thought. Can SRP replace SSH? Does it truly offer more security? Is it the better choice? In simple terms, what are *your* thoughts?

Comments

SSH has been banged on for years

[noeld]

As the subject says ssh has been banged on for years there is now even an OpenSSH project. This is time tested.

This counts a lot in my book, even if SRP is better in some areas, how well is it going to stand up when it starts getting banged arround.

Noel

RootPrompt.org -- Nothing but Unix

Re:SSH has been banged on for years

[Furry Ice]

True, the SSH implementation has been around for a long time, and there aren't any SRP implementations that I consider high quality (more later), but this doesn't mean that one can't be written. The simple fact is that the protocol is quite simple and appears to be equivalent (if I remember, it was proven to be equivalent) to the Diffie-Hellman problem, so the mathematics are solid--have been banged on for years, one might say. However, we just need a good, pervasive implementation, which would be a good project for the community. SRP isn't encumbered by patents and provides a lot of flexibility for encryption options.

For those who don't know, SRP just verifies the identity of a user to a server and, optionally, the server to the user. However, the process of this verification also _securely_ produces a shared symmetric key at both ends of the connection which can then be used to encrypt the rest of the session using a cipher of choice. Encryption is optional, if only secure authentication is required.

It's time we stop letting the fact that there aren't well ironed implementations of the protocol prevent us from using it. The main problem with the existing implemenatations from Stanford is that they require too many changes to the system (su, login, passwd, and some others) all have to be replaced with SRP aware versions, and yet another password file has to be created (/etc/tpasswd). PAM can probably relieve some of these problems (there used to be an SRP PAM module--is it still around?), but most of the difficulty with SRP lies in integrating it with your system. If we worked on simplifying this a bit, it could potentially be a very good solution.

Security

[jd]

Here is a crude list of the various options. It's not complete, and it's not meant to be. The opinions I express are my own - I bought them for 5 cents each at the corner market.

• SSH 1.x - Offers a nice, basic, secure link to a computer. There have been claims of buffer overruns, for some versions, but these have either been fixed or don't exist.
• SSH 2.x - A supposedly less restricted version of the above, but with a licence that makes me wonder. Still, it's a very nice security package.
• OpenSSH - A genuinely Open Source clone of SSH 1.x.
• LSH - A genuinely Open Source clone of SSH 2.x
• Kerberos - A serious network-buster, by all accounts. The overhead is high. On the other hand, the logo is cool, and it has been stress-tested.
• NIST IPSec - Would you trust a Government-produced encryption package? Besides, it's way out of date and the maintainers would make snails look like international sprinters.
• FreeS/WAN IPSec - Encrypt ALL your connections irrespective of the package you're using. VERY nice and VERY powerful. Needs to be installed at both ends, but that's true of all software, really.
• EnSKIP - Same as IPSec, comes with the International Kernel Patches. Faster encryption than IPSec, in some cases. The original EnSKIP code isn't maintained, so I hope the kerneli people are doing something with it.
• TCFS - An encrypted file system, linking two or more computers. If you're wanting to share files, this is probably a good bet.

Re:If only I could SSH --- You can

[Phil Hands]

Check out mindterm (a Java SSH implementation) and PuTTY (a Free Windoze Telnet/SSH)

Re:PKI and other issues, Interlock protocol

[stain ain]

There's a way to defeat, in some extent, man in the middle attacks when using public key cryptography: the interlock protocol designed by Rivest and Shamir.

The protocol works this way:
1) A sends B his public key
2) B sends A his public key
3) A encrypts using B's public key and sends half the message to B
4) B encrypts using A's public key and sends half the message to B
5) A sends the other half to B
6) B sends the other half to A
7) Both A and B put the two halves together and decrypt the message with their private keys

If someone is in the middle, he can change the public keys by its own keys, but then in points 3 and 4 he will not be able to pass the real message because it has not been transmitted yet; he will have to invent a completely new message and though the "conversation" will be completely different. This is not a perfect solution since, in fact, he will be able to intercept at least the first messages exchange, but his presence would be detected quickly.
As you pointed, the good solution is to use some kind of trusted third party authentication.

Re:PKI and other issues

[Jon Peterson]

Too many people either fail to make the distinction between authentication and encryption, or else feel that if you fix encryption then you fix authentication.

This latter belief appears to stem from the very shortsighted supposition that if you have an unguessable (not in crack files) password and always send it encrypted you'll be OK.

There are so many ways to get a password its not true. Passwords, while a good start, are not the be-all and end all of authorisation.

The public key authentication mechanism of SSH actually makes things worse, because the key is (effectively) tied to one or more computers rather being tied to the individual, which is almost always the wrong approach. Most authentication systems are trying to authenticate people, not computers - the fact that the same people often use the same computers is merely convenient - convenient for the computer system not the user.

Worse still, the public key, being digital, is easily copied without the owner knowing. Sure, it's password protected, but that just brings us back to passwords again.

So, for authentication I much prefer physical card based systems - i.e. two factor systems. You know when you've lost your card, you can keep track of who has cards, and you can't replicate stealthily.

SecurID is nice because it integrates well with existing systems - no special card reading hardware needed. Other such systems exist, too.

Sure, we need the encryption as well, but simply sending ye olde unix password over an encrypted channel is no magic solution to safe authentication.

Value added for SRP?

[srussell]

As far as I can see, SRP provides no functionality that isn't already present in SSH. In the interest of full disclosure, I'll state that I don't have anything to do with any SSH project, although I do use OpenSSH. When I speak of SSH below, I'm speaking of OpenSSH in particular.

From a purely technical point of view, SSH, when using public key cryptography, is as secure as SRP. In the following list, I don't claim that SRP doesn't do any of these things; I'm merely clarifying what SSH does do.

1. SSH keeps a "known hosts" file on the client, to thwart middlemen attacks. SSH warns the user if the server fails to authenticate itself properly.
2. SSH encrypts each session with a randomly generated key, which it communicates through a secure connection. Therefore, if a single session key is somehow compromised, all other sessions are still secure.
3. Authentication is done either with public/private keys or with a server side authentication mechanism, such as PAM. In the second case, any passwords or other information is transmitted encrypted, and so is secure. In the first case, the password is never transmitted and there is no chance of the user's password on the server being compromised through SSH. The user's password is never used to encrypt a session.
4. OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
5. SSH allows securing of arbitrary ports, and provides extensive port forwarding capabilities. Therefore, any service on a server running SSHD can be secured, as long as the client program can alter the port of the service it is requesting. As an example, to secure an IMAP connection, one would issue: ssh -L 1442:servername:143 servername and then connect with their email client to localhost:1442.
6. Although most users of OpenSSH are unaware of the fact, OpenSSL, which is required for OpenSSH, provides a powerful tool for dealing with X.509 certificates. With OpenSSL, you can encrypt, generate hashes, generate certificates, generate certificate requests, and perform a large number of other security-related actions. OpenSSL documentation is extremely sparce, and due to the complexity of X.509, using OpenSSL tools can be difficult; this is probably the primary reason why most people are oblivious to OpenSSL capabilities.
7. OpenSSL is the basis for a number of port wrapping tools, such as sslwrap. With these tools, you can provide secure sockets to services such as HTTP, IMAP, telnet, and POP. Many clients, such as Netscape, understand secure sockets, and several ports are defined as "well known ports" for these secure services. (EG: IMAP's secure port is 993, and Netscape Communicator knows and can take advantage of this).
8. Using public keys with SSH simplifies accessing services, so that 'ssh' and 'scp' are as easy to use as 'rsh' and 'rcp'. This is slightly less secure on a shared client, because the private key is held in the client memory during a login session, and is subject to core dump attacks. If the client machine is not shared, this is not an issue.
9. OpenSS[HL] doesn't require using RSA algorithms; in fact, you can choose from any number of non-commercial algorithms.

The SRP site claims that there are several "advantages" to using SRP, but never says what these advantages are in relation to. In particular, the SRP site does not claim that SRP is more secure than SSH. SRP is certainly more secure that vanilla telnet, but I see no advantage to using SRP over SSH. The obvious advantage to using SSH over SRP is that SSH is ubiquitous, and well tested.

Please, if anyone knows any way in which SRP is superior to SSH, I'd like to know.