EFF: Lenovo is breaking HTTPS security on its recent laptops

In the UK we have the Unfair Terms and Conditions Act. If I as a private individual object to clauses in a contract, the Judge can just throw them out.

I think here, where it seriously compromises a security mechanism ("I agreed to give them a skeleton key to my house?!?! wtf!?!?"), I think a Judge would throw it out almost without bothering to think about it.

Cheers,
Wol

My understanding was that http://perspectives-project.org/ does something like this, installable as a Firefox extension.

The reasoned interpretation is that to see executives not worried demonstrates that SB has no teeth. In fact most of it never went into effect, because the detailed rules still have not been written. The new US Senate is hard at work dismantling what little bite it has.

To repeal protection of investors takes a positively dizzying cynicism.

Lenovo is a Chinese company incorporated in Hong Kong, traded on the Hong Kong exchange, and headquartered in Beijing. Sarbanes-Oxley doesn't apply to them, they don't file 10Q, and they aren't regulated by the SEC.

Your comment is accurate, but note from the article: "We can report that the Decentralized SSL Observatory has seen 44,000 Superfish MITM certificates, all of which have been signed by the same Superfish root cert. The fact that there are significant numbers of Firefox victims somewhat contradicts the speculation that Firefox is safe because it doesn't use the Windows root store. This either indicates that Superfish also injects its certificate into the Firefox root store, or that on a large number of occasions Firefox users have been clicking through certificate warnings caused by Superfish MITM attacks."

> It was discovered because a Google security researcher noticed something funny when he logged into Bank of America on his new Lenovo laptop. He examined the certificate and saw that it was not what BoA typically uses. He then mentioned it on a security mailing list and other people confirmed what he saw and found the core issues.

Do you have a link to that mailing list post? I tried searching for it, but since this news has spread like a forest fire during a lengthy drought (it even got to LWN even though it's not Linux related at all!), I couldn't find where it was originally posted.

"It will be very difficult to know for _certain_"

Yes, I would liken this situation to the case with counterfeit coins.

I cannot be certain that any particular coin is genuine. But there are a series of ways in which counterfeits might fall short of the specification for the genuine article and if I spot one of those differences I can be certain it's a counterfeit.

All the mint can do is try to make it easy enough for me to spot the difference that counterfeiters are likely to give up because the expense of producing a passable fake is too high to permit a good profit on such a criminal endeavour; and of course to insist on heavy penalties for anyone who gets caught.

This is also like counterfeiting in that it's decidedly NOT an impulse crime. Crimes of impulse don't respond to penalties. The average murder or theft is spontaneous, the criminal doesn't research the tariffs or prosecution rates, and so e.g. imposing a death sentence for murder doesn't make much difference to your murder rate. But you'd better believe no-one sets up a successful counterfeiting operation without a great deal of advance planning and consideration, and that means they know exactly what the penalty is if they're caught. Imposing a 10% of revenue fine for Lenovo over the period of the wrong-doing would send the message that this is actively _bad_ for your bottom line and dissuade other executives from considering such shenanigans.

Why doesn't the browser's navigation bar show the certificate issuer all the time, and more prominently than the URI?

How can this MITM work with arbitrary domains? Shouldn't the browser check that the requested hostname matches the CN or subjectAltName fields in the certificate that the server responds with? Does the Superfish software generate new certificates on the fly, with the proper CN?

Of course wildcard certificates are possible, but AFAIK they are restricted to one level. So a hostname such as internetbanken.privat.nordea.se (as shown in the screenshot above) wouldn't match a wildcard such as *.se, even if the certificate contained wildcard subjectAltNames for all top level domains - of which there are a lot nowadays, and increasing all the time.

Am I missing something?

These days most insider traders would just use a 4G-enabled phone.

Besides, there are absolutely no regulations that require companies to filter traders' traffic or monitor what they say to each other in restrooms.

> As for the trader example, I didn't make it up.

Well, a lot of banks have demonstrated their banking incompetence and their own "SuperFishes" over the last few years, so what kind of IT [in]competence and naivety can you expect from them?

Maybe this is what happened with http/2 and proxies (just a wild guess): very long list of use cases and requests, most of them completely stupid, a couple of valid ones hidden/buried in the middle. Rejected.

> it's a lot easier to set up a centralized security gateway than to trudge through thousands of clients

And in these days of BYOD, it's debateable whether it's acceptable, as a requirement of employment, for employers to demand access to their employees' private property.

There are a few cases out there, where an employee has left, the employer has wiped their phone, and the ex-employee's "entire" social life has been wiped - personal photos, contacts, friends, etc etc.

If it's a company phone then the employee should have returned it, but if the employer *expects* the employee to provide their own phone, that sort of behaviour is likely to land them with a very expensive data recovery bill, at an absolute minimum! In Europe, that would be considered completely unacceptable.

(Oh, and as a - I believe real - example, can I refer you to the guest lecturer who's laptop unexpectedly rebooted in the middle of his presentation. The University he was visiting, the network had detected his laptop, installed their own security software, and forced a reboot, all without him knowing anything about it!!!)

Cheers,
Wol

> One of the arguments for not fixing the proxy situation in browsers is that users are easily misled and therefore:

Well, it's true that users are easily misled. It's also true that often the user is not in control of its own computer, even if the user has not been misled.

> 1. the web site should be in total control of the connexion and

Both ends should be in total control of the connection: the browser and the web server.

> 2. the browser should not give users any choice (much like TV advertisers "own" TV viewers brain time and some blue ray players do not let users skip ads).

I don't see many arguments against in-browser ad blockers, in-browser script blockers, or many other things which give users choice.

> When proxies are Internet-giant side they are called good CDNs. When they are user side they are called evil MITM to be eradicated at all costs.

The argument is not against proxies. The argument is against MITM. The CDNs do not do MITM; they terminate the secured TLS connection before the proxy. The client-side equivalent would be a client speaking plaintext HTTP to a proxy which in turn opens a HTTPS connection to the server.

> Because proxy services are useful trying to blindly fight proxying (renaming it MITM) instead of putting users in control only results in mass workarounding. With malware like superfish taking advantage of the situation.

Nobody is renaming anything. "Man-in-the-middle attack" is a technical term. When a normal connection is between endpoints A and B, a MITM attack splits it into two connections, one between endpoints A and M, the other between endpoints M and B, while making A believe it's still talking directly to B and vice-versa.

Against a purely passive attacker, unauthenticated encryption is sufficient. If, however, the attacker can pretend to be one of the endpoints, he can negotiate the encryption as if it was the endpoint, and thus defeat the encryption. To protect against that, the endpoint must be authenticated: that's what the server certificate is for.

SSL was designed to protect a connection against eavesdropping, so the user can send confidential information like a credit card number or a password to the server, secure in the knowledge that only the server will have access to it. To be able to do that even in the presence of active attackers, it has to authenticate the server, as I just explained. Any attempt to work around this authentication breaks the confidentiality which is the whole point of using SSL/TLS in the first place.

There's no "blind fight" against proxying; the fight is against proxies which break the TLS model. You just mentioned proxies that don't break the TLS model, like Tor and CDNs; the fight is not against them.

> Superfish could only happen because adding CAs roots manually is common. It is only common because browsers refused to fix proxy interfacing. They'd rather have users add CA roots manually to override browser security than admit they need to tackle proxy interfacing seriously (admittedly, it's a hard problem, but seriously? how much effort did they extend those past years to please their advertising sugar daddies?).

The problem with "proxy interfacing" is that it still breaks the TLS model: while it doesn't break the protocol (avoiding the kinds of disasters we've seen with Superfish and we'll keep seeing with other MITM proxies), it allows a third party to have access to confidential data. Which is probably why it isn't taken seriously by the browser and protocol developers.

The addition of CA roots is because of a bug in the X.509 model: any CA root can create a certificate for any endpoint. That's a hard problem to solve, but it is being worked on. Unfortunately, some have turned this bug into a feature, which conflicts with attempts to fix the bug.

> Tor helps users route connexions through a proxy system. This proxy system
> provides a service to users (anonymising). There are many other
> user-friendly services a proxy can provide. Some rely on decryption, others
> not (mail antispam smtp relay services rely on decryption). Proxying is such a
> core part of the Internet architecture it is one of REST pillars.

And it's just been shown Ad-Aware used the same tech to talk to the browser. Not a malware, something the user explicitely installed and wanted to work.

I rest my case. Browser proxying defficiencies are pushing more and more legitimate uses in ssl-attack-land.

> Any reasonable implementation of "safe proxies" in the browser would ensure that the user is warned about the proxy, so SuperFish would still be forced to resort to installing its own root certificate and pretending to be the remote site.

I think you are still missing the point.

If "mutually consented" proxies were implemented, then installing root certificates could be made near impossible. With certificates pinning or whatever else.

Installing root certificates is way too easy because it's the only workaround for the lack of mutually consented proxies. This is the hole SuperFish used.

> But don't presume that it would have prevented this situation.

We do :-)

>> The thing is, providing a "clean" way to MitM a user's connection wouldn't have changed anything about SuperFish, because the designers of SuperFish *didn't want the user to know* that the connection is being intercepted. <<

_Nobody_ wants the user to know. That's the dirty secret that Nim-nim probably won't want to talk about.

In newer default Android there is a mandatory reminder on every reboot if you have an extra CA cert that would allow MitM. That's all. Just a reminder prompting the user to check and pay attention if they don't intend to be snooped on. Everything still works, but each time you reboot the reminder is there "Your network access may be snooped".

I get that message because I have my personal root CA installed on one device.

Corporates with MitM proxies were _outraged_. They said Google had just made Android unusable, it was a huge breach of trust with them, they would have to switch to iPhones and ban Android across the corporate network...

Why? Because Android was telling their users the dirty secret, that everything they do is snooped. They don't want users to know that! Their lawyers have assured them that some phrase in a contract like "the company may at its discretion use technological means for intellectual property protection and other purposes" means they're legally entitled to snoop on everybody if they can find a way, and so that's exactly what they do. They stashed a MitM CA on the corporate Android image precisely so that their users would _not_ know they were being snooped.

A "safe" proxy will only be acceptable to these people if in fact all the protections you imagine it would have can be disabled. They will argue that their users _already_ consented and so there definitely shouldn't be any real warning UI, any clear sign that they're being snooped on. So yes, Superfish would just install its "safe" proxy and check the "Yes, I 100% pinkie swear that I obtained full consent from the user so it's just between you and me" box.

Now in practice we have enough UX knowledge at this point for the "hush it up" crowd to be satisfied with some sort of UI change. For example some people in this thread have discussed adding a new colour to the URL bar. That would be fine. Maybe on IE you get a purple diamond, in Firefox it's an orange triangle, in Chrome it's a yellow circle. Users won't know or care what those mean just like they never cared what a broken padlock symbol meant, so that'd be fine. And LWN readers inclined to support this stuff will be able to say "But they were warned, so it's OK" and sleep soundly. But an actual effective warning? Not going to happen.

If the security department is preventing you from doing the job that you were hired for (with the implied, the way you think you should be doing it), you have a few options

1. figure out if there is a way for you to do your job that the security department will agree with

2. get your management to convince the security department to relax their restrictions

3. find another job.

note that "find a way to bypass security" is not one of the valid options.

While you may be convinced that you know what you are doing and the security guys are paranoid idiots, you don't have the full picture of everything that's going on and all the requirements that may be in place. Management is paid to make find the balance between the competing desires of the company, and they need to do their job. If they can't do this, the company is not going to do well in the long run and you really do need to be looking for another job so that you have a place to land when it implodes.

Having a security group that runs amok and shuts the business down is bad, but so is letting every employee decide that they know better than the rest of the company what processes and policies they are going to follow.

Now, if you want to talk about specific policies in specific situations and argue that they are wrong, that's a very different discussions. But the idea that the Security people are always wrong and it's perfectly fine to ignore them is no more valid than deciding that the HR people are always wrong, or the Finance people are always wrong, both of which will get you fired _really_ fast.