Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Great Cannon has been deployed again

cybersecurity.att.com

Post reply on HN
Print view View original

391–400 of 470 posts

Re: The Great Cannon has been deployed again

#391

Post by inimino »

jefftk wrote: post #107
mminer237 wrote: post #95

Earlier quoted context omitted.

The Chinese government has the root certificates for every Chinese certificate authority. It can MITM traffic for any citizen, even over HTTPS.

What makes this attack powerful is not that sites within China can be shut down (the government can already do that) but that sites outside of China can be tricked into DDOSing other sites outside of China. Which is why this attack only works over HTTP.

It would work just as well over HTTPS, they would just have to make a different phone call (to the site hosting the script rather than to the GFW).

Re: The Great Cannon has been deployed again

#392

Post by sonofhans »

thaumasiotes wrote: post #389
kerng wrote: post #388

Earlier quoted context omitted.

It's called hyperlink and doesnt require any code or javascript to run. Maybe excessive requests to same IP could be throttled by a user agent. An outbound browser firewall could helps also.

> It's called hyperlink and doesnt require any code or javascript to run. Hyperlinks generally don't open themselves. There is an obvious exception -- img tags[1] -- and I think it's worth considering whether they should be allowed to have the behavior they do. As far as I see, img tags load themselves so that, if you're editing HTML by hand, you don't have to deal with binary image data in the middle of what was sup…

HTML was initially intended as, and still largely is, a markup language. An HTML file provides a container and presentation for other types of content. If you saved all those types of content into the same file you'd have many of the problems HTML was specifically designed to avoid, like bloat, vendor lock-in, format incompatibility, and editing difficulty.

Re: The Great Cannon has been deployed again

#393

Post by thaumasiotes »

sli wrote: post #305
kortilla wrote: post #234

Earlier quoted context omitted.

You do know you’re suggesting that sites not be able to load assets from other sites right?

They are specifically suggesting that HTTP-only sites not be able to load from third party sites, which is quite a bit different than your interpretation of generally preventing any site from loading any external content. HTTPS ought to be the default and browsers can, and should, move towards that. But to answer your question more directly, yes they clearly know what they are suggesting.

I note this language in the writeup:

> These attacks would not be successful if the following resources were served over HTTPS instead of HTTP:

> http://push.zhanzhang.baidu.com/push.js; or

> http://js.passport.qihucdn.com/11.0.1.js

This seems overly generous. I personally would not assume that the government of China couldn't persuade Baidu or qihucdn.com to serve government-provided JavaScript.

It also assumes that the end users ("victims") here don't trust any Chinese certificate authority.

Re: The Great Cannon has been deployed again

#394

Post by kerng »

thaumasiotes wrote: post #389
kerng wrote: post #388

Earlier quoted context omitted.

It's called hyperlink and doesnt require any code or javascript to run. Maybe excessive requests to same IP could be throttled by a user agent. An outbound browser firewall could helps also.

> It's called hyperlink and doesnt require any code or javascript to run. Hyperlinks generally don't open themselves. There is an obvious exception -- img tags[1] -- and I think it's worth considering whether they should be allowed to have the behavior they do. As far as I see, img tags load themselves so that, if you're editing HTML by hand, you don't have to deal with binary image data in the middle of what was sup…

Iframes are popular for these things - also, dont require javascript to run.

Re: The Great Cannon has been deployed again

#396

Post by geofft »

paulddraper wrote: post #385
upofadown wrote: post #218

Browsers really have to be a lot more skeptical about the code they run. Running code should not be able to randomly attack any IP address on the internet. Code from non-TLS pages should not be able to run at all. Perhaps that should also apply to code loaded from 3rd party sites. Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on…

> Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on the net. But that is literally what web users want . Everything you named is a fine opinion, but runs contrary to the wishes of the vast majority of millions and millions and millions and millions of web users. EDIT: That said, browsers have features for users such as yourself to…

I think you'll need some evidence for that. Silence is not consent, and it's certainly not enthusiastic consent.

And even if you do want to take silence for consent, the fact that the vast majority of millions of millions of web users do not install an extension to route around Google AMP indicates that they do not want the operators of the web page to do whatever they want, they want to run a restricted subset of what the web designer might imagine. AMP is extremely popular among web users; approximately 100% of Google users use it. (The more defensible argument, of course, is that users don't really want AMP, at which point the question of what users really do want gets back on the table.)

Also, users did vote with their feet against downloading EXEs from the internet - which can actually do whatever the developer wants - and using JS on the web platform, which can make unrestricted GET requests (even if it can't see the responses), sure, but can't do anything near "whatever." It stands to reason that users would gladly accept even more restrictions on the execution platform.

Re: The Great Cannon has been deployed again

#397

Post by anoncake »

paulddraper wrote: post #385
upofadown wrote: post #218

Browsers really have to be a lot more skeptical about the code they run. Running code should not be able to randomly attack any IP address on the internet. Code from non-TLS pages should not be able to run at all. Perhaps that should also apply to code loaded from 3rd party sites. Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on…

> Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on the net. But that is literally what web users want . Everything you named is a fine opinion, but runs contrary to the wishes of the vast majority of millions and millions and millions and millions of web users. EDIT: That said, browsers have features for users such as yourself to…

No, that is not what web users want. No one asked them and they probably don't even have an opinion on that. It's what web developers and browser makers want.

Re: The Great Cannon has been deployed again

#398

Post by BurningFrog »

xucheng wrote: post #155
jacquesm wrote: post #149

Earlier quoted context omitted.

So it does work. It doesn't really matter where you break the chain as long as it gets broken.

It only works if you somehow remove entire China from the Internet.

China can easily operate any number of servers outside China.

Re: The Great Cannon has been deployed again

#399

Post by zzo38computer »

upofadown wrote: post #218

Browsers really have to be a lot more skeptical about the code they run. Running code should not be able to randomly attack any IP address on the internet. Code from non-TLS pages should not be able to run at all. Perhaps that should also apply to code loaded from 3rd party sites. Connecting to a web page should not be consent to allow the operators of that web page to make my computer/phone do whatever they want on…

> Browsers really have to be a lot more skeptical about the code they run.

I absolutely believe you, and wrote a document how to make improvement.

> Code from non-TLS pages should not be able to run at all.

Whether or not it is TLS is irrelevant. Either way the user may wish to put their own code, and either way the server operator can change things whether or not is what the user intends. (TLS does prevent spies from adding code, but not all unwanted code is from spies.)

> Instead of locking the web down, let's give users the freedom to put on or remove as many locks as they want to live with.

I agree. Furthermore, allow the user to override any behaviour they want to do, too.

Allow the user to examine and copy the script (possibly with modifications); if the script changes (whether due to MITM or due to the author altering it or due to some other company purchasing them), it no longer runs unless the user approves the new one, too. Extensions that only allow free software to run don't help either; just because it is free software does not necessarily mean it is a program the user wants their computer to execute. Or, maybe the user wants to execute a modified version instead!

Re: The Great Cannon has been deployed again

#400

Post by geofft »

jMyles wrote: post #263
greggman2 wrote: post #241

Earlier quoted context omitted.

Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Someone needs to come up with a solution for that. Ideally one that works with free and open source projects and not just well funded companies.

> Unfortunately there's a giant category of devices that can't serve TLS. Like pretty much every consumer router in existence that you connect to through a webpage. Come on now. Of course those devices can use TLS - they just can't do so in the capricious constraints imposed by the system of "certificate authorities". It's not a fundamental limitation of the technology. If we were using something like noise protocol,…

Why do they have to use self-signed certs? Ship the device with a valid cert for $last_three_octets_of_mac_address.$vendor.com to the device, and print it clearly on the setup instructions. Typing in something like d63d15.ui.com isn't onerous.

The CA/Browser Forum allows certs up to 27 months - do routers sit on store shelves for 27 months before being configured? Do they even sit for 12 months? (Once they're online, they can renew their cert, possibly with the help of the vendor who can track the private key or something.)

Post reply on HN