August 2007 - Wine-Devel - list.winehq.org

Re: RFC: root cert tool

by Juan Lang

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

Aug. 15, 2007

Re: RFC: root cert tool

by Paul Millar

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.

Aug. 15, 2007

Re: RFC: root cert tool

by Juan Lang

> 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

Aug. 15, 2007

Re: [PATCH] Fix Bug in DeadZone calculation

by Kuba Ober

On Wednesday 15 August 2007, Andrew Talbot wrote: > Kuba Ober wrote: > >> You calculating center wrong: > >> > + ret = (props->lMax-props->lMin)/2; > >> > >> This won't work for min=1000 max=2000. > > > > But it does. Maybe you meant if min/max were switched? In such case > > > > ret = (props->lMax-props->lMin)/2; > > if (props->lMax < props->lMin) ret = -ret; > > > > Cheers, Kuba > > If ret is meant to have a value that is half way between props->lMax and > props->lMin, then I believe there should be a "+" between them, not a "-". > In other words: > > ret = (props->lMax + props->lMin) / 2; Yeah, another case of one (me) reading what one wants to see, rather than reading what's really there. I feel hilarious, having suggested a non-fix (ret = -ret) ;) Cheers, Kuba

Aug. 15, 2007

Re: RFC: root cert tool

by Kuba Ober

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

Aug. 15, 2007

Re: RFC: root cert tool

by Juan Lang

> 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

Aug. 15, 2007

Re: [PATCH] Fix Bug in DeadZone calculation

by Andrew Talbot

Kuba Ober wrote: >> You calculating center wrong: >> > + ret = (props->lMax-props->lMin)/2; >> >> This won't work for min=1000 max=2000. > > But it does. Maybe you meant if min/max were switched? In such case > > ret = (props->lMax-props->lMin)/2; > if (props->lMax < props->lMin) ret = -ret; > > Cheers, Kuba If ret is meant to have a value that is half way between props->lMax and props->lMin, then I believe there should be a "+" between them, not a "-". In other words: ret = (props->lMax + props->lMin) / 2; -- Andy.

Aug. 15, 2007

Re: RFC: root cert tool

by Alexandre Julliard

"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

Aug. 15, 2007

Re: RFC: root cert tool

by Juan Lang

> 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

Aug. 15, 2007

Re: RFC: root cert tool

by Alexandre Julliard

"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

Aug. 15, 2007