Wednesday, March 23, 2005

I've just finished a meeting about an issue we're having with our .NET components. Though I fully agree with our decision, it's very frustrating, and I thought I'd share this with you.

A few years ago, before .NET was officially released, we decided to embrace the idea of digitally signing our ActiveX DLLs. The idea was to garantee our clients those DLLs were really from us. It was an added value that had no (visible) impact on the products themselves.

When .NET came in, though one could argue the strong name was sufficient, we decided to stick with digitally signing and do both. Actually, the strong name isn't offering CRL verification, nor detailed information about the "signer". It's not actual identity, it's only integrity.

Somewhere in time (we're still not sure when... maybe since .NET 1.0 SP3/.NET 1.1 SP1?), clients started complaining about our assemblies causing a network access. For most of them, the only impact was their sudden suspicion that our products were spywares, while in reality it was Windows' WinVerifyTrust API accessing or to check if the certificate used to sign the DLL was revoked.

But others got bigger problems. Some people behind a very strick firewall, ignoring outgoing connections instead of rejecting them, had a timeout while loading our assemblies. That timeout (at least 15 seconds) is hardcoded in WinVerifyTrust! We can't do anything about it.

And finally, those using a dial-up connection were seeing their Dial-Up dialog box appearing when our assemblies were loaded. Nothing to put confidence in our products. How come using Xceed Grid for .NET causes a network access?

There are solutions for those clients, but ugly solutions that either involve disabling CRL checking in the first place (yeah, right, let's sign our DLLs, then ask our clients to turn off its use!), or regularly install our certificate in the list of trusted certificates, which is only good for a certain period, and must be repeated again and again.

We've just decided to stop signing our .NET assemblies. Most of our competitors don't anyway. And those that do are having the same problem. But it's so damn frustrating to see that security is again loosing a battle. Sure, the impact is quite minor, but I'm left with a mixed feeling of failure and blames against the current implementation of WinVerifyTrust.

3/23/2005 4:16:14 PM (Eastern Daylight Time, UTC-04:00)  #