What they're saying is that AV's and other tools who are using this method, make your system less safe in a sense. https://cxsecurity.com/issue/WLB-2015120310
The .pdf isn't dated, so don't know when it was published. As far as Eset goes, it does support TLS 1.1 and 1.2. However, some have had some issues. From the Eset Smart Security forum: This is a problem of Schannel which ignores the information that TLS 1.2 is supported. If the remote server used 1.2 though, it would work but some rely on the inaccurate information provided by Schannel. Not sure if MS has addressed this in a hotfix, will try to get more info from our devs. The main issue I see with most AVs that use private keys is their storage protections are not up to standards. My tests using the Quals SSL tests on my bank web site is that there is no difference in protection using Eset's root cert. versus not using it. Note their are major issues with SSL protocol scanning with the new ver. 9 of Smart Security and NOD32. My tests were performed using ver. 8. Eset's SSL protection also does certificate pinning checks. Although in my testing, it did in one instance pin the wrong intermediate certificate. Again the authors of this study recommend browser changes and in reality, that is where SSL enhancements should be done.
From what I've understood, it's a new report published on 30 December 2015. But would indeed be cool if browser developers would focus a bit more on this issue.
I finally went through the https://madiba.encs.concordia.ca/~x_decarn/papers/tls-proxy-ndss2016.pdf report in detail and things are much worse than I imagine on the issue of SSL protocol scanning by AVs. Besides all the previously known issues that have been discussed in reports issued throughout this year on the subject, using this AV feature exposes you to man-in-the-middle attacks. I verified this using Eset's SSL protocol scanning by enabling CAPI2 operational event logging. Then observing the slew of revocation server access attempt errors in the log. Bottom line - if a web site chained their cert. to a rouge intermediate CA cert., none of the nine AVs mentioned would ever detect the revoked cert.: C. Certificate validation and trusted stores Our certificate validation analysis reveals various flaws in nine out of 12 proxies. 1) Invalid chain of trust: We use nine test certificates with various errors in their chain of trust; see Table II. We highlight the dangerous behaviors in the table (“Accept” and “Changed”). If a proxy can detect a certificate error, it may react as follows: send the browser a certificate issued by an untrusted CA (“u-CA” in the table), typically named “untrusted” along with the proxy’s name; send a self-signed certificate (“SS”); ask confirmation from the user by delivering a warning webpage or an alert dialog (“Ask”); or, terminate the connection altogether (“Block”). For expired certificates, the period of validity may be passed as-is to the client (“Mapped”), or updated to reflect a working period (“Changed”); in the latter case, the browser cannot detect if the original certificate has expired. For certificates issued for the wrong domain name, the CN field may be passed as-is to the browser, or may be changed to the domain name expected by the browser. Finally, proxies may entirely fail to detect invalid certificates, exposing browsers to generic MITM attacks (“Accept”). Only Kaspersky and Net Nanny successfully detected all our invalid certificates; however, when detected, the user is asked to handle the error.
According to this, it supposedly does cert. validation. Only testing will validate that it is indeed performing all pinning functions correctly: http://wsa.sophos.com/swa_docs/ws1000/tasks/ConfigGlobalPolHTTPSScanning.html -EDIT- Reviewing this again, I really have no idea if UTM properly performs cert. pinning checks. I believe this option is only applicable to the web site cert..
Actually, the question to be put to the AVs doing SSL protocol scanning is "If Kapersky can get cert. pinning validation correct for the most part, why can't you?" Heck, even Net Nanny gets that part correct ........................
http://www.csoonline.com/article/30...-could-make-your-company-more-vulnerable.html Some MITM / SSL info in this great article as well.
Good article but a bit oversimplified in my opinion. Most corps. only use endpoint solutions to protect local client machines. All incoming and internal network traffic is monitored by sophisticated network appliances and isolated by web and mail servers. He also somewhat glossed over the fact that most retail products are not just plain signature based AV products. They also include a firewall and possibly a HIPS or behavior blocker. Actually, unencrypting Internet traffic in corp. settings is a desired option but for the purpose of monitoring outgoing employee traffic! As far as the possibility of AV operation being tampered with or shutdown, I personally have not seen an instance in many moons. The main issue appears to be the possibility of inception of AV signature and update downloads. There has been a noticeable move recently by many vendors to use SSL for such communication.
A bit related to this subject: https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
Yes. The Eset root. cert. used for SSL protocol scanning is SHA-1: However, for Firefox users who are behind certain “man-in-the-middle” devices (including some security scanners and antivirus products), this change removed their ability to access HTTPS web sites. When a user tries to connect to an HTTPS site, the man-in-the-middle device sends Firefox a new SHA-1 certificate instead of the server’s real certificate. Since Firefox rejects new SHA-1 certificates, it can’t connect to the server.
