15

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?

  • 6
    If you're lucky it uses a different CA for each computer and the proxy validates the original certificate. If you're unlucky, it's just as bad as superfish or Privdog. – CodesInChaos Feb 23 '15 at 20:46
  • 1
    mrclschstr, welcome to Information Security, and thanks for bringing this here! I don't think it is substantially different, though as @CodesInChaos says hopefully it is not as broken as the others. Still doesn't change the negligent attitude to TLS, PKI, and CA security though . – AviD Feb 23 '15 at 20:49
  • It can be the same as Superfish, but as Kaspersky first objective is securing (not pushing ads and tracking you), I would think Kaspersky is safer. – ThoriumBR Feb 23 '15 at 20:53
  • 2
    @ThoriumBR Comodo also makes security software (well-known for their free firewall), and is even a major CA for SSL certs used across the Internet, and we're hearing they got it wrong too - so I wouldn't assume Kaspersky to do any better, without actually testing myself. – Iszi Feb 23 '15 at 21:10
  • 1
    Link to Comodo story. Lavasoft (Ad-Aware) is also mentioned. arstechnica.com/security/2015/02/… – Iszi Feb 23 '15 at 21:11
12

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.

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

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

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

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

  • A browser plugin or other utility could compare the certificate to other certificates previously seen at the same site by the same user, and alert the user to unexpected changes. (e.g.: Different CA than before, new certificate issued far out-of-sync with previous certificate's expiration, etc.)
  • A browser plugin or other utility could compare the certificate to certificates reported at that site, by an online community or other trusted authority, and alert the user to unexpected discrepancies (e.g.: 98% of users in your region report seeing a different certificate than the one you're seeing).
  • A diligent user might check the certificate themselves frequently and notice the unusual changes.

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.

  • Meanwhile someone did the testing: bugs.chromium.org/p/project-zero/issues/detail?id=978 – mrclschstr Jan 5 '17 at 20:59
  • @Iszi - If i have understood post correctly, my understanding is that a proxy would install its own certificate on a client. It would then establish a connection to a site on-behalf of a user. Assuming this is correct, how does this differ from SSL termination and inspection? – Motivated Nov 2 '18 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.