| |||||||||||||
|
| |||||||||||||
CAs say few people are getting replacementsCAs say few people are getting replacementsPosted Jun 16, 2008 18:51 UTC (Mon) by endecotp (guest, #36428)Parent article: SSL Certificates Vulnerable to OpenSSL Flaw on Debian (Netcraft)
I think the interesting bit is this linked story: http://www.eweek.com/c/a/Security/CAs-Not-Getting-Big-Res... Even though CAs are offering free replacement certs, people aren't taking them up on it. I would have thought that by this point anyone who knew that they were vulnerable would have had time to fix the problem. The people who are left either don't know they have a problem or don't care. I think we need either: - Browsers to include pre-computed tables of vulnerable keys, as is now done in the Debian ssh packages. Is this practical? - CAs to publish certificate revocation lists for the vulnerable certs that they've issued. Again, I don't know enough about the subject to know if this is possible. - Payment processors to check the certs of their clients and get them to fix them. This is probably the most practical way to go for that important subset of SSL sites. What a mess.
(Log in to post comments)
CAs say few people are getting replacements Posted Jun 16, 2008 19:11 UTC (Mon) by flewellyn (subscriber, #5047) [Link] I just looked up your question regarding revocation. Yes, the CAs can and should issue a revocation list of vulnerable certificates. The X.509 certificate standard provides for such a capability. That the CAs haven't used it yet indicates they aren't taking this problem as seriously as they should.
CAs say few people are getting replacements Posted Jun 17, 2008 2:41 UTC (Tue) by ringerc (subscriber, #3071) [Link] As far as I know most user-agents don't support, or check, a CRL. From what I've seen support generally requires user/admin configuration and mostly seems to get used on SOE setups and corporate intranets.
CAs say few people are getting replacements Posted Jun 16, 2008 19:19 UTC (Mon) by cortana (subscriber, #24596) [Link] > Even though CAs are offering free replacement certs, people aren't taking > them up on it. > > I would have thought that by this point anyone who knew that they were > vulnerable would have > had time to fix the problem. The people who are left either don't know > they have a problem or > don't care. The CAs should have already revoked all certificates that it is possible for them to detect. The fact that they have not indicates that they serve no useful purpose, and are only in the business for the protection money. Not that it matters. Even if all the CAs shipped by your browser had updated their Certificate Revocation Lists, your browser will not bother to check the lists. What should really be done is for browser vendors to drop all CA certificates that do not specify a working OCSP responder, and configure their browsers to always do OCSP validation, aborting if there is an error or failure. But that will never happen. > - Browsers to include pre-computed tables of vulnerable keys, as is now > done in the Debian ssh > packages. Is this practical? It isn't. According to https://bugzilla.mozilla.org/show_bug.cgi?id=435082#c7, "Right. 9MB (3MB compressed x 3 bit sizes) is larger than the rest of Firefox and NSS put together. There's absolutely no chance we can ship that. None."
CAs say few people are getting replacements Posted Jun 16, 2008 19:28 UTC (Mon) by bboissin (subscriber, #29506) [Link] Well it could at least use the blacklist if it is available (as it will be likely the case on linux distro), or suggest a plugin.
CAs say few people are getting replacements Posted Jun 16, 2008 19:34 UTC (Mon) by Los__D (subscriber, #15263) [Link] ...and configure their browsers to always do OCSP validation,
aborting if there is an error or failure. But that will never happen.
CAs say few people are getting replacements Posted Jun 16, 2008 19:42 UTC (Mon) by cortana (subscriber, #24596) [Link] It's hardly a single point of failure... it is the CA's job to ensure the high availability of their responder. But you highlight the big tradeoff--that between convenience and security. Currently we are way, way too far into the realm of convenience, and we are paying for it with every data breach.
CAs say few people are getting replacements Posted Jun 16, 2008 19:57 UTC (Mon) by Los__D (subscriber, #15263) [Link] True, but it still limits the points of attack significantly. To many commercial sites, loss of availability is just as bad (or worse?) than phishers. You are trading one kind of security for another, not convenience for security.
CAs say few people are getting replacements Posted Jun 16, 2008 20:00 UTC (Mon) by jwb (guest, #15467) [Link] 9MB is not anywhere near as large as the 50MB+ "phishing protection" database that Firefox already ships. So I think they should ship this blacklist.
CAs say few people are getting replacements Posted Jun 16, 2008 20:47 UTC (Mon) by nix (subscriber, #2304) [Link] Firefox doesn't *ship* that; it's trickled down as needed.
CAs say few people are getting replacements Posted Jun 16, 2008 21:01 UTC (Mon) by jwb (guest, #15467) [Link] What's your point? The same means of distribution can also be used for the blacklist.
CAs say few people are getting replacements Posted Jun 16, 2008 20:49 UTC (Mon) by dfsmith (guest, #20302) [Link] I wonder how many of the "notification of vulnerable certificate" notices ended up in spam folders.... E.g., Dear Webmaster! We've noticed that your SSL certificate is vulnerable. Please visit this web site http://... to receive a FREE replacement SSL certificate! Your CA guys.
CAs say few people are getting replacements Posted Jun 17, 2008 8:28 UTC (Tue) by pjdc (subscriber, #6906) [Link] The one from Thawte landed in my inbox unscathed, about a week after I'd gotten the certificates reissued and installed.
CAs say few people are getting replacements Posted Jun 19, 2008 8:38 UTC (Thu) by jschrod (subscriber, #1646) [Link] OR: https is only used for encryption and server identification doesn't matter.Even though I updated all problematic SSL certs on all my servers, there were several where it would not have been necessary: There SSL is only used for mailman interfaces of public open mailing lists, and I don't give a damn if that mailman server is impersonated by someone else or not. Risk mitigation is here against transmitting passwords in the clear, not against MiM attacks. (We don't use a publicly well known CA, for starters, but have our own.) You might have different risk analysis outcome in other situations, but here we chose to decide otherwise and focus on 1st-order risks to confidentiality and cut off at threats on authenticity (and thus downstream 2nd-order confidentiality).
|
|
||||||||||||