Fully trust digitally signed assemblies

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello all,
Im posting this question to this forum as well hoping to find an answer. I
had previously posted to the .net security forum but have not gotten a
response yet. Here is the problem.

I have an isolated network where I am not connected to the web. I'm using
some digitally signed assemblies in my .net application and am running the
application from my local drive. Im signed in as admin to the machine. With
Windows 2k, sp4 and .net 1.1. I notice unusually long loading times when
using the digitally signed assemblies (10+ seconds) and I can see that
whenever I launch the app, some network activity is generated. There are some
queries to crl.thawte.com made and the form loads up. Normal loading time is
supposed to be about 1 second.
I have tried using the .net config tool to give full trust to the publisher,
the assembly and so on. But it seems like the .net framework always like to
walk the certificate chain everytime and in doing so needs to be connected to
the net. Otherwise, the timeouts just end up delaying the loading of the
assembly.

If I am running the app from a fully trusted location, why would the
framework need to keep validating the certificate and look up the crl? I
though this would only happen if I'm downloading the app from a url link or
running it from a network.

How do I fully trust a publisher so that I do not get these delays? Can I
somehow force the framework to reduce its timeouts? Or to not check for crl's
online?

Can I install something locally on the system so that it does not require
network access to load the speedy fashion?

Is network access a prerequisite to using digitally signed assemblies ?

Has anyone else run into these problems before?

Thanks
 
Hi Bilal,

Thanks for your posting. From your description, you've a 3rd party assembly
which is digital signed via a certain certificate. When you used it in your
net application, everytime the clr load it, it will take period of time
for the runtime to verify the certificate over net and you're wondering why
we can't turn off this ,yes?

As for the problem you mentioned, I think it is a normal behavior because
the digital sigend info in an assembly is just like the strong-named info ,
which is an evidence of a certain assembly. So when CLR loading an
assembly, if it detect that there is digital signed info(certificate) , it
will first validate the certificate to see whether the certificate is
validated, to do this, it will connect to the certificate's CA over network
and check the CRL on the CA site. So this has nothing to do with the trust
level we grant on the assembly. In otherwords, such validtion steps will
always occur when we load a assembly with a Cerfiticate digial signature.

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
But this behavior is causing problems for my customers, since it any .net app
using our signed assemblies takes 10+ seconds to load up. Plus I was
surprised to see this behavior in the first place, since I was loading the
application from a fully trusted path and the assembly was signed with a
valid certificate timestamp.

And the other surprising thing is that even though a connection is not made
to the CA's crl list, the framework loads up the assembly anyway without any
sort of security warning or error.

So if this expected behavior, my questions are:

1. Why was there no security error or exception or warning? And why load the
assembly if the crl check didnt go thru?

2. Is there a way to configure the timeouts or number of tries that the
framework uses to check the crl?

3. I didnt find information about this side effect anywhere. Is there
documentation about this behavior? Is there any place where I can find what
the network requirements are when using a digitally signed assembly? For
example, you must have this port open or this is what to expect?

4. Can I install something on the users machine ( certificate in the cert
manager?) so that the framework does not do a lookup? If the assembly was
timestamped using a valid certificate and the certificate is kosher and is
installed in a location that the framework knows about, why do a lookup,
right?

5. Can I configure this behavior in anyway?

6. I find that if expose the machine to the internet ( no longer isolated),
and run the app, I no longer get the delays nor the network activity on
subsequent runs when I switch back to my isolated mode. So somewhere some
state information is being cached on my system. What kind of information is
this? And can I access this information in a supported manner?

5. Can I expect the same behavior in the 2.0 framework?

6. Why don't i see this behavior when loading digitally signed activex
controls from a .net application? I would have expected to see similar
behavior if I am using another type of signed component on the same machine,
but apprently this seems to be isolated to .NET libraries.

All my tests were done using the .NET 1.1 framework.
I will test out Nicole's suggestion to see if it helps. But I would like to
avoid disabling crl checking on the entire system, since this is one of the
advanced options in IE and not a secure thing to do according to the
documents on MSDN.

Thanks for your help.
 
Hi Bilal,

Thanks for your followup and the further description. Currently I'll
consult some other experts on this to see whether there is any better means
to resolve this problem. I'll let you know when I get any further info.
Meanwhile, if you find any new values, please feel free to post here also.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Hi Bilal,

After some further research, I've found the problem in the existing known
issues.
Yes, the delay at the start time is due to the CLR make verification
against the certificate info in the assembly. However, .NET CLR calls
WinVerifyTrust internally and the problem is that
WinVerifyTrust does not allow for specifying a timeout for revocation. So
the problem is actually due to the WinVerifyTrust of the windows system
rather than the .net runtime system. I've asked our PKI folks and they
said they might add such flags to control default timeout in a post MS04-11
QFE and W2K3 SP1.
And currently, there is one approach that may turn off this verification in
IE setting:

The IE setting can be found by
1. Going to Internet Options
2. Clicking on the Advanced tab
3. Scrolling down to the "Check for publisher's certificate revocation"
checkbox.

However, this is not a good solution from security standard point. So if
you feel this a urgent issue since it concern to your product, I suggest
that you try contacting the PSS to work on this issue to see whether there
is any possible quick fix on this.
http://www.microsoft.com/services/microsoftservices/supp.mspx

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Thanks for looking into this.

Were you able to find out why the assembly is loaded anyway, even after
failing the crl check?

And can you provide a public link to something that documents this known
issue? It would be useful to others hitting this problem and we can use it to
inform our customers about this as well.

The solution you described is not the best way to go about this, so I'll
look into the PSS route some more.
 
Thanks for your response Nicole. This tool basically sets the same option for
disabling crl checking in IE. Not the best thing to do, but I guess this is a
command line way option of doing the same thing.
 
Hi Bilal,

Yes, the CLR won't break the starting application though the CRL
verification over network fails, I'm also not sure on the detailed info
since the CLR guys haven't described much on this. Maybe the CLR will just
bypass it or identify the assembly as a normal assembly (without
certificate evidence) after fails to verify the CRL info).

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
Back
Top