Recently we have had a couple customers complain that our .NET component assemblies
have a fifteen second delay the first time they get loaded. I don't know about you,
but when an application is mysteriously delayed for fifteen seconds on my machine,
I'm reaching for task manager to kill it, so naturally I was quite concerned about
the delay. At first we could not reproduce it, but came to realize the machines
were this delay was noticed were not connected to the Internet. Come to find out
this was problem occurred because Windows is notices that our .NET assemblies have
a class 3 organizational certificate, commonly known as an
Authenticode certificates, digital certificates, or
code signing IDs.
You might be wondering why one would even sign .NET assemblies with an Authenticode
signature since you can use sn.exe so sign assemblies with a "strong name"
- especially if you know that the "class 3 organizational certificate"
cost $400 and the certificates used with sn.exe can be generated by anyone for free.
The short answer is that the certificates used with sn.exe can be generated by anyone
for free. As Don Box notes in his book Essential .NET, Volume
I: The Common Language Runtime:
Although the private key used to sign the assembly is a unique fingerprint for each
organization, it does not provide the same level of nonrepudiation that digital
certificates provide. For example, there is no way to look up the developer's identity
based solely on an assembly's public key.
A .NET strong name certificate is primarily used to establish a very unique "Identity"
for an assembly. A class 3 Certificate provides a higher level of "Trust"
than a .NET strong name certificate provides. For example, since anyone can get
their hands on a certificate used with sn.exe to sign an assembly with a strong
name, anyone could take any assembly, even signed one from a reputable software
publisher, disassemble it, inject it with some malicious code into it (which is
remarkably easy with CLI/.NET assemblies), and resign
it with their own freshly generated strong name key. Now a hacker has just been
able to provide what appears to be a valid, signed, and "strong named"
assembly, even with the assurance that it has not been manipulated since it was
signed, but has malicious code in it.
To obtain a class 3 software publisher certificate, in addition to making a pledge
not to distribute malicious code, the publisher must provide a Dun & Bradstreet
(D&B) rating for their organization. So an enterprise could protect themselves
from the "signed" assembly with malicious code in it described in the
previous example by enforcing a policy that only allows installing applications
that were signed with class 3 certificates, which that malicious hacker is unlikely
to be able to obtain. Although it is not easy, nor likely, hackers have proven they
can obtain class 3 certificates, that's why we can revoke them.
It is very difficult for a malicious person to obtain a class 3 certificate, nevertheless
there is a famous case of someone getting their hands on one in a round about way.
The funny thing about it, is they got their hands on a very special one... Microsoft's.
VeriSign explains what happened
here. Essentially, somebody claimed they were with Microsoft and got two new
certificates with Microsoft's name on them. However, this is why certificates can
be revoked and why certificate authorities such as VeriSign constantly publish their
up to date certificate revocation list (CRLs). You can download VeriSign's CRL
here.
On recent versions of Windows you don't have to download these lists, Windows will
do it automatically. It is thoughtful of Windows to protect you from revoked certificates
without requiring you to worry about downloading these revocation lists, unfortunately
this is the reason some of our customers experience this fifteen second delay the
first time their application loads our assemblies, because they aren't connected
to the Internet. So far the only workaround I now of is to configure Windows to
not check revocation lists. You can do this by following the steps below:
- Launch Internet Explorer and go to Internet Options
- Click on the Advanced tab
- Scroll down to the "Check for publisher's certificate revocation" checkbox and uncheck
it.
If anyone else knows another workaround to this issue please leave me a comment.
If I figure something better out, I'll make another post.
posted @ Sunday, March 13, 2005 3:49 AM