Google Chrome Wants To Block Some HTTP File Downloads (zdnet.com) 207
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.
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.
UGh. (Score:5, Insightful)
Re: (Score:2)
On top of that there are a ton more file extensions that should be added to it if they are trying to stop on the fly bin replacment. This is google playing nanny again.
Re: (Score:3)
Ask ten people what TLS is (Score:2, Insightful)
Yeah, if you ask 10 random people what TLS is, you'll find out why Google security engineers think that they know security better than thr average consumer does. It's their. JOB to know security, so they SHOULD be much better informed than the average user. They shouldn't forget that fact when they make *defaults* and *warnings*.
On the other hand, I've been an internet security professional for twenty years. I can reasonably decide to override the defaults in selected situations. I am not a typical user i
Re:UGh. (Score:5, Insightful)
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: (Score:2)
It's incredibly stupid that browsers don't make a peep about plaintext HTTP connections, but go into full "DANGER WILL ROBINSON!!1" alert for HTTPS connections with a self-signed or invalid cert. In what way could the latter possibly be less secure than the former?
Defective product. Declared secure, illusion of se (Score:3)
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 con
Re: (Score:3)
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.
Re: (Score:2)
The purpose of the cert is for the browser to know whether they are talking to your server, or to my MITM proxy which I made on a Raspberry Pi, ans presents itself as a WiFi network "Convention Guest WiFi".
If you don't tell the browser WHICH cert you've rolled, it's unable to distinguish your cert from my imposter cert, and therefore you have almost zero security.
> 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)
I suspect u
Re: (Score:2)
The green lock is there because the user doesn't know the difference between http: and https: in the URL bar. As such, the browser should display the green lock for an HTTPS connection with a valid cert and not display one for an HTTP connection or an HTTPS connection with an invalid cert. It's even easier for your RasPi to MITM an HTTP connection, but the browser will happily use that protocol without complaint.
Re: (Score:2)
It's not stupid at all.
Do you expect a warning every time you walk down the street while you talk that your conversation may be overheard by the person walking next to you?
Do you expect a warning when you're in your home and someone has installed a microphone in your closet?
There are completely different use cases.
Re: (Score:2)
You make the same mistake as raymorris, in asserting that most users even notice the difference between HTTP and HTTPS. They don't, which is why browsers have green lock indicators etc.
https://slashdot.org/comments.... [slashdot.org]
Re: (Score:2)
You are supposed to install a local root certificate that you use to produce your own test certs.
Re: (Score:2)
I've read it's a lot harder to install a local root certificate on an iPhone, iPad, Android phone, or Android tablet than on, say, a desktop computer. Besides, as of Android 7, local root certificates don't even work in all apps unless each app's developer has opted into using local root certificates through the app's Network Security Config.
Re: (Score:2)
It's fairly easy: https://support.google.com/nex... [google.com]
Should work with all major browsers.
Re: (Score:2)
Should work with all major browsers.
From the page you linked:
Do you mean that the publishers of Chrome, Firefox, and other major browsers do in fact "choose to let their apps work with manually added CA certificates"?
Re: (Score:2)
Read it again, carefully. That caveat only applies to CA certificates, not ones you make yourself.
Re: (Score:2)
If you're acting as a private CA, what's the difference between "a local root certificate that you use to produce your own test certs" and "CA certificates"?
Re: (Score:2)
Basically it's the level of trust that each gets. CA certs are generally handled transparently without any user interaction and accepted as validating identity. Self signed certs are just used for security and don't prove identity, and some clients may choose to ask the user to confirm their use, typically only once the first time they are encountered.
Re: (Score:2)
as a muscle memory reaction,
Just hand Chrome (Chromium) over to the UI/UX experts. They'll have your errant muscle memory fixed in no time. And even better, it'll even STAY fixed since they'll keep moving it around and changing it's appearance.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Congratulations, Google, you're training people to click on the "Proceed to x (unsafe)" link EVERY time
No. They are training IT experts who should be immune to to the training to do so. The number of times an ordinary user will experience a page with a legitimate SSL certificate error that they need to routinely click through is close to zero. The result is that people take pause.
Quite telling that your example talks about internal development sites. I'm not concerned too many users have to worry about those.
Re: (Score:2)
I gotta agree with the AC here. If your SSL cert is invalid, then you're the one teaching people to proceed to unsafe as muscle memory reaction, unless you're the only one using that site.
If you are the only one using the site, you're expecting a browser customization to make your life less annoying by allowing you to disable a feature that benefits most users. The Big G ain't gonna do that.
Re: (Score:2)
No. Granted, working in a dev environment is a bit of a corner case, but there is no reason this can't be a configuration option. I am not generating a bunch of certs for staging servers or other environments that are highly volatile and constantly built and torn down. Google is getting pretty draconian with their policies and changes.
Re: (Score:2)
I am not generating a bunch of certs for staging servers or other environments that are highly volatile and constantly built and torn down.
Your slackness in automating something that is easily automated shouldn't rely on Google adding yet another option to their product.
Re: (Score:2)
Like I said, it's an internal development site. I don't want to waste my time setting up and maintaining SSL certificates for it.
All I want is a simple "ignore SSL warnings for this domain" checkbox. It's not a huge ask.
Re: (Score:3)
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
Re: (Score:2)
It would so much easier if LetsEncrypt gave you error messages with at least a little info on what went wrong. If a file is a problem: give me the damn filename! (and the path you where YOU think it should be. Then I will be able to find out if it is the content or the location that is a problem. If the permissions are wrong, let me know. Its not that hard).
However, with regard to the OP, if there are multiple errors, you might have to
Re: (Score:2, Interesting)
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 roo
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
https://support.mozilla.org/en... [mozilla.org]
Re: (Score:2)
Most people have no ability to decide. Providing the feature can be turned off, I have absolutely no problem with a default that blocks files that are the most frequent delivery agents of malware.
Re: (Score:2)
Re: (Score:2)
Why oh why does Google think that they know better than everyone?
I'm going to guess it's because they spend more money on R&D and human interaction studies than the typical armchair warrior does.
Re: (Score:1)
Re: (Score:1)
I might have a stalker troll. I've been poking at them a lot the last few days. The entertainment helps me get through my work day.
But, now that I can put your response into its proper context, well done. Read the right way, it did give me a chuckle.
Re: (Score:1)
Re: They are SELF-proclaimed (un)"holy" JEWgle (Score:2)
uhh,, (Score:3)
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: (Score:3)
But it does mean that the executable file wasn't altered in transit.
Re: (Score:2)
Auto check summing would be better all around.
Re: (Score:1)
I always wondered... if the checksum was from the same place, how do you know some MITM attack didn't change the checksum?
Re: (Score:3)
Simple, just send a checksum of the checksum! PROBLEM SOLVED!
Re: (Score:1)
Re:uhh,, (Score:4, Insightful)
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: (Score:2)
It's about dictatorships (Re:uhh,,..) (Score:3)
http make little sense today (Score:2)
Re: (Score:1)
I like big CATS and I cannot lie
You cheetahs can't deny
Re: (Score:2)
The difference is that HTTP allows practically ANYONE to MITM your downloads..
So does HTTPS. You just get one of hundreds of CAs to issue you a cert by MITMing their automated DNS/Website flag planting procedure then you can MITM that sites HTTPS downloads to your hearts content.
Certificate Transparency (Score:2)
You just get one of hundreds of CAs to issue you a cert by MITMing their automated DNS/Website flag planting procedure
Would these be CAs that submit all issued certificates to Certificate Transparency or CAs that do not?
Re: (Score:2)
Would these be CAs that submit all issued certificates to Certificate Transparency or CAs that do not?
What difference does it make? Nobody monitors CT logs so why does it matter?
If by some miracle you discover a cert issued by someone else it's already too late. Security has already been compromised. All of your fellow government protestors already been rounded up and carted off to the gulag. Too bad so sad.
This is all certificate transparency really is:
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
The most common way to deliver malware is from a compromised site.
How would an individual developer go about proving to users that the software he offers through his website was not placed there through compromise?
Re: (Score:2)
Then the question becomes how to prove that the public key itself has not been replaced through compromise.
*facepalm* (Score:2)
Ok, and how exactly do they expect people to be able to download software, or other files?
Apparently in Google's world everyone has gigabit fibre so very large log files (for example) is not an issue. But for those of us in the real world, being able to compress stuff before sending is still incredibly valuable.
(And for anyone that plans to latch onto the log file example like starving dog on a steak and say "Well you should be splitting up your log files!", I kindly invite you to eff off in advance. I'm
Re: (Score:2)
Or, I could read the summary and article a little more carefully and realize it's restricted to HTTP downloads from an otherwise HTTPS site.
I can why they would do that since an HTTP connection can be MITM'ed easily. But that goes for literally anything. Malicious office docs, PDFs... There are tons of files that can have a malicious payload beyond the ones they mentioned. Hell, someone MITMing an HTTP connection can basically send whatever they want, so it would be far simpler to just bring up a warnin
Re: (Score:2)
The big difference I see is that executable inherently get pretty much full unrestricted user-level access to the machine, whereas compromised documents rely on exploiting vulnerabilities in applications (i.e. it's somebody else's problem). Those applications are typically constantly being updated to remove vulnerabilities (well, so long as they're not "too big to care about users' needs" at least, which perhaps covers the specific examples you mentioned...)
That said - yeah, it does seem like simply warnin
Re: (Score:2)
We're talking about files downloaded from insecure links on secure pages - I'd say it's safe to assume that this is a move designed to discourage putting the user in an unexpectedly dangerous position, rather than provide greater technical defenses. A user downloading a file from a trusted and obviously secure web page (it has the secure icon.) is going to reasonably assume that the file that leaves the server is the same as the file that arrives at their computer, rather than realizing it could have been
Re: (Score:2)
My wish... (Score:2)
Is that we could all agree on some sort of standard whereby from a secure site you could initiate a download, have that download be unencrypted, but the download link would include a sha256 checksum that would be checked automatically by the browser once the download was complete.
This would allow popular downloads to be cached closer to the user, while providing for verification of the download integrity.
Re: (Score:1)
if you think about it a bit longer you'll discover that doesn't solve anything
Re: My wish... (Score:2)
The idea, that was not communicated clearly, is that the hash would be transmitted over the encrypted channel, thus extending trust to the object served outside of that trusted umbrella.
Re: (Score:2)
I'm not seeing it.
Obviously the checksum would have to be sent over the encrypted channel, but so long as you do that, sending the data itself unencrypted and cacheable is a non-issue. (well, aside from surveillance)
I've often wondered why such a thing isn't common myself - not just for security purposes, but to reliably and transparently detect accidental transmission errors.
Re: (Score:2)
Bingo. The hash is part of the URL, so it's delivered securely, but the body of the download isn't.
This is how Microsoft (and apple I think) do their updates. The control channel is secured via https, but the mass download of the updates is not. I always know when a big update is put out, as the effectiveness of my WAAS setup goes up dramatically for a few days.
Re: (Score:2)
Would a "signing-only cipher suite" make sense?
Mostly Pointless (Score:5, Insightful)
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: (Score:2)
Most sites provide their file hashes over HTTPS. If I'm going to verify the file on my end anyway
Well to my knowledge there's no standard way to do this. Like if you could have an <a href="http://my.plain.download" sha-256="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"> this would be fine, simply fail if it doesn't verify. But if you're expecting the average user to verify security certificates etc. then 99.9% of them won't do that.
Re: (Score:2)
>Most sites provide their file hashes over HTTPS.
I'm going to have to disagree. In my experience, most sites don't provide hashes, and most users don't know how to check them anyway.
If you're downloading ISOs you're probably a fellow Linux enthusiast, which puts you in a (generally) much more technically competent group, but a group so small as to be largely irrelevant to the attack channels used against the broader population.
Also - even for technical users they're not talking about blocking all HTTP d
Re: (Score:2)
You really want to try to explain how to do that properly to your average user?
More to the point - why should even a skilled user have to do that manually when it's such a fundamental part of safely downloading a file? How many millions of man-hours per year would be wasted doing that easily-automated task, if everyone actually could and did do so for every download?
Re: (Score:2)
Nobody will see this due to the wall of trolling that's accumulated under your post, but...
Sure there is. "They'll"* know that you downloaded that file through their deep packet inspection gear.
*They being the government (three letter agencies), or the transit provider, or the cable/DSL oligopoly, or FAANG because why the hell not.
Re: (Score:2)
What percentage of internet users do you think actually know what a hash is?
This is just another step towards fixing a very old mistake. Security should be the default.
Re: (Score:2)
What percentage of internet users do you think actually know what a hash is?
Is this an issue that needs solving? Are people actually being owned by this vector? What percentage of Internet users have been attacked in this way? Where is the evidence supporting this position? Why are less assertive measures insufficient?
Or like Google's bullshit reasoning for reducing security by removing public key pinning and falsely claiming certificate transparency is an effective analogue is this just another scheme for punishing *undesirable* sites who link to third party files for download
Re: (Score:2)
Is this an issue that needs solving?
Yes. MITM attacks are used by everyone from governments to ISPs to spread malware.
there is something fucked up when one company imposes restrictions on the entire Internet because it can.
The entire internet runs on Chrome?
Re: (Score:2)
Yes. MITM attacks are used by everyone from governments to ISPs to spread malware.
There isn't a government in the world worth mentioning lacking resources to MITM HTTPS. Numerous CAs are located in effective dictatorships, some even state run.
This fact is why it was so damaging and counterproductive for Google to have removed key pinning protections from Chrome while falsely claiming certificate transparency to be an analogous replacement. The man asked and Google complied.
As for ISPs spreading malware this is illegal criminal behavior in most of the world. Any ISP caught doing so fa
Re: (Score:2)
If I'm going to verify the file on my end anyway
What are you working for the NSA or something? Normal people don't do that.
Re: (Score:2)
If there was a virus that would render 4chan's foul spawn unable to get on the Internet, I'd be all for it. Even if you're joking, you're still a disgusting piece of crap.
HTTP/HTTPS (Score:1)
Let me guess: So that a site without a Hollywood approved security certificate can't make use of HTTPS to encrypt and circumvent mandatory Hollywood file inspection?
Re: (Score:2)
What does the neighborhood of Hollywood or even the US movie industry have to do with HTTPS? Let's Encrypt offers free certificates to anyone who owns a domain name.
This has a funny taste (Score:2)
SCR files? (Score:2)
Including .EXE but forgetting about .SCR, .COM, .BAT, .LNK, and possibly other extensions that are treated just like .EXE files?
(Yes, .BAT files which are valid PE executables will run as executables, and it won't try to execute it as a command prompt script)
Not everything should be encrypted (Score:1)
I think there's actually a push to encrypt too much. It's got obvious benefits for privacy and security, but encrypted traffic can't use the internet's caching infrastructure which would benefit popular downloads, which tend to be ZIPs, EXEs, TARs and such. What I'd really like to see is browser integration to insecurely download files and securely confirm its fingerprint.
That said, informing the user aware of an unencrypted download from an encrypted site would be good. Blocking it would be bad.
Download from HTTPS CDN (Score:3)
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.
Won't this require... (Score:2)
... web site to go through all their web pages and make sure that no instances of "http:" are accidentally left in pages where downloads are available?
It might be easier for web sites to merely add a browser detector to their pages to warn the user that they're using a product from a vendor that's actively trying to make their use of the Internet into a royal pain in the behind?
Google Echo Chamber in full effect (Score:5, Interesting)
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: (Score:2)
Google declares war on general-purpose computing. (Score:1)
It's getting close to a point where we need to make our own web and web browsers, with blackjack and hookers (but seriously!). There are lots of free TCP ports left, let's just choose another one and walk away from the HTTP2/3/AMP/QUIC bullsh$t. Make a translator gateway if someone wants to visit the "Google-web" with all of its limitations.
This is a clear violation of stack layers -- a general purpose APP for browsing and fetching online content should NOT attempt to be the gatekeeper for what the TRANSPOR
.torrent (Score:2)
Chrome? (Score:2, Funny)
As long as it continues to let me download FirefoxSetup.exe, we're good.
Strange selection of files (Score:2)
why not include office documents and pdf's as well? they've been a source of infections too.
well, not much else is left except pure media (video/audi/pictures) files.
Re: (Score:3)
Re: makes no fucking sense (Score:2)
*router
Re: Google version of the web. (Score:3)
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.
Re: (Score:2)
If you visited the site using another browser, you can still do the download.
Another browser won't even run on a pre-Crostini Chromebook.
Re: Google version of the web. (Score:2)
Wine is an .exe player (Score:2)
.exe files are harmless on Linux
Unless the user has installed Wine. Valve's Proton distribution of Wine will only make Wine more commonplace among users of X11/Linux.
Re: How (Score:2)
Re: (Score:2)
Why on earth would one want to protect a file download against third parties?
Two reasons:
A. Protect a proprietary work from being downloaded by third parties who have not paid for access to the work
B. Protect a work from being modified in transit
[TLS] is only a transport PRIVACY measure against third-parties interposed between the two end-points (who may not be who you think they are)
My reply depends on what attack model you had in mind that results in the parties not being "who you think they are". Does it involve defrauding a CA? Typosquatting? Something else that you'll describe?