Cris, though I see and understand the issues you're bringing up, I'm
suggesting that in order to solve this 'out of the box' issue, curl is made
by default to trust everyone that presents what would have otherwise been a
good certificate chain, and doesn't trust single length self-signed
certificate chains. Look at an application like ssh or putty, they don't
store certs for doing ssh connections, they ask about the server they're
connecting to. In these cases it is damn simple for someone to be a man in
the middle and get your user name and password when you try and log in.
        What could be used in addition to this sort of behavior would be some sort
of user-interaction and certificate caching. This way curl remembers the
certificates of sites you've visited, and perhaps prompts when it encounters
a new site, or one that differs from that of a cached site. This would be
basically identical to the behavior of ssh.

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

On Tue, 20 Aug 2002 09:53, Bram Whillock wrote:
> 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.

Without someone (the user or the curl package) providing a list of trusted
roots, SSL adds no security. The question is, what is the best approach to
making users aware of this, or method of attempting to enforce the use of
cert checking in some way, so that curl is more secure 'out of the box'?

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

I think curls' cert checking behaviour has been mixed up with the IE/Windows
chaining vulnerability along the way. The two are unrelated. Curl isn't
vulnerable to the chaining issue, because openssl takes care of it properly.
You don't need to get a verisign cert to 'spoof' curl, and it won't help if
you did. The issue is that 'by default', any certificate can 'spoof' curl.
If
a set of root CA certs are provided, then curl/SSL should work 'as
advertised'.

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

An active SSL attack doesn't even know what the client is until the attack
is
complete and it can see the User-Agent :-) curl/libcurl are used in all
sorts of backend contexts, with a range of security profiles. I expect many
people use the php interface to re-submit credit card info over ssl to
payment gateways, for example.

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

Not really - a 'self-signed' certs is just it's own CA - you should be able
to give curl a copy of the cert as a 'trusted root certificate' (like any
other), and it should be happy. You shouldn't need to set up your own CA for
that.

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

Absolutely - but it's (ever so slightly) better than trusting anyone, which
is the current default. At least the list of CA's in IE or Netscape is a
list
of companies with enough money to pay MS or AOL to be included in the
browser. I don't know that that makes them automatically trustworthy :-)

> 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

I didn't really understand which spoofs you think should be checked for,
except for the CA checking? Do you mean 'check the certifcate but not who
signed it'? That isn't any different to not checking. Certificate chain/root
checking is the only thing that prevents an active SSL attack, so it seems
the obvious thing to enforce if you want to close that hole...

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