Yes, this does very much depend on your definition of 'secure'. But,
actually, checking for everything but the root certificate problem is a
decent solution to the problem without having to require folks to install a
bunch of root certificates. If someone wants to properly capitalize on the
error originally reported, they would need to get a verisign certificate
(like that's hard) and then use that to sign their own home brewed bootleg
certificate. Most folks aren't looking to fool curl, they're looking to
fool folks using IE or some other browser that will let them do this and let
the browser wave its hand at the bad certificate. So, in summary, some
simple error checking will avoid the usual spoofs Joe Hacker is trying to
throw at folks. You could also reject single depth self-signed certs, which
would make it so that in order to get by curl you'd have to have made your
own CA and had it sign your own certificate.
        If you're not going to have all the CA's you want easily accessible, this
is a pretty good solution. If you're using curl to do some simple automated
ssl downloads this would provide a minimum level of protection.
        In fact, thinking further, it might not be friendly to provide ssl
certificates to curl users as some folks might have issues with instantly
trusting a few hundred CAs (have any of you looked at your certificate store
in IE, I wouldn't trust some of these places!). I think that checking for
these common spoofs is a good compromise between these two issues, and then
leaving CA checking to the user.
        -Bram

-----Original Message-----
From: Cris Bailiff [mailto:c.bailiff+curl_at_awayweb.com]
Sent: Monday, August 19, 2002 4:30 PM
To: Bram Whillock; curl-library_at_lists.sourceforge.net
Subject: Re: curl bad verify SSL certificates

On Tue, 20 Aug 2002 04:24, Bram Whillock wrote:
> Just to clarify things here, ssl does establish a secure connection, no
> doubt about that.

As the saying goes, 'ah, yes but', unless you can be sure who you are
talking
to over the SSL connection (by being able to verify the certificate chain),
you don't have any kind of 'secure connection'.

Without verification, the encrypted connection can be trivially hi-jacked by
an 'active' man-in-the-middle attacker. Bascially, anyone on the path
between
the client and the server (e.g. same LAN, controlling a router or switch or
attached to any network segment you traverse) can pretend to be the server
during the SSL negotiation, then act as a 'transparent proxy' once the
connection is negotiated, passing data onwards to the server (including
re-encrypting using SSL).

(This is not a theoretical attack - try: http://monkey.org/~dugsong/dsniff/
for starters.)

> What we're talking about here is certainty of
> authentication of the remote host. You really can never be 100% certain
> about this authentication because there are any number of ways here that
> the remote host could have been compromised.

Of course, and SSL says nothing about host security - it only protects data
'in transit'. (I cringe each time I see a server claiming 'Secure Site' just
because it uses SSL. How many online stores accept payments over https: then
email the credit card data to some hotmail account? Doh.)

> Without using CA information
> to verify the remote host, you cannot actually verify him because you have
> no root certificates to authenticate his certificates. You could resolve
> the spoofed server problem by checking to see if the only problem with the
> certificates would have been the fact that you can't verify the root
> certificate.

And if you can't verify the root certificate, you might as well stop using
SSL - there's no point. As explained above, users are fooling themselves
they
 think that the 'encryption only' still keeps data private from all but a
trivial attacker. :-(

Cris

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Received on 2002-08-20