Google and Mozilla's message to AV and security firms: Stop trashing HTTPS

http://www.zdnet.com/article/google-and-mozillas-message-to-av-and-security-firms-stop-trashing-https/

Is there any real security benefit for consumers on enabling this feature in security products ?

 

Malware could be detected on network level instead of file system level... User could benefit if network monitoring part can detect more than file system monitoring part of AV. Personally I usually disable HTTPS scanning.

 

I think it's best to disable this feature. AV's should have other ways to detect and block exploits and malware.

 

But enabling this feature can allow security products to intercept Banking, Email, other sensitive traffic unless there is an option for user to exclude some sites or products decide to exclude sensitive sites by default
This could lead to some privacy issues if products intercept all https site traffic by default ?

 

Yes exactly, AV's have no business trying to intercept/inspect this type of traffic.

 

I have a simple solution to this issue.

Have the browser scan for malware in encrypted traffic. Might as well include unencrypted traffic as well. Until they are willing to do so, Google and Mozilla please shut up and cooperate with the AV vendors in developing scan methods that accommodate all in a secure and effective manner.

 

Some AVs have developed plugins to do just that.
Browsers also use safe browsing checkups by default so there are some basic protections put in place.

 

They can't scan encrypted traffic with them. The plug-ins, etc. are hooks they use to detect browser hijacking, keylogging, screen scrapping, etc. and memory modification attempts.

 

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."

 

OK, I understood their purpose was to monitor network traffic and not attacks against browser.
Description of let's say TrafficLight makes me think this way:
https://addons.mozilla.org/en-US/firefox/addon/trafficlight/

 

I believe Bitdefender's TrafficLight is nothing more that a reputation based scanner along the lines of SmartScreen. In other works its a blacklist.

 

Yes I know it's black list solution but I don't know if it checks network traffic after it's decrypted by browser and before it's written oh disk. I always thought that those plugins would solve a problem of encrytped traffic.

 

The checking is done after decryption from what is stored in memory and is primarily URL or IP address based. In other words, the actual code being used is not being scanned.

 

Thnx for explanation.

 

Apparently G DATA doesn't do HTTPS scanning, so the researchers made a mistake:

https://blog.gdatasoftware.com/2017/02/29496-g-data-does-not-touch-https

 

Although not evaluated in the original study, Emsisoft have posted on their blog that their products do not intercept any HTTPS traffic: http://blog.emsisoft.com/2017/02/09/https-interception-what-emsisoft-customers-need-to-know/

 

Another point of view:

https://www.virusbulletin.com/blog/2017/02/security-products-and-https-lets-do-it-better/

 

I read the article a while back and I concur.

Also these research studies if done properly do help - or more appropriately, strongly prod - the AV vendors to fix the deficiencies noted. Eset for example fixed the cert. pinning issues in ver. 9 which didn't exist in the latest ver. 10 products.

 

I'm with Rasheed

on this one. There may be, but I haven't seen it, discussion about a "good" AV cert replacing a "bad" site cert. Who's reponsibility is it?

We can all accept the Internet is fundamentally flawed, simply by being a product of a much less rapacious age. But over and above my belief that an AV should be solely concerned with the contents of files I import, is that mistakenly or correctly, it seems any MITM work, regardless of intentions, is an avenue of attack. How would we feel if our favourite AV was to do the same to our email clients?

Yes, Gammadyne Clyton offers encrypted (TLS1.2) connections. There is no way I want my emails made public.

AMSI is a good start. I understand why it won't ever be ported to Win7 (Does *nix or iOS have an equivalent?)

Perhaps because Google and Mozilla have very little experience in malware. (Please, no comments from the Peanut Gallery!) OTOH, maybe the AV industry should do so.

However, we have a chance to redesign the WWWeb in a secure manner. How about we lean on Mozilla, Google and others to put submissions to W3C? How about we lean on AVs to come up with a better solution than Certificates?

 

"Each to their own" as the saying goes. I'll stick with AV SSL protocol scanning.

Recently encountered a HTTPS web site that attempted to download Cerber ransomware upon access to the web site. This was by drive-by download and as best as I can determine no exploit was involved. Eset caught it by generic signature before it even hit the HDD and terminated the connection.



-EDIT- As far as Win 10's AMSI protection goes, its primary purpose is to scan WScript and Powershell packed and obfuscated scripts after they decrypt in memory. As such, it is a "post-execution" mitigation. Being a post execution mitigation, there is a risk that partial malware infection may have occurred.
Ref.: http://news.thewindowsclub.com/microsoft-antimalware-scan-interface-amsi-78665/

Bottom line - you want to stop malware before it hits your PC.

 

Engadget at https://www.engadget.com/2017/03/31/when-the-s-in-https-also-stands-for-shady/ has a lovely little think-piece.

Trouble is, TLS is for secure transmission, it was never intended to identify "SAFE" sites The dodgy site wiil deliver its payload to your browser securely, and probably quite safely

 

The problem the browser vendors don't want to elaborate on is since the decryption occurs in the browser, the malware can begin its execution.

The problem also is a definition and procedural one. That is, what is "secure point-to-point" transmission. I argue that once the encrypted transaction has reached the target's network buffer, TLS has been successfully completed. Which means that intercepting it after that point as some security products do is not only acceptable but necessary for malware prevention.

 

Ummm. I had a good read of "The Security Impact of HTTPS Interception" (https://jhalderm.com/pub/papers/interception-ndss17.pdf) as quoted in https://www.virusbulletin.com/blog/2017/02/security-products-and-https-lets-do-it-better/.

Particularly interesting are paragraphs 4 and 5 in Section 1. Introduction and following. I use Avast, for a number of nonsensical reasons, and I found it necessary to not install any Shield except File Shield. The insertion of Avast's Certificate in place of whatever the site offered meant I had no conception of the site's security or authenticity. I am assuming that Avast's Certificate and encryption was To Standard, but then we note in Fig 3. Security of TLS Interception Middleboxes that if had a Mac I could be in serious trouble:

AV 11 Win # # A* ✓ ✓ 1.2 Mirrors client ciphers
AV 11.7 Mac F ✓ ✓ 1.2 Advertises DES​

and since I don't normally use IE for browsing, it seems there's no interception anyway.

I think we can agree to differ in our opinions. But no AV will ever be allowed to inspect any of my web-facing activities.

 

For anyone concerned about whether their AV SSL protocol scanning is working properly, do what CERT recently recommended.

Go to the web site: https://badssl.com/dashboard/ to run tests to validate SSL processing is working correctly. The only test I have issue with is the dh1024 cypher test. Appears GitHub set that up to throw a warning if the cypher is allowed since it is recommended that only dh2048 be used. However, that is a recommendation only and dh1024 is still allowed per security rating concerns.

-EDIT- When running the badssl.com test, make sure you select "block" in response to every alert generated by your security solution's SSL protocol scanning processing.

 

Do no evil with Avira (or nasty HTTPS handshakes)
https://blog.avira.com/evil-nasty-https-handshakes/