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.

Can SRP shroud X connections?

[Mike Greaves]

SSH can protect connections to remote X clients. Can SRP do this too?

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.

Re:ssh -r and -l

[SL Baur]

Who moderated this up? This post is wrong. The -R and -L flags are used for tunneling, not specifying a port to connect to on the remote machine.
The -p flag specifies a port to connect to, however, it requires an sshd to be connected to it. There is no ssh equivalent for 'telnet host port'.

$ telnet ftp.xemacs.org ftp
Trying 207.96.122.8...
Connected to gwyn.tux.org(207.96.122.8).
Escape character is '^]'.
220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]

$ ssh -p 21 ftp.xemacs.org
Bad remote protocol version identification: '220 ProFTPD 1.2.0pre8 Server (ProFTPD on ftp.tux.org) [gwyn.tux.org]

Re:Telnet is the only solution.

[slashdot-terminal]

Telnet, unlike its "secure" counterparts, is the only communications program that lets you connect to any port of the destination computer, regardless of application protocol.

I would think that SSH is limiting in that manner if you wish to test some daemon or something in security than it would be good. Also each and every public type machine that I have ever used and all unix machines I have never used have never either made ssh avaible or it was not really practal. SSH is only useful if you regularly connect to remote unix machines that support it or you have multiple machines with shell access.

That is simply not an option for me.

Therefore, the question:
Do we want to sacrifice our liberty for the sake of security? Not Thomas Jefferson, nor do I

*partial sarcasm*
Well considering how probably most of the people on slashdot are most likely on the FBI's most wanted list or are agents of the Iranian government trying to export 128 bit RSA I would think that they like it.
*end partial sarcasm*

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.

Re:Telnet With S/Key

[Inoshiro]

Uhm, that's just a login thing. Saying that you have a one time pad (because telnet is clear) to login is still no substitute for SSH. If you type "su," or do anything requiring a password, people will see it (although the S/Key su fixes that a bit). Ditto for any sensitive files edited or viewed, or anything else that is typed or displayed. It's like giving your credit card out over a cell phone. Don't do it.
---

It can't happen to me!

[HancockDC]

Regarding the ssh/srp comparison, I cannot evaluate whether I am dealing with a ticking bomb (by using ssh) or not.

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

[slashdot-terminal]

I would love to use SSH... problem is the machines I have to connect from. Is there any way to use SSH from a windows box. I would install SSH except all of the machines on campus are winblows boxes.

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:Yeah there are some at tucows

[TheTomcat]

I'm running an SSH client for Windows called SecureCRT. It works very well (key emulation is not 100%, but I can't even find a TELNET client that works properly). There's a 30day evaluation on Tucows.

SSH issues?

[freddie]

which are those? I've been ssh for quite a while, and the only thing I had heard about was a buffer overflow. Are there any questionable architecture design deciscions on ssh?

Also, does anybody have a mirror, it like this site is getting slashdotted already.

Re:Telnet is the only solution.

[EXTomar]

Naw...you can get SSH to connect through any port using SSH protocol and therefore encrypting the transaction. With this feature, you can encrypt many socketed transfers, like using "fetchmail" to get your email.

I look at SSH and I wonder if the protocol is generic enough to encrypt any stream. If it is, then why not write a ENFS(Encrypted NFS) file system for the kernel? You could theoretically use SSH-like schemes to authenticate and encrypt.

Data encryption

[Boolean Tryst]

Quick thought on SRP vs SSH. From the quick glance at the SRP web site, it seems to me that SRP only offers secure password transmission and forgoes on packet encryption, offered by SSH. The two solutions differ very much. Therefore I could still be able to sniff yyour traffic and possibly gleam other important info, after the login ( su anyone ??? ). Note, I did only glance at the site while munching my lunch at my desk while troubleshooting a networking issue and chatting on IRC.

Re:Data encryption

[ajm]

The telnet and ftp implementations they offer do provide session encryption. However, to get hold of these you have to be a US/Canadian citizen and email them. Getting the source looks even more difficult.

Re:telnet rulez

[_fuzz_]

So you send your root password over the internet in cleartext? Now that's living on the edge... of stupidity. Have you ever used a packet sniffer? The output looks like this:

[anonymous@coward /]$ su -
Password: ontheedge

[root@coward /root]#

Next thing you know, you're taking part in a DDoS attack.

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:Security

[Hawke]

Nice list, but you are comparing apples to oranges without pointing out the differences:

• SSH - Encrypted the telnet session. Supports but does not require better authetication, but does not provide a central authority.
• Kerberos - Provides centralized authentication. I believe your connection is still vulnerable to sniffing, but could be wrong.
• IPSec - Provides an Point-to-Point encrypted network link. Where SSH just provides a single TCP/IP stream, IPSec can provide a whole interface. Authentication options for IPSec vary.

Re:Security

[logicTrAp]

Kerberos itself doesn't guarantee that a connection is encrypted but as a matter of course most kerberized applications do encrypt traffic.

Re:If only I could SSH

[jschauma]

There is an SSH-Plugin for TeraTerm Pro.

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:If only I could SSH

[Masem]

Get TeraTerm Pro (FREE) from any tucows.com site, then go to the TeraTerm homepage, and follow links for a FREE SSH addon for TeraTerm. I've been using it for several years and have not been disappointed.

Re:telnet rulez

[slashdot-terminal]

So you send your root password over the internet in cleartext? Now that's living on the edge... of stupidity. Have you ever used a packet sniffer? The output looks like this:

Maybe there's nothing that you care about on the machine. I had a thought I don't know about you but perhaps if you security gets compromised and someone was doing one of these fabled attacks then perhaps you could just shut down the machine or turn it off in the first place?

[anonymous@coward /]$ su -
Password: ontheedge

[root@coward /root]#

Who transfers to the root partition as part of their normal access or for su'ing?

Next thing you know, you're taking part in a DDoS attack.

Assuming you edit the file /etc/login.access or something like that you could just remove logins for root or anyone else from certain times. Bango you have removed the problem without expending any problems at all. Or perhaps you just use a complex C++ program that would analyze voice prints (ala Millenium "Forrest Green is People" *snicker*)?

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

[Kaa]

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).

You seem to be confused (umber hulks are a problem in your area? :-) We, and you, are not talking about *data integrity* which is being sure that your chunk of bits got from point A to point B without having been changed en route. We are talking about authentication which is a hard problem, has been a hard problem, and will stay a hard problem for the foreseeable future.

Think about it this way. You, Alice, communicate with some entity at the other end of the wire. This entity tells you that it is Bob. Well, for this statement to be meaningful the label "Bob" has to refer to some entity that Alice knows of.

Now, if Alice and Bob-that-she-knows-of have a shared secret, Alice can test that the entity-on-the-other-end-of-the-wire is really Bob-that-she-knows-of. There are standard crypto protocols for this. However, consider the situation that Alice and Bob have no shared secrets. All that Alice knows about Bob is publicly available info. In this case Alice cannot be sure that the entity-on-the-other-end-of-the-wire is Bob-that-she-knows-of and there is no way for her to be sure.

Again, this problem has nothing to do with "data integrity over a public network". It all revolves around existence of a secret (=key) shared between Alice and Bob.

And, by the way, if Alice has a trusted PKI key server with a trusted path to it, then she can authenticate Bob easily enough over a different, completely non-secure network. That's all standard PKI stuff, really.

Kaa

Re:PKI and other issues

[iabervon]

SSH keeps track of the server public keys of sites you connect to and warns you strongly if the key has changed. Since the private key corresponding to the public key is used in the protocol, either the man in the middle is simply forwarding the traffic, which remains secure, or the server has been compromised, or the man in the middle is reporting a different public key for the server.

The initial connection is important-- you need to get the right server key the first time (and any time the server changes it). But in the usual case, you have an independent way of verifying that you're connected to the site you think you are in special circumstances.

Re:PKI and other issues

[Chalst]

Kerberos v5 allows multiple domains, where the compromise of the
certificate authority only breaks authentication in that domain.

This is a good source of information on Kerberos.

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.

Re:PKI and other issues

[TheCarp]

> 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.

I have to agree and disagree.

ssh IS a very good system. The public key system
it uses does work. However, it only works if
the user sets it up right. (of course it is
defeatable if someone can sit in the middle and
play with all packets...thats besides the point
and not always, or even usually feasable)

The security of the system is in the encryption
of the private key. The authentication is that
anyone with the private key, has to be me (is
assumed). So...if my key has a passphrase...only
me can ever open the private key and use it...
even though it is stored on multiple machines
(hopefully moved to them in a secure manner)
only I can unlock it on any of these machines.

Re:PKI and other issues

[TheCarp]

> I want to keep my private key in my wallet and
> protected it that way IN ADDITION to a password.

Well hell, add a "me too" on that. However,
even that scheme has its problem. The main
problme with it is hardware overhead.

It means that every machine you might wish to log
in from will need special hardware to read your
private key (unless you plan to type it in every
time)

I think that for most applications, and most
people, the ssh solution is "good enough" (of
course ssh doesn't say you can't put your private
key on a smart card or something...I am sure that
if you had a smart card reader it would be
trivial to change ssh to use it)

Take my current setup. my desktop has the
private key, with a moderately strong passphrase
(its not exactly random chars, but its not
going to fall to a dictionary attack or any
simple permutations)

If I remember right, an 128 bit hash is made of
the passphrase and used to encrypt the private
key. With a strong passphrase that is nearly
impossible to break.

more importantly.. the system is secure enough
that it would be easier to compromise the
machine or take me into an ally and beat me up
and force me to give them the passphrase then it
is to defeat it other ways... smart cards fall
to those exact same "methods".

Re:Telnet is the only solution.

[jbarnett]

Sure telnet can connect to any port, this is really great for testing out service "by hand" or to see if xyz host can connect to port xx on host zyx though the firewall. Sure telnet is invaulable for some things, but it is still unsecure.

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...

[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.

Re:Differences...

[Anonymous Coward]

SSH does a P-K exchange (RSA) first then does authentication. SRP sends the username in the clear, then does something similar to Diffie-Hellmann and incorporates a hash of the password as authentication. Both are secure against password sniffing, but I like the first better because it also hides the username.

Re:Differences...

[joneshenry]

"SRP is under the GPL."

I am baffled by this assertion. I just downloaded srp-1.5.1. The LICENSE file in the docs subdirectory explicitly states that the license is akin to X11. The license also states that srp is "free for both commercial and non-commercial use."

In this case since the authors want srp to become a standard, its X11 type license is appropriate.

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:SSH windoze client? Yes! Use TeraTerm. 3.1/9x/N

[slashdot-terminal]

Do a search for TeraTerm or TeraTermPro. Then get the add-on for ssh and the crypto (Blowfish, IDEA, RSA). No source for any of this, though. Binary only. But since it's for windows, how secure could it possible be at best? If
your machine is on the net, MS can probably read your keystrokes anyway.

secureCRT form for download

zow Which also provides for ssh

Re:If only I could SSH

[rnt]

The rare occasions I need to ssh from a windows machine I use PuTTY.

The main reason I like it is because it's just one .exe file. I always find when I'm in need of ssh there is no ssh-client installed on the machine I'm working on...
PuTTY doesn't waste my time with fancy installshields: you download it and you start it. That's it.

I must admit most of the time I'm working on unix machines, PuTTY is just to fill the gap... :-)

http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html

Re:telnet rulez

[vectro]

Erhm, actually, su -, unlike su generates a login shell, not just a regular subshell. This includes resetting your enviornment (as root) and chdiring to the /root directory. It's especially useful on systems where /sbin is only in root's path; with su -, you get /sbin in your path when you su.

Re:Telnet is the only solution.

[slashdot-terminal]

If you want to remotely admin a box using an insecure protocol, you're an idiot. Please come back when you have a clue.

I am just wondering if PCAnywhere (and other related NT admining tools) have encryption features comparable to ssh and friends?

SSH - the only secure solution... for now

[John Hurliman]

I would gladly use SRP... as soon as sourceforge.net uses it on it's servers... as soon as I can use it to log into my shell accounts and cvs repositories instead of SSH. Even if this technology is far superior to SSH, I won't use it until it becomes more standardized.

SSH

[Anonymous Coward]

Surely IPSec is the way forward in the next few years. Encryption at the network level means that you can telnet, ftp, whatever without having to worry about the contents of your packets being intercepted and put to misuse (e.g. password gathering) ...

So if you run an ISP, or just a webserver, in a few years your 'lusers' will be able to put up their nifty HTML and links to their family and friends' websites without compromising your security ...

Although Win2k comes with IPSec, its not the most obvious of things to set up, so don't expect 'em to be using it right away! Hopefully a default configuration will come along in a few years and we will all be able to surf safely.

p.s. In the meantime, can anyone recommend some international software that I can install to secure my FTP connections? I don't live in America, so I am missing out on all the websites with "download my great secure software" with a .org extension in the URL, not mentioning where they are hosted, cos I don't want the FBI, NSA, or whatever you people have banging on my door one night! So tell me! p.s. I already use PuTTY.

I allow telnet in, but only as bait to nab h4x0rz

[Anonymous Coward]

I have a crippled dummy account set up which I openly telnet or ftp into occasionally. There's no write permission for ftp, the shell does nothing but return a fortune cookie and exit. I do however track all logins and login attempts. I use this account to lure the packet sniffers out of hiding and report them to their ISP. Come and get it boyz. heh heh.

Comparing Apples to Oranges

[Joe_NoOne]

People I know use SSH to encrypt their connection. This is nothing but a replacement for RADIUS or TACACS - a means to encrypt your login but not your session.

Re:telnet rulez

[Fluffy the Cat]

Maybe there's nothing that you care about on the machine. I had a thought I don't know about you but perhaps if you security gets compromised and someone was doing one of these fabled attacks then perhaps you could just shut down the machine or turn it off in the first place?

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 /etc/login.access or something like that you could just remove logins for root or anyone else from certain times. Bango you have removed the problem without expending any problems at all.

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

[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:Name one major hack based on an SSH weakness

[GoNINzo]

Groundless, eh?

Here's a buffer overflow.

Here's a bounce attack

Here's another one.

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

SRP plus CIPE

[rjamestaylor]

it seems to me that SRP only offers secure password transmission and forgoes on packet encryption

We've used telnet over the Internet for over two years as our initial ASP offering (we're readying our web-based application to replace it). That is, we're able to deliver our *nix based enterprise application over the Internet via telnet (as long as we have a maximmum latency of 500 ms, that is). These issues of securing login and packet data had to be addressed for us to convince our Fortune 500 customers to buy into our Internet-based solution.

Combining SRP, for password transmission, and CIPE for complete packet encryption, we're able to provide a reliably secure telnet session.

If we didn't have SRP and CIPE, we'd be SOL.

P.S. At the project's inception in 1996 we could not cost-justify any solution that required a per-user license fee. This threw us into Open Source solutions (and the ability to hack at the source code has proven a marvellous benefit since then).

:-only kona in my cup-:
:-robert taylor-:

Re:USe OpenSSH

[jpatokal]

I wouldn't trust an SSH binary I didn't compile myself, particularly from an american company the NSA allows to exist.

You don't have to -- SSH happens to be from Finland. <grin>

ObURL: http://www.ssh.com/about/company/

Cheers,
-j.

Re:Once again, name a major hack due to SSH flaws

[GoNINzo]

Hrm.

Having my box compromised due to someone evading tcp wrappers, or talking unencrypted.

One way, my box is hacked. The other, someone *might* be able to snoop me, assuming they have some node between myself and my box.

--
Gonzo Granzeau

Re:Telnet is the only solution.

[TheCarp]

> Also each and every public type machine that I
> have ever used and all unix machines
> I have never used have never either made ssh
> avaible or it was not really practal. SSH is
> only useful if you regularly connect to remote
> unix machines that support it or you have
> multiple machines with shell access.

Well yes of course... ssh is only useful when
connecting to a host that has sshd installed.

Personally, here at work, ALL of our machines
use ssh. Also, any machine that is mine to
administer as I see fit, doesn't even support
telnet...I turn it off.

I think anyone who runs a unix server should
install ssh, and encourage all users to use it.
In fact, wherever even remotely feasable...telnet
should be turned off.

ssh is too easy to use to not support. plaintext
passwords are too easy to sniff to allow.

(I should note that we recently had a user acount
compromised, which we believe was the result of
a password sniff when one of our users was out
of the country and telnet'd in internationally)

-Steve

Re:Telnet is the only solution.

[The Mayor]

BackOrifice provides a secure method of remotely administering a Windows-based PC. It's free, too.

-dan

Re:Once again, name a major hack due to SSH flaws

[GoNINzo]

What part of 'I was hit with [a security issue with ssh]' don't you understand?

Someone breached my network because of ssh. How 'secure' is that? It should be a solution, not the problem.

unencrypted telnet? I'll admit it's not the safest thing in the world, but I don't have a false sense of security, and I havn't had someone break in since sshd was removed.

Of course, I'll point out that this was all ssh1, not ssh2.

--
Gonzo Granzeau

Re:PKI and other issues, Interlock protocol

[fizzz]

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...

Re:Encryption style

[toastyman]

Perhaps I'm just in a bad mood today, but debunking this sounds fun.

First, the code you posted below, apparently never outputs anything but:

f1 :
f2 :
not a good cypher
cancelled
way :
pfa 0.1 by Frank Joppe (C) Copyright 2000
Usage:
pfa
pfa
--x Hexadecimal input, use lowercase only!
--help This screen
help

from a look at the binary. I'm not quite silly enough to try to run it, but I'm sure someone here on a scratch box will.

Secondly... Define fast? Faster than, say, http://www.entropia.net/prime? They're using a massive distributed effort to factor prime numbers, and it still takes a serious amount of time.

My PIII 600 takes a few weeks to look for factors of (2^8858987)-1 using Lucas-Lehmer's algorithm. If you've got something that can top this, I'm sure a lot of people would like to know....

People like The EFF especially, who is offering up to $250,000 for large prime numbers.

How about some benchmarks, or some documentation on how it works? Or why you're using geocities to distribute it?

- Kevin

Re:Telnet is the only solution.

[guacamole]

Your post is totally off subject. You can use telnet -application- to acconect to any TCP port. When people say telnet is insecure the refer to the telnet -protocol-. You can even use telnet program to connect to the -ssh- port on some host and conduct all your transactions in a secure way if you could just encrypt and decrypt all the data in your head. No one is saying that the application should go away, but people who know about ssh and still use telnet for remote logins should be shot.

Re:Encryption style

[QuMa]

The link's broken. Do you by any chance mean GIMPS?

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.

Re:Value added for SRP?

[tjw99]

In a sense, you are correct when you say that SSH when used with RSA authentication offers the same level of security as SRP. The big value-add is that SRP doesn't require you to keep an RSA key - it derives its security using only a password. You can sit down at any remote location, knowing only your password, and log in. At the same time, the session is fully protected against both active and passive attacks.

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).

Re:Value added for SRP?

[Furry Ice]

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.

This can be thwarted with a man-in-the-middle attack when the known hosts file is created.

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.

Here's one where there is some value-add to SRP. In this case, both create session keys which, if cracked, cannot be used to crack other sessions. However, if the private keys to an SSH connection are leaked, then _all_ sessions can be immediately cracked. With SRP, even if the secret (a password) is known to an attacker, he can't crack sessions. He would be able to successfully authenticate himself, however. One thing I've never been sure of is what's actually stored in an SSH private key file. Is it the key itself, or an encrypted form of the key, which is decrypted with your passphrase? If so, then SSH keys do have some protection in the event of a system compromise. SRP does not store passwords on the system in cleartext, just verifiers. If the verifier file is compromised, then an (expensive) dictionary attack on it is possible. This is the only known way to employ a dictionary attack against SRP.

One difference between SRP and SSH (which I would call an advantage, some may call a disadvantage) is that SRP requires only an SRP enabled server and client to operate. If you know your password, you will authenticate successfully. With SSH, this will work if you have password authentication enabled, so that the two hosts authenticate each other, negotiate a symmetric key, and encrypt the password. As mentioned above, if those servers' keys are ever compromised, your password will be revealed to the attacker. To make SSH more secure you need to create your own keys on every machine you use, and copy the public key to the machines you wish to access. If the hosts you wish to access don't allow password authentication, then you can only access them from the particular computers you've explicitly allowed access from. This can be very inconvenient, especially when you work with many computers. In this case, I have to say I prefer SRP. One password works from anywhere with perfect forward secrecy.

Re:Telnet is the only solution.

[evilpenguin]

Huh, I say, Huh?!?

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

[Robin Hood]

There's an SSH module available for Tera Term someplace.

You're thinking of TTSSH. 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

[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.

Advantages to SRP

[kkenn]

The main advantage to SRP is that it uses a simple password to authenticate, instead of requiring the user to carry around a public/private keypair with them as they move around (in other words, there's no client-side setup required beyond the installation of an SRP-capable client app). This can be the same password as the regular UNIX account password, although it's hashed in a different format and so SRP can't be used with existing password files. I've written a plugin crypt module for a replacement to FreeBSD's libcrypt which teaches crypt() how to speak SRP hashed passwords, so if you do something like this then everything else (non-SRP apps like login) will authenticate just fine. There's also an SRP PAM module floating around.

Security-wise, the authentication protocol has been well investigated, and as far as I know it's stood up fine so far - no serious weaknesses have been discovered.

On the other hand, the SSH v1 protocol as implemented by OpenSSH and all other SSH v1 implementations has an insertion attack which allows the insertion of data into the stream because of insecure integrity protection (it uses a weak checksum). The SSH2 protocol fixes the design flaws in SSH1 (as well as allowing other key exchange schemes than RSA) but OpenSSH doesn't speak it (since it's based on an old SSH 1.x distribution). Hopefully this will change in the near future.

As part of the SRP authentication handshake, a session key can be shared which allows the rest of the session to be encrypted. So SRP provides for authentication as well as secrecy, like SSH does.

SRP is just an algorithm - there's nothing preventing someone from creating a SSH-like app which authenticates using SRP, and then provides all of the port-forwarding features which SSH does. This would be quite useful, actually, and is something I'm hoping to do when I get around to bringing native SRP capability into FreeBSD.

The major downside to SRP is that the authentication is only as strong as your passphrase. But on the other hand, this is true as well in SSH if you can get a hold of someone's encrypted private key (if they carry it around with them on a floppy so they can log in from random hosts, for example). This can be mitigated by enforcing strong passphrase selection on the SRP server. An attacker sniffing the authentication exchange cannot obtain any data which is useful for determining the passphrase, even by a brute-force dictionary attack - you have to obtain access to the /etc/tpasswd file and brute-force attack that.

The Stanford SRP distribution is distributed under a BSD-style license. This is good for most people (e.g. commercial users who want to add SRP support to their products, etc), but it may prohibit the code from being incorporated into a larger GPLed program (because of the GPL's "no other restrictions" clause and the BSDL's "must give acknowledgement" clause). Consult your lawyer..

On the whole, SRP is more practical to implement because it doesn't require per-user client-side configuration. In most ways it seems to be a superior solution which is just awaiting wider adoption.

here are the links

[Jesus Christ]

It's not complete, and it's not meant to be.

Maybe this will help make it more so: homepages for some of the software you discuss.

• OpenSSH - http://www.openssh.com/
• [Commercial] SSH - http://www.ssh.com/
• Kerberos Network Authentication - http://web.mit.edu/kerberos/www/
• ENskip - http://www.tik.ee.ethz.ch/~skip/
• Linux FreeS/WAN - http://www.xs4all.nl/~freeswan/

Anyone interested in the software mentioned above, or even just general UNIX security, would do good do take a gander at OpenBSD (http://www.openbsd.org). It's based on 4.4 BSD, like most of the Freenixes, and is designed with security foremost in mind. Think of it as FreeBSD after reading "1984". ;-)

It comes with OpenSSH. And Kerberos.

Ooh, and also... stickers! Put them on your box, and maybe the MiBs that break into your house while you're at work won't even bother trying to crack yer system.

Remember: paranoia is good. Anyone with doubts regarding the truth of that statement should check out the Echelon links that have been appearing here lately.

Ciao.

I am the Lord.

two-party vs. three-party authentication

[coyote-san]

Any list, no matter how short, should include a reference to two-party vs. three-party authentication.

SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.

Kerberos, digital-certificates and some government sponsored systems use three-party authentication. This puts some limitations on your use, but these are generally reasonable restrictions if you think about it. (E.g., do you really want John Cracker to be able to remote mount your files?) Third-party authentication got a bad rep after some clumsy government posturing with the clipper chip, but it seems that a lot of people lost track of the many places where it's appropriate.

Re:two-party vs. three-party authentication

[dmiller]

SSH and (IIRC) IPsec use two-party authentication. That means anyone can talk to anyone else, but as another article pointed out it also opens the door to "man-in-the-middle" attacks.

Both SSH and IPsec also include mechanisms for prevention of MITM attacks. SSH uses RSA host keys which can be pre-exchanged (OpenSSH extends this to include PGP-style key fingerprints), IPsec can use a variety of methods including preshared symmetric or PK keys or certificates for various forms (OpenPGP, X509, DNSSEC).

Re: Kerberos

[coyote-san]

Kerberos is also available for both Red Hat and Debian. Debian has at least three implementations - two European implementations are on non-US, and I've packaged MIT Kerberos 5. (Still no word on when MIT will drop the export nag page, unfortunately.)

OpenSSH is still an excellent choice, but not because it alone supports Kerberos.

Re:SSHD everywhere?

[TheCarp]

> So, why can't I get my university to install SSH
>clients on all the desktops that we use to
> connect to our unix servers?

If the desktops are unix boxen...then they
should get their asses in gear and install
openssh (IMHO)
however...for Windows boxes...licencing can be
expensive. Here we have a SecureCRT licence pool
and ar eletting students and faculty get copies...
I have no idea what its costing the
University though.

Hopefully someday telnet will fall into disuse and
we can stop supporting it.

A metacomment

[Tr011Thr4$h3r]

Note to everyone: People, please don't make references to the "comment above" or derivatives thereof. There are many different modes for showing comments, such as Threaded, Nested, Flat, etc.

They can be sorted Newest First, Oldest First, or Highest Scores first. There are different levels you can set before it spills into index mode. You can change the threshold from -1 to 5. You can have different thresholds for replies. And it goes on and on. Besides, posts accumulate quickly - even with the same settings, it may not be "the one above" if you wait too long before hitting "submit".

So please, if you're going to refer to a post, and it's not one you're replying to, it helps to give the post's ID. That makes things much easier to follow.

Thanks.

Re:SSH, what a misnomer.

[I R A Aggie]

Just to justify myself, having gotten burned by sshd before (twice even. `8r/), I've included URL's to make you all snuggily happy.

Oh, joy!

Here's a buffer overflow.

Quote:

Date: Thu, 5 Nov 1998 02:38:51 +0200

This message contains information relevant to people who compile ssh with --with-kerberos5. There is one or more potential security problem in the Kerberos code. These issues are not relevant for people who have not explicitly specified --with-kerberos5 on the configure command line.

Here's a bounce attack Here's another one.

Two examples of the same thing, from August and September 1997 and version 1.2.17. You realize that skript kiddies prey upon those who don't keep their software up-to-date?

Now what would happen I used a more current source of attacks? There were a couple on BugTraq a couple months ago...

You mean this CERT advisory dated 13 Dec 1999?

Quote:

Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code.

I think the lessons are:

1. Keep your software up-to-date.
2. Don't believe for a moment you're completely protected.
3. Keep informed of the latest in security threats.

The only completely safe computer is one that is incapable of being turned on.

James

SRP+SSH Vulnerabilities

[Orasis]

Hello, my name is Justin Chapweske and I developed a system called Natz, which is very similar to SRP.

The biggest weakness with Strong Password Authentication protocols like SRP, Natz, and B-SPEKE is that they are vulnerable to a man-in-the-middle attack if the password is known before hand. Thus these systems are worthless for encrypting data to a public resource, like public/anon FTP or a web site.

My biggest issue with SSH is very similar, a man-in-the-middle attack can performed when the server is sending its certificate to the client for the first time.

So basically they both suck, and to this end I have been working on a solution that combines the strengths of both to significantly minimize the cases where a man-in-the-middle attack could be employed.

Oh, BTW, you people that are comparing SRP to SSH based on features don't know what you're talking about. It would be trivial to use SRP allong with SSH or TLS's transport protocols, just using SRP for the authentication/key generation...so quit yacking about SRP not having X-windows tunneling support and whatnot....screw features, its the security thats important.

If you are interested in this, please email me at justin@cyrus.net or continue this thread.

Re:SSHD everywhere?

[Athos]

I have one word for you. (and a link)

Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty /)

Not perfect, but good.

--

Re:Encryption style

[Signail11]

16-bit composites can be decomposed into prime factors in much, much, much less than a second. Assuming that the worst case scenario of two 8-bit prime factors holds, a naive brute force test all primes up to sqrt() factoring algorithm takes about 8000 cycles to factor the number (checked using the pentium RTDSC instruction).

*I* can find primes fast!

[tilly]

It isn't very hard. Finding primes has little to do with factoring though...

Cheers,
Ben

PS Here is a moderately efficient algorithm in an unefficient language:

#!/usr/bin/perl -w
# primes - generate primes
# Written for the PPT initiative by Jonathan Feinberg.
# The algorithm was substantially modified by Benjamin Tilly.
# See docs for license.
use strict;
#use integer; # faster, but cuts the maxint down
$|++;
my @primes = (2, 3, 5, 7, 11); # None have been tested
my @next_primes = (); # Avoid redoing work

my $VERSION = '1.002';

END {
close STDOUT || die "$0: can't close stdout: $!\n";
$? = 1 if $? == 255; # from die
}

chomp(my $start = @ARGV ? $ARGV[0] : <STDIN>);
my $end = $ARGV[1] || 2**32 - 1;
for ($start, $end) {
s/^\s*\+?(\d{1,10}).*/$1/ || die "$0: $_: illegal numeric format\n";
$_ > 2**32 - 1 && die "$0: $_: Numerical result out of range\n";
}
primes ($start, $end);
exit 0;

sub primes {
my ($start, $end) = @_;
return if $end <= $start;
if ($start <= 2 and 2 < $end) {
print "2\n";
}
$start = 3 if $start == 1; # Don't report 1 as a prime
$end--; # Reindex
# Initialize the list of primes
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
while (scalar @next_primes) {
push @primes, @next_primes;
# Careful, we need to ensure that
# we get a prime past sqrt($end)...
&more_primes($primes[-1]+1, int(2 * sqrt($end)));
}
my $from = $start-1;
my $to = $from;
until ($to == $end) {
$from = $to + 1;
$to = $from + 99999; # By default do 100,000
$to = $end if $end < $to; # Unless I can finish in one pass
&more_primes($from, $to);
print map {"$_\n"} @next_primes; # Print primes
}
}
sub more_primes {
# This adds to the list of primes until it reaches $max
# or the square of the largest current prime (assumed odd)
my $base = shift;
my $max = shift;
my $square = $primes[-1] * $primes[-1];
$max = $square if $square < $max; # Determine what to find primes to
$base++ unless $base % 2; # Make the base odd
$max-- unless $max %2; # Make the max odd
$max = ($max - $base)/2; # Make $max into a count of odds
return @next_primes = () if $max < 0; # Sanity check
my @more = map {0} 0..$max; # Initialize array of 0's for the
# odd numbers in our range
shift @primes; # Remove 2
foreach my $p (@primes) {
my $start;
if ($base < $p * $p) {
$start = ($p * $p - $base)/2; # Start at the square
if ($max < $start) { # Rest of primes don't matter!
last;
}
}
else { # Start at first odd it divides
$start = $base % $p; # Find remainder
$start = $p - $start if $start; # Distance to first thing it divides
$start += $p if $start %2; # Distance to first odd it divides
$start = $start/2; # Reindex for counting over odd!
}
for (my $i = $start; $i <= $max; $i += $p) {
$more[$i] = 1;
}
}
unshift @primes, 2; # Replace 2
# Read off list of primes
@next_primes = map {$_ + $_ + $base} grep {$more[$_] == 0} 0..$max;
}

__END__

=head1 NAME

B<primes> - generate primes

=head1 SYNOPSIS

B<primes> [I<start> [I<stop>]]

=head1 DESCRIPTION

The B<primes> utility prints primes in ascending order, one per line,
starting at or above I<start> and continuing until, but not including
I<stop>. The I<start> value must be at least 0 and not greater than
stop. The I<stop> value must not be greater than 4294967295. The
default value of I<stop> is 4294967295.

When the primes utility is invoked with no arguments, I<start> is read
from standard input. I<stop> is taken to be 4294967295. The I<start>
value may be preceded by a single C<+>. The I<start> value is
terminated by a non-digit character (such as a newline).

=head1 BUGS

B<primes> has no known bugs.

=head1 AUTHOR

The Perl implementation of I<factor> was written by Jonathan Feinberg,
I<jdf@pobox.com> and Benjamin Tilly, I<ben.tilly@alumni.dartmouth.org>.

=head1 COPYRIGHT and LICENSE

This program is copyright (c) Jonathan Feinberg and Benjamin Tilly (1999).

This program is free and open software. You may use, modify, distribute,
and sell this program (and any modified variants) in any way you wish,
provided you do not restrict others from doing the same.

Try a 20 digit number

[tilly]

As a point of comparison, standard general-purpose math programs such as Mathematica can factor ~20 digit numbers (e 70 bits) on commodity hardware in a fraction of a second.

If you cannot come within shouting range of that, your algorithm is not likely to be interesting. If it does then it would be interesting is to know how your algorithm scales to, say, 30 digit numbers...

Ben

Re:Telnet is the only solution.

[copito]

Nobody says you have to get rid of telnet. Just telnetd.
--

Oops

[tilly]

I should fix that.

Cheers,
Ben

SRP is the secure one - cryptographic reasons

[Paul Crowley]

SSH is secure only if the client has the server's public key with which to authenticate it - and even then there are problems. SSH works in three stages:
1) negotiate an encrypted session with the other party
2) authenticate the other party
3) the client sends the password in the encrypted session.

Clearly, if you can spoof the server you can get the Holy Grail: the real, plaintext password. This is why SSH flashes up big warnings saying "THIS SERVER IS UNAUTHENTICATED: REALLY PROCEED?" when you log on to a server the client hasn't seen before. To which everyone just presses "yes", defeating the so-called security. You can also get the Holy Grail if you can subvert a server to which the target logs on.

Contrariwise, SRP offers real network password security. SRP was designed around the assumption that the normal situation for network security was that people went up to new, vanilla clients and used only their passwords to log on to servers the clients had never seen before, and any protocl that wasn't secure under these assumptions just wasn't secure. SRP does damn cunning public key manipulations to allow the password to be used to verify both the client *and the server*, while only storing a password verifier on the server. Eavesdropping real connections, spoofing clients, or spoofing servers will leave you no better off than when you started; you can't even launch a dictionary attack, in contrast to disastrous protocols like CHAP which don't work for the low-entropy passphrases used in the real world. You can mount a dictionary attack if you subvert the server (this is unavoidable), but that's still more work than just reading the plaintext-equivalent phrase from the password file as is the case with challenge-response protocols; even subverting the server doesn't help.

SRP (and its cousin, B-SPEKE) solved the real, difficult problems of network password security. Accept no substitutes.

I only wish Slashdot didn't prioritise being first over being right so much, so more people could see the good information...
--

Re:Network Topologies and sniffers

[Effugas]

Switched networks are (at present) irrelevant to a determined attacker--I send out a gratuitious ARP identifying myself as the MAC to send all your IP traffic to, everyone sends me your traffic, which I then A) Read and B) Send along to you with a forged MAC address.

Really nasty when you do this to the gateway.

Defeating this requires security mechanisms which are rarely deployed at the switch level.

See the dsniff toolkit for example code.

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Key Theory

[Effugas]

OK, thought about this a little.

SRP essentially combines the concept of "Hashed Password" and "Secret Key" into one small, low entropy object: The stored password.

"Dictionary attack" difficulties aside, it's not hard to imagine an intruder running a pre-computation attack against a password file. *However*, the password file *can be* much more secure--crypt() is far less secure than SHA-1, though SHA-1 isn't drastically better than the MD5 passwords deployed on most Linux boxen.

It is moderately unclear through the documentation how the "public verifier" gets distributed; more emphasis should be placed on this. The public verifier, distributed via OOB mechanisms, is *the only* way to get around "first contact" problems. Now, the public verifier can be shared, extended, chained, and so on, but at some point there has to be a Out Of Band(OOB) contact.

Of course, the problem with chains is Entropy Erosion and Failure Amplification--your original entropy never increases, but your risk of compromise *does*.

Another brought up a good point--SSH ideally requires compromise of both a private key(what you have) *and* passphrase(what you know) to experience a critical failure; SRP only requires one. One nice thing is that SRP can mandate that a user have a passphrase; I don't believe SSH has a truly secure method(not client based) to make sure that they don't.

More later, if anyone's still alive in this thread. (Gotta go.)

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Re:Once again, name a major hack due to SSH flaws

[Pathwalker]

I had a system at home broken into through the recent attack technique involving bugs in RSAREF. Little buggers did an rm -rf /* when they realized it was a 486. Saved me the trouble - I was going to wipe and reinstall it in a couple of days anyway :-)

Re:PKI and other issues, Interlock protocol

[bluGill]

This won't work for all man in the middle cases. Consider this:

1)A sends B is public key
C intercepts that key can changes it to his public key
3)B sends A his public key
4)C intercpets and changes
5)A sends C a message encrypted with C's public key.
6)C decrypts and recrypts with B`s public key
7) B sends half the message encrypted.
You get the idea

Remember for this to work A and B have to have no non-seceret knowledge of the other that C does not share, and C needs compete high speed access to the entire data stream. Of course if any step is accomplished where C cannot get it (snail mail? federal crime, but doable. Meeting face to face can be fixed too, with impersonators.)

In the end you have to take some risk. Then again, if A and B know so little about each other and are doing buisness that is sensitive enough to encrypt they probably don't trust each other at all anyway.

RSA License and RSAREF

[_Sprocket_]

SSH 1.2.x only links against RSAREF if you tell it to. This is only an issue for places where the RSA patent is valid (which, by the way, expires in September of this year).

No good deed goes unpunnished.

Those who actually tried to stay within a quasi-legal standing in compiling SSH1 with RSAREF ended up with an insecure implementation. The thing to consider here is... did it buy them much? There is still some question whether using RSAREF actually allows one to avoid licensing issues. I wouldn't be suprised to find more installations of SSH1 today compiled by admins who got fed up with the whole situation.

As a side note, admins working for the US Government have no need to worry about RSA licenses. The US Gov't has an open license to RSA since Government money was used in developing RSA at MIT.

Completeness Theorem != Incompleteness Theorem

[divec]

> I hope you have tongue firmly in cheek [...]
> See Godel's Incompleteness Theorem

Ah, these are two different results. Godel's Completeness Theorem says that any *first order* statement which is true can be proved. "First order statements" are, essentially, mathematical statements which only talk about certain things. Amongst other things, first order statements can't talk about "For all sets such that blah".

On the other hand, there are statements which do include things like "for all sets such that blah " - called second order statements. Godel's *Incompleteness* Theorem says that there are some second order statements which are true but cannot be proven.

My comment was that FLT fits into the first category, so an automated proof is (theoretically) possible. Of course, it would take ages to run!

FLT not undecideable

[divec]

If FLT were undecideable, we'd be able to find a model of the natural numbers in which it was false. There would be a counterexample a^k + b^k = c^k in this model. But (a,b,c,k) is a finite [ordered] set of natural numbers, so it is a decideable set, so it exists in any model of the natural numbers, and so a^k + b^k = c^k would hold in any model. But then (Exists x,y,z)(x*...*x + y*...*y = z*...*z), so we have a disproof of FLT which holds in any model.

there are Diophantine equations which are unprovable in Gödel's sense

Not quite - what Chaitin showed was that there's no single algorthim for solving all Diophantine equations.