RFC: root cert tool

Paul Millar paul at astro.gla.ac.uk
Thu Aug 16 18:20:43 CDT 2007


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.



More information about the wine-devel mailing list