Steema Central

Posted: **Fri Jan 23, 2009 10:33 am**

Daniel,

Daniel wrote: It does appear (meaning no, it doesn't "does not")

Some more yes/no questions then, if it's ok

1) With access to a valid DNS server, does a TeeChart application with a valid Digital Certificate start without delay?

2) With access to a valid DNS server, does a TeeChart application without a valid Digital Certificate start without delay?

3) Without access to a valid DNS server, does a TeeChart application with a valid Digital Certificate start without delay?

4) Without access to a valid DNS server, does a TeeChart application without a valid Digital Certificate start without delay?

Daniel wrote: What is the information behind the DNS queries to 22.22.22.22 (cut off on the right hand side in your screen shot)? Is there a crl.usertrust.com (as it would be in my case)?

Here's the detail:

Code: Select all

27	5.278226	172.26.0.2	22.22.22.22	DNS	Standard query PTR 1.0.0.127.dnsbugtest.1.0.0.127.in-addr.arpa

So no, no mention of crl.usertrust.com.

Daniel wrote: Indirectly it is, because it is your certificate that's causing the problem when the DLL loads in my application.

With all due respect, this is only speculation. We do not know if it is specifically the Steema Digital Certificate which is causing the problem or if this behaviour is displayed by all Digital Certificates. If the case is the latter, then the issue lies with Digital Certificates per se and not with Steema's implementation of them.

Daniel wrote: The "empty" DLL would IMHO cause it too.n Have you asked Verisign about this behavior? That would be an interesting information...

Yes, if I could only reproduce the issue here I'd have more confidence to ask Verisign what is happening. Maybe the time is coming when I'll have to ask them anyhow ("a friend of mine has a problem..."

)

Daniel wrote: I hope that bairog has more success (good luck)!

So do I

Many thanks for your help so far, Daniel!

Posted: **Fri Jan 23, 2009 2:38 pm**

Daniel,

Chris wrote: With all due respect, this is only speculation. We do not know if it is specifically the Steema Digital Certificate which is causing the problem or if this behaviour is displayed by all Digital Certificates. If the case is the latter, then the issue lies with Digital Certificates per se and not with Steema's implementation of them.

Well, bairog's tests indicate that there could be a problem specific to Steema's Digital Certificate, at least compared with the Dummy Test Certificates that makecert.exe produces.

I've made available a couple of "empty" UserControls, one signed with the Steema Digital Certificate and the other signed with Dummy Digital Certificate produced by makecert.exe. These test files and an explanation of how they were created can be found at the very end of this thread here:
http://www.teechart.net/support/viewtop ... 7&start=15

Unfortunately (for us, at least) bairog will be on holiday until 01/02/2009, so won't be able to have a go with these two test UserControls. If you could find five minutes to give them a go, that would be very useful ... !

Posted: **Mon Feb 02, 2009 12:10 pm**

Christopher,

just some information.
Last week I ran my test application at home with the result that my firewall (Active Armor from nVidia nForce4 chip set) asked permission to connect to the IP address of crl.usertrust.com.

So maybe you install a personal firewall (software) on your PC and see if you can reproduce the accesses. But I strongly recommend at least a virtual machine to test it safely away from any development environments.

P.S.: I'll try your test apps in the next days at home as well...

Cheers
Daniel

Posted: **Mon Feb 02, 2009 4:26 pm**

Daniel,

Daniel wrote: So maybe you install a personal firewall (software) on your PC and see if you can reproduce the accesses. But I strongly recommend at least a virtual machine to test it safely away from any development environments.

Thank you very much for your continued interest in this issue. You're help has been very useful to us! I will definitely follow your suggestion of using a VM to try and reproduce the issue here, although I fear that I have little control over this particular behaviour. We are currently trying to contact the technical support of our certificate provider to see if they can help us at all with the matter.

Daniel wrote: P.S.: I'll try your test apps in the next days at home as well...

Thanks again! Just to let you know that bairog found a problem with one of the *.dlls, so I've posted a newer copy of the files here

Posted: **Tue Feb 03, 2009 12:24 pm**

Daniel,

Good news. I have a definitive answer for you. Here it is:
http://www.tech-archive.net/Archive/Off ... 00057.html

I'll paste in the relevant reply below, for future reference:

Hello Dave,

Microsoft Office uses some of the security settings set by Microsoft
Internet Explorer when it attempts to authenticate certificates of trust
prior to use, even if the certificate is already accepted and present on a
user's computer. Each time an Office application attempts to run an
executable signed with an attached certificate, some events occurs if the
Check for publisher's certificate revocation check box is set to checked in
the Internet Explorer Advanced settings dialog (See
http://office.microsoft.com/en-us/ork20 ... 81033.aspx).

The issue arises because the .NET Common Language Runtime (CLR) uses the
Public Key Infrastructure (PKI) system found on Windows systems and on an
isolated network. When .net framework is verifying a digitally signed
assembly, it requires downloading the CRL (certificate revocation list)
from the Certificate provider. The certificate checking mechanism times out
after a certain number of attempts to servers that host the CRL. The .NET
CLR loads the assembly after all the re-tries are completed, which shows up
as a 15 seconds delay. That is why it takes a long time to load your office
add-in. This behavior is by design.

This problem would occur with any .NET assemblies that are code signed
(http://msdn2.microsoft.com/en-us/library/ms537361.aspx) with a digital
certificate. A code-signed assembly is different from a strong-named one
(see http://conferences.codegear.com/cn/article/32226 ) . Code signing
assemblies is recommend because it makes components tamper-proof and
ensures users know the identity of the component publisher. Therefore we do
not suggest that you remove the code sign of your dlls.

The workarounds include:
1. uncheck the "Check for publisher's certificate revocation" in IE. By
disabling the CRL checking, you are not exposed to a security threat.
2. You could manually download the CRL and install in on the system. But
the CRL is valid only for 10-15 days.
3. it is possible to programmatically set the CRL verification. When the
'Check for publisher's certificate revocation' is unchecked, a setting in
the registry is changed. To turn off CRL verification, set
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing\State from 0x00023c00 to 0x00023e00. To turn
CRL Checking on again, reset the State key to 0x00023c00

Please let me know if you have any other concerns, or need anything else.

Sincerely,
Jialiang Ge (jialge@xxxxxxxxxxxxxxxxxxxx, remove 'online.')
Microsoft Online Community Support

=================================================
When responding to posts, please "Reply to Group" via your newsreader
so that others may learn and benefit from your issue.
=================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Posted: **Tue Feb 03, 2009 2:38 pm**

Christopher,

this is very good to know and helps a lot!

But as David Thielen posted as an answer in that tech-archive forum you quoted from (I highlighted some parts):

Hi;

I don't want to change the CRL setting on user's computers because I think
it is wrong for an install program to change a user's security settings and I
think the security admins would not allow our program at some companies if we
did that.

So I think our answer is to not sign our code (we will of course still
strongly name it).

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

I must admit that I agree with Dave, even if MS suggests not to remove code signing. If the behavior to use IE settings for "normal" applications (that do not need an Internet connection) is "by design", I consider it a "bad design". Our company can not afford to make customers to change security settings for our application to run properly.

So, what do you suggest or what is your conclusion given those news concerning TeeChart?

Cheers
Daniel

Posted: **Tue Feb 03, 2009 5:01 pm**

Daniel,

Daniel wrote: So, what do you suggest or what is your conclusion given those news concerning TeeChart?

My personal position is the following: If I were a security guy, I would be very concerned that the code running on my machines was actually built by the people it was supposed to be built by. I would therefore want all code to be digitally signed and I would want the process that checks whether or not the signature is valid to include a check on revoked signatures and I would want this list to be as updated as possible. I would therefore be fine with security processes downloading a list of revoked certificates from a URL. If, on the other hand, and being conscious of all the above, I decided to take some of my machines "offline" and not give them access to valid DNS servers, then I would be more than happy to make the necessary security changes on the machines in question so that the list of revoked certificates was not checked. I would much prefer to do that than to have to install software on these machines with no digital certification whatsoever.

However, as I cannot suppose that all security guys are as reasonable as I am

then we have decided to release a "non-signed" TeeChart for .NET v2 build. This build will become publicly available within the next three working days and I will advise you when it is.

Posted: **Wed Feb 04, 2009 6:50 am**

Christopher,

However, as I cannot suppose that all security guys are as reasonable as I am then we have decided to release a "non-signed" TeeChart for .NET v2 build. This build will become publicly available within the next three working days and I will advise you when it is.

This sounds very good to me, and I agree, that your customers should be able to choose whether to use a secure version of TeeChart or not!

But:
Without wanting to counteract my wishes, what if someone modifies your unsigned DLL and signs it with, say, a stolen or fake signature, which states it is valid and OK? Then the user has to look deep into that certificate to identify it as coming from steema, if he ever senses that there is something wrong. I know, this sounds a bit paranoiac, but with enough "criminal energy" you'll never know...

Nevertheless, most of our customers from aerospace or automotive using our application are running on closed networks, so we appreciate your decision.

Cheers
Daniel

Posted: **Wed Feb 04, 2009 10:11 am**

Daniel,

Daniel wrote: This sounds very good to me, and I agree, that your customers should be able to choose whether to use a secure version of TeeChart or not!

Ok, the TeeChartNET2UpdateBuildUnSigned.exe is now available, as can be seen here.

Good luck!

Posted: **Wed Feb 04, 2009 11:22 am**

Christopher,

thanks a lot. I'll try it out this afternoon...

edit:
OK, so far my tests are all successful!

Cheers
Daniel

Steema Central

TChart is trying to connect to 205.234.175.175?