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.
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.
It is more likely than the MiTM attack is being added in order to try to catch the traffic generated by an already installed piece of malware. Think a metamorphic trojan who talks to its command and control servers via HTTPS (maybe through a known social networking site). In such case, being able to decrypt the traffic might allow heuristic detection of a piece of malware that would normally avoid file-signature detection.
Edit: I guess only Server and Enterprise have POSIX: http://brianreiter.org/2010/08/24/the-sad-history-of-the-mic...
the "normal" way this was done was to have your kernel driver replace system call implementations with wrappers that check an alternate security policy. this was done so often that linux implemented loadable security modules (LSM) and then SELinux on top of that, while other systems (grsec, rbac) exist as patches. it was also one of the main causes of system instability on windows because the people that wrote the wrapper functions did not understand nearly as much about the operating system as they thought, and introduced at best crashes and at worst outright vulnerabilities.
so microsoft created a technology that stopped people from patching their kernel in that way. okay, in the game of cat-and-also-cat that is systems security in the same kernel-level privilege domain it doesn't "stop" them technically it "deters" them but the protection system is semi-random and silently updates, so if you figure out a way to break it and then later your clever hack is silently broken your customers computer will crash in a way that says "hey this one particular product just broke the rules and you should uninstall it" and why run that risk.
they replaced it with a bunch of mature callback APIs that let you do kinda the same thing but with less chance of fucking everything up.
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.
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.
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.
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.
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. 
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.
I believe that if you truly own your machine, you must be able to have complete control over the network traffic that it generates. If you consent to letting AV inspect it for you, and there would certainly be some phrase in the EULA which says so, then I see no problem with that. Personally I don't use AVs for other reasons, but opt-in consent of letting a third-party inspect all your data is not bad.
In short, the only problem here is Avast has buggy SSL implementation. I don't know if they use something like OpenSSL, but revocation checking with OpenSSL has to be done manually. A good SSL/TLS client library that has these features would make it a lot easier to do it correctly...
disclamer: I run a MITM proxy for adblocking and filtering (yes, SSL too) so I may be a bit biased.
From the above article:
The Palo Alto Networks NGFW uses a certificate-copying mechanism to open up TLS 1.1 sessions (TLS 1.2 for outbound is not yet supported but the process negotiates down to TLS 1.1) that basically works like a corporate-operated man-in-the-middle attack.
Does that mean Chrome/Mozilla will detect the negotiation down and block access to these sites?
I suppose it's different if are focused on trying to win from a starting point of a compromised machine, a kind of Core Wars game. On current systems this can't be reliably recovered from unfortunately, in that situation user should just be alerted to wipe & restore from backups.
The only real problem here is not checking the validity certs. (Which is an incredibly serious problem.)
There are other problems. I am not sure where the third party doctrine will stand, but you are trusting all of your secure connections to a third party with full consent.
If avast get subpoenaed and their software has called home, which any antivirus does - they must collect new samples all the time - this could spell trouble.
Microsoft Internet Explorer, don't even allow viewing a certificate until after you have accepted it
Incorrect; there is a "view certificate" button on the warning dialog:
Yes, SSL inspection is a security tradeoff. Whether the folks rolling it out realize this is another story.
According to Kaspersky  it's possible to mitigate 85% of threats by restricting administrative privileges, using application whitelisting and keeping the OS, browser(s) and applications patched.
If you've installed a program with administrative privileges, it already has total, unrestricted access to your machine. There may be a reason to be concerned about this, but it's not that they're getting some access that the user has not already granted by installing the software.
I'm not a fan of blacklist-based security like AV, I think it's basically useless. But if the filtering features of Avast are something you want for some reason, this seems a legitimate way to do it. The alternative is to read this data directly from browsers memory (they can do this with the access they already have), which is likely to break at every update and require a huge amount of programming effort.
I'm curious - are you looking for something more command-line oriented or GUI-driven? I have no idea how to do it via command-line, but shift-right-click on an icon will give you the Run As Different User option. This may also not satisfy your needs - it only works for some users (i.e. you can't do Run As DefApps)
The shift-right-click menu offers different entries depending on where desktop icon come from (the .lnk file is stored either in \Public\ or the users desktop directory). The run as different user is only shown if the lnk is stored in the "public" desktop.
Haven't used it much personally though.
Looks like I need to keep an eye on it, which pisses me off because if this is true of the Windows version, it means at this point there simply isn't a Windows AV solution that isn't complete garbage from one standpoint or another.
Says who? Any reliable source to back this claim up?
I assume Avast still offers full functionality without those features, since they scan program execution and resource loading anyway.