This reports that Avast, an antivirus program, inserts itself as a man-in-the-middle on all SSL connections on computers it's installed on. This actually makes sense; if it wants to scan for malware in web pages and file downloads coming from https sites, it has to either do this or mess with the internals of web browsers, and MitM is easier and less likely to cause technical problems.
The problem is, making a secure SSL endpoint is really hard; if you aren't very very careful in how you distinguish good from bad SSL certificates, then users are vulnerable to having their connections tampered with by things like untrusted Wifi routers. Web browsers put a lot of work into distinguishing good and bad SSL certificates, and Avast's MitM interferes with this working correctly. In particular, this article reports that Avast will accept revoked SSL certificates, which is a problem.
What ought to happen here, is that Avast (and other AV vendors) should be coordinating with Chrome (and other browser makers) to provide an API for antivirus software to get access and scan, in a way that doesn't interfere with the normal SSL authentication machinery. I suspect that browser vendors are hesitant because an API created for that purpose would likely also get hijacked and used by malware and adware.
Microsoft has introduced Antimalware Scan Interface in Windows 10 which tries to accomplish this, idea being that applications with possibly malicious content can feed buffers to be scanned by whichever antivirus programs that have registered themselves as ready to handle such calls. This also means that e.g. a JS engine could feed strings fed to eval() to be scanned.
This is the right way to do it. Microsoft got AV companies to change for XP SP3 (something to do with Windows Security Center?), maybe they can do it again here.
Avast installs its own kernel drivers (on windows at least) so it already has access to everything in userland without requiring a special API.
The MITM part was probably added for performance reasons or perhaps out of sheer laziness judging from how they managed to mess up certificate validation. Although this seems to be a common issue with web filters in AV/DPI products.
It is also worth noting that certificate pinning in Chrome was deliberately weakened to accept a self signed CA certificate in order to maintain compatibility with the aforementioned corporate web filters. DropBox, in contrast, has strict pinning policies that it is essentially MITM-resistant without compromising the client first.
> It is also worth noting that certificate pinning in Chrome was deliberately weakened to accept a self signed CA certificate in order to maintain compatibility with the aforementioned corporate web filters.
All major browsers (including firefox) allow MitM for a user installed CA. This is not Chrome-specific.
What ought to happen here, is that Avast (and other AV vendors) should be coordinating with Chrome (and other browser makers) to provide an API for antivirus software to get access and scan, in a way that doesn't interfere with the normal SSL authentication machinery.
No. MITM'ing SSL means it can access all communications, not just the ones one browser wants to give it. There are plenty of other things on a system (and increasingly more these days) that can communicate via SSL, and it makes sense for AV to inspect those too; whether you trust AVs is a different issue.
The problem is that revocation essentially doesn't work.
What other browsers do is this:
* Connect to OCSP server
* If connection fails certificate is considered valid
At some point the Chrome devs decided that instead of having a stupid, insecure revocation check that does nothing if an attacker knows how stupid and insecure it is they could also disable it.
This could be fixed with OCSP Stapling and Muststaple, but it's still a long way till this will reasonably work.
> This actually makes sense; if it wants to scan for malware in web pages and file downloads
Since when does Avast concern JS? I would have thought, to intercept file you'd use the systems file API? Everything else is the concern of the browser, because it knows how to mess with the internals of web browsers.
A browser API would defy the purpose of security layering. The browsers for example, doesn't report their internal tracking request to the developer tools, and probably wouldn't provide that info to an API either.
Does anyone have a guide on how to MITM SSL from your own computer!?
> Suppose, for example, that you go to the Bank of America site to transfer some funds or pay a bill. As with Google, and as would happen with any other secure site, it turns out their certificate gets replaced with the Avast certificate. I doubt anyone needs me to lecture them on the potential security issues involved in having a third-party watching their banking transactions without permission!
Antivirus software runs with the highest level of privileges, divert system calls...
They could theoretically log everything you type on the keyboard, no need to MITM SSL connections
> Avast is replacing certificates with its own without bothering to check the validity of those certificates!
Avast is not the only antivirus program that does that these days; ESET does it, and Symantec's Norton products do as well IIRC. As everything moves toward TLS, this is pretty much a required step on the client for "Internet Security", and the average person doesn't know or doesn't care.
Largely, you probably should not either if you are trusting the AV client with the rest of your computer. Yes, it can be fucked up and break TLS, but there are a thousand other ways a privileged executable like an AV program could fuck up a lot more of your system. For example, a bunch of CVEs were found in Kaspersky's product by Tavis Ormandy in September, and it appears that a few found in Avast have been made public within the past few days. [1]
Sophos AV seems to go a step further, intercepting any outbound telnet connection. Good to know if your company uses Sophos and you used to use telnet for basic connectivity testing.
> Largely, you probably should not either if you are trusting the AV client with the rest of your computer. Yes, it can be fucked up and break TLS, but there are a thousand other ways a privileged executable like an AV program could fuck up a lot more of your system.
You're right that antivirus software is more or less a sieve of a shield, but this doesn't really make sense.
If AV exploits are worth fixing, then so are the exploits made available by AV certificate handling.
I'm quickly understanding that I need to learn to be more specific as to what the premise of my statement is before I comment here.
I agree with your point as to fixing all holes; I was making the point more toward people freaking out that these AV systems are inserting the certificates and inspecting the traffic in the first place. Sorry for the confusion.
(The article is almost a year old, but the issues remain)
The AV MITM certs are not exactly Dell- or Lenovo-bad, as they are all uniquely generated in each installation, so you can only fake traffic on computers you have Admin access - and then you don't need Avast for that.
However, the real issue is if these MITM-proxies render compromised, expired or otherwise insecure TLS-connections "secure".
The bare minimum should be to respect the cert storage of the computer, although that will fail with any application with its own storage, like Firefox. To me this feels like it has too many points of failure to increase security instead of lowering it, so you really would focus on detecting malicious content based on other things, like the host reputation, files that land on disk, or maybe having a browser plugin that would see at least some of the decrypted HTTPS content.
Any sufficiently advanced antimalware program becomes indistinguishable from malware in its methods. He who fights monsters should see to it that he does not himself become a monster.
The "well you trust your AV with your computer anyway, you should trust it with this" argument is a terrible one. It's not about trust. It's about decreasing footprint.
ESET had a pretty big security vulnerability over the summer. As seen in this post, Avast isn't properly validating certificates. AV providers aren't bug free by any stretch of the imagination. Granted, browsers and OSes have their own vulnerabilities. At the end of the day, though, the fewer people that touch your encrypted communications, the better. Every time there's some hack or workaround or other vulnerability, the number of devices affected increases substantially.
_This isn't okay._ Especially for a security vendor. Security should be done the right way, every time, period. Taking advantage of hacks or workarounds or other unsupported ways of intercepting data (e.g., MITMing HTTPS traffic with a self-signed cert) exposes users to risk. Not to mention, browser or OS vendors might close those loopholes in the future and break the security software.
This is like saying, "I'll protect your car from carjackers. Just replace all your door locks with these ones." How much do you trust the security provider to not use the same key twice? How much do you trust that they're properly checking which key is the correct key? How much do you trust them that their proprietary black-box locks work as advertised? Do you trust them more than your car manufacturer? Do you trust that they aren't going to be vulnerable to a malicious key fob?
That said, if encrypted traffic is a blind spot for AV vendors, they should be working with browser vendors to make sure proper, secure APIs exist to get around those limitations. Hacky workarounds are not the answer.
One of the big problems with "security" software is that it wants to plug itself into the system at such a low level that the security software itself becomes a security risk. Much security software isn't very secure. After all, if it has online updating, it is a backdoor.
We have to be much more suspicious of software like that now, with the FBI Director pushing for backdoors and trying to get vendors to install them.[1]
Readit News
The problem is, making a secure SSL endpoint is really hard; if you aren't very very careful in how you distinguish good from bad SSL certificates, then users are vulnerable to having their connections tampered with by things like untrusted Wifi routers. Web browsers put a lot of work into distinguishing good and bad SSL certificates, and Avast's MitM interferes with this working correctly. In particular, this article reports that Avast will accept revoked SSL certificates, which is a problem.
What ought to happen here, is that Avast (and other AV vendors) should be coordinating with Chrome (and other browser makers) to provide an API for antivirus software to get access and scan, in a way that doesn't interfere with the normal SSL authentication machinery. I suspect that browser vendors are hesitant because an API created for that purpose would likely also get hijacked and used by malware and adware.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn8...
The MITM part was probably added for performance reasons or perhaps out of sheer laziness judging from how they managed to mess up certificate validation. Although this seems to be a common issue with web filters in AV/DPI products.
It is also worth noting that certificate pinning in Chrome was deliberately weakened to accept a self signed CA certificate in order to maintain compatibility with the aforementioned corporate web filters. DropBox, in contrast, has strict pinning policies that it is essentially MITM-resistant without compromising the client first.
All major browsers (including firefox) allow MitM for a user installed CA. This is not Chrome-specific.
Yeah but at the kernel level the packets are still encrypted, the encryption happens in userland.
AV kernel drivers exist to prevent or harden against tampering, as well as disk access filtering.
No. MITM'ing SSL means it can access all communications, not just the ones one browser wants to give it. There are plenty of other things on a system (and increasingly more these days) that can communicate via SSL, and it makes sense for AV to inspect those too; whether you trust AVs is a different issue.
Deleted Comment
It should be noted that Chrome itself has this problem. Android does as well. Rather odd given Google's generally proactive work on SSL.
What other browsers do is this:
* Connect to OCSP server
* If connection fails certificate is considered valid
At some point the Chrome devs decided that instead of having a stupid, insecure revocation check that does nothing if an attacker knows how stupid and insecure it is they could also disable it.
This could be fixed with OCSP Stapling and Muststaple, but it's still a long way till this will reasonably work.
Since when does Avast concern JS? I would have thought, to intercept file you'd use the systems file API? Everything else is the concern of the browser, because it knows how to mess with the internals of web browsers.
Does anyone have a guide on how to MITM SSL from your own computer!?
All they have to do is write an addon that communicates with the native part of the virus scanner.
Deleted Comment
Antivirus software runs with the highest level of privileges, divert system calls...
They could theoretically log everything you type on the keyboard, no need to MITM SSL connections
> Avast is replacing certificates with its own without bothering to check the validity of those certificates!
This is a far bigger issue
Largely, you probably should not either if you are trusting the AV client with the rest of your computer. Yes, it can be fucked up and break TLS, but there are a thousand other ways a privileged executable like an AV program could fuck up a lot more of your system. For example, a bunch of CVEs were found in Kaspersky's product by Tavis Ormandy in September, and it appears that a few found in Avast have been made public within the past few days. [1]
[1] https://code.google.com/p/google-security-research/issues/de...
You're right that antivirus software is more or less a sieve of a shield, but this doesn't really make sense.
If AV exploits are worth fixing, then so are the exploits made available by AV certificate handling.
I agree with your point as to fixing all holes; I was making the point more toward people freaking out that these AV systems are inserting the certificates and inspecting the traffic in the first place. Sorry for the confusion.
The AV MITM certs are not exactly Dell- or Lenovo-bad, as they are all uniquely generated in each installation, so you can only fake traffic on computers you have Admin access - and then you don't need Avast for that.
However, the real issue is if these MITM-proxies render compromised, expired or otherwise insecure TLS-connections "secure".
The bare minimum should be to respect the cert storage of the computer, although that will fail with any application with its own storage, like Firefox. To me this feels like it has too many points of failure to increase security instead of lowering it, so you really would focus on detecting malicious content based on other things, like the host reputation, files that land on disk, or maybe having a browser plugin that would see at least some of the decrypted HTTPS content.
ESET had a pretty big security vulnerability over the summer. As seen in this post, Avast isn't properly validating certificates. AV providers aren't bug free by any stretch of the imagination. Granted, browsers and OSes have their own vulnerabilities. At the end of the day, though, the fewer people that touch your encrypted communications, the better. Every time there's some hack or workaround or other vulnerability, the number of devices affected increases substantially.
_This isn't okay._ Especially for a security vendor. Security should be done the right way, every time, period. Taking advantage of hacks or workarounds or other unsupported ways of intercepting data (e.g., MITMing HTTPS traffic with a self-signed cert) exposes users to risk. Not to mention, browser or OS vendors might close those loopholes in the future and break the security software.
This is like saying, "I'll protect your car from carjackers. Just replace all your door locks with these ones." How much do you trust the security provider to not use the same key twice? How much do you trust that they're properly checking which key is the correct key? How much do you trust them that their proprietary black-box locks work as advertised? Do you trust them more than your car manufacturer? Do you trust that they aren't going to be vulnerable to a malicious key fob?
That said, if encrypted traffic is a blind spot for AV vendors, they should be working with browser vendors to make sure proper, secure APIs exist to get around those limitations. Hacky workarounds are not the answer.
It is not superfish-bad, but it's still bad. But AVs are full of security problems, it's really just a broken concept.
We have to be much more suspicious of software like that now, with the FBI Director pushing for backdoors and trying to get vendors to install them.[1]
[1] http://www.theregister.co.uk/2015/10/09/us_encryption_backdo...