SSH v. SRP
Posted by
CmdrTaco
on Thu Feb 24, 2000 12:35 PM
from the glad-it's-not-called-PSSST! dept.
from the glad-it's-not-called-PSSST! dept.
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?
This discussion has been archived.
No new comments can be posted.
SSH v. SRP
|
Log In/Create an Account
| Top
| 299 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
SSH has been banged on for years (Score:5)
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 [rootprompt.org]
ssh -r and -l (Score:4)
-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 (Score:4)
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 [inner.net] which can provide a one time pad for telnet, FTP and even su.
Better yet, OpenBSD comes with this feature built into the OS.
It can't happen to me! (Score:3)
What I CAN do is point out that the most dangerous security attitude is "It can't happen to me!" There is no substitute for watching the security web sites, making sure you have applied the latest security patches, and simply being aware of what is happening on your system.
ssh is a definite plus over telnet, and I use it routinely. It is now just as natural to me as using the telnet command was 10 years ago. I'll certainly keep an eye on any new ways of doing things, but it would take a little more than what I have seen so far to make a switch at this time
-----------------------------------------
Yeah there are some at tucows (Score:3)
Actually if you look at your local tucows mirror you can get ssh type telnet shells. I know of at least one I saw being used but forgot the name.
Re:telnet rulez (Score:3)
Security (Score:5)
Re:If only I could SSH --- You can (Score:5)
PKI and other issues (Score:4)
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:Telnet is the only solution. (Score:3)
For example, if you telnet into a server, su to root, do some root work, exit root account, read your email, exit the telnet session. If someone was sniffing your network they would have
1) you login and password
2) ROOTS! login and passowrd!!
3) the IP of the machine your telneted into
4) A rough idea of how you work, what "major" logs, info you check when you fist log on
5) that you girlfriend is pissed at you (via the email)
6) that your boss is pissed at you (via the email)
7) that pretty much anyone that emails you has some bitching to do about something (via the email)
8) how good of a typist you are.
Sure telnet is convent, but is insecure. If you do anytype of remote rooting(TM) you need SSH. I would highly suggest you use SSH for normal remote logs and ALWAYS use SSH when doing remote rooting(TM).
True story, I know a freind that used to go to college part time, and did Jr. level admin stuff for a local company. At school one day he was chilling at the computer lab after class, he got an email at his school's email account saying that their was problems with XYZ on the server at work and all hell was breaking loose. He quickly fired up Windows 95 Telnet, hoped over to the site in normal user mode, looked around and firgured out the problem. The problem needed root access, he shoved up the SU command without a thought, entered the password, fixed the problem, the bosses where happy.
The thing he didn't know was that there was a group of college security nerd playing around in the computer lab at the time, they where developing a Windows 95 ethernet sniffer. It was still beta, but it sure enough grab his password and also ROOT's password!!! They told him about it, and he promptly called an admin on site that changed root's password from the console, but if these security nerds in the computer lab where script kids or malice mother fuckers, who knows what would of happened!!
Sniffing is easy, try sniffit, a easy to use packet sniffer for Linux. When I was on help desk I used to sniff the admin computer and come up with all kinda of neat things. The thing I didn't want to find out though is that %90 of his day was involed in IRC chatting under the #lesbains channel with the nick Amy34Blonde (he was male).
Differences... (Score:4)
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 (Score:4)
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? (Score:4)
Re:Yeah there are some at tucows (Score:3)
Re:telnet rulez (Score:3)
If a single machine on a network is compromised, the entire network's security is greatly decreased. If someone cracks my machine, 600 other machines become hugely more vulnerable because the first thing any even vaguely competent script-kiddie is going to do is install a packet sniffer. As for turning machines off if they start being used for DoS attacks - great. I'm sure the remote site will be thrilled that it only took a few hours for you to wake up/get home/notice before pulling the plug. Security is not something that should be dealt with half-heartedly, and if you're not going to care about security then your machine should not be allowed anywhere near the internet.
Who transfers to the root partition as part of their normal access or for su'ing?
That's what su - does.
Assuming you edit the file
You mean block root access at certain times of day? But that would prevent me from doing remote administration at certain times of day, and still does nothing to prevent someone packet sniffing my root password when I do use it. From that point on, I've lost. You should never transmit your root password via telnet unless you trust all the other hosts on your network.
Re:PKI and other issues, Interlock protocol (Score:5)
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:Name one major hack based on an SSH weakness (Score:3)
Here's a buffer overflow [rootshell.com].
Here's a bounce attack [rootshell.com]
Here's another one [rootshell.com].
Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago.
And don't tell me that 'patches come out quickly' because the bounce attacks were not patched for several weeks, and I know, because I was hit with them. So it might sound like just hype, but there is proof out there.
And I forgot, just because URL's were not included, I have no clue, right? Happier?
--
Gonzo Granzeau
Re:PKI and other issues (Score:5)
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.
Re:SSH has been banged on for years (Score:5)
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.
Re:PKI and other issues, Interlock protocol (Score:3)
The algorithm you're suggesting is mostly a precursor of the current PKIs (I haven't read its reference paper, and don't really have the time to find it, but I wouldn't be surprised to find that it dates back ~RSA publication times).
By definition, at it's worst, a man-in-the-middle attack cannot be blocked/prevented: if A has never met B, there is no way for A to be convinced that she is really talking to B and not to C. If B is in the same situation (having never met A) and is also really speaking with C then although their communication may get from one to the other, it will always be possible for C to see all of it (since C can simply pretend to each of them to be the other player and then decrypt/reencrypt the message).
For trust to be achieved perfectly you will always need an additional piece of information (or mean of identification) in which you can trust... PKI's are one of the possible solutions. In the case of the Rivest-Shamir you're describing both parties must have common knowledge of the message's content prior to starting the algorithm otherwise a middleman could switch messages for it's own. In essence the protocol becomes dependant on the messages's nature and the fact that both players must know it... Two complete strangers could not use it.
But then again, there can't exist a protocol for two complete strangers to identify themselves to one another...
Value added for SRP? (Score:5)
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.
- 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.
- 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.
- 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.
- OpenSSH, OpenSSL, and LSH are all open source, non-commercial projects.
- 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.
- 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.
- 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).
- 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.
- 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.
Re:Telnet is the only solution. (Score:3)
When you telnet to a specific port you are just connecting a socket to it and passing stdin to it and passing what comes out of it to stdout. If you had to write this from scratch it would be about 150 lines of C code (and many fewer lines of perl or Java code). You aren't "sacrificing telnet" to use ssh!
The rest of telnet is support for terminal emulation and some terminal capabilties negotiation at start up, all of which works only when talking to telnetd, and none of which comes into play when connecting to any other port (unless, of course, you're connecting to telnetd on another port).
A later poster complains that ssh is only useful for shell accounts. Absurd. You can do arbitrary port forwarding through ssh, turning ANY network service into an encrypted service. It is a VERY handy way to create a secure opening through a firewall:
Machine A is behind a firewall that forbids incoming connections.
Machine B is out on the internet.
You want to use a service on machine A from machine C (another machine out on the internet).
Machine A can make an outbound ssh connection to machine B and tell machine B to open port 3500 on B for listen and to "tunnel" it to port 80 on machine A.
Machine C can then type this URL into his browser:
http://[machine B's address]:3500/
This will connect to port 3500 on machine B (obviously), but less obvious is that machine B will forward all traffic encrypted over the SAME ssh socket Machine A has open to B. No one observing the traffic between A and B will know that machine C sent traffic to machine A, nor will they be able to tell that more than one "conversation" is taking place over the single link.
SSH is not sacrificing freedom, it is enabling freedom. No, I won't use SSH2 (which is a close commercial product), but I certainly will use SSH1 and OpenSSH.
SSH is a major tool for flexibility,
SSH for Teraterm: TTSSH (Score:3)
You're thinking of TTSSH [zip.com.au]. When I have to use a random Windows box and I need SSH, this is what I download and use.
-----
The real meaning of the GNU GPL:
Apples and Oranges (Score:4)
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.
Re:Value added for SRP? (Score:3)
SRP is more secure than SSH+regular passwords.
SRP is more convenient than SSH+RSA authentication.
SRP can be integrated as an authentication mechanism for SSH (and it has, check out LSH).