This is cool and all but if the victim has Superfish installed there's no need to use the private to MitM the connection. The Superfish software is not properly passing the validation state of the public cert when it connects to a website like Bank of America as an example.

The software is simply not triggering appropriate warnings in the browser when provided an obviously fake certificate that has been generated in a way to bypass browser warnings. It's also not properly validating revoked certs. Both of these situations are very bad. Allowing any self-signed cert would lead me to believe that this could have easily been exploited in the wild without prior knowledge of this vulnerability.

I've notified the software vendor of the impacted software and they are working diligently to patch all of their software. As such, I not going to provide a how-to guide on how to exploit users here. I also notified both Superfish and Lenovo of this issue on Thursday (US), neither of which have responded.

Anyway, the following is an example of the improper status pass through based on doing something that might be quite obvious to those who understand how the browser validates a public against the fully qualified domain name.

This is what the browser should do when it encounters a self-signed cert delivered by an SSL/TLS MitM solution:

http://defaultstore.com/six.png

However, it's not doing this for this self-signed public cert:

http://defaultstore.com/four.png

Note both certs show "verify_fail." at the beginning and those who know how browser cryptography works will understand what has likely gone wrong with their implementation.

The ramifications of this are fairly significant. An attacker running sslsplit as example, configured like many instances are that we actually see in the wild can MitM Superfish software connected HTTPS sessions without the Superfish private. This means that a bad guy didn't actually need to know about this software and reverse it to compromise connections.