The Continuing End of SSH/SSL 60
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.
This discussion has been archived.
No new comments can be posted.
The Continuing End of SSH/SSL
Related Links Top of the: day, week, month.
The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.
What a lame attempt (Score:1)
SSH/SSL is still better off than nothing at all (Score:5)
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
Conspiracy Theories (Score:3)
Re:SSH/SSL is still better off than nothing at all (Score:3)
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.
nothing new here (Score:4)
SSH and SSL, when used correctly, can provide good security. They aren't idiot-proof, but then again, what security system is?
Re:SSH/SSL is still better off than nothing at all (Score:2)
Sure, Verisign is the dominant authority, but they're not without competition.
He's right (Score:1)
Crypt-kiddies and Script-kiddies are basically the same.
I don't get one point (Score:5)
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
What's the use then? (Score:1)
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? (Score:2)
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? (Score:1)
But if the attacker is sniffing, wouldn't they have also sniffed the key in the beginning of the session?
Re:nothing new here (Score:2)
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?
MITM is nothing new, and there are solutions (Score:1)
Is this really a problem? (Score:4)
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:SSH/SSL is still better off than nothing at all (Score:1)
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
Missing the point on client soft key change msgs.. (Score:4)
I use PuTTY [greenend.org.uk] 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. (Score:1)
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" (Score:3)
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:I don't get one point (Score:2)
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:What's the use then? (Score:1)
Monday's Experts (Score:4)
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?
Re:SSH/SSL is still better off than nothing at all (Score:1)
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.
If you're already rooted... (Score:1)
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:nothing new here (Score:1)
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:SSH/SSL is still better off than nothing at all (Score:1)
--
Murphy said (Score:1)
--
Re:I don't get one point (Score:2)
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:SSH/SSL is still better off than nothing at all (Score:1)
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.
See? Kurt is spreading FUD (Score:2)
-russ
Re:What's the use then? (Score:2)
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.
--
Obsolete? (Score:1)
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 (Score:1)
And that is why your message is score 0.. frankly, I think it should be -1, offtopic.
Re:If you're already rooted... (Score:1)
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...
The human brain is obsolete (Score:1)
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...
Re:nothing new here (Score:1)
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).
Not impressed with Seifried's followup (Score:3)
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:What's the use then? (Score:1)
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.
Human mistake (Score:1)
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.
Re:Not impressed with Seifried's followup (Score:1)
He doesn't argue very well and is way to dogmatic, loosing sight of the big picture.
Re:I don't get one point (Score:2)
Sigh, even your followup is more FUD.
Is this a real problem? (Score:1)
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.
Re:What's the use then? (Score:1)
thanks for clearing that up!
Re:What a lame attempt (Score:1)
rooted (Score:1)
Re:Not impressed with Seifried's followup (Score:1)
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.
Exageration in the extreme (Score:3)
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.
Re:SSH/SSL is still better off than nothing at all (Score:2)
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.
Zero Knowledge (Score:2)
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:"Security is a process, not a product" (Score:1)
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.
Translation (Score:1)
-- Seifried
Zero Knowledge - you are right, but... (Score:2)
Work continues on password protocols about which good things can be proven: check out Stefan Lucks's Open Key Exchange [uni-mannheim.de] 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:Zero Knowledge (Score:2)
It's important to emphasise that SRP is *much* better than Kerberos, this caveat notwithstanding.
--
Re:Conspiracy Theories (Score:1)
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:Is this really a problem? (Score:1)
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:nothing new here (Score:2)
Yes, they do. That's why every car with airbags has a permantantly attached label with the user instructions.
Re:Conspiracy Theories (Score:1)
Re:SSH/SSL is still better off than nothing at all (Score:1)
Re:Is this really a problem? (Score:2)
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:best not of (Score:1)
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.
Re:Is this really a problem? (Score:1)
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.