Microsoft Advisory about fraudulent SSL Certificates
Update: Looks like the update is marked important, but will not install automatically. You may have to run Windows Update to install it
Update 2: And Comodo just published an advisory: http://blogs.comodo.com/it-security/data-security/the-recent-ca-compromise/
also not that this is still the same issue we talked about this morning with respect to Firefox 4.
Microsoft just released an advisory [1] alerting its customers that a total of 9 certificates where issued using the leaked/stolen CA certificated from Comodo.
The affected domains are according to Microsoft:
- login.live.com
- mail.google.com
- www.google.com
- login.yahoo.com (3 certificates)
- login.skype.com
- addons.mozilla.org (already known from an earlier announcement by Mozilla)
- "Global Trustee"
The advisory states that Comodo has revoked these certificates and listed them in its revocation list. Microsoft also is releasing an update that will blocklist these certificates.
Of course, this issue is "serious", not just considering the household brand names affected. Probably even worse then the possible man in the middle attacks that may have happened is the simple fact that this fundamentally breaks the trust model of SSL. SSL is using a "trust pyramid", A few certificate authorities are trusted to issue certificates to entities they trust. Of course this trust should be based on some kind of verification and the ability to secure the private key that goes with the root certificates and the signing certificates based on it. This event more and more looks like the trust pyramid was really more a stinking pile of doo . No surprise given the rush to the "no paper work required bargain basement certs". I recently started using free certs from startssl.com just for that reason: At least startssl doesn't charge me for not verifying who I am.
In short: Patch... and hope you will be ok until the next time this happens. It would be nice if Comodo would come forward with details. It was probably the APT Monster that ate it.
[1] http://www.microsoft.com/technet/security/advisory/2524375.mspx
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Online | US Eastern | Jan 27th - Feb 1st 2025 |
Comments
Spoken so eloquently!
BLAS
Mar 23rd 2011
1 decade ago
Wow.
Susan
Mar 23rd 2011
1 decade ago
Pete
Mar 23rd 2011
1 decade ago
Please read either the Microsoft Security Advisory or the Comodo blog post. Internet Explorer (like Firefox) does not necessarily need this update; as Comodo has updated their CRLs and OCSP responders to provide revocation data. But because of the high profile of the domain names, Firefox and Microsoft decided to release an update that would help ensure that end-users knew these certificates were revoked. This way, the clients don’t need to rely on fetching a OCSP/CRL to know these certs are bad.
Adam
Mar 23rd 2011
1 decade ago
You mean it used to be valid? :) Was that before, or after Verisign gave away a couple of microsoft certs...
Steven
Mar 23rd 2011
1 decade ago
I might not be able to give a signed OCSP back, but then I can timeout, which will make some software work.
Signed DNS (DNSSec) as a requirement and the public key in DNS would be the next step. This would help a lot. Preventing DNS hijacking is the important issue here.
PHP
Mar 24th 2011
1 decade ago
Name resolution shouldn't be a high priority target for an attacker.
The existing DNS system is perfect for what it's supposed to do; like IP itself DNS is a best efforts service, you ask for a name and it gives you one or more IP addresses that probably point to the machine you're after and it does this as quickly as possible.
DNSSEC doesn't change this; connections will still fail, old data will still be cached. What DNSSEC does is improve the security of certain (actually broken) protocols that depend on the DNS structures being perfect. (actually, it can also slow things down a bit ...)
The fact is to use one of the compromised certificated you don't need to poison the DNS, you can get 'in the middle' many other ways; eg: ARP, routing, wifi hacks and so forth. DNS is just the one with the longest range; for the moment.
The only way to actually do the authentication of an unknown peer is the way kerberos does it, using a direct specific query to a trusted third party whom you can authenticate directly. If you do that you have the choice of how long to accept a cached 'ticket' with SSL certificates the 'ticket' is cached by the person providing it to you; probably for years.
Robert
Mar 24th 2011
1 decade ago
Dale
Mar 24th 2011
1 decade ago
Check your approved classifications in WSUS, this is classified as a critical update not a security update.
Scooter
Mar 25th 2011
1 decade ago
It takes 5 minutes to replicate a website. The hack was discovered 2 hours in. Not sure how soon certs were blocked, blacklisted. Would this mean some users have lost information including personal data? Should we be advising all to change their passwords? A lot can happen inbetween the point of certificate publishing and certificate black listing.
Paul
Mar 28th 2011
1 decade ago