Certificate pinning in Internet Explorer with EMET

MSFT has just released a new beta of EMET (Enhanced Mitigation Experience Toolkit) v4 and one of the new features is certificate pinning. Pinning was introduced into mainstream usage by Google Chrome in 2011. Soon afterwards it proved instrumental in exposing the DigiNotar certificate authority breach that allowed Iranian government to intercept communications from political dissidents.

To recap why pinning is an important security feature: as described in earlier posts, the current trust model for digital certificates has a systematic flaw. Almost any one of 100+ trusted “certificate authorities” can fabricate a certificate on behalf of any company– even those located in a different country and have no business relationship with the CA. Such a credential will be happily accepted as authentic by web browsers and every other application about to make critical security decisions based on the identity of the website at the other end.

On the one hand, a diversity of CAs each serving different market segments is great for scaling the model commercially. On the other hand, a situation where all CAs are equally trusted and any one CA can undermine the security of websites served by a peer  leads to a quick race to the bottom in security. There is little incentive for competing on operational security or honesty, when customers are still at the whim of every other CA. Pinning addresses that problem by allowing a website to commit in advance to a set of CAs that it will do business with. That commitment takes all other CAs out of the risk equation. Even if they make a mistake, are compelled by a government to forge certificates or are simply dishonest, any certificates issued for the pinned site will be rejected by users aware of the prior commitment.

The catch is there is no standard for making such commitments. There is no field in the X509 format for a website to declare its intentions about what other CAs it may get certificates from in the future. (There is a draft RFC for HTTPS usage but that is at best partial solution. HTTP headers will not address the code signing case, for example.) Instead both Google and MSFT introduced their own home-brew designs independently.

  

Here are some preliminary observations based on experimenting with a beta of EMET and comparing it to the existing pinning feature in Chrome: (This post may be updated as more information is available.)

• Caveat emptor: certificate pinning only applies to Internet Explorer, unlike other EMET protection which apply broadly to all applications. This may seem obvious– after all Chrome pinning only applies to Chrome– but the difference is Windows provides a general purpose cryptography API for verifying certificates. IE happens to be just one consumer of the API. Many other critical applications both from MSFT (Skype, Office, …) and third-party ISVs would have benefited if pinning was added at lower-level in the platform instead.
• Fine-print continues: pinning only works for the standard version of IE which has 32-bit renderers. It does NOT work with 64-bit renderers used by Enhanced Protected Mode. This is a problem. EPM itself is a security feature; for example, it has additional mitigations against memory corruption vulnerabilities. Asking users to disable one defense in order to take advantage of a completely orthogonal one is dubious at best.
• On the plus side, IE allows importing pinning rules via XML files. [Default configuration] An enterprise can deploy its own constraints to protect employee machines for example. By comparison Chrome pin rules are hard-coded, and can not be modified easily by end users.
• Going into the gritty details
  • Both designs have similar structure for describing the pinning constraints. There are pinning rules identifying a group of acceptable issuers. Then particular websites such as login.live.com are associated with exactly one of these rules. This model makes sense as rules are shared across many sites– all Google sites have the same constraint in the Chrome version, as do all three MSFT sites pinned in the EMET flavor.
  • The rules have roughly similar expressive capability. Chrome allows specifying a set of issuers that are specifically excluded, and can not appear anywhere in the chain– in addition to the usual notion of pinning that whitelists particular issuers. EMET has a blacklist option for unpinned sites.
  • Chrome allows specifying a trusted CA to appear anywhere along the chain, including as intermediary. Judging by the GUI-based configuration utility, EMET only allows white-listing by root CA.
  • EMET permits exception by country of origin of the CA, but this turns out not to be useful: it only allows whitelisting CAs based in a particular region, effectively creating a loophole for the constraint. Similarly the documentation refers to exceptions based on key-size, which seems intended as defense against CAs with short keys, rather than an affinity towards any particular CAs.
  • Chrome identifies certificates by hash of the subject public key. EMET uses the combination of distinguished name and serial number.
• EMET allows rules to have an expiration date. This is useful, since the certificate itself will expire and the website may decide to go with a different issuer at some point. (There is a deeper issue about pinning creating an implicit lock-in: without changing the pinning rules, the site can not switch to different CA because everyone will interpret that as forgery attack.)
• Chrome treats violations of pin constraint as fatal errors. By contrast EMET displays an out-of-band warning toast near the Windows tray that the user is free to disregard:

Notification for a certificate pin error

• By default EMET records such failures as warnings in the Windows event log. Chrome can upload suspicious certificates observed to the cloud.

Windows Event Log, with EMET certificate error

• Chrome makes an exception for private CAs installed on the local machine. These could be used by an enterprise for by-design content inspection, or by developers for monitoring web applications, as in the case of Fiddler or Burp Proxy. EMET appears to have a problem with these cases, flagging them as errors.

CP