Slashdot Mirror
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.
← Back to Stories (view on slashdot.org)
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
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.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
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?
Well this guy bashes everyone and everything. Except centralized authentication.
/. 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.
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
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.
this space for rent
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.
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
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.
--
Xenu loves you!
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?
How we know is more important than what we know.
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
Don't piss off The Angry Economist
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.
--
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
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.
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.
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.
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.
--
Xenu loves you!