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