On Thu, 12 May 2011, girish_at_shankar-software.org wrote:

>> I wouldn't call that a "major weakness". I think you're bending the
>> existing feature to better suit your slightly unusual corner case.
>
> How then is the list of root certificates protected against tampering?

It isn't. Browsers and clients typically allow "tampering" so that the client
can decide for themselves which CAs to trust or not trust.

This idea of yours to lock down the CA certs as a means to prevent the client
from being able to access another site is a completely new idea to me and I've
never heard of anyone done so before. (Of course that doesn't mean that people
haven't done it anyway, just that nobody ever discussed it with me or on this
list.)

Most applications will simply just fail if you trick the client to access
another site, as clients typically require some specific resources from the
"real" server that alternatives just don't provide.

As you're using HTTPS, the connection is encrypted so you could just as well
make sure your server sends the correct identifier in a specific reaponse to
the client. The client would then need to get properly "hacked" to get out of
such a check, quite similarly to how it needs to get "hacked" to get out of
your suggested CA cert lock.

> What is the point of trusting root certificates that can be tampered easily?

The whole point is to allow the user to decide which CA to trust and which to
not trust. Trust is a funny thing but you can't shove trust onto somebody and
force them to trust someone. That's not trust, that's something else.

> We might as well turn off https and communicate in the clear.

Then the client can't tell if there's a man in the middle. But if that's
important or not for your case I can't tell.

>> I'm not convinced this is a feature we need in libcurl - and if we do, your
>> implementation of it is far too OpenSSL-specific.
>
> OK. We will apply the changes only to our software, as and when we
> incorporate the latest curl into our software.

Ok, that's your choice. If you can't stand up and argue for your feature then
I think even more that is for the best.

> I can't make this feature for non-openssl, as I don't know much about them.

Of course you *can*. The fact that you didn't and didn't bother to even
consider it is another matter. Heck, I'm personally guilty of adding features
that are OpenSSL specific so I'm perfectly aware of what it means and takes.

In this specific case you basically didn't even make the libcurl code very
OpenSSL specific but left all of that for the application code so I believe it
would be a relatively small effort.

> I needed to make those changes to make libcurl work for me. LoadLibrary
> resolves to LoadLibraryW in my system whereas it should resolve to
> LoadLibraryA always. So these changes make the code more robust. If you
> insist I will submit a separate patch for that.

That would be really nice thanks, as I believe these changes came in under the
radar now for the Windows guys that would or should be interested in these
changes. I personally know very little about that and prefer to not take such
decisions without proper guidance from fellow libcurl hackers with Windows
knowledge.

>> Can't you accomplish the same thing by using an existing callback already?
>> For example the CURLOPT_SSL_CTX_FUNCTION one ?
>
> I checked out this option, suppose that when my function is called I replace
> the cert store with my certstore. Will my function get called again when the
> SSL_CTX is about to be destroyed, so that I can restore the previous store
> so my store is not destroyed?

I figured your app would use a compeletely separate CA cert setup always, and
your code should make sure that when your app tries to connect to the server
the ca cert is in the state you sanction and deem is OK.

I admit I don't have the complete picture so I can't say this with 100%
certainty, which also is why I put it as a question!

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html