On 5/8/05, Jean-Marc Desperrier <[EMAIL PROTECTED]> wrote: > Frank Hecker wrote: > > And IMO this in turn means we should not let ourselves get distracted to > > the point of single-mindedness by the whole issue of SSL certs and what > > protection they provide (or should provide), but rather also focus on > > minimizing the possibility that Firefox and other Mozilla-related > > products will be vectors for getting keystroke loggers and similar > > programs onto users' systems. This means not only addressing bugs > > causing vulnerabilities but also securing the "distribution chain" for > > Firefox-related code, particularly extensions, including whatever role > > code object signing might play in that. > > That would mean distributing signed executable ? It would not be such a > big deal to distribute the win32 executable signed by a Verisign/Thawte > code signing certificate, as this is the prefered distribution mecanism > for this OS. > I would *in addition* include in the download page some reference to the > code signing certificate mozilla.org uses saying that for complete > security, users should make sure they are not installing software that > is signed by another certificate, even when the signature verifies.
Teaching the use is probably not the answer though it may be part of the answer. > > Securing extensions would require more work. > > There's a bug about signing FF extension in bugzilla, that what closed > WONTFIX. There was some comments by the FF developers that digitally > signing ActiveX has not proved effective against spyware. I somewhat agree, though the reason it's not effective is that it's not really used. Users know they "should" click OK when their computer asks them a question that seemingly interferes with their normal goings on. Having said that I'd point out that signed deceptive (not disclosing) spyware is revoked as a normal course of operations at VeriSign. I don't know of a single case where VeriSign has refused to revoke a certificate that was used in a manner violating policy (policy varies by the CA in question, the rules for BREW certificates is different than the rules for cable modem certificates, or SET certificates etc). > I agree with that but I maintain digital signing is still the solution > only with some additional measures, in one word making sure an > *effective* revocation framework is in place. That is part of the solution. Another part is requiring signatures - perhaps only to access certain APIs. > > At the moment, no commercial provider of code signing offers a proper > solution for that, I disagree. VeriSign operates a variety of solutions for a environments with similar if not identical needs. > so I think this would mean mozilla.org would have to > roll out and only accepts it's own authority for emitting the > certificates to sign extensions. As long as the only intended market is > mozilla's intrinsic use, this is not such a big deal, and you could find > competence to do that on this group. Competency certainly. Economically viable would require finding generous volunteers. A commercial CA has the benefit of leveraging their people / systems / bandwidth / crypto hardware across thousands of deployments. Scale matters. > > We don't need to garantee then that all extensions signed with those > certificates will be proper, only that there is a channel that enables > to report and get revoked any certificate that was used in an abusive > manner. Commercial CAs are not very good for that, because there's a > conflict between doing it, and satisfying their clients, the signing > certificates buyers. I disagree. Commercial CAs are quite happy to revoke certificates that are misused - they've done it before and they will continue to do it. The issue is around cause - it is not enough to dislike what someone is doing but rather they must violate policy. Every once in a while someone makes the claim that CAs won't revoke their customers' certificates or that there is a conflict of interest and I just don't buy it. Show me content signed by a certificate chaining up to a decent CA that violates policy (typically this includes violating law or lack of disclosure but may be stricter than that depending on the CA in question). To make this clearer consider who the real client of a CA is; we may collect our money from the certificate enrollees (part or all of the revenue) but ultimatley it is the platform providers who decide if we are trustworthy and control the value of our offering. If IE and Mozilla stopped trusting a CA for SSL that CA would not have a business selling public SSL Server IDs. > On the contrary, mozilla.org purpose is to satisfy > FF's users, if the CA policy says it has the final say on any decision, > there's is then no risk someone can sucessfully abuse signed extensions. Precisely. VeriSign operates thousands if not tens of thousands of CAs under a variety of policies including ones specified by platform providers (OS, hardware, other) and others specified by industry standards and others specified by VeriSign policy alone. > > The next step is to make sure the crl that includes the revocation > information gets widely distributed to FF users. Exerience tells me you would regret going down the CRL path. You want to use OCSP on the client side. > There's already a > mecanism in FF to check for security update, it could be expanded to > also check/download/install the latest version of that crl (without user > prompts). We could find other distribution channel if needed. > > I don't expect this crl will get large. If signed spyware extension > don't work, attackers will very fast give up and try something else. There is something here. Until there is warning or prevention of the installation of un-signed extensions it really doesn't matter if you can revoke signed ones or not. Until there is revocation checking of signed extensions it doesn't matter if you revoke or not. The CA still has the duty but neither the user nor the platform provider benefit. In the case of a walled garden where their is a direct benefit to the platform owner/manager (think tel co or cable co) there is signing requirements and revocation checking. On the internet no one is seemingly concerned enough yet although there has been slow progress over the last few years on this. I think we're on the cusp here and expect significant improvements over the next couple of years. > > One last thing : I see one weakness in the current signature mechanism > for extensions. Only the content of the extension is signed, no title or > description. You could therefore push someone to install a validly > signed extension that doesn't do at all what he expects. This is why policies are important. VeriSign will revoke certificates used to sign code that doesn't fully disclose what the user would want to know (e.g. if the software claims to be a download accelerator and the documentation doesn't mention it is also spywhere that will do it). _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
