The Continuing End of SSH/SSL

Kurt Seifried, who started out this End of SSL and SSH string, with Silverman responding, has now issued his follow-up. I promise anymore of this string will just go in Slashback.

Comments

What a lame attempt

[Anonymous Coward]

This guy completely loss all of his credability in the security industry and now he tries to write a better article show that he isn't a complete moron. He should have posted this second article instead of the his awful attempt on the first one. All of ideas he "wrote" about were all posted on bugtraq criticizing him for lack of knowledge. Go kurt!

Re:What a lame attempt

[xcyber]

sigh,,,,,,,,,, he is not rebutalling oreilly,but write up another piece of shit. i can find that kind of information else where.

SSH/SSL is still better off than nothing at all

[rkt]

I think this issue is not new. And every Admin who has installed SSH knows this drawback. However SSH/SSL is still better off than non-encrypted channel any day. It is definitely not acceptable for an E-Commerce solution. I don't think I'll ever transfer a million dollars using SSL technology. Its too much of a risk still. I don't care how many bits it supports.

I have implemented Cache engines/proxy servers. And its pretty simple to setup a trojan there which could in theory decrypt SSL... I think we will see more of these kinds of trojan attacks over SSL in the near future. There is not much one can do to avoid it. Nothing that I can think off.

Since the number of keys are exponentially rising I think some work needs to be done in refining the implementation of this technology.

1. To begin with, as the author of this article says, Force Expiration of all keys. No key should exist for ever. Its like junk yard in space after the satellites break down. The junk has to be removed eventually. Its better if we start now.

2. I think some time back there was some work done in distributing PGP keys in DNS records. This could in effect make SSH more secure. If I were to use the KISS principle I'd make SSH clients to auto-register its keys in the local DNS somehow.

3. Same with SSL. By default Browsers should reject SSL keys if its not signed by a CA. Exceptions could be made if it can be verified atleast by using a reverse lookup on DNS.. or something like that. However that doesn't mean that the proxy server cannot sniff DNS requests and forge it too... NEway... its just an idea. May be we should reject everything not signed by a CA.

OK.. that were weird ideas... I don't think anyone can be serious enough to go all the way, because I personally can't think of implementing such a complicated solution for my clients.

rkt

Re:SSH/SSL is still better off than nothing at all

[um... Lucas]

Same with SSL. By default Browsers should reject SSL keys if its not signed by a CA. Exceptions could be made if it can be verified atleast by using a reverse lookup on DNS.. or something like that. However that doesn't mean that the proxy server cannot sniff DNS requests and forge it too... NEway... its just an idea. May be we should reject everything not signed by a CA.

Hope there's an option to turn that back on in the advanced preferences of this browser of yours... There are several sites that i visit where they use self signed keys. There's nothing intristically valuable at those sites, so there's no point the owners having to pay VeriSign for a certificate. It's just a way of maintaining a small bit of privacy while browsing a given site...

What other CA's are there that have their certificates preinstalled in IE and Netscape, anyhow? Verisign? Thawte, except now VeriSign owns them. So essentially, by mandating that a certificate come from Verisign in order to initiate SSL and SSH connections, you've put them in the drivers seats of being able to dictate who can communciate to whom and under what conditions... Isnt' that special?

I understood a lot about what was mentioned so far in this series of articles, and while there may be flaws in the implemntations of some things, for the most part the problems seem to stem from lax policies and such.

Re:SSH/SSL is still better off than nothing at all

[YU Nicks NE Way]

If you run W2K, at least, you can go and look at the list of 118 default trusted CA's available on your machine.

Sure, Verisign is the dominant authority, but they're not without competition.

Re:SSH/SSL is still better off than nothing at all

[charon.de]

You make some good points, but: There are several sites that i visit where they use self signed keys. There's nothing intristically valuable at those sites, so there's no point the owners having to pay VeriSign for a certificate.

If you're doing e-commerce on a high traffic site you can't use selfsigned certs, most users will get curious, reject it, or write a mail to you. Do you want to answer dozens of email a day? No, you pay that VerySign tax and you have no problems....

As for SSH, it's the admin only who chooses to implemt it poor, or spend some time on setting it up in a secure way...

Michael

Re:SSH/SSL is still better off than nothing at all

[um... Lucas]

If you're doing e-commerce on a high traffic site you can't use selfsigned certs, most users will get curious, reject it, or write a mail to you. Do you want to answer dozens of email a day? No, you pay that VerySign tax and you have no problems....

Right. As far as commerce is concerned, the money spent to get a certificate from a real CA is (or should be, if everythings done right) a drop in the bucket for any company. I was more talking about a couple of webmail sites and specialized search engines i use that the owners have decided would like to offer the option of using secure forms to access their services. The certificates are signed only by the owners of the sites, not by Verisign or any other CA. I like that option, because i never enter any valuable information into them anyhow. The certifiates could very well be compromised, but at least everyone in my neighbor hood who might happen to be running a sniffer won't know what i've been looking at.

Understand what i'm saying here? I just don't think that browsers should be bolted down in such a way that it's impossible to have secure communications with other sites without Verisigns okay. Maybe in the default installs of IE, Mozilla, Netscape, and Opera, they could reject certs that weren't signed by "trusted" authorities, but as long as they present a dialog and explain to you that if you'd like to accept that certificate, "go to Edit->Preferences->Advanced->Certificates and change a setting" or something like that.

Default install could be "only accept certificates from sites with Verisign signed certs" with the option to let you use unsigned certificates or certificates that were signed by people who aren't built into your browser.

Re:SSH/SSL is still better off than nothing at all

[darkonc]

In Netscape, you can view the list of signers by left-clicking on the lock icon in the bottom left corner of the window. Then choose Certificates/ Signers.
--

Re:SSH/SSL is still better off than nothing at all

[Chandon Seldon]

It is definitely not acceptable for an E-Commerce solution. I don't think I'll ever transfer a million dollars using SSL technology. Its too much of a risk still. I don't care how many bits it supports.

I'd be purfectly willing to risk exactly as much on the security of an SSL/SSH connection right now as I'd be willing to risk on the validity of the key on the other end. If I've manually installed a key on an SSH server, I know that the machine is otherwise secure, and the fingerprint checks out, I'll risk an arbitrary amount on the security of that connection.

Unless you have some good reason to believe that 1024 bit RSA/ElGamal or 128 bit 3des/Blowfish can be broken there's no reason for you not to trust SSH/SSL equally.

Re:SSH/SSL is still better off than nothing at all

[bobv-pillars-net]

Have you ever tried to *buy* a certificate from any of those non-verisign CA's ???

I chased them all down last year (things might have changed since then) and there were exactly two (Verisign and Thawte) that offered certificates to the general public and weren't reselling certificates issued by one of the other CA's.

Now, if you happen to be part of the banking industry, your options widen a teensy-weensy bit, but for Joe Q. E-Commerce, there is only one option: Thawte/Verisign.

Re:SSH/SSL is still better off than nothing at all

[Anthony]

The sooner this crazy Verisign monopoly is over the better. It is bizzare that we are beholden to an unknown company who signed a cosy deal with Netscape to say what certificates we accept. It is bizarre that Governments have to go to a private company to get a Verisign certificate. Soveriegnty? What's that?

Conspiracy Theories

[aozilla]

Sure, if anyone had tried to claim that ssh/ssl were dead a year ago, RSA would have shut them up in a second. Of course, now that the RSA algorithm is public domain, big business has every incentive to deem it useless... Concentrate on tweaking the implementations, the basis of public key cryptography is rock solid.

Re:Conspiracy Theories

[swillden]

now that the RSA algorithm is public domain, big business has every incentive to deem it useless

The only companies I can see that would have any incentive to "deem it useless" are RSA Data (assuming they had something else to push) or some of the companies pushing alternatives to RSA (like Certicom, who holds a large number of ECC-related patents). In point of fact, however, the rebuttal mentioned in an earlier /. article was written by Bob Silverman, an employee of RSA Data, so apparently they still stand by the usefulness of SSH/SSL.

In addition, Certicom and others would gain very little from this particular attack on SSH/SSL, because the same weaknesses mentioned would apply even if RSA were replaced by another algorithm.

Nope, this conspiracy theory doesn't work.
--

Re:Conspiracy Theories

[aozilla]

good point. i didn't actually think it was actually the case, but i thought it was at least a possibility. i guess not...

nothing new here

[Sourdough]

Basically, all he's said is having good security is hard, and your average user is not up to the task. Another way of saying this is that the weakest part of most security systems now is the people that use them. I think this is pretty well-known already.

SSH and SSL, when used correctly, can provide good security. They aren't idiot-proof, but then again, what security system is?

Re:nothing new here

[Sven Tuerpe]

If this is well-known, where are the solutions? How can the weakest part be made stronger?

BTW, does your car have airbags? Do they enhance security? Do they require any knowledge in their user's head in order to work correctly?

Of course airbags aren't idiot-proof either, but it takes an advanced idiot to render them useless. Does the same apply to SSH?

Re:nothing new here

[tve]

If this is well-known, where are the solutions? How can the weakest part be made stronger?

I guess regular excercising might do the trick. :)

BTW, does your car have airbags? Do they enhance security? Do they require any knowledge in their user's head in order to work correctly?

Of course airbags aren't idiot-proof either, but it takes an advanced idiot to render them useless. Does the same apply to SSH?

I'll separate this into protocol and implementation.

Protocol:
The only weak part in the protocol is getting the public key of the server to the client in a secure way. Once it's there, the protocol is secure (AFAIK).

Implementation:
Now getting that public key to the client is where implementation comes in. There are several ways a sysadmin could go about doing this:

1. Maintain a know_hosts files on all the users machines containing only keys known to be secure (enough) (e.g. because the admin verified them over the telephone). This is quite secure and leaves little to the users, but in most cases is totally impractical.

2. Have the client software add the public key to the know_hosts file the first time it connects to a new server. This is relatively low maintanance, but leaves a window of opportunity for a Man In The Middle attack during those first connections. In this scenario it's also sometimes necessary for users to update their know_hosts file when a server's key changes. There lies another opportunity for an attacker to get a foot in the door: because users generally don't want to be bothered by security, but just want to connect, a lot of them will just hit 'y' until all warnings about changed host keys go away. Because users are allowed to change keys in their known_hosts file, they might also hit 'y' when an attacker is intercepting their connection and (in this scenario) there is no way of preventing this: no piece of software can destinguish between a legitimate change in host key and an attack occurring. The only thing that can be done (as mentioned in the article) is to display a really scary warning message to the user hoping (s)he will make the right decision about changing the key.

So, in most cases the responsibility for security will come down on the users. Therefore, the only way to increase security that I can think of is educating the users.

Re:nothing new here

[Fnkmaster]

Hmm. You're giving a really inadequate analogy. A physical safety device does not aim to do anything other than soften a blow. Likewise, misuse of a seatbelt can be more harmful than no use at all, much like encryption. Furthermore, an airbag can deploy in a low speed crash and give you a black eye. I suppose these analogies are lame too, but no worse than the original one.
There are known protocols and methodologies for secure communications that are immune to MITM-type attacks. Unfortunately, all of them are either inconvenient or impossible over an open, insecure communications medium like the Internet - this is simply a feature of the network architecture and design. If it's used carefully (i.e. the people factor here), it can be secure, but the nature of the medium is to be insecure. If you want a truly secure medium, don't use a public, massively accessible packet switching network. Use an isolated quantum encryption protected channel or some other system designed for security, that takes security out of the hands of the user.
In any case, I think one of the other posters made a good point on the distinction between protocol and implementation. The protocol is no perfect but is pretty good, much like the airbag protocol. It can be all-but-advanced-idiot proof in a good implementation. But a poor implementation can put even a sophisticated user in harms way, just like a shitty airbag can bust you in the nose. And while the government regulates airbag quality, nobody is going to regulate SSH or SSL implementations (side note: why does the government give a shit about your physical safety but not at all about your data's security).

Re:nothing new here

[gorilla]

Do they require any knowledge in their user's head in order to work correctly?

Yes, they do. That's why every car with airbags has a permantantly attached label with the user instructions.

He's right

[Sven Tuerpe]

Seifried has a quite valid point. Cryptography is not a magic thing that makes everything secure by simply activating it. Cryptographic algorithms and protocols are only a building block that, if applied carefully, can make a system more secure against certain risks and attacks. Having encryption, signatures, and certificates, does not provide security by itself. It can help, but a system secured by cryptographic techniques can be as insecure as any other system. It can even be better to be honest and leave out cryptography if it does not really enhance overall security, instead of giving false promises by advertising -bit keys being used in a product which is snake oil by concept. No, I did not say SSL/TLS/SSH are snake oil. :)

Crypt-kiddies and Script-kiddies are basically the same.

I don't get one point

[Ektanoor]

Well this guy bashes everyone and everything. Except centralized authentication.

Well Mr. Seifried let me say one thing. If you compromise a SSH connection you mostly compromise the computers that are inside this connection. In most cases two computers.

If you compromise a Kerberos server then one may get the security of whole networks to be put under question. While you speak a lot about the +++ and --- of several protocols, I would remind you that Kerberos had some glitches for the last time. As far as I know, M$ and RH have issued a few patches after they started releasing Kerberos. No matter their nature, this shows that the realisation is still not perfect. So may in a moment we may get a few security holes to deal with for long.

But the main reason for not using Kerberos lays in the fact that computers are more than a service. Yes, one may try to step up a security server doing only Kerberos. But to what cost this will come? It is surely more expensive than having SSH doing its dirty job in every computer. Not everyone has money and guts to make things perfect. A backdoor in some third service, administrator access to Kerberos and let's see how good this stuff is...

Besides you forget that a Kerberos security scheme is more prone to DoS. Any well planned attack against the security server and let's see how your clients will live. But, even this may not be needed. A glitch on the network may be able to create havock. I have seen many cases when this stuff shows clearly that it is better to have an SSH backdoor everywhere rather than laying security in one only place. Any possible problem that breaks contact with the "mother of all networks" and you are on your own. Services start to run crazy, overloading machines and networks. Users cannot go in to stop this or to do external tasks.

Kerberos may be a solution to organise things. But it has as many drawbacks as the services you point out. One of them distribution and here we are in the same place as the DNSSEC/IPSEC. As far as I see even this two protocols have a more well-spread distribution than Kerberos. If we take a look, a good piece of that stuff is already laying on Linux. probably other systems supporting IPv6, and Bind 9. Why they are not used? Because of the necessity to change a few critical things and sysadmins lazyness to do it.

To /. staff. Maybe it is correct to have the answer to public reaction published. A good form of pluralism and democracy. Howoever beware of these FUD articles from first start. Anyway, every security system depends fundamentaly on one only protocol. One with two legs, two hands and a head with a whole need for bugfixes, patches and Service Packs. No one has ever replaced this protocol. And so, no other security protocol can be 100% secure. Any claim on stating protocol disadvantages from typical human actions, and made in such partial way as Mr. Seifried did, is nothing but FUD.

Re:I don't get one point

[sheldon]

Hmm... It seems to me that the central point of contact requires less monitoring than multiple points of failure.

That is, all the examples you say... if you are monitoring the Kerberos key server carefully, you will detect these DoS and other problems you suggest near immediately and be able to do something about it.

Ohwell, it doesn't seem to me that your opinion is any less FUD than the article author.

Re:I don't get one point

[Ektanoor]

FUD? Cool. Answer just to one question:

Have you ever been inside a situation where you don't have access to the security server?

Other questions:

Let us think you have 3-5 minutes to react to a wholescale crash of you centralized security system. No it's not SF. It happens with some networks and barely you can change this stuff (to do it you need to rewrite a lot of code, if you have the source). In 5 minutes you get 80% of the network completely dead and the only way to get out, is to run around to fix things. Some systems may be located miles away. Mirrors and proxies may help but, the fact is that they don't always work. So how much time you'll get to put things back together?

Let us think you need to monitor that same Kerberos server. However a 1st class security question: What systems they are up to? I hardly believe "they" need the Kerberos system so much.

You talk about "immediately". What does that mean? I have no black glasses with micros and LCD displays on it. Nothing of an optic tube going to my brain. Sincerly I have never see the word "immediately" in no security dictionary. Even NORAD or its Russian counterpart take 5 minutes to react... Now a DoS attack may last a few seconds. Enough to knock down the service if it has some bug in it. I will surely react in more than a minute. Now I may have to put things back together in a few minutes. Or else things will get worser. So my first reaction may be quite far of going to search for DoS attacks. If the attacker knows this feature then he may process his DoS attack, such way, that it will take hours to put things in place. And sorry, there is no SF on this.

SSH = Many points of failure? Maybe. But if you knew something about security then it would be MUCH BETTER to have SEVERAL points of failure rather than a SINGLE one. But note, here, even SSH can be a single point of failure if you distribute one and the same key over several servers. Some idiots do this and forget to close the keys to world's eyes... Anyway how can you speak here about security? You are exactly contradicting yourself by stating "less monitoring than multiple points of failure". So if the single point goes down, what is monitoring needed for. Grab the ashes? And if your system is on a "no-glitches 24h/day" demand?

So don't speak about FUD here.

Re:I don't get one point

[sheldon]

I've actually worked in a Kerberos environment.

Sigh, even your followup is more FUD. :(

What's the use then?

[CBAS]

If SSL/SSH doesn't protect people's passwords from MITM attackts, what _does_ it protect them from?
Seriously, isn't encryption only protecting against MITM situations or am I missing something here? (I hope I am, otherwise this would all be one silly discussion!)

zalig kerstfeest,
CBAS

Re:What's the use then?

[lomion]

the encryption protects against packet sniffing. With telnet if you login and su to root anyone sniffing on the network just saw the root password. With SSH they see an encrypted stream.

The arguments presented here are basically implementation of the tool, in this case SSL/SSH. Nothing is 100% secure, but you balance what you have and use multiple levels. SSL/SSH, good security policies, properly securing an OS, use of detection and monitoring tools. It's all part of the big mix. His issues are know issues for years, nothing new or exciting.

This thread has mostly become a pissing match now. Probably a good solution would be to use ipsec.

Re:What's the use then?

[CBAS]

With telnet if you login and su to root anyone sniffing on the network just saw the root password. With SSH they see an encrypted stream.

But if the attacker is sniffing, wouldn't they have also sniffed the key in the beginning of the session?

Re:What's the use then?

[f97hs]

Yes, the public key. But to decrypt data encrypted with the public key, an attacker would also need the private key, which is stored on the server. Some introduction to public key cryptography can be found here. The basics of this attack is also described there.

Re:What's the use then?

[darkonc]

What he described was essentially a version of the 'two camps' problem (I first heard this story in the early '80s with respect to TCP handshaking).

You have two allied camps in a war zone separated by enemy territory. The commander of one camp sends a runner to the other camp with a message. "we attack at 6am -- but only if we know you got this message safely". The question is: How do BOTH camps know that the other got the message and it wasn't intercepted?

At some point, the answer is "trust". Building a secure trust without a secure channel is next to impossible without some sort of out-of-band communication.
Send a number of volleys equal to your mistress' birth month 200 Metres north of our camp to acknowledge this message.

Even with Thawte or Verisign, how do you know that the installation software for your browser wasn't compromised? How paranoid do you want to get? With any cryptographically based authentication scheme, there comes a point where you have to trust SOME communication to be accurate and the underlying data secure.

The question then becomes: How much work do you want to put into the key exchange and verification process (as a user), and how much work should we put into making the process user-friendly (as developers).

The answers to these questions will differ for different people and different applications. General users doing random web browsing probably don't care quite enough. An IT spook at CSIS (Canadian Security and Intelligence Services), on the other hand, was quoted as saying "We don't have a firewall -- We have an air gap." between their 'secure' systems and their net-accessible systems).

Chocolate / Vanilla -- Choose.
--

Re:What's the use then?

[Rares Marian]

If you don't have X's keys then you tell Y keys info and you never need X's keys cuz Y thinks you're X.

It's easily fixed just need a different approach.
I have one. It's slightly clumsy but I do have one.

Coming soon... Hint: session keys (only the computer knows them)... and multitude of ambiguities caused by things like fixed length verification exchanges even though your algo is simple. There is only one case when the keys can be discovered by backtracking, that's when the keys are discarded anyway.

It's kinda like Diffie-Hellman but MITM proof.

The only thing I can imagine is someone recording random sessions a la SETI and then trying to find when key rejections occurred and then testing a long list of possibilities.

Re:What's the use then?

[CBAS]

see, I knew I was missing something ;-)
thanks for clearing that up!

MITM is nothing new, and there are solutions

[Anonymous Coward]

The server has to authenticate itself to the user and the user has to authenticate to the server. Taking these one at a time... First, OpenSSH2.4 will support the use of CryptoCard authentication tokens. This does a good job of authenticating the user to the server. Second, well, you have to check the public key the server sends out to make sure it doesn't change. Part of this is a UI issue with the clients. Also, the client machine needs to be secure and tamper-resistant. If it is trojaned, there is nothing you can do to prevent session hijacking. Secure OS and secure hardware are part of the requirements here. We have a fairly secure OS: OpenBSD. We need a secure web browser, and to get really security, we need tamper-resistant hardware. Remember this mafia guy that the FBI bugged his keyboard? We need hardware that can prevent those kinds of attacks. So we have a ways to go before we get to secure communication. But SSH, especially ssh+cryptocard+openbsd, is a huge step in the right direction.

Is this really a problem?

[q000921]

Systems like SSH and SSL are clearly designed to protect against eavesdropping, not against man-in-the-middle attacks. Now, are man-in-the-middle attacks really a problem?

Tools like dsniff seem mainly designed for use on non-switching LANs. Unless you manage to subvert the infrastructure of a major ISP, I don't see how they would help you with hacking the traffic between me and my bank using a man-in-the-middle attack. But the infrastructure problems that allow man-in-the-middle attacks are much easier to exploit for denial-of-service, so it seems likely that major ISPs already have a strong incentive to guard against them.

So, before getting all pushed out of shape about the possibilities, I would like to hear more discussion about the possibility of man-in-the-middle attacks on the Internet infrastructure itself--the part between my site and the bank's site which neither the bank nor I control; the case of attacks on shared LANs at my site or the bank just isn't all that interesting to me because I don't perceive it as a significant additional threat compared to what my users or the bank's employees can already accomplish using other, simpler means.

Re:Is this really a problem?

[swillden]

Systems like SSH and SSL are clearly designed to protect against eavesdropping, not against man-in-the-middle attacks.

Wrong. SSH and SSL are clearly designed to protect against MITM attacks as well as passive eavesdropping. SSL versions 1 and 2 use public key certificates produced by trusted certificate authorities to defeat MITM. SSH version 1 provides a server key fingerprint mechanism to facilitate key verification over another channel to defeat MITM. SSH version 2 provides client-side keys in addition to the server key fingerprints. Both SSL and SSH provide all the technology required to construct secure connections that are immune to MITM attacks.

Regarding the possibility of an attacker standing between you and your bank, I suggest you do a traceroute sometime and look how many systems and how many companies (and therefore employees) have access to your packets. What is the likelihood that none of the machines in the dozen or more hops in that traceroute list can be hacked?

MITM attacks would be very feasible if it weren't for the fact that SSL and SSH were designed to defeat them. As it is, they're still possible, but much more difficult.
--

Re:Is this really a problem?

[q000921]

Regarding the possibility of an attacker standing between you and your bank, I suggest you do a traceroute sometime and look how many systems and how many companies (and therefore employees) have access to your packets.

The same is true for telephone conversations or financial transactions. Thousands of people have opportunities to intercept either, yet there seems to be fairly little actual fraud by employees. My point is that ISPs and backbones carry important personal data, and their employees must live up to a similar level of responsibility. This isn't a burden the consumer should have to carry.

SSH and SSL are clearly designed to protect against MITM attacks as well as passive eavesdropping.

Well, I suppose you are right that the intent is arguable. However, the actual product is clearly ineffective in preventing them. And that's hardly a surprise: without secure key distribution via a route other than the Internet, there is no way you can guard against man-in-the-middle attacks.

Re:Is this really a problem?

[cduffy]

And that's hardly a surprise: without secure key distribution via a route other than the Internet, there is no way you can guard against man-in-the-middle attacks.

Well, yes. However, ssh does help OOB key validation (by printing a key's signature the first time it's encountered). Hence, a business or university could publish a list of valid host keys and users could validate them on connection (phone in to validate, whatever).

Not that it'll ever happen.

Another interesting (and somewhat offtopic) option is pgpfone's biometric authentication (used to detect MITM attacks), but that still has OOB data inasmuch as Alice and Bob must know each other's voices.

Missing the point on client soft key change msgs..

[Akardam]

In the article, Kurt spends a couple of paragraphs expostulating on the lackluster way in which SSH clients present new/changed key issues. While I agree that SSH clients should be more strenuous in warning the user of new/changed keys, the failure to do so is not a fault of the protocol, simply of the writers of the software.

I use PuTTY on my Win boxes to SSH into my servers, and its messages are exactly as he says they should be... "Warning!", etc, so clearely, this is not a universal problem.

Also, AFAIK, there is no facility in the SSL/SSH protocols themselves to deal with alert messages such as this, although I don't think that the protocol itself is the place for these kinds of messages.

To put it succinctly, it's not the protocol's fault if a user blindly accepts these new keys as authentic.

Akardam Out

Secure Sockets and Shells, but Insecure Users.

[The Monster]

I think this issue is not new.

It's as old as computer security itself. This whole controversy about an alleged "flaw" in SSH/SSL is bogus. The weakest link in the chain is the user, who is [un|mis]educated about security. The way that I explain it to the uninitiated is thus:

I can install a solid steel door in your house, with the best deadbolt locks, a top-of-the-line alarm system, and all the bells -n- whistles you can imagine. But if it's too much trouble for you to lock the damned door, none of it does any good. When someone knocks and says "Candygram", it might just be a land shark. We all saw Matthew Broderick read the password off the secretary's desk, defeating whatever security was behind that password.

Can the protocols be fine-tuned to make security holes more obvious to those who know what they mean? Sure. We'll argue about the details of when keys should expire (I say there should be some long-term keys used for nothing other than signing shorter-term keys, for instance), and other minutiae. But I've seen people pay good money to attend classes where the instructor said that "https://" means "you're secure", and left it at that.

Frankly, Joe Average User hasn't had the educational background to question authority, perception of reality, etc. If it looks official, it must be. Like so many other of the issues we discuss here (DeCSS, copy-protected HDs, crypto export restrictions, etc.) we must educate Joe (and Jane) if we ever want to make progress. When was the last time you explained to your semi-computer-literate friends "Email is like a postcard, PGP/GPG is like an envelope"? Widespread use of the Web of Trust model would help make the use of secure protocols as secure as the protocols themselves.

"Security is a process, not a product"

[Paul Crowley]

I'm sorry, but for the main part it seems like interpreting Bruce Schneier's motto "Security is a process, not a product" to mean that therefore all products are insecure and we should panic. It's hardly news that these products don't drop into place and create perfect security. No measure is perfect; what's wonderful is that when you use these measures, it gives an attacker headaches like greater expense and difficulty and a better chance of being caught, and that's what computer security is really all about.

Now I think there's a lot to be said for articles that detail the ways someone might try and mount attacks that circumvent the protection offered by these measures, so that you know how to gain the most protection from them, but presenting it in the form of alarmism about sensible security precautions is irresponsible.

Also, there's at least one important error in this article: Unlike SRP, B-SPEKE et al, Kerberos is *not* a ZKP password protocol. The Kerberos password protocol, IIRC, is a "weak" password protocol that allows offline dictionary attacks where no extra authentication information exists at the client end. Seifreid interviewed the creator of SRP last year (sorry, can't find URL just now), but I'm not sure he "gets it" about why SRP and friends are so great.
--

Re:"Security is a process, not a product"

[nestler]

Unlike SRP, B-SPEKE et al, Kerberos is *not* a ZKP password protocol.

You're right that Kerberos isn't a zero knowledge protocol. You're wrong about SRP, B-SPEKE, etc. Those aren't zero knowledge either. Sure it may be hard to mount dictionary attacks on them, but that does not make them zero knowledge.

I wrote more about this in a thread of its own called "Zero Knowledge" on this article.

Monday's Experts

[QuantumG]

If an attacker manages to break into a server that uses SSL to secure services they can steal the certificate. [...] They can then use the certificate to setup a service that looks identical to the original, with some DNS poisoning they can direct users towards it.

This is so toy it's not funny. Let's consider the 101 reasons why no-one does this. First, if you can "break into a server" that is used for secure transactions, you have a lot of options for getting those little magic numbers. First, you can look in their database if they are stupid enough to log cc numbers (hello amazon and all you one-click wannabes) and get a few million cc numbers. You can also trojan the web server or the cc processing cgi and intercept live transactions there. But perhaps the attacker is a little afraid of getting caught so he doesn't wanna touch anything on the web server cause he might "break it". So why wouldn't he go set up a fake server? Well, he has the server certificate! He can just passively monitor the traffic and watch the handshake using the private key, get the symetric session key and watch all the traffic go by at his leisure. This is not to say that people don't set up fake servers and redirect DNS to point to them. It happens all the time, but these are people who don't have the certificate and hope that shoppers wont notice that the transaction isn't encrypted or is encrypted with a different certificate.

This "rebuttal" is filled with similar stupid statements that real experts immediately pick as scare mongering. What is your motive here Seifried?

If you're already rooted...

[Baconator]

If an attacker were to break into a system and managed to retrieve the keys they would then be able to execute a man in the middle with extreme ease.

The way I see it, you need to have root to retrieve a private key. If someone already has root on your computer, don't you have more pressing concerns than whether or not someone might execute a man-in-the-middle attack against you?

-Alec

Re:If you're already rooted...

[Felinoid]

Heres a thought...
Someone has root on your box...
I mean they have control of the computer it dosn't matter what encryption you use..
I mean for that matter.. you could be using no encryption at all and you'd never even know...

Murphy said

[darkonc]

An old "murphy's laws" listing (circa 1979) included the phrase:

Investment in security will continue until the cost of the security exceeds the cost of the breach -- or until somebody insists on getting some serious work done

I just put a self-signed key on my site mostly for the hell of it. It allows people to view the highly political contents of the site with complete paranoia. Is it worthwhile for me to find someone to pay for a 'secure' version of the certificate? no. Are people going to accept the self-signed certificate? I don't care.
--

See? Kurt is spreading FUD

[Russ Nelson]

Kurt is only saying things that are true, but it's the way he's saying them. In this case, he gave CBAS the idea that SSH doesn't protect people's passwords from MITM attacks. In reality, SSH, when carefully used, is perfectly secure. For better or worse, this existing implementations don't insist that you use it carefully. For example, before accepting a host key, ssh could ask you for its fingerprint. How do you get its fingerprint? You get it from the host in some secure manner; perhaps by logging into the console.
-russ

Obsolete?

[Felinoid]

I know someone who uses CP/M and I still use a printer terminal.
While some throw out 386s others surf the web on XTs.
Intel discontinues old Pentium chips annother chip maker builds faster 65816 chips (20 mzh) and others make imbeded computers using 486 clone chips.

While some throw out a larg screen TV for a new HDTV others buy old B/W 9 inchers..

While some buy new digital clocks some go out of there way for wind ups...
The point?
What the hell is obsolete?
Obsolete is someone elses idea of "not useful anymore" but nothing ever really becomes "not useful"..

SSH/SSL will die when mankind dies... piriod.. Not when it becomes unuseful in the eyes of the majority... but when isn't a single person left who might spawn a child who might find it useful for something....

So XXX is dead... yeah.... Dos is dead.. thats what Microsoft keeps saying... and they still can't get rid of it...
Nothing ever dies.. software never dies.. it just stops being populare...

Re:monitoring, how MSFT/AOL undermine SSL security

[QuantumG]

perfect forward secrecy: In cryptography, of a key-establishment protocol, the condition in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session.

And that is why your message is score 0.. frankly, I think it should be -1, offtopic.

The human brain is obsolete

[Felinoid]

Clearly the human brain is obsolete..
When prompted the human brain will run e-mail trojens (posably viruses) even when it knows better.
When prompted it will accept incryption keys even when the prompt details that the new key is very likely invalid and DaNgErOuS.

The human brain is quite capable of designning all kinds of elabrate securing systems but any time the brain plays an active role in this process the brain attemps to use easlly hacked passwords.. leave defaults in place... say ok to prompts that say "Danger you WILL die if you accept this"...

The human brain must be replaced soon...

Not impressed with Seifried's followup

[tytso]

I too, was not impressed with Seifreid's followup. He changed his arguments on a number of different issues, and completely avoided areas where he was shown to be wrong or misleading. In a formal debate session, he would have been docked massive points by the judge. It was clear he was trying to be sensationalistic, and after reading his original article, the rebuttal, and his followup, I'm left wondering how much he fundamentally understands the tradeoffs of how public key works and what's necessary to make a useful/usable system.

One very important point which hasn't been addressed to date is that if you're using RSA authentication (and not password authentication) the risks are much reduced. Also, even if you use an insecure means of getting the public key of a host, the MITM attack only applies the *first* time you contact the host. Once you have the public key stored in your known_key file, you'll know if the public key asserted by the host ever changes. That's actually a pretty strong assurance, in real life. If you ever once had a secure channel between host A and host B, if a script kiddie breaks into your next work the following month and installs desniff, you'll get the warning message about the host key changing.

Kurt Seifried's defense against this point was that he pointed out that one Windows client has a lame message which isn't as strong as the warning made by the Unix client. That's a valid complaint, but that's a complaint against a specific implementation, and not against the protocol. So much for his claims in his original article that the ssh protocol was irretrivably broken....

In the greater scheme of things, perhaps the biggest disappointment was that Slashdot posted a link to his original drivel... His original article wouldn't have passed my editorial standards.

Re:Not impressed with Seifried's followup

[Anonymous Coward]

Yea totally. I ran into this guy on #linux and he kept saying about how no software is secure without being compiled with a stack guard.

He doesn't argue very well and is way to dogmatic, loosing sight of the big picture.

Re:Not impressed with Seifried's followup

[claus-at-work]

I too, was not impressed with Seifreid's followup. He changed his arguments on a number of different issues, and completely avoided areas where he was shown to be wrong or misleading.

Agreed.

However; I think he has a point regarding the missing facilities in the SSH protocol for expiring of keys. Keys should not live forever. And if you can't distinguish a changed key (a potentional security breach) from an expired key (a normal event in a security conscious environment), you and your users got a problem.

Human mistake

[jsse]

Sometime the vulnerability might due to human mistake, or misconception. Most people would enable both RSA(public/private keys) authenticaion and Password Authentication when setting up a SSH server in *nix.

Enable password authentictaion is effectly breaking the security of RSA, introduce a easier method, or backdoor, to intrude.

Is this a real problem?

[billsf]

I plan to continue to use ssh. The only threat appears to be lack of paying attention. It is not nice to expire host keys without warning users ahead of time.

On Unix, ssh is quite secure. Using it from M$ should be avoided, but admitably, it isn't allways an option. Other extreme security problems in Windoze, not ssh, appear to be the real problem. Just try to avoid doing remote system maintainance
from untrusted systems and clients.

rooted

[sfraggle]

SSH also does not protect the key beyond file permissions,

to get around the file permissions you would have to be root, and if you have root then surely you can just ttysnoop them anyway?

Exageration in the extreme

[sjames]

To call the problem the death of SSL/SSH is extreme sensationalism.

Considering the many less secure protocols in use everyday, let's just say THE INTERNET IS DEAD!!!!!!!!!! Burn your computer now before it's TOO LATE!!!!!

Notw that THAT's out of my system, Let's face it, the same people who worry about how secure their credit card is in transit will cheerfully hand it over to a waiter who will disappear with it for 5 minutes at least, hand it over to the part-time temp worker behind the register, or call it out over the phone to a person they can't even see, much less know.

The bigger problem seems to be what happens to the number AFTER it is sent. Several databases have been raided by crackers, and several companies have turned out to be fraudulant (but they WERE who they said they were and DID have valid certs).

There are a lot of ways to get credit card numbers for fraud, MITM is one of the more expensive and risky. It would be much safer to redbox a payphone and just ASK people at random (I'm with Xbank and I can save you hundreds a year, to get started, I need the Name. number and expiration from your Visa). Many will hang up, many will tell.

As for corperate security, the risks may be higher, but can be overcome with employee training. I'm guessing that employees writing down their passwords (or choosing lame passwords) is a bigger problem in that setting.

Like everything, risks exist, there is no magic bullet, and proper precautions can mitigate that risk.

Zero Knowledge

[nestler]

Other ZKP (Zero Knowledge Protocols) protocols such as SRP allow you to prove your identity to a server without ever sending any sensitive data (like your password) over the network. Implementing Kerberos, SRP or other ZKP protocols into SSH would make man in the middle attacks more difficult.

Neither SRP nor Kerberos are zero knowledge protocols. A zero knowledge protocol ('proof' is actually a better term than 'protocol' here) is a very specific mathematical thing. It involves a prover proving something to a verifier in such a way that the verifier does not gain the prover's knowledge; only the fact the the prover has that knowledge.

As an example, it is possible to do a zero knowledge proof to some verifier that I know the discrete logarithm of a given number (mod some prime p) without giving away what that logarithm is. The verifier does not learn anything from this. The official definition says that the verifier himself could have simulated anything I said during the proof. This official definition (a simulation argument) is what is missing with things like SRP and Kerberos.

Ignorant security "experts" (Seifried and others) spout off stuff like "well, it doesn't look like you send out any important info, so it's zero knowledge". Zero knowledge is a not a flashy adjective to toss around to impress people; it's a mathematically precise term. It requires formalism (a simulation argument) for a protocol to earn this designation, not just some rambling and hand-waving.

Bruce Schneier's book Applied Cryptography has sort of a brief introduction to the topic. For more info, one should look into the cryptographic literature. I believe Schneier's book lists some good papers on the subject in the references.

Re:Zero Knowledge

[Paul Crowley]

See my comment Zero Knowledge - you are right, but... in response to your response to me.

It's important to emphasise that SRP is *much* better than Kerberos, this caveat notwithstanding.
--

Translation

[srhea]

I really just wrote an article about how security is hard, and involves a lot more than just software. User interfaces are particularly important. Anyway, I gave it a very doomsday title just to get more people to read it. I really wish I had something new to say.

-- Seifried

Zero Knowledge - you are right, but...

[Paul Crowley]

Thanks for the comment, and you're right to criticise my imprecise use of the term. In my defence I can only say that David Jablon, designer of B-SPEKE, employs similarly imprecise terminology, though Thomas Wu of SRP avoids it.

Work continues on password protocols about which good things can be proven: check out Stefan Lucks's Open Key Exchange for a password protocol that uses a simulator-based argument under the Random Oracle model to prove that finding a more efficient attack is dependent on breaking the underlying public key cryptosystem. AMP is another proposal in the works.
--

Re:best not of

[QuantumG]

see you appear to have tracked down two of my posts to reply to my sig line (why not try a recent post and put a name on it so I can actually reply to you?) I'll respond here and hope you get it. For archival purposes my sig line is currently:

The guy who invented the ice cube tray best not of applied for a patent

and Mr AC here doesn't seem to think "best not of" is valid english. Now I can only assume that our friend here is not an english speaker because "best not of" is a similar to saying "better not of" but is slightly more strong, implying that the threat implicit in "better not of" is taken to an extreme. Our AC friend however would probably debate the legitimacy of the sentence fragment "better not of" and to this I can only direct Mr AC to a linquistics book where he will discover than grammer is a descriptive disciplin, not a prescriptive one. That is to say, grammar is used to describe how people talk in a particular language, not how they should speak. If one cares to debate this opinion then one need only look at "Old English" to determine that language indeed does change and that such change is to be welcomed.