Another Research Report That Gives Eset's SSL Scanning A Grade of "F"

[itman 1,755]

https://zakird.com/papers/https_interception.pdf

I read the report twice and could not find a detailed explanation for the two main evaluation categories used; certificate validation and cyphers. So, I will let Eset handle the rebuttal on this. 

[Marcos 5,287]

Unfortunately, this is the first time we have heard about that research. To put things right, it is not true that ESET does not verify certificates. Unfortunately, the authors of the research didn't provide information about the version of v9 and modules which were used for testing so that we could verify their findings on our part in the very same scenario. As for not supporting modern ciphers, I, for one, am not aware of a lack of support for modern ciphers either. As soon as more information is available, we'll update this topic.

 

 

[itman 1,755]

I will add I use the QUALS Client Browser test here: https://www.ssllabs.com/ssltest/viewMyClient.html to validate Eset's SSL protocol scanning. I believe this test only works for Internet Explorer. Eset also uses its own root cert. for this site. I get a perfect score on the test. If there were any issues with Eset's use of ciphers when reconstructing the encrypted transmission, they would show up in this test.

If anything, Eset's SSL protocol scanning has improved since I now pass OCSP stapling which I did not occur in prior Eset versions.

[itman 1,755]

As to be expected, it didn't take Google and Mozilla very long to seize upon this report to continue the demonizing of the AV industry for performing such activity: http://www.zdnet.com/article/google-and-mozillas-message-to-av-and-security-firms-stop-trashing-https/

I do hope Eset does note my reply on this subject posted in my 'Sour Grapes' comment.

Edited February 8, 2017 by itman

[itman 1,755]

Another solution to this ongoing "trash talk" against SSL/TLS encrypted scanning is one I proposed a while back in the security forums I frequent.

The AV vendors approach AMTSO in regards to the development of a certification procedure for SSL/TLS encrypted scanning. AMTSO would perform the necessary testing to ensure the product meets all existing standards. An alternative source would be one of the certified AV labs such as NSS Labs. 

At the minimum this certification would "shut down" these independent research activities which are most certainly not performing a known, approved, and standardize methodology in determining their research findings.

[itman 1,755]

I am duplicating a posting I made of this subject over at wilderssecuity.com:

In reality, the issue of scanning browser encrypted traffic is a more complex issue.

When TCP/IP was created which predates PC browsers, SSL/TLS encryption was developed as a means to ensure secure point-to-point data transmission. As the Internet developed and PC browsers were created to be the primary means of interfacing with it, the "receiving point" for encrypted data and subsequent unencrypting was extended to the browser. This was a reasonable extension at the time since HTTPS traffic was minimal and restricted to high valued information such as banking data and the like. Obviously, this is not longer the case. Actually, the situation is rapidly evolving into the exact opposite where the majority of browser based Internet traffic is being received via HTTPS; largely due to initiatives like HTTPS Everywhere and recently by the browser manufacturers themselves.

There is one entity that is at least partially doing something about the issue of encrypted malware - Microsoft. In Win 10, they developed the anti-malware scan interface(AMSI) to deal with the every increasing problem of malware using packed and obfuscated scripts that decrypt in memory. This interface allows AV security vendors to exam the scripts for malware after decryption but prior to execution.

OK .......... So why haven't Google, Mozilla, and Microsoft developed a like interface for their own browsers to do the equivalent of that provided by AMSI? This interface would no longer require security concerns to perform man-in-the-middle activity using their own root CA certificates to do the same. Draw your own conclusions. Mine are that the browser vendors do not want encrypted traffic examined by anyone for any reason. This leads me to believe there are ulterior motives involved or they just don't want to incur the cost of doing so. After all, publically bashing the AV security industry falls in the category of "talk is cheap."

[itman 1,755]

Appears Virus Bulletin "beat me to the punch" in previous reply comments about use of the AMSI interface by the browser manufacturers:

 When Mozilla and Google start to include AMSI support in their browsers, AV vendors will easily be able to adopt AMSI in their products, with the result being that most developer headaches will be eliminated. This goes for the AV developers as well, as they will no longer have to resort to using their own root certificates to break encryption in the browser, and other workarounds. So the AV software will become less complex and thus more secure.

Ref.: https://www.virusbulletin.com/blog/2017/01/living-dead-anti-virus/

Glad to see the AV Labs are "getting on board" about the issue. AMTSO ....... time for a like policy statement.

[planet 232]

Interestingly, the report is no longer available (404 error). 

 

[Marcos 5,287]

They made some mistakes not only with regard to ESET so I assume an amended version of the report to be available soon.

[itman 1,755]

Oops - thought you were referring to the VB report.

I believe the concept of creating an AMSI "like" interface in the browsers was correct. The use of the existing Win 10 AMSI interface was not since it was designed to monitor stand-alone script execution. 

Edited February 16, 2017 by itman

[itman 1,755]

For those who question who question the need for SSL scanning, here is a recently published Zscaler report on the subject: https://www.zscaler.com/blogs/research/rise-ssl-based-threats-1

[itman 1,755]

Appears the original .pdf is back onlilne again.

They are still giving Eset an "F" for broken cert. chain validation. Worse, Virus Bulletin is now referring to the report in this latest posting: https://www.virusbulletin.com/blog/2017/02/security-products-and-https-lets-do-it-better/

[Marcos 5,287]

It is important to say that only v9 was affected by the broken validation issue and a fix addressing it was released as a module update a while ago.

[itman 1,755]

9 hours ago, Marcos said:

It is important to say that only v9 was affected by the broken validation issue and a fix addressing it was released as a module update a while ago.

Kudos for the clarification and issue resolution.