Digital certificates are a key mechanism for establishing identity on the Internet. Trust in these certificates is a result of trusting the issuing entity - the Certification Authority (CA). Unfortunately, as a result of a number of CA related incidents over the past few years, that trust has been somewhat undermined. A number of approaches to address this lessened trust have surfaced in academia and industry, including Public Key Pinning, network notary based solutions such as Perspectives and Convergence, and making the list of issued certificates public by either requiring CAs to operate a simple web service, or supporting more complex protocols like Certificate Transparency (CT).
Today, browsers base trust decisions on the inclusion of roots of trust in a root store. Inclusion in that root store is usually based on factors such as WebTrust for CA or ETSI TS 102 042 audits and adherence to industry guidelines published by the CA Browser Forum for SSL certificates. Each browser vendor may specify additional technical requirements.
Microsoft requires each root CA to provide evidence of a successful audit from a qualified auditor annually. In addition, the root CA is also required to sign a contractual agreement to follow technical requirements such as the use of strong cryptographic algorithms.
In all browsers, trusted roots are effectively treated equally, and for the most part, can issue certificates for any domain name. If one CA is compromised (e.g. DigiNotar) or fails to follow its established operating procedures (TurkTrust, ANSSI), the result is often wrongly issued or fraudulent certificates that may be used in Man-In-The-Middle (MITM) attacks to spoof the identity of web sites. CAs are not infallible and when problems do arise, the CA has a very difficult task detecting all fraudulent or wrongly issued certificates quickly or at all.
Detecting fraudulent certificates (or any fraudulent cryptographic statements in general) used in MITM attacks is difficult because the attacker often erases any evidence of issuance from the compromised CA. Detecting attacks from the victim’s point of view is also difficult because the victim do not have data from the perspective of users not under attack for reference.
As the cost of computing power decreases, the likelihood of attacks against weak cryptographic algorithms has significantly increased. In May 2012, a complex piece of targeted malware known as “Flame” was identified which essentially spoofed the Windows Update channel by exploiting a Microsoft operated CA that was still using MD5 and convinced the victims to download its binaries as a security update from WU. This incident taught us that simply requiring all CAs to stop using weak cryptographic algorithms is not sufficient. We must also monitor the ecosystem closely for compliance and drive the ecosystem to switch to stronger algorithms by announcing timelines to block weak crypto algorithms from MS products far in advance.
Microsoft believes the best way to improve the security of certificates is to have the capability to detect fraudulent or wrongly issued certificates in the wild quickly.
Like the SmartScreen Filter built into Internet Explorer that is designed to warn users when they attempt to visit a phishing site, we believe monitoring the internet for fraudulent or wrongly issued certificates should be an integral part of the browsing experience. We also believe that any viable solution to improve the security of certificates cannot add more complexity or place more burden on web site operators and end users.
In Internet Explorer 11, we have extended the telemetry collected by the SmartScreen Filter to include the SSL certificates presented by web sites. We are building tools to analyze this information on our servers to build intelligence about certificates issued by every root CA trusted by IE as seen by our users around the world. Our initial goal is to flag potential MITM attacks using publicly trusted certificates that affect thousands of IE11 users. Over time, we will enhance the feature to detect attacks against a smaller number of IE users.
The following are examples of some of the scenarios where we can detect fraudulent or wrongly issued certificates using this data, in addition to detecting CAs to do not meet the technical requirements defined either in the Microsoft Root CA Program, or in the CA Browser Forum guidelines.
1. A website is using a certificate that is capable of being used as a subordinate CA. This would indicate the certificate has been issued wrongly2. If a website suddenly presents a different certificate only to a certain region where a different CA issued the certificate. This might indicate a possible MITM attack in a specific country or region3. There was a sudden and significant change in the fields a CA includes in certificates it issues. For example, omission or change in the OCSP responder location. This would indicate a CA was either compromised, or has not followed standard operating procedures
When potential fraudulent or wrongly issued certificates have been identified, we will work with the CA to identify the cause. Depending on the severity and scale of the problem, the CA could revoke the certificate using standards based certificate revocation mechanism. In addition, Microsoft may also use the Disallowed Certificate Trust List mechanism to revoke certificates that affect the security of a broad set of Microsoft customers.
Note that that the detection of homoglyphic attacks (where human is fooled due to visual similarity, such as rnyspace.com and myspace.com) and fraudulent certificates issued as a result of insider attacks are out of scope.
Many customers consider internal DNS records to be sensitive information that they do not want to make public. At the same time, they may prefer to purchase certificates from public CAs for servers on their internal network where the server name is under subdomain of a public domain name that is not published in public DNS records. With more businesses permitting employees to bring your own device (BYOD) and use them on internal networks, we believe customers should have the option to purchase certificates from a public CA for internal servers without disclosing internal network information to the public.
We also believe domain registrant should have the option to monitor all certificates issued by all public CAs that contain their domain names, once the domain registrant prove domain registration. Such as service could be similar to the Smart Network Data Service (SNDS) operated by Outlook.com to allow owners of IP address space to help fight against spam. In addition, domain registrants could be notified by email when new certificates with their domain names appear in our database. The domain registrant would have the option to report suspicious certificates to us and notify the CA to revoke the suspicious certificate.
Privacy is a core component of trustworthy computing. Microsoft is committed to helping ensure users’ privacy while providing protection from unsafe websites. Telemetry submitted to the SmartScreen web service for evaluation is transmitted in encrypted format over HTTPS. The data is not stored with a user's IP address or other personally identifiable information. Because user privacy is important in all Microsoft's products and technologies, Microsoft has taken steps to help ensure that no personally identifiable information is retained or used for purposes other than improving online safety; data will not be used to identify, contact, or provide advertising to users. You can read more in our privacy statement.
In conclusion, with IE11, you can feel safer when browsing to your popular email or banking website. We do this in a seamless manner for both user and trusted CAs perspective via collecting telemetry as part of user browsing activity and performing analysis on our backend servers. New certificate related activities for a domain name could be automatically reported to domain registrants who can decide whether it needs to be revoked or not. In summary, Microsoft is working hard to protect you from fraudulent or wrongly issued certificates with a solution that does not require changes to existing web site operations or the IE user experience.
Many thanks to Kelvin Yiu and Anthony Penta for co-authoring this blog post. Also, thanks to Nelly Porter, Kevin Kane, Glenn Pittaway and Magnus Nystrom for their review of this blog post.
SmartScreen is great, and I'm glad to hear you are doing similar work with your internal telemetry information related to certificates. However, declaring that this is an adequate and privacy-preserving substitute for a public database, such as a Certificate Transparency log, is very misguided. Certificates issued by publicly trusted CAs are assertions of identity that will be accepted by billions of systems. Making such an assertion is a fundamentally public act. There is no privacy to preserve. They are "public" authorities.Furthermore, Certificate Transparency does provide the option to issue certificates for internal servers that chain to public roots and do not need to be logged, but only from sub-CAs that are publicly logged and which employ name constraints to prevent misbehavior from having a broader impact.If the analytics that Microsoft is able to perform with its own view of the entire certificate space is useful, surely allowing other interested parties to perform their own such analyses of al of the public statements of trust has its own value. Certificate Transparency is not inimical to privacy, it is about preserving the public trust upon which most user privacy depends.
How will this affect developers using self signed certificates for internal testing??How does it affect performance?? Will websites load slower in IE?
Why would you want homograph attacks to be out of scope??
So this is like http://convergence.io/ http://en.wikipedia.org/wiki/Convergence_(SSL)What's the difference?
@Brad Hill: Thank you for your comment. We definitely agree that allowing other interested parties to perform their own analysis of certificate space, without violating privacy of site owners, is valuable and should be encouraged. Examples include EFF observatory.While CAs are publicly trusted entities, the information contained in certificates are not necessarily public information. This is analogous to DNS records. For a given public domain (such as microsoft.com), we make decisions about what machine names and subdomains under microsoft.com to be exposed in our public DNS records. DNS records for internal network names are kept strictly within our internal DNS servers. As we have argued in the blog post, public CAs play a key role in enabling TLS in BYOD scenarios on internal networks. As the registrant of microsoft.com, we want access to information about certificates issued by all public CAs that asserts any hosts in the microsoft.com domain but we don’t necessary want the public to know about these names.Our approach with IE 11 enables future development that allows web site owners to be notified upon changes to their certificates. We believe that this provides the most protection for our users given that web site owners can make the best call about their certificates. Whether allowing other website owners to see each other certificate improves user security is not clear to us.
@rasane: Thank you for your comment. This feature should not have any impact on IE browsing experience.
@EricLaw: While it is possible for us to detect such attacks on post analysis on our backend servers, it was not one of immediate attacks we were trying to target with this feature.
FYI:The site that hosts this post (https://blogs.technet.com) is trying to load an HTTP script. In Chrome, the HTTP script is blocked by default. As a result, the formatting of the page looks terrible. I'd like to think that IE is also probably blocking the HTTP script, so the blog ends up looking bad for anyone who is viewing it over HTTPS.
@ChrisL: Convergence is a different approach for defining trust model on user browser. When verifying an identity of a site, in convergence, instead of relying on one CA, user browser will rely on votes from notaries to establish trust on that site. IE 11 feature that is described in this blog post does not alter trust model of user browser. It collects telemetry which are then used in post processing to detect fraudulent certificates. This telemetry collection does not require any user action. Indeed, there is no impact on user experience directly, except for cases when fraudulent certificates are detected. In that case, that certificate is revoked and user browsing to that site is blocked.
@Adrienne: Thanks for your feedback. I will share this problem with TechNet owners.
How does SmartScreen protect victims where the attacker can partition them from the SmartScreen service, such as the Iranian victims of the DigiNotar incident?
@Brad Hill: Sorry for late post. Somehow, the request for publishing got buried in my emails. Answering your question, SmartScreen SSL data collection is protected by SSL channel. We are looking into enhancing it against DNS poisoning.