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.

Update: This user-experience was improved in IE10.

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.

-Eric

Comments

• Anonymous
  June 13, 2012
  The comment has been removed

• Anonymous
  June 13, 2012
  @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.

• Anonymous
  June 13, 2012
  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.

• Anonymous
  June 13, 2012
  The comment has been removed

• Anonymous
  June 13, 2012
  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.

• Anonymous
  June 15, 2012
  if the SSL site is on the local host, winverifytrust really ought not to interfere (just as it does not interfere with MD4, on the localhost case).

• Anonymous
  June 15, 2012
  @peter: On one hand, that makes sense. On the other hand, that leads to the problem where developers/IT Pros never know that there's a problem, because "it works on my machine".