stronger NOD SSL certificate

unless mistaken the NOD SSL certificate is relatively weak considering

SHA-1 With RSA Encryption @ 1024 bit
168bit key length

isn't it feasible to get one a bit stronger/sophisticated?

and what about the SSL scanning for FF - as it stands it has to be excluded from NOD web protection. will that ever be solved?
and from which version onwards will the matter with the Chrome browser be solved?
also in Opera 11 when having only 256bit ciphers enabled it is not possible to connect to a 256bit SSL site when NOD SSL scanning enabled, due to the weak NOD certificate.

 

Can you clarify the SSL scanning issue with FF? I'm using FF with NOD32 without any issues. How can I recreate the issue you're experiencing and I'll try it here?


Jim

 

here are related threads - try with the FF beta 4

FF Chrome Opera

that is what happening in FF 4 with NOD SSL protocol filtering enabled. either disable entirely or exclude FF from scanning, both not really good solutions



forgot to mention that Safari 5.0.3 is troubled with the NOD certificate injection as well

Virus signature database: 5633 (20101119)
Update module: 1032 (20101025)
Antivirus and antispyware scanner module: 1293 (20101110)
Advanced heuristics module: 1115 (20101116)
Archive support module: 1123 (2010110
Cleaner module: 1049 (20100604)
Anti-Stealth support module: 1022 (20100812)
SysInspector module: 1217 (20100907)
Self-defense support module : 1018 (20100812)
Real-time file system protection module: 1004 (20100727)

 

Why would you want a stronger certificate? It is only used for the communication from ESET back to the browser. The communication from the website to ESET is still the websites own certificate.

 

because it is weakening a strong SSL cyphered webpage. where is the communication chain from Eset to browser? right in the middle between browser and website...

 

As written above, the communication between EAV/ESS and your browser is encrypted using the ESET root certificate while the communication between a particular web server and EAV/ESS is encrypted using the web server's certificate.

 

those browsers only recognizing the strength of the NOD certificate, which being the weakest in the chain. how is it possible to test/verify your above statement that the communication between the webserver and the EAV/ESS proxy is facilitated by the webserver's cypher?

remaining the questions about the browsers and NOD's SSL protocol filtering mode compatibility.

 

The problem vtol is that Chrome, Firefox and Safari are using their own certificate management instead of using the one built into Windows. There is a logical reason why they want to do this and not depend on Windows.

If you want to make the ESET certificate work on these browsers, you need to export the certificate from the Windows Certificate Server and import them into the browser, and then make it a trusted source.

 

that would be certainly an idea (though still a lot of manual tweaking for the inexperienced), however neither FF 4 nor Chrome 9 (7 still still ok, did not test with nor Safari 5.0.3. do accept Eset as trusted authority, unless of course I did something wrong. Suggested earlier Eset to work something out with the browser developers, though there was no feedback.

As you mentioned the browser developer as of late diverting from the windows certificate root certificate trust it is not surprising that there is this trouble with NOD - relying solely on the windows certificate root certificate trust. That development (hardening the browser against MitM certificate injections) seems so obvious that I mentioned earlier that the current NOD SSL protocol filtering model may end up with one compatible browser only - IE.

What I find also curious, and pardon me ignorance, how the SHA-1 With RSA Encryption @ 1024 bit / 168bit key length cypher between the browser and EAV/ESS proxy gets converted into a SHA-1 With RSA Encryption @ 4096 bit / 256bit key length cypher between EAV/ESS proxy and the webserver, if such provided by the latter?

 

You can set ESET to ask about every SSL certificate, and you'll see that certificate added to ESET.

 

Personally, I don't use it period as there is a lot of manual configuration, and a lot of social applications I use that uses SSL for oauth that doesn't work with ESET.

I also believe that this ESET certificate could be used against us for targeted attacks. Even though it's a CA, we do have it in our trusted list. Who says malware writers can't create an SSL based site and exploit the ESET CA that we trust.

While I have no proof-of-concept of this, I just believe it's going to be bad karma if I use this. Afterall, if any virus was to be executed through an SSL attack, it still needs to be written to disk before it can do anything, therefore the realtime scanner will pick it up if there was a detection for it.

Setting up SSL scanning at this point in time is just suspenders to keep the pants and belt in check. Not required at all, but could potentially make you look fashionable.

 

what would that achieve in the context of this thread?

 

thought about it and tend to concur, although and admittedly lacking in-depth knowledge. yet the data stream must be altered somehow in the EAV/ESS proxy when brokering the NOD certificate against the certificate of the the webserver

not sure whether Eset had fashionable lingerie in mind when putting this feature into NOD, but until there is a clarifying response from Eset and perhaps a better compatibility with the various browser I may stay away from it too.

 

You would literally have to have a quantum computer sitting inside your computer case that you are unaware of for the encryption key strength between your browser and the Nod32 kernel to even be a remote concern for compromise.

 

...or a key logger, but then your screwed anyways. SSL or not.

 

if intending to crack the encryption inside, else there are several cloud based tools which could crack such key relatively fast.

the point is the broker process in the EAV/ESS proxy, if there is
the NOD certificate being the weakest link in the chain - why to succumb to it when there is stronger cypher available from the page's server
browser incompatibilities

 

Let me tell you again. The certificate for ESET is only used on YOUR system. It does not LEAVE your system and onto the internet. It ONLY facilitates communication between the browser and the ESET client. ALL outbound communication uses the websites own certificate. A stronger certificate therefore is not needed.

 

appreciate your input and value the statement. how to test/verify that? FF add-ons for SSL certifcate checks come only up with the strength of the NOD certificate. those mentioned browsers do have a problem with that. do you know how the data stream in the EAV/ESS proxy is brokered?

 

How do you mean? Data comes in, ESET decrypts data, ESET scans data, ESET encrypts data, ESET gives data to browser.

 

the data become transparent in between the decryption and encryption, when the scanning happens.

how is it possible to test/verify that the communication between the webserver and the EAV/ESS proxy is facilitated by the webserver's cypher?

 

Set ESET to ask about every new SSL connection, it'll show you what the original certificate is.

 

much obliged for your patience...

leaves the incompatibility with various browsers, but that actually was not the topic.

that and preferring the intact SSL chain between browser and server (avoiding the transparency phase) I prefer to leave the NOD SSL protocol filter off