Authenticode, HTTPS, and Weak RSA Keys

Over on the Microsoft PKI blog, there’s some important information about upcoming changes for website operators who use HTTPS or deploy Authenticode-signed applications or ActiveX controls.

Weak RSA Keys Blocked

To briefly summarize the PKI team’s post, a security update coming to Windows 2008, Win7, Windows Vista, Windows 2003, and Windows XP in August 2012 will treat as invalid signatures that use RSA keys that are weaker than 1024 bits. That means that a HTTPS site that uses a cert with a weaker signature in its chain, or an ActiveX control signed by such a certificate will be blocked as having an invalid signature.

Within IE, this blockage will be visible via a notice that a executable or ActiveX control "was reported as unsafe”:

WinVerifyTrust will report a signature error for such files, because weak RSA keys do not provide a meaningful degree of protection. Regular readers will recall a similar issue when Windows began rejecting MD2 & MD4 signatures. An exception is made for ActiveX controls or Authenticode signed downloads that have a cryptographically-validated timestamp showing that they were signed prior to Jan 1, 2010.

For HTTPS sites, the blocking experience is different. When navigating to a HTTPS page that relies upon a weak RSA key for security, navigation will be interrupted by the “Problem with security certificate” error page:

In this situation, the “continue to this website” link will be non-functional; you cannot use the browser UI to override this blockage.

Prior to IE10, you can distinguish the source of this error from other HTTPS errors by the lack of a specific “error text” message appearing at the normal location; e.g. in the HTTPS Subject CN Mismatch error, you see the following explanatory text:

Faster Certificate Revocation

The PKI team also announced a new improvement for helping address certificate revocation latency, which you can read about here. The highlight is that the new feature provides dynamic updates for revocation information so that Windows clients can be updated with untrusted certificates at most within a day of the information being published (no user interaction required); this updated information helps serve as a backstop for Windows’ existing certificate revocation checking support.

It still boggles my mind that we have the completely unbreakable (well, supposedly intractable 🙂 ) encryption system of RSA and AES, but it's all backed by the wishy-washy mess of the current PKI. It would be really nice if we could find and move on to an alternative method of trust.

Somewhat back on-topic, your screenshot of IE raises a question I've had for a while.

When you click the "Click here to close this webpage" link, you're presented with the standard Javascript (sorry, JScript :P) confirmation box asking for permission to close the window (because it wasn't opened with Javascript). I realize that IE's error pages are just resources a DLL or on the filesystem somewhere, but why doesn't it treat them specially to avoid this confusion? Or was this left enabled on purpose, to make sure the user really wants to navigate away (considering the slight cognitive dissonance generated by a green link — usually the "go ahead" color — actually resulting in a halting of events)?

@Nick: Yes, we probably should make the "Close this page" link not prompt the user *if* there are no entries in the browser's back stack. If there are, we want to make sure that the user has the opportunity to cancel the close.

It would be much better to have some specific text about the issue, rather than basing it off the lack of specific text… That could be any number of actual issues, and means that its really hard to figure out what the issue is.

Also, just re-reading it, its not great that there's a "continue to this website" link if its not functional – not a great user experience.

@Matt: The trouble here is that IE's display is just looking for specific error codes returned by the layers below it. It wasn't designed to report on weak certificates. This update only affects the lowest level of the stack, crypt32.dll. IE itself would need to be updated. It's probable that would affect more than just the UI, at least UrlMon.dll and WinInet.dll – and MS would have to take care that other users of those libraries would handle the new error codes correctly. It might require more opt-in compatibility work.

From my reading of the documentation, UrlMon detects specific errors returned by WinInet and delivers them to the app via IHttpSecurity::OnSecurityProblem, one call per error code. There is no WinInet error code defined for 'weak security', unlike the codes for incorrect certificate name, expired/not-yet-valid, and invalid certification authority.

Mike is essentially correct. WinVerifyTrust returns a TRUST_E_SIG error in this case, which doesn't have a specific UI in the IE error page because it basically never happened in the past, only the most obscure situations would trigger it (e.g. you had two self-signed roots in your Trusted Store that had the same CN but different public keys).

The hope/expectation is that virtually no one will see this new error condition either; this blog post is here only because we know that some user with an odd configuration (e.g. hitting some ancient Java-based legacy server using 512bit certs) will see this IE error page and wonder why.

It's also important to keep in mind that we're talking about the UX for our *already shipped* versions here, not what you'll see in IE10. Stay tuned.