I've read a lot about Superfish (and similar ad-ware) lately and I basically understand the vulnerability to MITM attacks. But I'm actually wondering if the "secure connection scan" by Kaspersky Antivirus is as broken as the Superfish example?
I mean Kaspersky installs a root certificate onto my computer and "man in the middles" all connections to scan for malware. For my understanding this isn't any better than the Superfish disaster... what makes Kaspersky more secure?
Hopefully, someone will do the testing and give a definitive answer for Kaspersky for you. Meanwhile, here's an answer for the general case:
It depends.
Does running an SSL proxy against yourself weaken your security posture? Certainly. Will any given product weaken your security posture as bad as Superfish? That's very implementation-dependent, and also subject to the threats against the individual product itself.
Superfish failed at two critical points.
It used a weak password to protect a private key that was not unique for each system. This resulted in the key being easily breakable and publicly disclosed so that anyone could pretend to be your authorized Superfish proxy.
It failed to properly validate certain conditions on SSL certificates, which allowed the Superfish proxy to accept otherwise-invalid certificates and present the website to the end-user as if it were legitimate.
While the first part is an important break, it's the second bit which is arguably the most critical flaw. Without the second flaw, users would still be relatively well protected so long as the key remained secret. (Kerckhoffs's principle in action.) However, given that second flaw, an attacker wouldn't even need the key to launch a convincing Man-in-the-Middle attack between a Superfish user and an otherwise-secure website.
Taking this into consideration, there's a couple simple countermeasures which can largely protect users.
Generate unique root keys for each installation, protect them with strong and unique passwords, and do not distribute the keys beyond the host on which the proxy resides. This prevents disclosure of the key for one system from having a substantial impact on the security of any others.
Validate SSL certificates properly, and provide appropriate notifications to the user when something is amiss. Without this, the key doesn't much matter - an attacker just needs to convince the proxy that their site is legitimate, by exploiting a flaw in the validation process, and the proxy will present the site as such to the user.
Get these things correct, and you're good to go - right? Well, not quite.
See, now we run into a problem with presenting the certificate to the user. Because the proxy has to intercept the traffic, and re-key it with its own credentials, the user still never sees the original credentials of the site. Every site will appear to have a certificate issued by the proxy, with date and time stamps according to when the proxy generated the MitM cert. This completely removes the user's own ability to decide which CAs or trust paths they hold credible, or to recognize changes in the certificate over time. It also prevents corroboration of the certificate with other trusted external entities.
Take the case of DigiNotar, where an attacker was able to use a commonly-trusted Root CA to generate bogus certificates for Google services. Without an SSL proxy in place, the user may be alerted to suspicious activity by one or more of several means.
With a proxy, all of these options are no longer available to the end-user. The proxy itself may be configured to watch for, and alert upon, these issues (just as some browser plugins do) but ultimately the end-user still loses the ability to see it for themselves.
