11

Some antivirus software MitMs, or through other methods, HTTPS connections in order to scan for malware, for example, Avast, and maybe other vendors too.

  1. Is the method they (let's say Avast as an example) use secure? Is their claim that the data never leaves my computer true?

  2. Should HTTPS connections really be scanned? I'm not asking whether HTTPS automatically protects from viruses, it doesn't, but is the probability of getting such malware from an HTTPS secured website high enough to enable this feature?

  • 1
    I tend to use an application layer firewall, but I know that Avira at least is able to scan web content without breaking HTTPS. It flagged a JS file from apis.google.com (pretty sure I use cert pinning for *.google.com sites), though it was a false positive. Try monitoring outgoing packets if you're worried about privacy though. – timuzhti Jan 15 '17 at 00:41
  • I'm not worried in the sense that I'm paranoid or something, nope, I'm just asking whether such a feature is really necessary or not. – Buffer Over Read Jan 15 '17 at 00:56
  • @Alpha3031 Could you expand a bit on this? – Buffer Over Read Jan 15 '17 at 02:20
  • 1
    @Alpha3031 That's true for manual downloads. But what about, say, malicious flash applets? – Arminius Jan 15 '17 at 02:23
  • 1
    @Arminius Well, many antiviruses are capable of scanning memory objects, though not on access. It's something that *could* be implemented instead of SSL stripping. – timuzhti Jan 16 '17 at 02:38
  • 1
    @timuzhti: Most browser don't enforce certificate pinning against user-installed (or AV-installed) root certificate. – Lie Ryan Mar 07 '19 at 09:45

3 Answers3

9

~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

Tyler
  • 417
  • 5
  • 12
  • Would be really amazing if there was a suite one could upload to a website and test all this. Research is good but not having practical uses for it is really disapointing. – Dan Jan 31 '20 at 15:41
5

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.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • Thanks for your answer. Is there any way I can view the original certificate's properties without disabling the feature, then? – Buffer Over Read Jan 15 '17 at 02:01
  • @TheBitByte I'm not sure how to retrieve SSL certificate details on Windows. On Linux I use OpenSSL on the command line with: `openssl s_client -showcerts -connect google.com:443` – Arminius Jan 15 '17 at 02:12
  • I meant on Chrome. Doing it from cmd line each time is hassle when really 95% of the time I just don't care and browse normally. – Buffer Over Read Jan 16 '17 at 18:10
  • 1
    @TheBitByte Chrome can't see the original certificate anymore, so you can't check it from within Chrome. But as said, Avast still ensures that the certificate is valid. – Arminius Jan 16 '17 at 20:10
  • If even if it was at the time, this is no longer true, see Cisco's Encrypted Traffic Analytics: Detection without Decryption https://www.youtube.com/watch?v=oFoAVJOoCZw – Tyler Mar 21 '19 at 05:51
0

This is certainly the first I've heard of avtivirus software scanning inbound HTTPS connections.

I'm aware that Avira's antivirus solution will scan cache content as Firefox writes it. Some secure sites will ask for contents not to be written to cache, so obviously scanning will not take place under that circumstance.

But turns out that yes, in fact it is replacing web certificates with its own root CA certificate and then using that in place instead of the website's certificate. This is how Man in the Middle (MitM) attacks are carried out.

From Avast's Website:

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.

Further goes on go to explain:

The Avast WebShield must use a MITM approach in order to scan secure traffic, but the important difference is that the “middle man” we use is located in the same computer as the browser and uses the same connection. Since Avast is running with Administrator rights and elevated trust on the computer, it can create and store certificates that the browser correctly accepts and trusts for this, and only this, machine. For every original certificate, Avast makes a copy and signs it with Avast's root certificate, located in the Windows Certificate store. This special certificate is called “Avast Web/Mail certificate root” to clearly distinguish who created it and for what purpose.

An important note about this:

Our customers’ privacy was our first concern when planning the implementation of HTTPS scanning. That’s why we created a way for whitelisting, or ignoring, the connection when Avast users access banking sites. Our current list has over 600 banks from all over the world and we are constantly adding new, verified banking sites. You can, and should, verify the bank’s security certificate when using online banking sites. Once verified, you can submit the banking or other web site to our whitelist by sending us an email: banks‑whitelist@avast.com.

What happens if I attempt to connect to a website with a self-signed certificate? Avast will detect this, and use an untrusted certificate signed by Avast, allowing for normal "insecure" browser behaviour. The browser will still warn the user that the connection is insecure.

I don't see any mention of secure data being shipped off site, but be sure to read the software's privacy policy and end user licence agreement. The feature can be turned off, as explained Avast's website.

Web link: https://blog.avast.com/2015/05/25/explaining-avasts-https-scanning-feature/

dark_st3alth
  • 3,052
  • 8
  • 23
  • "what happens if I attempt to connect to a website with a self-signed certificate? As far as I know it will become trusted" -That's wrong. Avast still checks with the Windows certificate store if the original certificate is legitimate. If it's self-signed, you will be notified in the browser. – Arminius Jan 15 '17 at 01:30
  • @Arminius So it's not signed by Avast, and the browser continues on as it normally would? – dark_st3alth Jan 15 '17 at 02:03
  • Maybe I'm misunderstanding you. My point is that Avast will still detect invalid certificates. It won't silently hide untrusted certificates behind its own root certificate and present them to your browser in the same way it presents trusted ones. The verification step is effectively delegated from your browser to Avast but it's still done in the same way. – Arminius Jan 15 '17 at 02:18
  • 1
    Avast first checks the original certificate against your computer's certificate store. If the original certificate is **not** valid, it will intentionally perform the stripping with an **untrusted** Avast certificate to trigger the browser alert. – tlng05 Jan 15 '17 at 02:26
  • @tlng05 thank you for the clarification. I will update my answer. – dark_st3alth Jan 15 '17 at 05:21