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