This should be mitigated by browser vendors by integrating HTTPSEverywhere as a core functionality of the browser that needs to be explicitly turned off (instead of the current state of affairs where we have a tiny minority on the web who are familiar with installing security add-ons). Visiting a HTTP site should come with a scary warning. I understand this throws old sites under the bus, but there could be other solutions here such as restricting 3d party resources as a second layer defense once the user clicks through the first warning to access the HTTP content.
and in case I'm totally wrong, what mitigations are feasible? More trade war such as by compelling ISP's to null-route Chinese businesses like Baidu.com as a form of sanction?
I recently (4 or 5 months ago) joined an online community of aircraft owners and pilots that is primarily focused around a single brand of aircraft (although it's not an official site of, property of, that brand nor is it endorsed by that brand).
When I signed up, they emailed me to welcome me to the site (they actually require manual authorization of users by an admin, which is... refreshing, but uncommon). The email ended by stating that if I lost my password, they could "recover it" and send it back to me.
I raised a thread about it in one of their off-topic sections, and got harassed - "How secure do you need your browsing to be?" (And hey, I mean, I was asking them to do more work)
But it stands out that most of the public doesn't know, and doesn't care to know. Even a site that's populated by people with net worths and/or incomes that average in the six-to-seven figure range, that they probably signed up for with the same email address and password that they use for their bank and brokerage accounts.
HTTP should come with a warning. Furthermore, it would be fan-fucking-tastic if there was some generalizable way to (automatically) audit a website's security practice. Like, a crawler that just runs standard OWASP-style attack-vector checks, and sends an email to the site's owners when one succeeds. And then put that data into a database and warn users (with a browser plugin) when they are creating credentials for sites with bad security.
I'll top that. I used TABCPermit.com to get licensed to serve alcohol in Texas. Their signup form says "no special characters in password". I used one anyway, putting in "password$1" for example. It accepted it, and I worked on the test.
Next day, I can't login. I use the "forgot password" link. They send me and email, and it has my password in it! Bad, right?
That isn't all. My password, they said, was "password1". They silently stripped out the special character.
I just about flipped a table at how security-shallow people who build websites can be.
Are you sure your password has a $ in it? What makes you think that they don't strip the $ when you set and enter your password?
If it seemed like they were doing a hash then compare, I would wonder if they are using the legacy unix crypt that truncates passwords at 8 characters.
I know when I registered and typed twice that my password had "$" in it. And they mailed me back my password without it. Finally, it wasn't just a truncate because there were characters after the position where "$" should be.
And if they did strip it out, that is bad. That's the point.
I'd recommend using an OpenID Connect provider to authenticate if you're concerned about their practices but it's just as easy to improperly implement auth even with mainstream libraries to help you connect something like Auth.0 to your app.
e.g. Don't assume the email address is owned by the person making the claim. You can sign up for an account with an email and if it's not verified or the verification is mis-clicked or phished into being clicked the original account owner would never know the difference.
Still, at least with OpenID Connect you know your password isn't sitting in plain text.
That's a bit too harsh. The GA people are lobbying to continue to be able to fly their aircraft. The FAA has been sitting on the problem of non-leaded avgas for something like 30 years now. The GA people don't like being exposed to lead any more than anyone else.
Yes, harsh on people literally choosing to spray a neurotoxic heavy metal compound over populated areas for their fun. Their advocacy is the roadblock to the adoption of safer fuels.
It doesn't actually accumulate in any particular area. There was a study done at at an airport that showed no particular accumulation at the airport. Leaded gas ends up poisoning the whole world a bit.
This "dilution is the solution to pollution" argument is the excuse the FAA uses for forcing everyone to use leaded avgas. This should be more of a scandal. The FAA is basically helping maintain a harmful oil company monopoly at the expense of the world.
This is not just about recreational aircraft. For example, 45% of the Canadian commercial fleet is piston engine based. Incidentally, Canada was involved in a test program with the FAA for leaded fuel replacements. The FAA recently dropped out of that program.
I think we'd all rather burn cheaper / more prevalent gas than a leaded fuel that is the output of specialty refining. We're not allowed to by regulation, though, and furthermore present solutions would also endanger safety in a big slice of aircraft. The fleet of general aviation aircraft is really old, after all.
> This should be mitigated by browser vendors by integrating HTTPSEverywhere as a core functionality of the browser that needs to be explicitly turned off (instead of the current state of affairs where we have a tiny minority on the web who are familiar with installing security add-ons).
We're talking about China, so that's probably not going to work: Chinese users are using Chinese browsers [1] to access Chinese websites. I don't think Chinese browser-makers and website operators are going to take action against their government like that.
That's fine. If the Chinese government wants to commandeer their own citizen's resources to DDoS other people, that's on them. They could very well also direct their state controlled ISPs to do the same. Doing either would be obviously be attributed to them and would be cause for them to be de-peered - solving the problem.
sure. but that would still limit the attack to only come from within CN (and possibly users outside with a CN browser) and not from every potential user who has Safari/Mozilla/Chrome.
It would mitigate attacks from inside China against outside entities, which for somebody not based in China is all I want.
The concern here is people using Chinese websites abroad. The Great Cannon rewrites javascript for a subset of remote users visiting Chinese sites, causing the users' browsers to participate in a DDoS against a target.
for anyone interested, Brian Krebs did an excellent article[1] on The Great Cannon after the Citizen Labs incident.
> [Nicholas] Weaver said the attacks from the Great Cannon don’t succeed when people are browsing Chinese sites with a Web address that begins with "https://", meaning that regular Internet users can limit their exposure to these attacks by insisting that all Internet communications are routed over "https" versus unencrypted "http://" connections in their browsers. A number of third-party browser plug-ins — such as https-everywhere — can help people accomplish this goal.
> But Bill Marczak, a research fellow with Citizen Lab, said relying on an always-on encryption strategy is not a foolproof counter to this attack, because plug-ins like https-everywhere will still serve regular unencrypted content when Web sites refuse to or don’t offer the same content over an encrypted connection. What’s more, many Web sites draw content from a variety of sources online, meaning that the Great Cannon attack could succeed merely by drawing on resources provided by online ad networks that serve ads on a variety of Web sites from a dizzying array of sources.
> and in case I'm totally wrong, what mitigations are feasible? More trade war such as by compelling ISP's to null-route Chinese businesses like Baidu.com as a form of sanction?
Probably something like this, but I'm afraid of where that would lead.
If the Chinese government wants to man in the middle traffic to foreign sites they can just force PC vendors to install a CCP controlled CA root on systems and make it illegal and/or very difficult to remove it. Shit, they can require vendors include a hardware backdoor, especially since so much of that hardware is produced domestically.
Then they can view the traffic even going to and from foreign sites who would not comply with an order to share private keys and no safe browsing blacklist (like that would be accessible from inside the regime anyway) will help you.
>If the Chinese government wants to man in the middle traffic to foreign sites they can just force PC vendors to install a CCP controlled CA root on systems and make it illegal and/or very difficult to remove it.
>Shit, they can require vendors include a hardware backdoor, especially since so much of that hardware is produced domestically.
If they're only doing it for local computers, the consequences/response is the same as the previous paragraph.
If they're doing it for foreign computers on a mass scale required for a DDoS attack, if discovered will torpedo their entire electronics sector. All the "ban huawei" politicians will have a field day with that.
The Chinese government can do this for systems sold within China. They don't have the authority to do it for computers globally.
If I'm understanding other comments correctly, browser vendors installing HTTPSEverywhere cuts down the potential for this Great Cannon attack from 7.7 billion users to 1.4 billion. An 80% reduction seems significant.
I was under the impression that the other commenters were referring to HTTPS as a solution for those in China to protect themselves from their own government. Perhaps I was wrong.
> In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances that session keys will not be compromised even if the private key of the server is compromised.[1] Forward secrecy protects past sessions against future compromises of secret keys.[2][3][3]
Forward secrecy only helps you if the server private key is comprised in the future. If it's compromised already, and an active attacker can modify traffic between you and the server, forward secrecy doesn't help.
Ultimately, if an attacker has all your keys and controls all your traffic, there's nothing left that distinguishes the attacker from you. No security is possible in that scenario.
I fail to see how this attack has anything to do with http? The scripts can be served over https no problem, it’s the host that is compromised. Maybe you’re thinking of sub-resource integrity attributes?
It's injecting the malicious script into the source of http pages.
With httpS, this is not possible unless you also change the root certificate of the computer.
In most javascript sandboxes if you request a domain from an site you are restricted by the same content policy. This makes it harder to do things like make requests to sites for example that don't use https when your on one that does use it.
I don't quite understand the mechanism after reading the article. Is the attacker (presumably the PRC) MITM'ing these CDN resources at the infrastructure level? If they had exploits in place within these CDNs (presumably within the PRC's capabilities) HTTPS wouldn't help, no?
More than likely they placed a phone call to Baidu and told them exactly what to do. I doubt it's a technological MITM probably just a social one. A totalitarian state can do that.
that's why probably null routing at ISP level is more likely. the time it takes to adapt to new defenses is much less than what it takes to come to an agreement in cabforum. When things escalate nobody will push vendors to agree on new security features when a blunt instrument like legislation is cheaper. If things escalate they'll just sinkhole all traffic going in and out of China.
I understood it so that if things escalate what would stop them from simply serving malware from Baidu. If CN sees these actors as an attack on their freedom and autonomy to shape internal policy then they could easily justify this (at least to themselves).
Notable reason (for those unfamiliar) is that tee will overwrite the file unless given the -a argument which will append the input to the end of the file.
>and in case I'm totally wrong, what mitigations are feasible? More trade war such as by compelling ISP's to null-route Chinese businesses like Baidu.com as a form of sanction?
A slightly less broad measure that's just as effective would be to block unencrypted http traffic from entering China. Want to get unblocked? Get letsencrypt.
A even better (but slightly greyhat) route would be to inject HSTS headers with the maximum expiry date. This will cause any visitor's browsers to get "infected" with an unskippable warning, forcing them to upgrade no matter what.
surprised the relevant powerful/time tested and highly technical participants at whichever appropriate layer of networking aren't just forcing https only. #studentquestion
and in case I'm totally wrong, what mitigations are feasible? More trade war such as by compelling ISP's to null-route Chinese businesses like Baidu.com as a form of sanction?