Shouldn't Lenovo be issuing a recall and pulling all the inventory in their distribution channel? In other words, Best Buy shouldn't be selling these things!
Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
11–20 of 188 posts
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#12This is a PDF attached to this issue, requesting blacklisting of the Superfish certificate: https://bugzilla.mozilla.org/show_bug.cgi?id=1134506
I'm somewhat puzzled by the single certificate. Couldn't they have generated a new signing request and self-signed on each machine - at least ensuring that each customer has a unique cert for their proxy?
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#13Earlier quoted context omitted.
The Superfish proxy accepts any certificate. If you're being MITMed (before Superfish MITMs you), Superfish will help them by replacing their certificate with Superfish's.
I don't believe that's true, but if so – for example if it replaces self-signed certs, or certs from any untrusted CA, with its own (force-trusted) cert – then that would be worthy of another scary explicit bullet point. (It might just accept all CAs locally-configured, and it's accepting its own because they didn't special-case a rejection.)
It is true. I can't remember where I read it, but I remember seeing it either here on HN or on Twitter.
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#14I find it a bit weird that it can MITM https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#15Shouldn't Lenovo be issuing a recall and pulling all the inventory in their distribution channel? In other words, Best Buy shouldn't be selling these things!
You are absolutely right, but frankly, they never should have sold them to begin with.
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#16I find it a bit weird that it can MITM https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.
Maybe it triggers the logic that allows (supposedly) user-added certs to override those pins? (Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections.)
Edit: I think that's the case. AGL's original announcement of pinning said:
"There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues."
https://www.imperialviolet.org/2011/05/04/pinning.html
If Chrome thinks that this was a "user installed root CA", it would have been allowed to override the pin. (Disclaimer: I haven't checked that this is right, I'm just using my recollection of how this could work according to AGL's account.)
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#17I find it a bit weird that it can MITM https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.
Chrome does do pinning, but ignores pins when the cert parent is a privately installed cert (because this is a "feature" used by many enterprises).
"""
Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor.
A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites.
'Data loss prevention' appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.
"""
See: http://www.chromium.org/Home/chromium-security/security-faq#...
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#18I originally discovered this issue a month ago when debugging my friend's Lenovo laptop. Neither chrome nor IE can render battle.net correctly because the HTML injection is not properly escaped. Since the problem persists after a fresh recovery, I guess it's from some pre-installed software. I almost reported it to FBI.
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#19I find it a bit weird that it can MITM https://www.google.com/ on Chrome. I thought Chrome did CA-pinning for Google-domains.
Maybe it triggers the logic that allows (supposedly) user-added certs to override those pins? (Google was pressured into adding such logic by corporate users, whose IT departments want to -- supposedly openly -- MITM employees' connections.) Edit: I think that's the case. AGL's original announcement of pinning said: "There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certifi…
Ah, That explains it. Thanks! And to semenko too.
Re: Browser Vulnerability to Superfish: A Fact-Finding Trip to Best Buy [pdf]
#20Earlier quoted context omitted.
I don't believe that's true, but if so – for example if it replaces self-signed certs, or certs from any untrusted CA, with its own (force-trusted) cert – then that would be worthy of another scary explicit bullet point. (It might just accept all CAs locally-configured, and it's accepting its own because they didn't special-case a rejection.)
It is true. I can't remember where I read it, but I remember seeing it either here on HN or on Twitter.
Komodia's own info says that it will generate an invalid certificate if the real certificate was invalid or untrusted "so it will not cause a security problem". They may be lying, but that page is fairly open about the way it works:
http://www.komodia.com/wiki/index.php?title=SSL_Digestor#Cer...