How Kaspersky makes you vulnerable to the FREAK attack and other ways Antivirus software lowers your

You can run certmgr.msc, go to folder Trusted Root CA and remove orphaned.

 

Thanks, was already working on it. Going to have to do it for about 15 machines.

 

The problem is that the AV handles the encrypted connection with the sites/servers instead of the browser, and it doesn't support the same features as the browser so it will be less secure. But if it is turned off so the browser can do it again, it doesn't matter that the certificate is still installed.(Unless they mess up as bad as Superfish, but that is another angle.)

 

My advice - do not use any AV's SSL protocol scanning feature in any form for any reason.

Here are some of the issues I have encountered with Eset's version:

https://forum.eset.com/topic/4747-catch-22-situation-encounter-in-ssl-protocol-scanning/

https://forum.eset.com/topic/4790-another-ssl-protocol-issue/

The last link is an especially nasty incident I had. My own opinion of this last link is Eset auto updated it's root certs in WIN 7 and Thunderbird and won't admit it.

 

I also take exception to this statement from the original article:

There's one more interesting thing: It seems all three tested Antiviruses don't intercept traffic when Extended Validation (EV) certificates are used. Extended Validation certificates are the ones that show you a green bar in the address line of the browser with the company name. The reason why they do so is obvious: Using the interception certificate would remove the green bar which users might notice and find worrying. The message the Antivirus companies are sending seems clear: If you want to deliver malware from a web page you should buy an Extended Validation certificate.

In my testing of Eset's SSL protocol scanning feature using IE 10, Eset Smart Security 8 was indeed modifying EV cert web sites totally invalidating the trust that cert implies:

EMET detected that the SSL certificate for "www.bankofamerica.com" is not trusted by the rule "BOACA" associated with the domain "www.bankofamerica.com".
Certificate Trust check failed:
Application : C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE
User Name : Don-PC\Don
Session ID : 1
PID : 0xC90 (3216)
TID : 0xBC0 (300
Certificate details:
[SSL CERTIFICATE]
Subject Name : CN=www.bankofamerica.com, OU=Network Infrastructure, O=Bank of America Corporation, STREET=135 S La Salle St, L=Chicago, S=Illinois, PostalCode=60603, C=US, SERIALNUMBER=2927442, OID.2.5.4.15=Private Organization, OID.1.3.6.1.4.1.311.60.2.1.2=Delaware, OID.1.3.6.1.4.1.311.60.2.1.3=US
Issuer CA : C=SK, O="ESET, spol. s r. o.", CN=ESET SSL Filter CA
Serial Number : 621760D77973A679B9D5597C2BFE15E5
Thumbprint : 35552E9E157B54B89CC3A807F43CD1164BCFED1A
Signature Alg : sha256RSA
Not Before : 2/18/2015 7:00:00 PM
Not After : 2/19/2016 6:59:59 PM
Public Key : 3082010A0282010100B7572D60968FD0B12038A0C4D9859CFCF9A45A18384BD4430BA300BA169584C41D8A4843DB555D54B4A8F0D32B2DC23F75B8327724B7C5B95B2102FCD1572D9374EEA6FC034B765D7C56F098AE0A5ABD89F39A6796D9A4BB8D95B2D6362253689BA644BF7A24DA912F5B1FAF216C66CA18818CC42B46EB83E425BC9C610BF13F53D6E2651C9C65B542D92C594DB9A62F6AA91AEA613A0CDB66B478F0B83A2FDF67C2627D1DAD78F27181FC85F3F17958447A1C0DEB0CF0BAFC1731E9F0F7742D99E26F27A900F286A6AD21FA61A1908763D28E72061AB85A44F864DDB530B2506AB60E94D03549EDEB0F6D61C63AB9AF31EBC62CBB6F13F3AEADDB7C0AA034FD0203010001
[ROOTCA CERTIFICATE]
Subject Name : C=SK, O="ESET, spol. s r. o.", CN=ESET SSL Filter CA
Issuer CA : C=SK, O="ESET, spol. s r. o.", CN=ESET SSL Filter CA
Serial Number : 3C5F8DEB6E24CAA143202DF53F89093E
Thumbprint : 0E04CEF08EA60B0809FBFA8D3B4C01B0E439CF1A
Signature Alg : sha256RSA
Not Before : 4/23/2015 10:02:37 AM
Not After : 4/23/2025 10:02:37 AM
Public Key : 3082010A0282010100A3E8711EC5DDA1E70E10EF0422305B11F57E0A27FA507B904466CD6AE6D800935B8B34AA1C2D2BEF3880CE2B9B639667597632DB54F0CEBAC001D53242C0A46AE634503163753F4FE85289B824B304C5CBF3114F9EA2AA922A84052B7594EA11B0F04E356909FDBDEA23FFC9A6C319B9BB5487A912A7C54394252713E27DBB6F694F98E21CD855CD80EDC642555EADB3B86525DFB2672F234014A0AF932663AF091C977C2861F72FD887F83C925D4B9BF150C0E744CD8A450ECEC725A06D140DEDD0F9DE34D808DB98F262CB1DD92369D5D97380B73586D3C1F561BA838669DCBB4B5F7AA8B93206676FCB0CCB894FB2EB3D2F7AF5C00D6ECF9058C3258247210203010001

 

Anyone know if emsisoft or f-secure do this stuff?

 

So, according to this article, by disabling TLS interception by default, ESET is doing a better job of handling HTTPS security than Kaspersky and Avast?
And Chrome and Firefox are getting it right, but not if they are used along with an AV?

 

You'll always have someone high on Methamphetamines reporting this, it's the only thing they have to do to pass the day in question. If you believe everything you read then Antivirus Programs would be extinct within a short period of time, as nobody would trust them

 

Emsisoft intentionally refrains from stream scanning as a whole, not just https . That's how it should be done.

 

I also prefer AVs that don't scan protocols. With ESET I like how it is possible to totally disable driver that scans protocols.

 

Yes, but sadly this seems to impact LiveGrid as well. Try downloading the cloudcar.exe from AMTSO with protocol filtering disabled. It will work then.

 

So in your opinion, the two settings in the image provided should not be selected?

 

Protocol filtering shouldn't be disabled for users that don't know what they are doing as it provides additional security and prevents some malware from reaching your computer. There might be a situation where http scanner would stop malware, which wouldn't be stopped by file scanner alone.
On my setup, yes, I have protocol filtering disabled.

 

AFAIK, among the better known suites only AVG Internet Security has separate options for enabling HTTPS scanning and a sub-option for EV certificates scanning. Both are turned off by default IIRC (or the HTTPS one is turned on, but I'm positive that EV scanning is turned off by default).

 

What steps do you take in your set up to compensate for having protocol filtering disabled... and, is this related to the thread topic, because I don't want to take it OT.
Thanks.

 

I use script control inside browser and execution control system-wide. I also disable active content in other software (directX, macros) and disable windows script hosts.

 

What steps do you take in your setup to compensate for having SSL / TLS filtering disabled?

 

Also add Bitdefender to the "SSL Hall Of Shame": http://www.effecthacking.com/2015/02/bitdefender-products-break-https.html .

I use a SSL web site IP address blacklist from here: https://sslbl.abuse.ch/blacklist/ . I open up the download in Excel and edit it to be hosts file compliant. I then upload it to Emsisoft's Anti-malware web shield. Alternatively, you could just add same to your WIN hosts file. I have also requested Emsisoft include these IP addresses in the web shield for future releases.

You can do the same in Eset as shown below. I also believe you would not have to edit the list to be hosts compliant since Eset just requires the actual IP address.

 

another article
http://www.scmagazineuk.com/updated-kaspersky-leaves-users-open-to-freak-attack/article/411470/

from my view - complete unacceptable for any software.
additional eset dont support latest tls and eset and avast wont use ocsp stapling.
all three undercut and deactivate "key pinning" in chrome and firefox.
privacy aint given in such cases, security is worth nuts - i would call that fraud.

chrome and firefox have built-in databases (key pinning) and ocsp stapling is on the way.
i would recommend that and no other, any other is again like MITM.

Cheers.

 

@Brummelchen

My question wasn't aimed to insinuate that additional measures are necessary to compensate for the lack ssl / tls scanning, quite the opposite actually.

 

alright
i got rid of all active scanners, i have a paid mbam but use it on demand beside mbae (sometimes )
using firefox now for ages from time to time i check my installed certs. latest new is rcc for automatic check
https://www.wilderssecurity.com/threads/rcc-check-your-systems-trusted-root-certificate-store.373819/
http://trax.x10.mx/apps.html
but /me is an experienced user...

cheers

 

I would also point out that there could be severe legal penalties in the form of an unfavorable court ruling against anyone using a product that performs SSL protocol scanning here in the States. Perhaps the vendors who offer this feature don't care about this?

In the U.S. when a sizable online bank fraud incident occurs, you are pretty much guilty till proven innocent. The bank will most likely perform a number of defense measures; one being a forensic examination of all computers you use. If you refuse, they will most likely get a court order requiring you to do so as a condition of repayment of funds. The forensic examiner will be looking for any evidence you were negligent security wise in the operation of your PC; no security software, software not up to date, and software misconfigured among other things. What do you think his findings will be when that expert discovers that the normal browser SSL security has been circumvented by one of these AV's SSL protocol scanning features? Since he is employed on the bank's behalf of course he will gather all available evidence publically available as shown in this thread about the current issues with AV SSL protocol scanning. Need I say more on how the scenario is going to end?

I can only assume that since these AV companies reside in places like Russia, Slovakia, the Czech Republic, and Romania, their banks are more lenient on the consumer when bank fraud occurs? Will these companies guaranty reimbursement of your legal defense funds expended when using one of their products that have SSL protocol scanning enabled? Better yet, will they reimburse you for the amount of the fraud loss?

 

sounds strange - guilty because ssl-check. here in germany all banks recommend some antivirus software. additional they offer now smart phone apps for live view. and customer need to prove that fraud incident came not from his computer. it depends of the good will of bank if they assist with investigation on used ip and more. if customer was spied out he need to prove that he has all done against, eg antivirus, updates, etc.

ofc they will know but at least those scenarios seems only few while regular malware or fake email notifications are daily bread. read again above of banks here in germany - no antivirus = guilty. if further investigation proves that the ssl-check was causing the issue they will pay the money back in most cases. i dont know about claims versus authors.

on the other hand i do online banking now for years with out any common security - i use system options and had nothing. incl. paypal. maybe luck but i do now with the fourth (4.) bank without trouble.

 

That is true because nothing presently in Windows or IE presently will prevent a MITM attack. All I am saying is fooling around with standard SSL protection mechanisms using third party software is just asking for trouble.

Now an exception would be something that the bank offers it's customers. I can download Trusteer Rapport for free. It will prevent MITM attacks since bank uses Trusteer's server software. Note the bank does not require you to use the software. However, there is a potential "gotcha" here in that the bank recommend a security solution and you ignored their recommendation .... I tried the software twice and it slowed IE to a crawl doing normal surfing activities.

 

There is nothing inherently wrong with MITMing SSL connections, or for that matter doing something substantially similar via browser extension that intercepts requests/responses. In fact, we WANT... and NEED... to preserve such OPTIONS because they are so often required to FIX security/privacy problems at websites (including financial institutions!). However, it is obviously very important that it be done technically well... and, I would argue, that there be NO sharing of [sensitive] information with other parties. IOW, a purely local MITM process is one thing. A MITM process that involves phoning home information extracted from secure connections to a third party is something very, very different.