Web browsers are also to blame for Lenovo's Superfish fiasco
- 10 March, 2015 00:07
Lenovo pre-installing Superfish software was a security disaster. Whether Lenovo was evil, or, as they eventually claimed, merely incompetent, it's hard to trust them going forward. If nothing else, their initial denials that anything was wrong, leave a lasting impression. Of course, Superfish, along with the software that they bundled from Komodia, also deserve plenty of blame for breaking the security of HTTPS and SSL/TLS.
Taking a step back however, blame also falls on our web browsers.
Google (Chrome), Microsoft (Internet Explorer), Apple (Safari) and Mozilla (Firefox) enable the security hack that Superfish and others such as PrivDog and Gogo engage in. They do this by omission, not commission.
Let me explain.
Secure (HTTPS) web pages are required to send the web browser a file called a digital certificate which serves, among other purposes, to insure that you are actually viewing the website you think you are viewing.
This is needed because the underlying design of the Internet makes scam websites possible. That is, you could be looking at somebankingsite.com and instead of it really being a bank, it could be a phony duplicate site designed to trick you in any number of ways.
One defense against this, is the digital certificate file. Just as a postmark proves where and when a letter was mailed, the certificate file is supposed to prove the identity of the website.
To run a secure HTTPS website, you first have to get a certificate file from any of the hundreds of companies in business to sell them. These trust-selling profit-making companies are called Certificate Authorities. They are supposed to check the identity of the person or company making the request.
Pass the identity check, pay a fee, and you get a certificate file vouched for by a Certificate Authority.
Techies refer to the certificate file as "certificate" or, more often, just as a "cert". An article about Gogo at Ars Technica referred to it as an "HTTPS certificate". A recent Bloomberg story about Hilary Clinton's private email system called it an "encryption certificate" referring to another of its purposes - being the basis for encrypting data in transit. Google, in their explanation of the topic below, calls it a "security certificate".
Verbiage like this probably sounds reassuring, to non-techies, but, the system is terribly flawed, so much so, it borders on being a scam.
One of the biggest flaws in the system is that any Certificate Authority (CA) can vouch for any website.
Add to this, the fact that there are hundreds of Certificate Authorities and each one has sub-contractors than can also issue certificates.
Plus, no one knows who these companies are. GeoTrust, Entrust, USERTrust, GTE CyberTrust, Starfield, CertPlus, DigiCert and Thawte are not exactly household names. Steve Gibson is fond of pointing out that the Hong Kong Post Office is a trusted Certificate Authority. Would you trust a website whose identity is certified by the Hong Kong Post Office? Our browsers do.
The companies that produce web browsers did not create this flawed system, but they aid it, by hiding it.
The time has come for web browsers to stop hiding the name of the Certificate Authority vouching for secure websites.
No doubt, Microsoft, Apple, Google and Mozilla will point out that the name of the vouching Certificate Authority is readily available. Technically, it is. Realistically, however, it is not, at least not for the non-techies that need it the most.
To see the name of the vouching Certificate Authority you need to know a secret handshake, a clickstream that's never explained to newbies. And, the handshake differs for each browser.
Limiting myself to just Windows, I found multiple paths to uncovering the name of the vouching CA.
With Firefox 36 (above), you need to click on the company name in green, just to the left of the website name in black on the address bar. In the window pops up, "Verified by" is the CA name.
In Chrome 41, the company name is dark green in a light green rectangle. You again need to click on the company name, then on the word "Connection". It is not immediately clear in the window that pops up that there are two tabs, one for Permissions, one for Connections. For whatever reason, the visual design of these tabs is totally different than the browser tabs right above it. In the Connection tab, the CA name is in the first sentence, after "has been verified by".
With Internet Explorer 11 you don't need to click, but you do need to shift your focus from the left side of the address bar to the right side. Hovering the mouse over the name of the company, produces a popup window with the CA name displayed after "Identified by".
Opera 27 starts off like Firefox, you need to click on the company name displayed in green next to the website name in black. Then, you need to click on the word "details". The name of the Certificate Authority is shown, but it is not identified as such.
Vivaldi technical preview 2 offers a secret handshake hint. If you hover the mouse over the company name displayed in green to the left of the website name, a pop-up window says "site info". Another clue that clicking here offers more goodies is the fact that the background color changes from light green to dark green. Clicking on the company name produces a window that looks exactly like Chrome, with a default Permissions tab and a Connections tab.
One operating system, five browsers, four different click trails to learn the name of the vouching Certificate Authority.
Stepping away from Windows, Safari on OS X does not let you click on the company name, you have to instead click on the much smaller green lock to left of the company name.
Two iOS 8 browsers function like Jekyll and Hyde. Chrome does not show the company name, only the URL. In total contrast, Safari only shows the company name and hides the URL.
The worst thing about Safari on iOS 8 is that no matter where you click, press or hover, it won't rat out the Certificate Authority vouching for secure websites. Heck, it doesn't even show full URLs. Then too, Chrome running on Android is also incapable of identifying the Certificate Authority vouching for a secure website.
Strange co-incidence that the most popular browsers on iOS and Android are both missing an important security feature.
You may have also noticed in the screen shots above that the Certificate Authority is never identified as such. Nerds designed the user interface so they assume everyone on the planet is, like them, already familiar with the system. I guess they don't have mothers.
On Windows, Firefox, Chrome and Vivaldi use "verified by", Internet Explorer uses "identified by" and Opera just puts the name out there without a label.
The best explanation I have seen is Safari on OS X which says, in effect: company x has identified website y as being owned by company z. Fairly straightforward. But even this explanation does not identify the Certificate Authority as a Certificate Authority, making it that much harder for non-techies to get with the program.
Adding to the confusion is the name of the Certificate Authorities. In the Bank of America examples above, we saw four different names: VeriSign Inc, VeriSign (without the Inc), Symantec Corporation and my personal favorite: Symantec Class 3 EV SSL CA - G3.
How does one Certificate Authority end up with four names?
In part it comes from the certificate file having multiple embedded names for each CA. Chrome displays the "common name" while Firefox displays the "Organization name". None of the browsers displayed the "Organizational Unit" name, which, in this case, was "Symantec Trust Network".
Multiple names also stem from the use of sub-contractors (not the term nerds use, but one that better represents the concept) by Certificate Authorities.
These sub-contractors, in turn, can have their own sub-contractors. In reality, a single CA never vouches for an individual website, the lowest sub-contractor does. So, what name should the browser show? That of the lowest sub-contractor, an intermediate sub-contractor or the highest level Certificate Authority>
In the Bank of America examples shown earlier, the browsers reporting that VeriSign vouched for the website, got the name from either the mid-level sub-contractor CA or the original contractor CA (known to techies as the root CA).
And it gets worse.
In the case of the Bank of America, nerds know that Symantec bought VeriSign, so the NSA was not playing tricks on me when I took these screen shots. The two are one and the same.
But, does the Bank of America really use VeriSign? Maybe they use DigiCert or GeoTrust or Thawte. How can we know? The only way to know is if your sister works for the bank.
Still think my earlier use of the term "scam" was too harsh?
With this as background, we can now fully understand how Superfish worked.
Simply put, Superfish placed itself between the victim and the rest of the world.
When Lenovo customers thought they had a secure connection to somebankingsite.com they did not. They had a secure connection to Superfish software running on their Windows 8 PC.
Likewise, the bank was also fooled into thinking they were communicating directly with a customer. They were not, they were also talking to Superfish. It's a classic man-in-the-middle attack.
In the old days, only bad guys and spies carried out man-in-the-middle attacks. Now advertising companies do it too.
Classic man-in-the-middle attacks had an insecure HTTP connection between the web browser and the bad guy. If substituting HTTP for HTTPS did not give it away, then the missing lock icon should have. Things have progressed since then.
Superfish was able to hide its presence by providing the web browser with a certificate file. Not the real certificate file, of course, one that Superfish created on the fly. No matter what secure HTTPS website the Lenovo customer visited, Superfish dynamically created a certificate for it.
Another part of the attack involved getting the web browsers to trust certificates from Superfish. Normal computers do not.
Months went by without Lenovo customers noticing that Superfish was vouching for every secure website in the world. This tells me that finding the name of the vouching Certificate Authority is too hard. I'm sure that Gogo was issuing scam YouTube certificates well before a flying Google employee noticed it.
Web browsers need to clearly identify the vouching Certificate Authority in a prominent way. Make us click to remove the name rather than show it. Browsers need to shine a light on a system that functions in the dark.
The late retailer Sy Syms used to advertise that "an educated consumer is our best customer". Not so in the tech world. Keeping non-techies ignorant seems to be a goal.
If the Certificate Authority name was prominently displayed in the browser window, end users could benefit in multiple ways.
For one thing, financial firms might be motivated to publicize the Certificate Authority they use, making scams harder.
And, over time, we will inevitably learn something about the various companies in the business of selling trust.
We'll see the Certificate Authorities used by major companies and come to trust them more than a company whose name we have never seen before. We will know who is supposed to be vouching for the secure sites we frequent. As things stand, the identity of a CA means nothing to almost everyone using the Internet.
Spy agencies would hate educated consumers.
The current system serves them well. They can offer up a scam copy of a website and vouch for it with a certificate from a compromised Certificate Authority. Compromising a single CA, lets them vouch for any website, as long as the CA name is hidden. If we could see that Harveys Certificate Authority was vouching for the Bank of America, the scam wouldn't work.
So, lets see it Google, Apple, Mozilla and Microsoft. I dare you to prominently tell your users the Certificate Authority vouching for the identity of supposedly secure websites.
Certificate Authority identities matter.