Since there wasn't a clear consensus about how to get CA certificates into the registry, I decided to do what Mono does: punt. So I've written a tool that can load certificates from a file or from a URL and stick them in the registry. By default it assumes you want to download them from Mozilla's CVS front-end, and does so. A patch that adds it is attached. Comments? Thanks, --Juan
"Juan Lang" <juan.lang(a)gmail.com> writes:
Since there wasn't a clear consensus about how to get CA certificates into the registry, I decided to do what Mono does: punt. So I've written a tool that can load certificates from a file or from a URL and stick them in the registry.
Do we really need them in the registry at all? It would seem a lot safer to load them directly from some system dir. -- Alexandre Julliard julliard(a)winehq.org
Do we really need them in the registry at all? It would seem a lot safer to load them directly from some system dir.
The trouble is not knowing which is the correct system dir / file. It changes from distro to distro, from version to version. Guessing seems less safe (to me) than getting them from some known-good source, or from allowing the user to specify the correct source. --Juan
"Juan Lang" <juan.lang(a)gmail.com> writes:
Do we really need them in the registry at all? It would seem a lot safer to load them directly from some system dir.
The trouble is not knowing which is the correct system dir / file. It changes from distro to distro, from version to version. Guessing seems less safe (to me) than getting them from some known-good source, or from allowing the user to specify the correct source.
As long as you don't try paths under /home, even a moderate amount of guessing seems safer than storing them in a user-writable file. How many different paths are there really? -- Alexandre Julliard julliard(a)winehq.org
As long as you don't try paths under /home, even a moderate amount of guessing seems safer than storing them in a user-writable file.
I'm not sure I agree. If the threat model is a user doing dumb things, there's no protection against that. If the threat model is a rogue Windows program installing bad CA certs, that particular attack would only work in Wine. Our install base is too small to consider that likely. If the threat model is a winelib program or an external process installing bad CA certs, ditto.
How many different paths are there really?
I don't know. On my current machine, there are two equally probable locations, depending on whether I'm looking for OpenSSL's certs or Apache's. On my laptop, there was one (different) location for OpenSSL's certs for one distro version, and another (distinct yet again) for another version of that distro. So I haven't done a complete sample, but on the three distros I've used within the last year, there are at least three different locations. I don't mean to imply that the limit of the number of locations as the number of distros goes to infinity diverges, just that I haven't found a strict upper bound yet. --Juan
On Wednesday 15 August 2007, Alexandre Julliard wrote:
"Juan Lang" <juan.lang(a)gmail.com> writes:
Do we really need them in the registry at all? It would seem a lot safer to load them directly from some system dir.
The trouble is not knowing which is the correct system dir / file. It changes from distro to distro, from version to version. Guessing seems less safe (to me) than getting them from some known-good source, or from allowing the user to specify the correct source.
As long as you don't try paths under /home, even a moderate amount of guessing seems safer than storing them in a user-writable file. How many different paths are there really?
This should be a configure-time parameter to be set by packagers in the distro specific manner. Seems like a "duh" to me. Wine won't be the first software set up like this. Cheers, Kuba
Do we really need them in the registry at all? It would seem a lot safer to load them directly from some system dir.
I really should think longer before arguing with your feedback ;) Maybe the Root store should be a read-only one that reads from some system path set in the registry, and doesn't copy the certs in the registry. Does that seem reasonable? Then, as Kuba suggests, the packagers can set it up for people installing that way. --Juan
Hi Juan, Sorry I was going to reply earlier but was distracted... On Wednesday 15 August 2007 00:08:23 Juan Lang wrote:
Since there wasn't a clear consensus about how to get CA certificates into the registry, I decided to do what Mono does: punt. So I've written a tool that can load certificates from a file or from a URL and stick them in the registry.
Ta. I've had a quick look. A couple of minor comments: You might want to include "BEGIN TRUSTED CERTIFICATE" as an option when parsing PEM-format files. All the root CAs I've seen don't use this, but apparently its a possibility. Also, OpenSSL (but unfortunately not GnuTLS) can scan a directory, loading all files like <serial>.0 (e.g. "a87d9192.0"). Adding support for something like that might be useful, but certainly not urgent.
By default it assumes you want to download them from Mozilla's CVS front-end, and does so.
A patch that adds it is attached. Comments?
Hmmm, I think we could do better than downloading from an static (well-known) URL. As Jan Zerebecki put it:
The problem with that is that what we want to download here are certificates. So for them to be of good use one needs to obtain them in a way so that the trust chain doesn't break too much.
Exactly. This is one of the big problems with PKI: obtaining the CA root certificates. In general, it's impossible to do this reliably using just the Internet: some out-of-bound traffic (Phone, FedEx?) is needed to establish the trust.
The easiest way to get that is by distributing them with the normal source (and thus also with the distribution specific packages). Those are usually signed. [...]
One of the nice features of git (if I've understood correctly) is it's cryptographic internal consistency checks: if one trusts the first SHA-1 hash then all subsequent git-objects can be verified: you know the tree is always as Alexandre intended. There's still the problem of how can Alexandre know that the CA Root certificates on his hard disk are valid. This would require CDROM+FedEx (or similar). However, by distributing the CA root certs via git, we can verify them independently (by use, if nothing else). This effectively pushes the possible Man-in-the-Middle attack back to somewhere upstream of the last common component of the set of tester's network. Given a sufficiently large set of testers, this is the CA website itself. Probably "good enough". Just my 2c worth :-) Cheers, Paul.
Hi Paul, I appreciate the feedback.
Ta. I've had a quick look. A couple of minor comments:
You might want to include "BEGIN TRUSTED CERTIFICATE" as an option when parsing PEM-format files. All the root CAs I've seen don't use this, but apparently its a possibility.
Okay, I'll keep it in mind. If no one's using it I won't be in a big hurry. Thanks.
Also, OpenSSL (but unfortunately not GnuTLS) can scan a directory, loading all files like <serial>.0 (e.g. "a87d9192.0"). Adding support for something like that might be useful, but certainly not urgent.
Yeah, like above, I'll let usage dictate how quickly I get on that ;)
Hmmm, I think we could do better than downloading from an static (well-known) URL.
So do I, but mono does it, so I was lazy too ;)
Exactly. This is one of the big problems with PKI: obtaining the CA root certificates. In general, it's impossible to do this reliably using just the Internet: some out-of-bound traffic (Phone, FedEx?) is needed to establish the trust.
Yes, that's true, but if trust truly is the issue, we have to ask what exactly is being protected. Right now, in Wine, it's precisely nothing. Even once all the cert checking code is implemented, the apps that use these APIs are few. Running firefox in Wine, for example, uses its own certificate stores - downloaded from the Internet as part of the installer - and not any certs installed locally. In my personal opinion, certificates don't say as much as we'd like them to. If we'd never used certs with SSL, perhaps eavesdropping attacks would be more prevalent, but that doesn't seem likely either - one can use key negotiation protocols that don't assume you trust the other end. Man-in-the-middle attacks might be more likely - but they apply to downloading Firefox in the first place, so the fact that we ignore them means that they're either not that much of a threat, or that people don't care about them. Attackers - and I'm thinking of the web here - seem to be much more likely to engage in social engineering attacks, perhaps because users can't tell the difference between SSL-protected sites and ordinary ones, nor can they articulate the difference between the two, even if they can discern it. (I can dig up some paper references on this if you like.)
One of the nice features of git (if I've understood correctly) is it's cryptographic internal consistency checks: if one trusts the first SHA-1 hash then all subsequent git-objects can be verified: you know the tree is always as Alexandre intended.
That's true, and it's partly the reason I sent a patch adding the certs to the registry as my first attempt. The problem is that certs are opaque (asn.1 encoded,) so Alexandre can't easily judge whether the certs are correct. So for perhaps just this reason, or perhaps also that he doesn't feel they should be in the registry at all (see his other emails), that patch wasn't committed. That led me to this approach. What do you think of my most recent suggestion, that the Root store should not read from the registry, but should read from certs installed locally, where the path to them is set in the registry? Thanks, --Juan
On Wed, Aug 15, 2007 at 12:02:17PM -0700, Juan Lang wrote:
What do you think of my most recent suggestion, that the Root store should not read from the registry, but should read from certs installed locally, where the path to them is set in the registry?
I guess that is a good and felxible solution. That should push any trust concerns to the distribution that wine is running on. (Which is a good thing as e.g. for Debian you only ever need to obtain a installation cd from a trusted source once and after that can rely on the signature on packages, I would imagine that this is similar for other distributions.) Jan
Hi Juan, On Wednesday 15 August 2007 20:02:17 Juan Lang wrote: [snip!]
Yes, that's true, but if trust truly is the issue, we have to ask what exactly is being protected. [nothing's using Wine's CA root certs]
Sure, if nothing is using Wine's root store just now it's probably overkill. I'm just a little concerned that one day something will, and assume the Root store is trustworthy.
In my personal opinion, certificates don't say as much as we'd like them to.
I guess, ultimately, it comes down to the individual CA's Signing Policy document; but yes, I guess certificates may not mean as much as people think. They do mean something.
If we'd never used certs with SSL, perhaps eavesdropping attacks would be more prevalent, but that doesn't seem likely either - one can use key negotiation protocols that don't assume you trust the other end.
Sorry, I'm not sure I follow you here. I may be missing something, but I don't see what you hope to get back from an untrusted remote server. For TLS, if both ends have established the session key (via asymmetric encryption, if you happen to have the public key or anonymously, via DH) then the only way to eavedrop is via a MitM attack or a variant. The certificate chain-of-trust is to prevent these MitM attacks.
Man-in-the-middle attacks might be more likely - but they apply to downloading Firefox in the first place, so the fact that we ignore them means that they're either not that much of a threat, or that people don't care about them.
I think also "too (computationally) expensive to do", but it looks like that's changing.
Attackers - and I'm thinking of the web here - seem to be much more likely to engage in social engineering attacks, perhaps because users can't tell the difference between SSL-protected sites and ordinary ones, nor can they articulate the difference between the two, even if they can discern it. (I can dig up some paper references on this if you like.)
I believe you! But, I think this will change (slowly) over time. Attackers (the "informed" ones, anyway: Shannon's maxim) will go after the weakest link. Good enough crypto is where "they" use others methods: Trojans or key-loggers (installed somehow), steal the remote server's hard disk or wait for someone to loose a laptop or the backup tapes. As people get better informed and software better, I imagine attacking the chain of trust becomes more attractive.
[...] The problem is that certs are opaque (asn.1 encoded,) so Alexandre can't easily judge whether the certs are correct.
I think it depends what you mean by "correct": do they function correctly or are they the correct certificates. It would be hard to make the former easy for a human (even for Alexandre) because of the maths involved, with some software its easy. The latter is verifying authenticity, which would require something else (e.g. out-of-band comms). [...]
What do you think of my most recent suggestion, that the Root store should not read from the registry, but should read from certs installed locally, where the path to them is set in the registry?
But, yes, given that most distros have a collection of CA Root certs, using them would make sense. Saves us the bother. Do any Windows applications expect to be able to manage the root store? Cheers, Paul.
participants (6)
-
Alexandre Julliard -
Jan Zerebecki -
Juan Lang -
Kuba Ober -
Paul Millar -
Paul Millar