Secunia PSI 3.0 and NOD32 with HIPS

Secunia recently released version 3.0 of the PSI (Personal Software Inspector). It turns out that this application has an SSL conflict similar to that with Windows Update. The difference is that the PSI will start running and then halt and there will be no indication as to why it has stopped or any log entries that reveal the reason.

The cause of the halt is that NOD32 with SSL scanning enabled will block the SSL certificate for ps3.secunia.com. If that certificate is excluded in the SSL setup, then the PSI will work fine. There seems to be no other way to get it to work if SSL scanning is enabled in NOD32. I know this to be the case with 6.0.11.0 beta and assume that the same issue will show up with 5.x so long as SSL scanning is enabled. Of course, if SSL scanning is disabled, there will be no problem. That may be what many users will choose to do, at least for now.

I wonder how many other new applications will have similar problems with SSL scanning in NOD32? I wonder why there is no notification of blocked certificates when these conflicts happen? I know, one can set the program to ask every time a new site is visited, but that is very inconvenient and should not be necessary for most sites and applications.

 

That's a question for Secunia why they don't notify about the certificate issue and they probably refuse to accept ESET's certificate without any warning about it. From ESET's part, the communication is scanned fine and there are no problems with it whatsoever (at least that was the case with Windows Updates).

 

Well, when I excluded the Secunia certificate, that solved the problem. I'm not defending Secunia on this. Their application should report if there is a problem connecting their site. After all, in the case of Windows Updates, when there was a problem with that, at least IE would report that it could not connect, so users _knew_ there was a problem. Not so with the PSI, which sits there in icy silence without a single peep. How insensitive.

Since the PSI works if the Secunia certificate is excluded, I consider the problem solved. What Eset and Secunia do with this is no longer my concern. If someone from Eset wants to speak to Secunia about this, fine. If not, so be it.

 

There is a big fuss on the Secunia forum about version 3 generally and most are reverting back to version 2 which will be supported still.

 

I have seen that and I know that version 2 still works, though I suspect there will be no further updates to that version. The new version of Secunia's PSI simplifies the interface so that the user doesn't have to think so much, which is probably a good idea for the vast majority. In that respect, the philosophy of the design of the PSI interface is not all the different from the philosophy of the design of the interface in the latest versions of NOD32, is it?

 

Out of curiosity, I decided to see whether I could look up the certificate on the web. I went to the Digicert site (www.digicert.com) and plugged in the name that appeared when Eset NOD32 asked what to do with the certificate for Secunia PSI 3.0. That name was: ps3.secunia.com

According to the Digicert site, the certificate is valid, BUT the name does not match. According to the Digicert lookup, the name should be just secunia.com. Could that, perhaps, be an issue when Eset is doing SSL protocol checking? I realize that there is no way to see this at the user end, because if the program is set to "ask" for every non-visited site, it does exactly that, regardless of the certificate for that site. The same thing goes for whatever the Secunia site may be doing with the Eset certificate, because nothing is reported.