Should antivirus HTTPS scanning be left on? Is it secure?
~4 sources that will make you think twice about the security of AV TLS decryption:
Antivirus Software Weakens HTTPS Security: Researcher
“It seems strange that it turned into something people consider a legitimate security technology. Filtering should happen on the endpoint or not at all. Browsers do a lot these days to make your HTTPS connections more secure. Please don't mess with that.”
ESET representatives said the company is aware of the issues presented by the researcher.
The researcher reported that Kaspersky’s product is vulnerable to FREAK attacks, in which an attacker can force clients to use weaker, export-grade RSA encryption. This can be problematic considering that Kaspersky intercepts HTTPS traffic by default for important websites, the expert said.
“I also found a number of other issues. ESET doesn't support TLS 1.2 and therefore uses a less secure encryption algorithm. Avast and ESET don't support OCSP stapling. Kaspersky enables the insecure TLS compression feature that will make a user vulnerable to the CRIME attack,” Böck reported. “Both Avast and Kaspersky accept nonsensical parameters for Diffie Hellman key exchanges with a size of 8 bit. Avast is especially interesting because it bundles the Google Chrome browser. It installs a browser with advanced HTTPS features and lowers its security right away.”
That was in 2015;
And:
Validating TLS certificates in non-browser software is the most dangerous code in the world
See "DNS Over TLS" here: https://dnscrypt.info/faq or the source here.
Some Bitdefender products break HTTPS certificate revocation (Source):
If a website’s certificate has been revoked by a certificate authority—for example, because it was issued fraudulently or because its private key was compromised by hackers—affected Bitdefender products will still accept it as valid. More importantly, as part of their HTTPS scanning feature, they will convert the revoked certificate into a certificate that local browsers will trust, despite the fact that under normal circumstances those browsers would reject the original certificate.
Ditch the HTTPS Scanning feature of your antivirus (Source):
Users might be vulnerable while accessing secure HTTPS websites, and their antivirus is to blame. A thorough research, conducted by experts at Mozilla Firefox, Google, Cloudflare and three American universities, shows that several popular antivirus software “drastically reduce connection security” and expose users to decryption attacks. This isn't new by any means and the HTTPS interception technique used by anti-viruses has been the subject of debate for several years.
And here's the problem: Security software vendors are poorly handing inspection after the TLS handshake, according to the researchers. They’ve looked at eight billion TLS handshakes generated by Firefox, Chrome, Safari, and Internet Explorer, with antivirus software on. Researchers have analyzed Firefox’s update servers, a set of popular e-commerce websites and the Cloudflare content distribution network.
“In each case, we find more than an order of magnitude more interception than previously estimated,” the paper reads. They found interception happening on four percent of connections to Mozilla's Firefox update servers, 6.2 percent of e-commerce sites, and 10.9 percent of US Cloudflare connections. What’s worrying is that when intercepted, 97 percent of Firefox, 32 percent of e-commerce, and 54 percent of Cloudflare connections became less secure.
“As a class, interception products drastically reduce connection security. Most concernedly, 62% of traffic that traverses a network middlebox has reduced security and 58% of middlebox connections have severe vulnerabilities,” the report reads.
Not only do security software reduce connection security, but also introduce vulnerabilities such as failure to validate certificates.
That was in 2017,
The large attack surface and many variables of TLS stack like TLS cipher suite/false_start/secure negotiation, session identifiers, RTT-0, downgrade protection, Privacy oriented OCSP Stapling/public key pinning, and other parameters may be broken, downgraded, modified or unavailable by AV TLS and replace specifications of the browser. To be as secure as a browser, all these security mechanisms must be included, and kept up with the times, which is something dedicated web-browsers excel in. It would be best if they could detect and mimic browser settings. HTTPS interception also affects non browser connections. Hopefully they have and will continue to improve rapidly, but the "most dangerous code in the world" is something I would be cautious with. Replacing hundreds of points of failure (one cert in place of hundreds) with one point of failure is risky. Cutting this out may be a necessary change home & enterprise environments to ensure malware is not inadvertently assisted by MITM AV or Middlebox AV. Better alternatives include cisco Encrypted Traffic Analytics: Detection without Decryption
If you want to scan HTTPS traffic to find malware, you need to decrypt it. Avast achieves that by installing their own root certificate to locally intercept your web traffic, acting as a man-in-the-middle.
(Avast has a blog post explaining their approach.)
Is the method they (let's say Avast as an example) use secure?
The main emerging security problem is that whoever knows the private key for the generated root certificate can encrypt your traffic. That's why they create a unique one for every machine and don't send it anywhere else:
We want to emphasize that no one else has the same unique key that you have from the installation generated certificate. This certificate never leaves the computer and is never transmitted over the internet.
That's a good practice and in theory guarantees that they can't easily plot with your ISP to decrypt your traffic from remote. Also note that all certificates will still be checked against the local Windows certificate store so a self-signed certificate will be identified as such and won't be "covered" by Avast's root cert and displayed as trusted.
Another security concern to be aware of is that you can't inspect the original certificate details in your browser anymore. You can be sure that it's verified but the displayed properties (authority details, encryption algorithms, ...) will be those of the Avast cert, not the original ones.
Should HTTPS connections really be scanned?
If you think HTTP traffic should be inspected, then HTTPS should be, too. HTTPS just secures the connection, it doesn't verify that the website owner has good intentions and their site wasn't compromised.
is the probability of getting such malware from an HTTPS secured website high enough to enable this feature?
Subjectively, I'd say the majority of malware is still served over plain HTTP. But with free certificate providers like Let's encrypt it's not much effort for an adversary to switch to HTTPS. Serving malware over HTTPS has some advantages for the attacker - the padlock makes it appear more legitimate and it's harder to inspect. Malware over HTTPS will certainly become more likely in the future.
Also note that there are other, less intrusive approaches to protect you from malicious websites such as Google Safe Browsing.