New conflict with Secunia PSI 3.0

Secunia just released version 3.0 of their Personal Software Inspector (PSI) and being a long time user of Secunia, I decided to download and install the new version to see what it looks like. Secunia is pushing this version as a replacement for their earlier, and more complex, interface for the PSI (version 2.0.x etc). Well, installing it and getting it to run with NOD32 version 6.0.11.0 beta was a trip and a half. Securnia PSI 3.0 installed properly, without any complaints, but then when I ran it, the program sat at the splash screen indicating "loading," but after a short time, there was no disk activity and waiting for an hour or so changed nothing. I tried disabling NOD32, but even that did not work. I did NOT uninstall NOD32, which, in retrospect, might have allowed the new PSI to run, but I am glad now that I did not go to that extreme.

It turns out that this is a variant of the problem recently with Windows Update. I had to set SSL scanning to "ask" and then click on "exclude" when I was prompted as to what to do with the Secunia certificate. No other choice worked, though I did try allowing the certificate. Once I had accomplished adding the certificate to the "excluded" list, I was able to change SSL scanning back to "Always" and Secunia PSI 3.0 was/is happily co-existing with NOD32 6.0.11.0 beta.

I am pretty sure that those running 5..xxx versions will have the same problem with Secunia PSI 3.0, so if that subject comes up in the regular forum, I know how to fix it.

One thing that really bothers me about this is that if you have NOD32 set to "Always" scan SSL, then there are no alerts when a certificate is blocked. There are not even any log entries regarding blocked certificates. There should at least be those. I have since set notifications to "diagnostic" in order to see whether this will help me to know if the same issue of SSL certificates happens with any other appliction.

Nevertheless, I think it is just bad practice not to have any notification of blocked certificates. What user would even be aware of a problem without digging deeply into the software to find out what works and what doesn't? With a notification of a blocked certificate, we users might have a starting place for analyzing conflicts such as this. Blocked certificates should be logged automatically, even if this makes the log files larger.

I'm adding to this because the question about the Secunia site and SSL certificates seems to be whether Secunia is blocking Eset's certificate or vice versa. If the Secunia PSI 3.0 is not alerting to a connection problem, then that is on Secunia. It should alert, at least the way that Internet Explorer alerted to a failed connection to Windows Update when there was a problem with Eset NOD32, SSL scanning, and Windows Update. That said, is there no way for Eset to log anything about this? If the software is set to "ask" about non-visited sites, then it detects the certificate for the Secunia site and that allows the user to "exclude" the certificate, which bypasses SSL protocol checking for that site. I suppose there really is no other way to do this, but it certainly is an issue that is going to frustrate any user who opts to enable SSL scanning with Eset NOD32. The better choice for users of Eset NOD32 may well be to completely disable SSL scanning so that the issue never arises. That's just one opinion, of course.

 

The thing is the communication is not blocked by ESET but it's actually the application communicating via SSL which does not accept ESET's root certificate as a certification authority. So in the end it's the application that should report the issue, not ESET's products that have no information about 3rd party applications not accepting ESET's root certificate.

The only thing we could do is exclude Secunia's certificate from scanning by default.

 

I understand. I finally switched back to version 2 of Secunia PSI, as have others. That version does not use a secure server at Secunia. I also found that I would have to exclude Yahoo mail in order to connect to the secure web mail there when using IE8. This did not affect connecting using Firefox or Google Chrome. That was strange and I could not find a way to change this behavior. I did decide to set "do not scan SSL" under Protocol checking. It just simplifies things.