Andrei Korostelev wrote: > Here is what I've realized so far (special thanks to Subrata Mazumda > and Robert Relyea). > > 1. Currently (Firefox <= 2.x) the Mozilla Security Db supports > multiple readers and a single writer only hence it is not safe to > write to the Db while the Firefox is running.
Actually it's worse than that. The DB presently used in mozilla for cert and key DBs supports these combinations, only: a) multiple simultaneous readers and NO simultaneous writers, or b) one writer with NO other simultaneous readers or writers. > The situation is > promised to be improved in future versions of Firefox: the shared Db > has been just checked in to the Firefox 3 trunk. Thus, closing Firefox > is the only solution to safely write to its security Db from the > external process for Firefox <= 2.x. FireFox is always a writer. So, there must be NO other processes that open the DB AT ALL while FireFox has it open. I agree with the rest of what you wrote, down to here: > The major downside of XPCOM approach is that it requires user > intervention: for some reason you cannot pass the certificate trust as > an argument for the certificate import methods (see e.g. > nsIX509CertDB::ImportCertsFromFile) so the user will be presented with > a pop-up dialog where he'll have to tick appropriate check-boxes; Yes. Does that surprise you? It shouldn't. Should web pages be able to alter the user's set of trusted CAs without his knowledge? If they could, what would stop a "bad guy" from installing his own evil root CA certs as trusted in the user's browser, then then thereafter successfully attacking the user's otherwise "secure" pages? With a bogus root CA installed and trusted, an attacker could successfully MITM attack any server he chose. Imagine a rogue employee as your ISP doing that. The user's ability to control what certs he trusts is his PRIMARY DEFENSE against MITM attackers. If we take away that control from the user, and give it to the web site designer, FireFox users would have no reason remaining to trust anything they see in their browser windows, ever again. That's why we require user participation in matters affecting their security. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
