[18287] in bugtraq
Re: "The End of SSL and SSH?"
daemon@ATHENA.MIT.EDU (Martin Rex)
Thu Dec 21 15:36:05 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <200012211520.QAA19665@hw1464.wdf.sap-ag.de>
Date: Thu, 21 Dec 2000 16:20:03 +0100
Reply-To: mrex@sap-ag.de
From: Martin Rex <martin.rex@SAP-AG.DE>
X-To: perry@PIERMONT.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <877l4w5lzq.fsf@snark.piermont.com> from "Perry E. Metzger" at
Dec 19, 0 01:01:13 pm
Perry,
Perry E. Metzger wrote:
>
> Kurt Seifried in an article on SecurityPortal shrilly entitled "The
> End of SSL and SSH?" claims that SSH needs a PKI to be secure.
I don't like the general bashing of SSH and SSL either, however there
are grains of truth in those articles. The problem is not with the
protocols SSH or SSL itself, but with the environments these protocols
are used in *today* or bad combinations of these protocols with others.
(1) the significance of a secure key storage.
SSL: All Web-Browsers that I know keep Root-CA certificates in software
and it is quite possible for software to modify Root-CA certs
or to add new Root-CA certs, which subverts the whole
PKI trust model. Modifying this storage is not that difficult,
given the doors and bugs in Javascript, Java, ActiveX and
Browser plugins. And the more application vendors move over
to using Web-Browsers as frontends, the more (signed)
general-purpose lauch pads will be installed and used.
SSH: With SSH the known_hosts file is kept in the home directory of
the user and it only protected by means of the underlying OS.
On multi-user machines or with homes in network file systems
(like NFS), this OS-protection might be extremly weak,
especially on computers under central administration
in large companies.
(2) the significance of secure key distribution
SSL: Web-Browsers area shipped with >100 preconfigured CA certs
these days. Most Browsers can be downloaded via the Internet,
but many of the distributions are still not signed --
how do you know they haven't been backdoored with additional
Root-Certs?
SSH: building up a known_hosts file by connecting new hosts and
having the added after acknowledging SSH's warning is
very common. Quite a lot of people go to IETF meetings
without their own Laptop (me 2, I don't have a Laptop).
How many of them use SSH on a public PC in the terminal room
to dial into one of their own machines? How many of them
do bring their own known_hosts with them?
(3) the significance of correct protocol usage
SSL: Many online shops on the Web only perform payment via HTTPS (SSL),
catalogue browsing and filling the shopping cart is often
done via plain HTTP. The HTTPS link for the payment is not
typed in by the user, but it is a simple HREF, GET or POST
of an HTTPS URL, served in an unprotected document -- which
can be subverted. It's much easier to MITM the HTTP channel
that serves the document with the HTTPS url that to
MITM the actual HTTPS channel.
SSH: If SSH is used to replace telnet among hosts, but the home
directories are still shared via NFSv3, then it might be
quite simple to succeed an SSH authentication...
Still, the use of SSH will reduce the amount of plaintext
passwords travelling the networks through telnet sessions.
The general problem is normally, that security is only as good as
the weakest link in the chain. In many places one will find SSL and/or
SSH in long chains of legacy systems. Even though SSL and SSH
are among the strongest links in that chain, they will not make up
for the weak links.
One of the features of SSH and SSL is that they can be used for
Single Sign-On. In fact, they are used in such a fashion and
are becoming more and more popular for this feature (as are other
SSO-systems such as Kerberos or Microsoft's NTLM). In the presence
of weak legacy systems/protocols, the Single Sign-On turns into
a "Single Break-In", i.e. one hole in a large network of SSO-enabled
machines may give me access to all of them, in spite of the quality
of the SSO authentication protocol against brute-force guessing.
This affects SSL in Web-Browsers, Kerberos if you happen to find
a valid credential cache, SSH if you happen to find the socket
to a working ssh-agent or X11-forwarding.
What I don't like about X.509-based PKIs is that they are growing
in the direction of insecurity, i.e. when you expand your trust
you add new risks = you lower your security. If a single trusted
CA gets subverted, you loose.
With PGP/GPG-style "certificates" it would be possible to increase
the security. You could require a certificate to carry several
signatures from different authorities in order to be valid.
Subverting a single signing authority (CA) wouldn't immediately
subvert all your systems.
One final problem with HTTPS (a particular use of SSL) is, that the
servers are never acutally authenticated, they're only identified.
There is a simple plausibility check of a FQDN against the CN=
part of the subject distinguished name. (1) The signing CA is
irrelevant as long as it is among the set of >100 CAs preconfigured
in the Browser. Will you feel comfortable when your bank's
server identifies with a certificate from a foreign CA you've
never heard of before? (A CA that sneaked in with a previous
browser update, or even with a previous OS service pack!).
Your Browser will give you the same warm fuzzy illusion of security!
(2) domain abiguity: There is no obvious difference between
www.openssl.org and www.openssl.de for all casual humans.
However the domains are owned by different organizations!
How do people come up with URLs for Online shops? Quite
often by guessing the second level domain and then cycling
through the known TLDs. This is not exactly secure.
And then there are those numerous domain name disputes.
There have been quite many domains transferred. I don't know
whether any of the CAs closely tracks domain name ownership
once they've issued a server cert, but as far as I know,
my web browser doesn't check CRLs to see whether server
certs have been revoked by the issuing CA.
-Martin
