Certificate reputation, a novel approach for protecting users from fraudulent certificates
At the IETF in London last week, we presented a proposal called Certificate Reputation for detecting fraudulent certificates, in order to protect you from attackers that could have stolen a site’s identity. This prevents malicious sites from phishing your personal information like passwords, bank account numbers, credit card numbers etc. Recent attacks against public and Microsoft CAs (e.g. the DigiNotar and Comodo attacks) led us to develop mechanisms that protect you from such threats.
Background
When you visit your bank site, IE relies on digital certificates (certificate for short) to ensure you are connected to the intended Web site. In order for the certificate to be considered valid, it needs to be issued by a trusted authority. This is similar to driver’s licenses in the United States. The driver’s license is only valid and accepted if it is issued by the Department of Licensing. In the Web world, a “Trusted Certification Authority”(trusted CA for short) issues certificates for Web sites. A certificate issued by a trusted CA is considered legitimate by a browser just like a driver’s license issued by the Department of Licensing is considered a valid form of identification. Browsers maintain a list of trusted CAs that help them verify certificates and establish the identities of sites.
Sometimes, certificates can be fraudulent or issued incorrectly
Trusted CAs are in the business of selling certificates. Normally, the owner of the site hosted on yourbank.com picks one of these trusted CAs, say ABC and works exclusively with them to purchase their certificate. In this case, ABC should know the owner of the site hosted on yourbank.com and should not sell the certificate for yourbank.com to anyone else. However, recent issues with certificates from Comodo proved that these verifications can be error prone. Additionally, the attacker might be able to get the certificate for yourbank.com by either hacking a CA or one of its retailers. Unfortunately, a fraudulent certificate obtained in this manner from a trusted CA will be trusted on all browsers. While there is a very high bar for such an attack, DigiNotar and Comodo were victims of this.
A data driven solution for detecting fraudulent certificates
As you can imagine, this is a tricky problem to solve. This is similar to a “trusted authority” like the Department of Licensing issuing a driver’s license in your name to an impersonator. Since everyone trusts the drivers’ licenses issued by the Department of Licensing, a fake driver’s license would be very hard to detect.
When we got to the drawing board to solve this problem, we set forth some principles and goals:
- Keep you safe from fraudulent certificates on the Internet without interrupting your workflow or preventing access to legitimate sites
- Not require a lot of changes to the ecosystem allowing easier adoption
- Preserve the privacy of site owners
We landed on a solution called Certificate Reputation that utilizes telemetry to detect abnormalities. As you are browsing the Web with IE11 (and have opted in to SmartScreen®), IE sends data to Microsoft about certificates that it encounters while validating server identities.
If a new certificate issued by a different trusted CA (other than the one the site uses typically) is detected for a site, Certificate Reputation can flag it automatically. This positions us to contact the site owner allowing them to initiate a revocation of that certificate or confirm that it is legitimate.
This Microsoft service harnesses the power of data mining and relies on heuristic algorithms. It doesn’t require any action from you and changes from trusted CAs making it easily adoptable and sustainable over a long period of time. In the near future, we hope to automate the notification process as well.
In the future, the certificate telemetry collected by IE11 can be used to monitor CAs’ compliance with industry guidelines and Microsoft Root CA technical requirements for SSL certificates. We can reach out to the CAs when we detect weak certificates, raising the bar for attackers and keeping you safer on the Web. You can read about other ways in which we plan to use this valuable data to improve Web security in this other blog.
Conclusion
With Microsoft’s novel approach for detecting fraudulent certificates, you can feel safer when visiting your favorite bank, email or social networking sites. IE will do this seamlessly by collecting data about certificates in use, detecting new certificates and reporting them to site owners who can revoke them if invalid. This creates a fast and reliable process for revocation which does not require any action from you or trusted CAs and preserves the privacy of site owners. We received a positive response to this proposal from the attendees at IETF as they appreciated Certificate Reputation's goals around privacy and easy adoption. As we continue to engage with the CAs and IETF on this, we would love to hear your thoughts and feedback!
— Anoosh Saboori and Ritika Kapadia, Program Managers on Windows and Internet Explorer
Comments
Anonymous
March 10, 2014
Does your system collect the full certificate if it's unexpected, or only metadata about it? How do you handle cases where the user encounters an expected interception certificate (e.g. because they're debugging with Fiddler or are behind a corporate threat management proxy like BlueCoat, ISA TMG, etc)? The mechanism described doesn't actually protect the current user, does it? Since it's telemetry only, it only informs Microsoft that an interception is going on somewhere in the world, but it doesn't notify that victim does it? It also doesn't help in cases where the attacker can block network access to the SmartScreen service, does it? It seems like supporting one of the various certificate pinning proposals would be helpful to enable protection of the active user rather than some future site visitors? Is there any privacy impact? I assume you're not collecting certificates from sites in the Intranet zone?Anonymous
March 10, 2014
What if these data transmissions to Microsoft are blocked?Anonymous
March 10, 2014
Several major SaaS apps host sites with multiple subdomains to shard content and customers. e.g. cust1.example.com, cust2.example.com, custMajor.example.com and as such have a certificate for *.example.com Historically IE has been extremely suspicious of such wildcard certificates and displays warnings to the user. I certainly hope these "false" warnings won't be sent to Microsoft to potentially further damage the site's certificate reputation.Anonymous
March 10, 2014
No. I do not want you to deny users accessing to my sites. I do not want you to know who is accessing my sites - I don't even want you to know my sites even exist. I do not event want you knowing what sites I access. If you do not trust your CAs, that you have to rely on reputation services (that are rife of false positives/negatives), then you have an even more serious problem.Anonymous
March 11, 2014
When is IE11 coming to Windows Phones ?Anonymous
March 11, 2014
It sounds like the goal isn't to automatically trust or untrust any given certificate but to add a layer of notification when things change so that the site owner can confirm that they did, indeed, intend to change things. Is this the case? Or is this something else and I've misread this post?Anonymous
March 11, 2014
Right around //Build 2014, 2-4 April.Anonymous
March 11, 2014
IE has never made a distinction between wildcard and single FQDN certificates. It doesn't matter as long as the certificate is valid and the wildcarded hostname matches. There is no extra "warning" or whatever you may mean by "suspicious". Note, that sub1.sub2.example.com does not match *.example.com.Anonymous
March 11, 2014
Talking of "Trusted CAs". Just yesterday I read an interesting article on Heise about the fact that over half of the CAs that Windows/IE trusts from the beginning do not ever have issued a publically available certificate. In other words: you could just remove those CAs from the store and not a single user would see a difference. This would drastically reduce the possible attacke surface. The article is here: www.heise.de/.../Ein-Drittel-aller-Zertifikats-Herausgeber-nur-Security-Ballast-2139451.html und the paper it is based on is located here: www2.dcsec.uni-hannover.de/.../fc14_unused_cas.pdf . The paper is in English, the article in German (there used to be English translations of heisec, but I can't find it now).Anonymous
March 12, 2014
The comment has been removedAnonymous
March 12, 2014
@Brenno: We are looking into ways to allow delay reporting when SmartScreen service is blocked. Note that in our threat model, we assume that user is not under attack indefinitely and will be able to send report at some point.Anonymous
March 12, 2014
@Norton: Please note that the only thing that is sent to Microsoft is the certificate chain and not the warning.Anonymous
March 12, 2014
The comment has been removedAnonymous
March 12, 2014
@Nick: You are right Nick.Anonymous
March 13, 2014
Thanks!Anonymous
March 20, 2014
The comment has been removedAnonymous
March 20, 2014
The last 3 posts here are link spam - please clean them up.Anonymous
March 11, 2015
I was asked by Anton Moleda to point to the following conversation from Twitter: twitter.com/.../575418715178729472 It seems you guys have been building something that exists as a proposal for a couple of years now, is not limited to a single Microsoft Product and has an very active IETF Working Group for standardization. From previous comments and the Blog posts it seems you've reinvented CT unless I've missed something. Thanks for your time, Aaron (I'd apprechiate a reply via E-Mail as well: azet@azet.org)Anonymous
March 11, 2015
I've searched for the SmartScreen EULA for some time now, but am unable to locate it. Would you be able to provide a reference? Thanks, Aaron