Re: bad certificate database
Wan-Teh Chang wrote: If you would like to see this fix in NSS 3.9.1, please add a comment in Bug 53133 and we can work with John Myers to get his fix into the right NSS cvs branch. I did that, and I could also verify it as fixed in the Mozilla trunk. [...] I suspect you would need to delete the old certificate and install the certificate again with the new binaries of NSS 3.9.1 (or 3.10) that has the fix for bug 53133. This sounds bad :-(, because it seems the certs affected by this problem can't be backuped (see dependant bug 217305) ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane, Duane wrote: Those banking/fund protections may apply in some cases in the USA, but they certainly don't always in other countries. If someone steals your credit card number in France, you may still be liable. So SSL security plays a much more important role than you think. I know this from experience. What if they steal your credit card, not because of the certificate, but because of weak security in protecting it in storage? You would still be liable too. Security is after all about the weakest link, what point is there auditing CAs if you don't audit the hosts interacting with finacial information after you send it over the net? The point in auditing the CAs is that it's better than not auditing the CAs at all. Certainly other attacks exist, but attacks on certificates are one type of attacks that is possible. I agree that indeed Mozilla should be reviewed for all types of attacks, not just crypto/certificates attacks, but not that we should ignore crypto/certificates attacks. And how often has it happened I think you'll find is his point, not often if at all, they don't need to use ssl, just look at how much money is lost every year to 419'ers If that's his point, then I completely disagree with it. Just because every other part of Mozilla does security reviews wrong (or not at all) doesn't mean we also should do the same for the NSS and other security components of Mozilla. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian, Ian Grigg wrote: So SSL security plays a much more important role than you think. I know this from experience. You have experience of someone stealing your credit card over a connection? That's something I'd like to hear about. It would be very useful to apply some statistics to the situation. No, I know from experience that if you have a bogus transaction on your card in France, it's up to you to prove it, and the bank will not automatically reverse it. You have to file police reports and so on. It's very painful. I know several other people to whom it happened over there, as well. I don't know for sure how the card numbers got compromised, but through an insecure connection is a strong possibility, since retail transactions in France use smartcards, not magnetic stripes, and more than just a number is required to authorize any retail transaction. The number method is only used for remote transactions (mail order, internet). I also know someone in the US who lost her credit card number over a connection. She did a non-SSL transactions (with a business that didn't have a cert) on a university network. And other students were snooping on the connection and collecting numbers. How much time is spent arguing about crypto/cert attacks? How much time is spent coding for phishing attacks? How many of each attack occur, and how much are people losing on each attack? In the sector I've spent most of my time monitoring, DGCs (digital gold currencies) I've seen maybe 50 phishing attacks. One used SSL. None were protected by the CAs. Zero, zip, nada. That shows that current SSL security with trusted CA is rarely attacked. We should not lower the value of using SSL in this model by adding random CA unaudited certs without distinction. The entire discussion of CA certificate policy is about the SSL with trusted CA case. Any other case is irrelevant to the CA policy discussion, IMO. The other cases are relevant to browser security preferences and defaults. And I'm all for having more security warnings on by default. But it's another discussion. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: bad certificate database
Jean-Marc, Jean-Marc Desperrier wrote: Wan-Teh Chang wrote: If you would like to see this fix in NSS 3.9.1, please add a comment in Bug 53133 and we can work with John Myers to get his fix into the right NSS cvs branch. I did that, and I could also verify it as fixed in the Mozilla trunk. [...] I suspect you would need to delete the old certificate and install the certificate again with the new binaries of NSS 3.9.1 (or 3.10) that has the fix for bug 53133. This sounds bad :-(, because it seems the certs affected by this problem can't be backuped (see dependant bug 217305) Here is what I would do : 1) backup your cert8.db and key3.db files 2) remove your key3.db 3) delete the cert in current Mozilla 4) upgrade to the NSS version that fixes the problem 5) restore your old key3.db 6) reimport your public cert from the CA This should preserve the private key in key3.db, and is probably the only way to do it if the key was generated in the token (not escrowed by the CA), and you were unable to back it up yourself. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
John Gardiner Myers wrote: For reasons you mention, even checking against the latest currently available CRL is at most best effort. I fully concur this is only best effort. This is BTW exactly what I wrote in my message. But it's the level of best effort that *can* be achieved. I don't get why you want to settle for a best effort that is lower than that. I think that not doing that would be what law calls gross negligence. So nextUpdate is really a minimum for the amount of time one should use cached CRLs. I can't follow your logic here. How do you go from even checking against the latest currently available CRL is not perfect to So I don't need to do it, and worse solution are OK ? Even if I wait until the traffic light is green for pedestrian, there might be a car that won't respect it, so I won't care and I'll cross at the red light ? Or more perverse : Even if I wait until the traffic light is green for cars, there might be a pedestrian that won't respect it, so I won't care and I'll cross at the red light ? Do you think that kind of reasonning is correct ? The maximum is a matter of local policy, based on a risk assessment. There's always a risk assessment that can justify anything. In 1998, when the french banks were distributing smard cards with a signature done with a 320 bit long RSA key, their risk assessment was that updating all the ATM would be extremly costly (that was very right), and that the obscurity of the system made the probability of someone discovering the key was weak and breaking it very low, so that there was no way this would cost as much as replacing all these ATM. They ended up being ridiculised, having in a hurry to costly extend the key length to a reasonnable value, and their format loosing ground in favor of the concurrent EMV card format. Anyway, what you say does not even describe the current behavior of NSS. Currently the defined maximum for NSS is *infinite*. If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable. This in my opinion makes the CRL checking in NSS ineffective. When the NSS chech says check OK, a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that. This was recognised as a problem in bugzilla. And probably there's nobody available to correct that. But I can't get the logic of saying it's not a problem. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc Desperrier wrote: Currently the defined maximum for NSS is *infinite*. If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable. This in my opinion makes the CRL checking in NSS ineffective. When the NSS chech says check OK, a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that. This was recognised as a problem in bugzilla. And probably there's nobody available to correct that. But I can't get the logic of saying it's not a problem. Indeed, this is bugzilla 233806 . And while today is my last day at AOL, I will still be working on NSS at Sun from tomorrow. I can't say what the priority of this bug will be over there, but I can tell you that there is a good chance this bug will get fixed, inside or outside my job responsibilities. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Julien Pierre wrote: If that's his point, then I completely disagree with it. Just because every other part of Mozilla does security reviews wrong (or not at all) doesn't mean we also should do the same for the NSS and other security components of Mozilla. The point is, if you set this bar too high does it impact on security in a detremental way in other areas cause people to have sites collecting money without any encryption at all. There are some mediums gaining a lot of market share such as cable internet and wireless that are somewhat inheriently insecure because the nature of them is insecure. Alternatively people after credit details usually don't want one or two they want 1000's of them, and while we're all focusing on CAs and SSL enabled websites these things are poorly secured in other areas, cost in a lot of countries is a significant factor, and because of this online shops may forgo the expense. As stated before only approx 0.3% of webservers have SSL valid or other wise, I'm sure there are a lot of sites out there collecting personal information at the same time. Security should be a whole approach not focus specifically on one part of it that in the current form will leave people with a false sense of security. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Julien Pierre wrote: Security is after all about the weakest link, what point is there auditing CAs if you don't audit the hosts interacting with finacial information after you send it over the net? The point in auditing the CAs is that it's better than not auditing the CAs at all. It's not an absolute. There is no point in auditing the CAs if it achieves little or nothing, in terms of security, and costs money. The reason that Frank wrote his policy on these points, presumably, is that it's not clear that audits of CAs deliver value for money. Certainly other attacks exist, but attacks on certificates are one type of attacks that is possible. I agree that indeed Mozilla should be reviewed for all types of attacks, not just crypto/certificates attacks, but not that we should ignore crypto/certificates attacks. And how often has it happened I think you'll find is his point, not often if at all, they don't need to use ssl, just look at how much money is lost every year to 419'ers If that's his point, then I completely disagree with it. Just because every other part of Mozilla does security reviews wrong (or not at all) doesn't mean we also should do the same for the NSS and other security components of Mozilla. It's one of my points! Another of my points is someone has to pay for it, even if it doesn't happen. So, a good security view will ask, what's the value for money here? iang ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On a crypto security threat model for mozilla
John Gardiner Myers wrote: While denial of service is legitimately in the threat model, the risk of the attack is not increased by marking a CA trusted. If an attacker is able to falsely revoke a cert A and the CA that issued that cert is marked as trusted, the user is denied service. and mozilla users who relied on that trusted CA are harmed. If an attacker is able to falsely revoke a cert A and the CA that issued the cert is not marked as trusted, the user is still denied service. Then the mozilla user community does not rely on that CA, and rely instead on other CAs who take adequate precautions against false revocations, and are not harmed (have less probability of being harmed). So, evaluating CA's susceptability to fraudulent revocations is a worthwhile criteria because it reduces the probability of harm to mozilla users from false revocation. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
