On 28/05/14 17:49, Joshua Cranmer 🐧 wrote: > * Insufficiently secure certificate (e.g., certificates that violate > CA/Browser Forum rules or the like. I don't know if we actually consider > this a failure right now, but it's a reasonable distinct failure class > IMHO)
We would refuse e.g. a cert with an MD5 signature. In the future, we hope to refuse certs of insufficient bitlength. > It seems to me that some of these are more tolerable than others. There > is a much different risk profile to accepting a certificate that expired > two days ago versus one that fails an OCSP validation check. Actually, no. Because as soon as a certificate expires, the CA has no obligation to keep revocation information available for that cert. So the two are actually equivalent. That is to say, if a cert is expired, then you may not receive an OCSP response for it. And you can't make any assumptions about what that response might have been - it might have been "revoked". > We have an excellent chance to try to rethink CA infrastructure in this > process beyond the notion of a trusted third-party CA system (which is > already more or less broken, but that's beside the point). My own views > on this matter is that the most effective notion of trust is some sort > of key pinning: using a different key is a better indicator of an attack > than having a valid certificate; under this model the CA system is > largely information about how to trust a key you've never seen before. > There is a minor gloss point here in that there are legitimate reasons > to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL > entropy issue), and I don't personally have the security experience to > be able to suggest a solution here. Forgive me, but that sounds like "I'm going to propose a solution with one glaring flaw that has always sunk it in the past, and then gloss over that flaw by saying 'I don't have the security experience - someone else fix it'." > Doesn't the EFF's SSL Observatory already track the SSL certificates to > indicate potential MITMs? The SSL Observatory's available data is a one-off dump from several years ago. They are collecting more data as they go along, but it's not public. > 1. Any solution should try to only permit the "easy" certificate > override on account configuration. This minimizes scope for potential > MITM attacks. That sounds like a reasonable idea, actually; by analogy with Bluetooth pairing. Gerv _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
