Re: [PATCH] CURLOPT_CACERTSTORE
OK, I have to ask this - could you build your specific list of allowed CA certs into the app and simply not go get the list from a possibly-tampered-with external file?? That's what this patch is all about. You can load your list of allowed CA certs from your app resource or from anywhere else and then ask curl to use that store. Asking curl to use your store and not destroy your store is what this patch does. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] CURLOPT_CACERTSTORE
On Thu, 12 May 2011, gir...@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
Re: [PATCH] CURLOPT_CACERTSTORE
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. This is ok when the user is just a single person, we should of course trust him to do the right thing. But when the user is a large organization it is the authorities in that organization who determines who everyone in the organization should trust. Under that scenario, the individual user should not be allowed to tamper with the list of root CAs. This is the situation we are facing. 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. Its not my choice, but I can live with that. We incorporate a new libcurl say once a year and it takes just an hour to apply the changes so it is not a big deal. I can of course stand up and argue for my feature, but if no one else is going to need it, its best that the changes are kept private. That CURLOPT_SSL_CTX_FUNCTION looks interesting in that it allows us to plug in to libcurl and do our stuff. I am thinking of enhancing that option to do our stuff if you think the CURLOPT_CACERTSTORE is not for everyone, but that will change the prototype of the callback function, is that ok? will it break backwards compatibility? The callback function will have to be changed as it needs another parameter to say when it is being called as it needs to be called twice, once on creation and once before exit. 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. I don't understand this part. I know only about OpenSSL. I don't know *even the names* of the others so how can I program for them? Mastering OpenSSL was itself a large task and I am not sure I have the time or desire to get to know other SSL packages. 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. No I didn't. It is OpenSSL that still does the bulk of the work. I am merely tweaking OpenSSL to use my cert store instead of what it usually loads. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] CURLOPT_CACERTSTORE
On Fri, May 13, 2011 at 6:07 PM, gir...@shankar-software.org wrote: 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. This is ok when the user is just a single person, we should of course trust him to do the right thing. But when the user is a large organization it is the authorities in that organization who determines who everyone in the organization should trust. Under that scenario, the individual user should not be allowed to tamper with the list of root CAs. This is the situation we are facing. OK, I have to ask this - could you build your specific list of allowed CA certs into the app and simply not go get the list from a possibly-tampered-with external file?? Ralph Mitchell --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] CURLOPT_CACERTSTORE
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? Or is that precaution unnecessary for anything except my unusual corner case? What is the point of trusting root certificates that can be tampered easily? We might as well turn off https and communicate in the clear. 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. I can't make this feature for non-openssl, as I don't know much about them. Also note that your patch has several irrelevant changes that have nothing to do with the specific feature you're working on. It is important that we keep changes separate and that each patch fixes only the intended issue. I forgot about those changes. 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. 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? -- Please don't hesitate to contact me for further assistance or information. Thanks and best wishes. G.Girish. Shankar Software. New 14, Old 8 Shankarapuram First Street, Choolaimedu, Chennai, Tamil Nadu. India - 600094. Cell - +91-984718. http://www.shankar-software.org/ --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] CURLOPT_CACERTSTORE
On Mon, 9 May 2011, gir...@shankar-software.org wrote: This is the first time I am contributing to open source. Hi and welcome and many thanks for your contribution and desire to improve libcurl. Now we'll inspect your work closer and we'll discuss around the specific feature and the way you've implemented it to see where it'll go! We wanted a way to make sure that our program loads data ONLY from our website. To ensure that we decided to use https. But the major weakness of the scheme is that the list of root certificates supplied with the software can be compromised either by the user or his employees or by a third party. I wouldn't call that a major weakness. I think you're bending the existing feature to better suit your slightly unusual corner case. 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. Also note that your patch has several irrelevant changes that have nothing to do with the specific feature you're working on. It is important that we keep changes separate and that each patch fixes only the intended issue. Can't you accomplish the same thing by using an existing callback already? For example the CURLOPT_SSL_CTX_FUNCTION one ? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
