risks of using a/v HTTPS interception scanning

as detailed here in this document, suggestion is to not scan https traffic with a/v software that uses proxy techniques.

http://users.encs.concordia.ca/~mmannan/publications/ssl-interception-ndss2016.pdf

 

Yes .......... Been posted multiple times in other threads.

Also note that this is a republishing of the original 2015 article with no updates. Many of the issues noted in the article have been fixed by the vendors referenced. Some have not.

What is not specifically referenced in the article is what does SSL scanning actually gain you? Much of today's malware is packed and obfuscated so unencrypting those gains you nothing. If you run your realtime AV scanner in an aggressive mode and as long as it scans all files upon creation including anything from the browser, you pretty much have the same protection as if SSL scanning was enabled. These retail vendor SSL scanners employ a NDIS mini-port filter to allow their realtime engine to scan the unencrypted traffic while still resident in the network stack. All this employs is blacklist and signature checking.

 

It will never be fixed, because TLS is a moving target e.g. the http/2 protocol is not used by any security vendors. So the vendors may e.g. catch up with revocation checks in say a year time, but then something else new will be what they failing on.

TLS traffic is not meant to be intercepted full stop, so even if a miracle happens and the security vendors are compliant on everything else, they are still in breach by intercepting the traffic.

 

Another thing about SSL scanning is that "it cuts both ways." Since the vendor is using his own root cert., he can verify easily unencrypt all your outbound web and client e-mail communication. So potentially the vendor can intercept your web site passwords, etc..

 

Yes... https://www.wilderssecurity.com/thr...-client-end-tls-interception-software.385640/

 

repeat postings needed to bring awareness to it really.

I just tested emsisoft manually as that wasnt listed and somehow they manage to scan https without proxying TLS. So the vendors listed can do it without their current methods.

But apologies, I didnt know one was done only 9 days ago.

 

I use Emsisoft Anti-malware. It does not filter either HTTP or HTTPS network traffic directly.

What is does do is blacklist known malicious and phishing domains/IP addresses and optionally known PUP and privacy domains/IP addresses. It also allows a user to import their own host file of domains/IP addresses.

 

I disable SSL/HTTPS scan in security software.

What about product like Adguard Desktop that filters SSL/HTTPS to block ads, etc on SSL/HTTPS?
On Adguard Desktop I have enabled "Do not filter sites with EV Certs".
Should I disable SSL/HTTPS filter on Adguard Desktop completely?

Guess Avast now does SSL/HTTPS scan differently i.e no certs installed, am I right? And is it any better?

Guess new Norton Beta have SSL/HTTPS scan now, am I right? How is it?

Any security software that does SSL/HTTPS in a good/safe way or no matter what technique its better to not use SSL/HTTPS scan of security/any software?

 

No, you are wrong:

How Avast’s HTTPS scanning feature works (the short version)

Avast is able to detect and decrypt TLS/SSL protected traffic in our Web-content filtering component. To detect malware and threats on HTTPS sites, Avast must remove the SSL certificate and add its self-generated certificate. Our certificates are digitally signed by Avast’s trusted root authority and added into the root certificate store in Windows and in major browsers to protect against threats coming over HTTPS; traffic that otherwise could not be detected.

Avast whitelists websites if we learn that they don't accept our certificate. Users can also whitelist sites manually, so that the HTTPS scanning does not slow access to the site.

Ref.: https://blog.avast.com/2015/05/25/explaining-avasts-https-scanning-feature/
​

Sorry, that is a decision you have to make for yourself. Based on studies published on the web, not one security vendor is 100% properly performing HTTPS scanning. Based on the last report I viewed on Avast, they came the closest to performing it properly.

FYI - there is no way to scan HTTPS traffic unless a security vendor uses his own root CA certificate to do so which results in a MITM situation.

 

agreed. https://www.wilderssecurity.com/thr...ls-interception-software.385640/#post-2588175

I will request mods to merge the topics.

By the way I thought you use nod32, so you using both side by side?

 

I use both Eset Smart Security and Emsisoft Anti-malware with proper exceptions created for each. Zip performance impact.

 

are they both real time file scanning as well?

 

I have Eset realtime scanning set to max. settings i.e. strict cleaning, all extensions scanned, advanced heuristics, etc..

I have Emsisoft's realtime scanning set to scan upon execution(fast) for all extensions. I was running it set to scan on both execution and file creation(balanced) for a while and didn't notice any impact performance-wise with that setting. I just did want any detection conflicts to occur between the two scanners.

 

ok thanks.

 

An interesting comparison of the effectiveness of Emsisoft's IP/domain blocking versus Eset's NDIS mini-port network filtering of web traffic is given below based on non-lab based testing by PC Magazine. I have to assume that different malicious URL's were used for each test since they were done at different times. Overall though, it shows that both products were about equal in protection with Emsisoft receiving a slightly higher score. The conclusion I draw from this is one would be adequately protected from malicious HTTPS web sites using Emsisoft. Or in my case, using both products with Eset's SSL protocol scanning disabled.

Out of 100 verified malware-hosting URLs, Emsisoft blocked 67 percent at the URL level and wiped out another 20 percent during download. That total score of 87 percent is pretty good, but Avira recently scored 99 percent protection. Before Avira's blitz, the top score was 91 percent, shared by McAfee AntiVirus Plus (2016) and Symantec Norton Security Premium.

Ref.: http://www.pcmag.com/article2/0,2817,2477035,00.asp

In this test, I launch nasty URLs one after another and note whether the antivirus blocks access to the URL completely, wipes out the malicious payload, or sits idly doing nothing. I continue until I've recorded the results for at least 100 URLs. ESET earned an 84 percent blocking rate, evenly divided between blocking URL access and wiping out downloads. That's better than almost all the competition, though Norton and McAfee both managed 91 percent in this test.

Ref.: http://www.pcmag.com/article2/0,2817,2469847,00.asp
​

Comment: Take note that Emsisoft would have to be set at its default real-time protection mode of "balanced" to achieve the overall 87% score noted above.

​

 

Read Avast's perspective on HTTPS scanning: https://blog.avast.com/independent-test-shows-avast-offers-best-https-protection-in-the-market

 

Perhaps a nitpick, but does the:

Moreover, the study shows that several of the reviewed antivirus solutions “also mislead browsers into believing that a TLS connection is more secure than it actually is, by e.g., artificially upgrading a server’s TLS version at the client”. How would this make the solutions more vulnerable and how does Avast solve this problem?

section specifically address how Avast solves that problem? I think this would go back to mimicking and being as transparent as possible, which is mentioned earlier. Plus what comes after that question implies "don't send something better". However, when reading it (with a tired brain, anyway) it felt like an open question.

Edited to make clearer, I hope.

 

Hopefully, Avast does indeed have SSL protocol scanning right. However, there is no way to prove that without independent third party certification of the same.

 

I believe this is referring to "TLS_FALLBACK_SCSV supported" ref.: https://datatracker.ietf.org/doc/rfc7507/ ? If so, this is a server issue. The Quals SSL Server test will verify if a web site prevents TLS downgrading from occurring.

 

Do you guys happen to know, is any independent 3rd party doing certifications like this? If so, we would love to take a stab at it.

Thanks.

 

I made a comment on this here: https://www.wilderssecurity.com/thre...ls-interception-software.385640/#post-2588129 . Its akin to the "chicken or the egg" scenario. Someone in the security industry at the guidelines and standards level needs to take a stance on if SSL protocol scanning by the AV industry is an acceptable practice. Until that is done, I don't expect any AV labs and the like to wade into the issue and offer any compliance testing for SSL protocol scanning.

 

I get what you are saying. However, that can be broken down: 1) MITMing, 2) AV scanning in a MITMing context. The latter is a specific application of the first, and there are others. The first could be approached with an eye towards supporting the various applications, but it need not and arguably should not be ignored simply because there is not yet official agreement within one or some of those application communities.

Before you can certify something you need to establish what you will certify it to. What are the requirements that need to be met? Particularly in an important context such as this, I think you'd want said requirements to be carefully researched, robustly documented, and well reviewed (by multiple, independent, qualified, parties representing the different legitimate interests).

If someone (anyone) wanted to create or embed a generic MITM component today, could they find such a requirements document? How about even a less formal but still detailed "guidelines" or "best practices" document? I mean something an engineer could code to or test to themselves.

 

I would sum up the scanning of SSL traffic by AV vendors as well intentioned but misguided. Such scanning violates the whole principle of encrypted communication which is secure point to point transmission of data. Whereas there might be valid reasons to scan outgoing encrypted data in business environments where no guaranty of privacy exists, no such reasons exist for the doing so for non-business environments.

My opinion is AV vendors concentrate their efforts in the following areas:

Man-in-the-middle prevention

At the minimum, perform independent certificate pinning checks along the lines presently done by EMET. This can be easily done by users entering HTTPS web sites where they do e-commerce activities. The vendor then independently extracts the thumbprint of the associated root CA certificate and stores same. Thereafter, every access to a pinned web site is verified that its root CA certificate matches the stored one.

As an added protection against external MITM activity, the vendors could employ technology similar to that done by SSL Eye. This could be done for critical web sites such as banking ones. The validation would route a simulated connection though a collection of worldwide distributed servers for the purpose of determining if any external server interception is taking place.

Man-in-the-browser prevention

Harden existing Internet facing applications against methods employed by todays advanced persistent threats. Namely, memory and disk based injection and like methods, key logging, screen capture, etc..

Blacklisting

Blacklisting using URL or IP address is a proven and effective way of means of preventing access to malicious web sites.

Containment

All Internet facing applications need to be sandboxed with any non-user specified download data auto deleted from the system. This prevention factor alone will prevent almost all Internet based malware from being installed.

All the above methods are existing and proven methods for securing Internet activity and preventing any resultant malware activity from taking place. None require the interception and decrypting of SSL network traffic.

 

the stance is already there, MITM on TLS is a big no go.

 

I think that POV is completely reasonable, but only for some people and contexts. Said "point to point transmission of data" may be perfectly secure in the sense that it is immune to sniffing/MITMing/tampering... yet be used for infiltration and/or exfiltration purposes that HARM security/privacy. While there are various ways to try to avoid getting into such a situation, they don't always work. While there are various ways to try to determine whether an application/OS/device is abusing a communications channel that is impervious to inspection, the easier/practical ones don't always work and others can be so complicated and time consuming that virtually everyone (including most professional engineers) would give up and just pray it isn't happening. Having the option to decrypt/MITM connections, and perform inspection and/or protective forms of blocking, is incredibly important.

A business may want to decrypt/MITM encrypted channels in an attempt to prevent, or at least detect (so they can respond to), cases of infiltration and/or exfiltration. An individual person may want to do the same for the same reasons. The reasons are valid in both of those cases. Note, however, that in both of these cases I'm talking about the true OWNER/ADMIN of the system(s) making the decisions. The party we accept as having ownership over systems/traffic, and the right to make the decisions.

SEPARATE from that is the question of whether or not it is appropriate for one party to have access to another party's encrypted traffic. In the business case it is usually accepted that users exist as employees who have agreed to be subject to their employers practices, so interception is largely tolerated there. Also, parental monitoring (up to a certain age that is argued over), guardianship over mentally challenged adults, prison, perhaps some other cases, too. It is outside of such cases (where there is sufficient agreement that party A has a legitimate right/need to make decisions for/affecting party B) where we'd run into your "no valid reason to" point.