8 ms·

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

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.

wmt 11y ago
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. https://msdn.microsoft.com/en-us/library/windows/desktop/dn889587%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dn8...
- voltagex_ 11y ago
  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.
  - yuhong 11y ago
    Security Center was introduced with XP SP2.
  - josephcooney 11y ago
    This is on OSX though, right?
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
Laforet 11y ago
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.
- mschuster91 11y ago
  > Avast installs its own kernel drivers (on windows at least) so it already has access to everything in userland without requiring a special API. 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.
  - mentat 11y ago
    Kernel level drivers have access to user space memory and can see the unencrypted data easily.
    - mschuster91 11y ago
      Yeah but they have to find the data first. Given that Chrome with 10 tabs easily eats 2GB of RAM, not an easy task imho.
      - leereeves 11y ago
        And they'd have to be updated for every build of Chrome.
      - Laforet 11y ago
        True, hence I wrote "for performance reasons or perhaps out of sheer laziness". There are better ways to handle it but they are not always the easiest.
the8472 11y ago
Browser extension APIs already provide a way to intercept and inspect network connections. All they have to do is write an addon that communicates with the native part of the virus scanner.
- icebraining 11y ago
  What Chrome extensions APIs allow you to do that?
ceejayoz 11y ago
> In particular, this article reports that Avast will accept revoked SSL certificates, which is a problem. It should be noted that Chrome itself has this problem. Android does as well. Rather odd given Google's generally proactive work on SSL.
- hannob 11y ago
  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.
  - patcheudor 11y ago
    I raised the OCSP validation issue with the Chromium team in the past: https://code.google.com/p/chromium/issues/detail?id=439851 https://code.google.com/p/chromium/issues/detail?id=439851 While I understand their position, I don't entirely agree with it for one simple reason. I'm not convinced someone will always be on a compromised network. From my own experience, the most likely network man in the middle scenarios occur while traveling like when connecting to an airport or hotel network. Many bad guys know how to evil-twin WiFi and implement transparent TLS proxies. With this in mind, if a user visits a site frequently and that site revokes their cert, there's a good chance the user will not be on an evil network when the OCSP check is made. Therefore, if Chrome cached the responses and permanently revoked the certs the risk to the user does in fact decrease. As stated in my report, Heartbleed really did make the choice to ignore OCSP a bit more risky because private key material really was stolen from a number of companies.
userbinator 11y ago
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.
z3t4 11y ago
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!?
conceit 11y ago
> 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.

wmt 11y ago

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. https://msdn.microsoft.com/en-us/library/windows/desktop/dn889587%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/dn8...

voltagex_ 11y ago
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.
- yuhong 11y ago
  Security Center was introduced with XP SP2.
- josephcooney 11y ago
  This is on OSX though, right?

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

Laforet 11y ago

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.

mschuster91 11y ago
> Avast installs its own kernel drivers (on windows at least) so it already has access to everything in userland without requiring a special API. 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.
- mentat 11y ago
  Kernel level drivers have access to user space memory and can see the unencrypted data easily.
  - mschuster91 11y ago
    Yeah but they have to find the data first. Given that Chrome with 10 tabs easily eats 2GB of RAM, not an easy task imho.
    - leereeves 11y ago
      And they'd have to be updated for every build of Chrome.
    - Laforet 11y ago
      True, hence I wrote "for performance reasons or perhaps out of sheer laziness". There are better ways to handle it but they are not always the easiest.

the8472 11y ago

Browser extension APIs already provide a way to intercept and inspect network connections. All they have to do is write an addon that communicates with the native part of the virus scanner.

icebraining 11y ago
What Chrome extensions APIs allow you to do that?

ceejayoz 11y ago

> In particular, this article reports that Avast will accept revoked SSL certificates, which is a problem. It should be noted that Chrome itself has this problem. Android does as well. Rather odd given Google's generally proactive work on SSL.

hannob 11y ago
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.
- patcheudor 11y ago
  I raised the OCSP validation issue with the Chromium team in the past: https://code.google.com/p/chromium/issues/detail?id=439851 https://code.google.com/p/chromium/issues/detail?id=439851 While I understand their position, I don't entirely agree with it for one simple reason. I'm not convinced someone will always be on a compromised network. From my own experience, the most likely network man in the middle scenarios occur while traveling like when connecting to an airport or hotel network. Many bad guys know how to evil-twin WiFi and implement transparent TLS proxies. With this in mind, if a user visits a site frequently and that site revokes their cert, there's a good chance the user will not be on an evil network when the OCSP check is made. Therefore, if Chrome cached the responses and permanently revoked the certs the risk to the user does in fact decrease. As stated in my report, Heartbleed really did make the choice to ignore OCSP a bit more risky because private key material really was stolen from a number of companies.

userbinator 11y ago

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.

z3t4 11y ago

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!?

conceit 11y ago

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