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