Google Chrome Wants To Block Some HTTP File Downloads (zdnet.com)

An anonymous reader writes: Google wants to block some file downloads carried out via HTTP on websites that use HTTPS. The plan is to block EXE, DMG, CRX, ZIP, GZIP, BZIP, TAR, RAR, and 7Z file downloads when the download is initiated via HTTP but the website URL shows HTTPS.

Google said it's currently not thinking of blocking all downloads started from HTTP sites, since the browser already warns users about a site's poor security via the "Not Secure" indicator in the URL bar. The idea is to block insecure downloads on sites that appear to be secure (loaded via HTTPS) but where the downloads take place via plain ol' HTTP.

Comments

UGh.

[flippy]

Why oh why does Google think that they know better than everyone? Give a warning, sure, and then let the user decide. Just the same way it handles an HTTP page vs an HTTPS page.

Re:UGh.

[flippy]

100%. I get that they want to try to protect people from their own mistakes, but just outright disallowing stuff isn't the way to do that.

Re:UGh.

[supremebob]

I wish that Google gave you the ability to suppress those warnings as well. I have a few internal development sites with invalid SSL certificates on them, which Google throws an obnoxious "YOUR CONNECTION IS NOT PRIVATE" warning every time I hit them.

Congratulations, Google, you're training people to click on the "Proceed to x (unsafe)" link EVERY time they see that page as a muscle memory reaction, whether or not it's a real security issue or not.

Re: UGh.

[ilsaloving]

I used to feel the same way. Then I started seeing issues like mixed http/https, and similar things, which don't get caught until far later in the dev cycle than they should be. Occasionally it results in an unexpectedly complicated mess.

You don't need to be fancy about it. It may take a little initial setup to get, say, Lets Encrypt working, but incorporating SSL into your dev/qa environments will save you potential unexpected frustration down the road.

Generally speaking, the closer you can match a dev environment to the final prod environment (in all aspects that can impact the operation of the final product that is), the better off you'll be.

Re: UGh.

[fibonacci8]

Thoughts and prayers to everyone using your internal development site.

Re: UGh.

[Anonymous Coward]

Except Let's Encrypt doesn't work well for servers behind firewalls. You can coax out a manual cert via DNS but it sucks if your DNS doesn't have a dynamic update API or is only accessible via a special VPN network. And then Let's Encrypt certs are short-lived, so you end up repeating the process every 3 months.

The scenario you describe is precisely why we need DNSSEC DANE TLSA mode 3. Then we can all publicly run our own private CAs. Browsers would trust your root for your domains only and trust my root for my domains only. They would also be able to trust internal infrastructure behind firewalls signed with that root without ever having to install a single root CA cert. We would finally ditch public CAs at that point, including Let's Encrypt, and have real trust on both the Internet and Intranets.

Unfortunately, none of the major web browsers implement any part of DNSSEC DANE TLSA. At one point Mozilla even declared the relevant open bug/feature request as WONTFIX. If you read into the whole DANE TLSA debacle that's silently gone on for the past 8 years after the IETF finalized the specification, the TL;DR is that no one cares about implementing actual software security unless it makes a ton of money for someone.

uhh,,

[SuperDre]

But http or https doesn't really matter these days, even malicious sites are using https..
As long as you get a warning when downloading and you are still able to download the file, I don't have anything against it. But if they just block download completely because it isn't coming from an https site, than I won't be using Chrome anymore.. As I said, https doesn't say anything about the file being safe.

Re:uhh,,

[CastrTroy]

But it does mean that the executable file wasn't altered in transit.

Re:uhh,,

[Chris Mattern]

But it does mean that the executable file wasn't altered in transit.

Catching executables in flight and altering them sound like a really hard way to do something unless your ISP is doing it to you (and if your ISP would do that to you, you have much bigger problems). It ranks way down on my list of worries, being massively overshadowed by the possibilities that the site itself has been hacked or is intentionally serving up malware--neither of which this does anything to help you cope with.

Re:uhh,,

[darkain]

Simple, just send a checksum of the checksum! PROBLEM SOLVED!

Re:uhh,,

[balexis]

It may not be in your threat model, but it is to some Internet users. Have a look at this report for example: https://www.welivesecurity.com... The fact that other threat vectors are more likely to impact users does not mean that rarer cases should be ignored - they are not mutually exclusive.

Mostly Pointless

[EndlessNameless]

Most sites provide their file hashes over HTTPS. If I'm going to verify the file on my end anyway, there's no real reason for the site to waste CPU encrypting the entire ISO every time someone downloads it.

Digital signatures and hash verification address the same security concerns with less impact.

Re:makes no fucking sense

[JcMorin]

The idea is not to prevent to download them but to prevent the ISP, rooter, internet cafe or guy next door to change the content of that .exe during the download.

Google Echo Chamber in full effect

[nadass]

The Google Chrome engineer who posted this ask to the W3C mailing list ( https://lists.w3.org/Archives/... ) also made a social media poll, https://twitter.com/estark37/s...

Essentially, they're reinforcing their own echo-chamber effect to only listen to confirmations of their conceived notion of correctness rather than truly encouraging discourse on the matter. Her poll options are, "yes" and "yes" -- and several Twitter replies have been deleted.

Personally, it seems they are an engineer looking for a problem to solve to help justify their job... and that's just sad in itself.

Re: Google version of the web.

[Lanthanide]

Google are doing it in a standards based way though, Microsoft didn't.

If you visited the site using another browser, you can still do the download. Once the website admin jumps through Google's hoops, the download will still work correctly in any other browser that properly follows the HTTPS standard.

It's about dictatorships (Re:uhh,,..)

[whizzter]

On the contrary, i have some recollection of some nation-states poisioning downloads of "encrypted" communication apps to be able to eavesdrop. (Egypt? Iran?).

Defective product. Declared secure, illusion of se

[raymorris]

If you had a physical safe, 2,000 pounds, which would open whenever someone tapped it on the left side, that would be a defective product. Since you probably bought the safe to protect valuables, you'd want to know if it doesn't offer any security. A security warning about that safe would be warranted.

A cardboard box would not be defective of it could be opened easily. You don't store gold in a cardboard box and expect high security.

By applying TLS, the site operators are essentially declaring that the content needs to be protected and claiming that it is protected. If it's not actually protected as claimed, users may want to know about that.

Re:Defective product. Declared secure, illusion of

[GameboyRMH]

The problem is that you suggest the common user can tell the difference between a cardboard box and a safe. They can't (thus the green locks and such), and yet we're still treating a safe with potentially no lock (or potentially the best lock of all, if you roll your own cert, verify keys out-of-band, and save them) as a less secure container than a cardboard box. Which it in no way is.

Download from HTTPS CDN

[tepples]

encrypted traffic can't use the internet's caching infrastructure which would benefit popular downloads

A CDN contracted by the operator of the origin server, such as CloudFront or Cloudflare, can cache HTTPS just as easily as cleartext HTTP.