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.

ssh -r and -l

[Spoing]

#man ssh

-L port:host:hostport
Specifies that the given port on the local (client)
host is to be forwarded to the given host and port
on the remote side. This works by allocating a
socket to listen to port on the local side, and
whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
remote machine. Port forwardings can also be spec-
ified in the configuration file. Only root can
forward privileged ports.

-R port:host:hostport
Specifies that the given port on the remote
(server) host is to be forwarded to the given host
and port on the local side. This works by allocat-
ing a socket to listen to port on the remote side,
and whenever a connection is made to this port, the
connection is forwarded over the secure channel,
and a connection is made to host:hostport from the
local machine. Port forwardings can also be speci-
fied in the configuration file. Privileged ports
can be forwarded only when logging in as root on
the remote machine.

Add tuneling, and I think your points are easily addressed.

Telnet With S/Key

[n3rd]

Even though I haven't used it often, telnet with S/Key login seems to be a great alternative to vanilla telnet.

From what I understand, it's only vulnerable to TCP hijacking (most things are) and dictionary attacks (which can be easily detected or accounts can be configured to be "locked out" after X bad login attempts).

The best one of these is OPIE which can provide a one time pad for telnet, FTP and even su.

Better yet, OpenBSD comes with this feature built into the OS.

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)

PKI and other issues

[Signal 11]

The problem most people side-step or don't even know about is man in the middle attacks:

Works like this... you're host A connecting to host B but the packets go through host C. So unless host A and B have an alternate method to exchange keys, you're vulnerable to having host C replace the key with it's own, so in reality you're talking to host C and it's using a simple form of IP masquarading to make it look as if it's B or A...

So long as host C is the only route between the two (which is suprisingly easy to accomplish) - or through icmp and bgp manipulation makes that the case - you can ensure that host C has access to all the data over the wire even though those two hosts think they now have a trusted connection! Unless you can bypass host C via another path you won't even know it's happening.

Now, let me make this clear: there is no method for you to ensure data integrity over a public network like the internet. You must exchange keys over a secure medium before you can communicate securely over any network unless you can ensure that the entire network is under the same (trusted) administrative domain and have verified that it has not been tampered with (very, very difficult).

So in short: Yeah, SSH has problems. But this new program isn't going to make any leaps forward. You really need a PGP-style distributed key server system where you can verify the key's integrity through a trust network and/or via multiple independent routes / hosts. Otherwise, the alternative is a Kerberos-style system. Unfortunately THAT system has a single point of failure - if the key server is compromised your entire network is compromised. I'm not an expert though on Kerberos, so feedback is appreciated.

That is all,

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.

Differences...

[altair1]

SSH is a little more versatile in that it can do port forwarding to make
arbitrary TCP connections secured. It can even be used to support secure PPP
tunnels. SRP on the otherhand is less versatile. Only telnet and ftp seem to
be supported. Someone please correct me if I'm wrong, but as far as I know
SRP does not have any sort of connection forwarding like SSH does.

Another major difference is in licensing. SRP is under the GPL. No official
version of SSH is under a real open source licesense. SSH2 forbids any sort
of commercial use, even internally. SSH1 is slightly less restrictive in
that it allows for commercial use without paying them, but you can only use
it internally. These license restrictions are the reason SSH isn't found in
most linux distros.

However, there is an open source implementation of SSH being developed by
the OpenBSD people at http://www.openssh.org. It is ususably stable in its
current version.

The main thing SRP and SSH have in common is that they require no
infrastructure to be secure. In otherwords, you do not need any sort of key
distribution centers, or any other sort of software besides the daemon
itself and the client program to make everything work. Compare this to say,
Kerberos. Using kerberos, you can have secure connectivity to a machine,
however, there's a lot of additional infrastructure and complexity thrown
in, (such as KDC machines). You'll want to use Kerberos if you have a lot of
machines that will share a common user/password database. Kerberos will let
you log into one machine, say a kerberized workstation, and you'll be able
to securely log into any other machine (via telnet, rlogin, rsh, rcp, ssh,
ftp, pop3...) that's part of the same Kerberos realm without ever having to
type your password (assuming your client software supports Kerberos authentication).

SRP is arguably more secure than SSH, however SSH is a little more widely
implememnted and can be used for more things. If all you need is a secure
telnet and FTP, and the existing clients are suitable for you and you can
trust it (SRP is a litte newer), I'd give it a try.

Apples and oranges

[Djinh]

SRP seems to be an authentication protocol. A promising one, but just that, nothing more nothing less.

SSH on the other hand is a very useful application offering secure communications to another host. Keep in mind that SSH's password authentication happens after the encrypted channel has been set up. This means that the password can only be intercepted if the crypto fails.

SRP's security is based on similar cypro primitives as SSH's, so if the magic crypto hack we're all looking for gets found both will be useless.

Sourceforge?

[|c0bra|]

This is really interesting since anyone hosted by SourceForge is required to use SSH and SCP to get to their shell accounts and transfer files. It would be nice to see the people producing SRP put it up on SourceForge if they haven't already. For those of you who dont know, sourceforge is a free service brought to you by your friends at VA Linux. Its for people who need a place to work and publish Open Source projects and stuff. I love it so far.

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.

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.

Apples and Oranges

[Anonymous Coward]

Stanford's biggest complaint about SSH is a political one. Their point is *IF* you can't politically use encryption then SSH buys you nothing hence SRP is preferable. However, if you take the time to use SSH then you probably are able to use encryption. SRP does not provide an alternative to SSH with encryption, it provides an alternative to authenticating on an insecure transport. When compared with other similar protocols such as APOP, SRP has definate advantages. Despite these advantages, present implimentations do not address everything that SSH (with encryption) is designed to provide:

• 1) Keeping the initial authentication information secret
• 2) Authenticating future packets come from same client that authenticated
• 3) Keeping the entire session private

SRP does the first step of keeping the initial authentication secret. Since both sides then have a secret random number as a side effect of SRP, it would be possible to use a collision resistent one-way hash to "sign" future packets. However, as far as I can tell, no implimentation of SRP currently accomplish signing of future packets. The last point can't be addressed while still meeting SRP's goals of not using encryption. This becomes a problem when legacy authenitication methods are used withen the SRP authenticated session. For example, withen an SSH encrypted stream, the "su" application can be run without revealing the password in clear text and without the application needing to be altered. SRP on the other hand only can address this if your willing to replace the "su" application and all other authentication applications to be used withen the session (passwd, DBA tools, etc.) via SRP based ones. In some cases, such as with database tools, an SRP replacement may not be possible. Therefore, SRP has it's own political problem of: is all your authentication application vendors accepting enough of SRP to provide you with an SRP aware version of their application? You may find that depending on what country you live in, the politics of SRP acceptence is far worse problem then the politics behind encryption.

That all having been said, I am impressed by SRP and would like to see it submitted to the W3C for use in future revisions in the HTTP standard. There are several cases that I'm aware of that keeping the password private is important but the data isn't sensative enough to warrent the overhead of SSL.