Firefox Follows Chrome and Prepares To Block Insecure Downloads (therecord.media) 79
Mozilla developers are putting the finishing touches on a new feature that will block insecure file downloads in Firefox. From a report: Called mixed content downloaded blocking, the feature works by blocking files downloads initiated from an encrypted HTTPS page but which actually take place via an unencrypted HTTP channel. The idea behind this feature is to prevent Firefox users from getting misled by the URL bar and think they're downloading a file securely via HTTPS when, in reality, the file could be tampered with by third parties while in transit.
The problem with file transfers! (Score:5, Insightful)
Old XKCD [xkcd.com]
We have an issue where creating a "trusted" download is getting more difficult to setup and use, also requiring more expensive and expansive architecture. Where the functionality is nearly impractical.
Yes I get it why Firefox and Chome does it. However we need a way for us to get this stuff from an Untrusted site, just because we just may need someone from a person who we know.
Re: (Score:1)
This just means you can't use http on your already running https site. Also Let's Encrypt is free and takes all of 3 minutes to configure. Seriously. There's no reason not to use https.
Re: (Score:1)
Bah, I just want Telnet with the ZModem Protocol. XModem is just too old.
Re: (Score:2)
The PuTTY guy resists rolling in the zmodem patches [greenend.org.uk], despite the patches being available in LePutty and ExtraPutty.
Re: (Score:2)
He's not resisting, he's saying it's not worth the effort it'd take him but if someone else wants to submit patches he'll look at it.
I get the same thing, if I rushed out to respond to every random feature request I'd never get any actual work done. Even if someone submitted patches I'd have to decide whether I want to add thousands of lines of unvetted code for a feature that 0.001% of users will ever use.
Re: (Score:3)
Re: The problem with file transfers! (Score:2)
Re: (Score:2)
You try to show a friend of mine how to set up Let's Encrypt in 3 minutes and I buy you a beer.
But I want to watch. The entertainment value of that failed attempt of yours would be worth way more than the beer.
Re: (Score:2)
The certbot CLI tool made for Let's Encrypt detects the server you are running and basically automates the process. If you're using Ubuntu it honestly takes less than 3 minutes.
https://certbot.eff.org/ [eff.org]
Re: (Score:2)
Great, I have an old switch with an expired self-signed cert. I can't wait to update it so I don't have to use an old browser to talk to it!
Re: (Score:2)
Why do you need an old browser? I still just click through the warning, advanced, accept the risk, and continue.
Now if the old device is some masterwork of broken IE specific html code with ActiveX plugins then yeah... time to fire up the old Windows XP VM because its not worth trying to make it work on anything else, but thats not certificate related.
Re: (Score:2)
Every version, the browser gives you less options to click through the risk. If a page uses javascript that calls XMLHttpRequest, you may not even get a chance to click through, it'll just fail.
You might want to archive a browser that works on your embedded hardware now against the future when it disappears "for your own good".
Re: (Score:2)
Sure that's generally good advice if you need to manage old gear, but it's more to do with general compatibility issues than anything to do with certificates.
I do see the argument that there should be a special browser for IT admins and developers with a few more overrides and what not for security issues to make dealing with development issues and old equipment simpler, but then that browser shouldn't be too easily readily available to the general public nor should it be used on the public internet... mayb
Re: (Score:2)
You started to have the right idea, then minced it with restricted access (how should one get such access?) and restricted IPs because browser maker knows best and children shouldn't be allowed to stray from home (or something like that).
How about normally being secured and unless the user is ACTUALLY a child, letting them make the adult decision to bypass the protections as needed? Feel free to display a warning featuring the skull and crossbones, Mr. Yuk, and other discouraging iconography. If you must, d
Re: (Score:2)
"How about normally being secured and unless the user is ACTUALLY a child, letting them make the adult decision to bypass the protections as needed?"
I have no issue with having a secure tool with no bypasses, and making available separate insecure tool with specific bypasses enabled but restricted to LAN ranges with its own logo and brand name. There is no good reason to use that online, and differentiating the two products by use case is sensible.
And if you really really want the insecure version to use on
Re: (Score:2)
I still object to the LAN restriction. I am not only all growed up, I am an experienced professional. I don't need my hand held. I'm not going to be bypassing anything on some random site, but if the best I can do to avoid a 4 hour drive (each way) is to very temporarily nail up an inbound NAT, I would like for the browser to obey my commands and just do it so I can fix the damned thing and get back to bed.
Re: (Score:2)
"I still object to the LAN restriction. I am not only all growed up, I am an experienced professional."
There are millions of old laser printers and whatever else floating around, that average joes need to 'manage'. I view this tool as being as much for them as anything else.
"but if the best I can do to avoid a 4 hour drive (each way) is to very temporarily nail up an inbound NAT,"
Set up an outbound NAT on your side to alias a LAN ip address to a remote address, or use a vpn, or an HTTP proxy server... yeah
Re: (Score:2)
Or I could hopefully have a tool that doesn't assume I'm a child.
Re: (Score:2)
If the average person didn't act like a child we wouldn't be having this conversation.
Re: (Score:2)
You seem to be conflating better with perfect.
Proving you have control over DNS on the domain to get a cert is better than nothing.
Anybody can self sign a cert that says anything, that's the baseline case.
If you at least have to get over the hurdle of demonstrating you control microsoft.com before claiming your server is something.microsoft.com that's an improvement on the baseline case. Not everyone anywhere can do that. Microsoft can, its likely some state actors can coerce trusted root CAs to do it. So u
Re: (Score:2)
I fully understand the "certificate entitles you to speak for the domain" principle of DV certificates. However, determining "the server you want to be talking to" is itself nontrivial:
1. The router, printer, or NAS box on your home LAN probably lacks its own domain name.
2. Just because you own bank0farnerica.com doesn't entitle you to speak for the Bank of America organization.
Re: (Score:2)
Proving you have control over DNS on the domain to get a cert is better than nothing.
If you at least have to get over the hurdle of demonstrating you control microsoft.com before claiming your server is something.microsoft.com that's an improvement on the baseline case. Not everyone anywhere can do that. Microsoft can, its likely some state actors can coerce trusted root CAs to do it. So unless you've got the attention of some pretty powerful groups, the risk that you are talking to something not operated for/by microsoft is pretty low.
Is it better? Lets say you are worried someone will intercept your traffic. How is SSL better than nothing in that case? At least with nothing you are not under a false impression of security. At any time anyone actually able to intercept your traffic can tweak responses to pass automated tests and get themselves a valid cert for your domain and MITM all of your traffic without anyone knowing.
I cannot accept that this is better than nothing when false indications of security are considerably worse.
Ah yes the mighty SSL mafia at Lets Encrypt. Nice website you've got there, shame if something happened to it... here we'll protect it for you for free. There's no cost, no strings, and no favors, everything is open sourced. Have a nice day. That SSL Mafia?
This
Re: (Score:2)
re 1 - I've advocated in the past often that browsing to local addresses by ip address should be handled as a special case for precisely this reason. It should probably still warn you with a clickthrough or something, but generally shouldn't get in the way. An alternative is my more recent idea that there could be a separate app for this case. -- just for talking to local devices. So the web browser can be as paranoid and secure as it wants, and when you need to check the status of your laser printer, or c
Re: (Score:2)
" At any time anyone actually able to intercept your traffic can tweak responses to pass automated tests and get themselves a valid cert for your domain and MITM all of your traffic without anyone knowing."
Yes, but just how long is the list of people that can get a cert for my domain? Its certainly longer than I might like -- from the registrar to the DNS zone operator, to various dns root admins, the aforementioned state actors, some of the backbone operators, any of the trusted CAs, and me.
Its not perfect
Re: (Score:2)
I've advocated in the past often that browsing to local addresses by ip address should be handled as a special case for precisely this reason.
A trusted device on your home LAN and an attacker's device on a coffee shop LAN are likely to have the same private IPv4 address.
An alternative is my more recent idea that there could be a separate app for this case. -- just for talking to local devices.
For which desktop or mobile operating systems would this app be produced?
Re: (Score:2)
"A trusted device on your home LAN and an attacker's device on a coffee shop LAN are likely to have the same private IPv4 address."
Completely understood. But why are you manually typing 192.168.1.10 into your browser at a coffee shop?
Windows/ Windows firewall has the concept of Public/Private/Domain networks, to help further differentiate your home from a coffeeshop. Its not perfect, but it could be another factor in how it treats these devices at least on that OS.
Even so, I like the idea of a separate app
Re: (Score:2)
But why are you manually typing 192.168.1.10 into your browser at a coffee shop?
Laptop, tablet, or phone put in suspend at home, purging the tab from RAM, and automatically reloading when taken out of suspend at the coffee shop.
All of them ideally?
I wonder if a specialized web browser locked down to RFC 1918 addresses and using certificate fingerprints for server authentication would fit in the restrictions of the web view control under iOS.
Re: (Score:2)
Laptop, tablet, or phone put in suspend at home, purging the tab from RAM, and automatically reloading when taken out of suspend at the coffee shop.
In terms of risk profile, you can't eliminate all risk, but I'd put that fairly low on the scale.
Or... since the browser is doing special handling of this address space; if the tab is pointing at this space like this when it comes out of suspend... redirect to an information page that says this tab pointed at the lan prior to sleep won't be reloaded automatically as a security feature. (Or perhaps keep track of the local ip address and network ssid etc for tabs and don't automatically reload LAN tabs if you
Re: (Score:2)
Re: (Score:2)
I see that you haven't tried to teach these "automated processes" to an average user. I'm in on the beer offer with the parent, but I too want to watch the hilarity that will ensue as you fail.
What domain name? (Score:2)
Does it automatically detect the fully-qualified domain name of the server? Because a lot of servers on home LANs don't have one, and CAs don't sign certificates for mDNS names that end in .local.
Re: (Score:2)
Getting your first certificate setup is probably a 3-10 minute job, downloading and waiting for the package installer to finish is the bulk of the time. Getting autorenew to work is more time if your web server has any unusual configuration to it. Signing in and renewing every 30 days by hand is a minutes worth of work if you aren't willing or able to autorenew.
Re: The problem with file transfers! (Score:1)
Re: (Score:2)
https://certbot.eff.org/ [eff.org]
Use this tool. If you're on a stock Ubuntu Apache2/Nginx configuration it just works.
Re: (Score:2)
There are still great reasons to not use https. For example, embedded devices that may not have a fixed IP or DNS.
Re: (Score:2)
Re: (Score:2)
If you care about the encryption and do not care quite as much about the certificate chain, the usual solution is to run a private CA, issue a certificate, sneakernet the certificate to the server, and configure your devices to trust the private CA.
Re: (Score:2)
Re: (Score:2)
In SSH, how do you know that the server's public key fingerprint is correct?
Re: (Score:2)
Re: (Score:2)
Actually, there are lots of reasons. Not all material needs to be encrypted, because not all material is privacy sensitive. Which means, the only thing left to deal with is tampering.
A better alternative than blocking it altogether - because that mostly renders transparent proxies useless - is to force links to HTTP content in HTTPS transferred sites to be accompanied by a new attribute in the anchor tag with a file signature (or a link to an also HTTPS-only file containing the signatures) that could be che
Re: (Score:2)
However we need a way for us to get this stuff from an untrusted site
That way has existed for a long, long time. Just add and verify a PGP/GnuPG signature. You need to get the public key via a trusted channel, verify it via its signatures or its fingerprint, or, at the very least get it over a different channel (like a VPN or the TOR browser or a different internet connection). If you have lower security needs, it may also be enough when the signatures check out for several downloads spread over a longer time.
Re: The problem with file transfers! (Score:2)
Re: (Score:2)
Re: (Score:1)
Might as well tell them to reverse the polarity of their tachyon emitter array.
That's an expensive way to sign a file, but at least they'll understand it.
Re: (Score:2)
Today we can't detect if a site is trusted or untrusted anyway regardless of http or https because we never will be able to know. There are too many CAs out there and how can we know if one is compromised in some intricate way?
Re: (Score:2)
Mozilla actually built a service to make sending files easy. It was called Firefox send and they killed it last year due to nobody using it. Turns out everyone already has a Google Drive or OneDrive or Dropbox account, and you can download from them without an account which seems to be the issue that XKCD has.
Re: (Score:2)
We have an issue where creating a "trusted" download is getting more difficult to setup and use, also requiring more expensive and expansive architecture.
No we don't. This is saying you already have the infrastructure and all capabilities, so offer the download the same way. It's saying stop being lazy at the expense of security.
Pretty much bullshit (Score:5, Insightful)
No 3rd party will invest much into tampering with files in transit over HTTP. It is just too much effort. Instead, they will redirect to a download server of their own (with a apparently valid certificate) or tamper with the file before it is downloaded. Hence all this does is create a false sense of security.
The gold-standard is and likely remains to have a PGP/GnuPG signature on the file and to check that after download.
Re: (Score:3)
This is what you're looking for
https://developer.mozilla.org/... [mozilla.org]
Re: (Score:3)
I was not looking for it, but it nicely confirms my assessment. Any integrity verification aimed at tampering that does not use cryptographic signatures is bogus.
Re: (Score:2)
Not sure why you're obsessed with PGP in this instance. If someone can modify the hash used in the tag they can also generate their own PGP key and sign it themselves. The end result is the same.
Re: (Score:2)
Not sure why you're obsessed with PGP in this instance. If someone can modify the hash used in the tag they can also generate their own PGP key and sign it themselves. The end result is the same.
You do not seem to understand how cryptographic signatures work. Of course that public key needs to be verified in some way for the signature to have value. A hash cannot be verified.
Re: (Score:2)
A hash value that comes from a verified document is as verified as the document it comes from.
Re: (Score:2)
A hash value that comes from a verified document is as verified as the document it comes from.
It does. But there is no easy way to communicate a verified document. Unless there is a cryptographic signature on it and you verify the public key. Verifying public keys is usually easy. Verifying hash values is not.
Hence the whole idea to do this with a hash only is pretty much bogus.
URL and hash over HTTPS, file over HTTP (Score:2)
I understand the subresource integrity (SRI) flow as providing the URL and hash of the downloadable file over HTTPS and providing the file itself over clear HTTP. Because the hash comes from a document served over HTTPS, it is a verified document.
pre-Ransomeware I'd have agreed (Score:2)
Re: (Score:2)
The only way to reasonably to do this is very close to client or server. In that case it is often already possible to compromise client or server directly, no need to tamper with any data in flight to compromise any binary transfers after that.
Re: (Score:3)
Remember that Google has download scanning built into Chrome already. It uses a list of known malware but also a list of known malware domains and URLs. Google collects that data both from its own web crawler and from Chrome users who have malware protection enabled submitting URLs automatically.
So for Google requiring certificates is very helpful, because it prevents sites impersonating others. It also increases the cost of doing it, and makes it easier to identify groups of malware domains that were regis
Re: (Score:2)
Requiring certificates does not really prevent impersonation. CAs get compromised all the time or get tricked into signing certificates for the wrong people. As an identity-verification means, certificates are not very useful.
Re: (Score:2)
That's why Google stopped using certificates for identity verification.
That has nothing to do with this issue though. Getting a certificate for a domain requires a few basic things and some time. Once identified as malware it's easy for the CA authority to cancel batches of certificates linked to an email address, or an IP address that created them all. Nothing bulletproof but it all adds to the hassle that is required to distribute malware.
Re: (Score:2)
Trust (Score:3)
Does this ever happen? Wifi is encrypted although admittedly the older protocols are no longer safe. But anyhow, since when does anyone ever do main-in-the-middle attacks, other than the gov't secret services and this wont stop them anyway.
This 'feature' is nannying and should be easily over-ridden. If you don't trust the network then you can always encrypt files before you send them.
Idiots will still download trojan pron.zip.exe files regardless of whether you encrypt the network protocol.
Re:Trust (Score:4, Interesting)
This is actually way worse than someone opening a trojan cause you can hack people who do everything right and are seemingly unaware that their DNS has been hijacked.
If someone overrode the local DNS for say google's domain to instead point to some local IP instead of the real google server they could introduce arbitrary javascript to a real script and simply forward all requests to the real server then proceed to start stealing session cookies among other things by appending some of their own javascript to the official code.
The costs to accomplish this are low as well. You only need to tap into an ethernet jack and spoof some other mac address on the network that you happen to see nearby. You could even take over DHCP duties by answering broadcasts first and make machines think you're also the real DNS server.
I'm sure there's tons of engineers that think like you that work at big companies and don't want to https their local websites but you do so at great risk if you have any public facing terminals.... like say at an airport or a grocery store chain.
Re: (Score:2)
DNS hijacking isn't really an issue with Firefox, since it does DoH.
Re: (Score:1)
Translation: ... since it already is hijacked.
I got my own DNS server, thank you very much for ruining it, Mozilla!
Thanks (Score:2)
I already know how to verify checksums with a signed certificate. If I want to fetch something using HTTP or FTP, I can just use my dedicated up/download client and bypass Chrome/Firefox altogether.
erm (Score:1)
"Directly accessed HTTP download links (copy-pasted in the Firefox address bar) will not be blocked."
Says it all (Score:3)
Re: (Score:2)
Yeah, fuck Chrome. All other browsers should stand their ground. Heck go opposite direction. Remove TLS3 support. Disable warnings over HTTPS, we can't be seen doing anything security related, that would be too much "Chrome".
Re: (Score:1)
No, remove HTML5 support! And tabs!
As I said for years: The browser is just a worse virtual machine at this point.
Just run a virtual machine with paged-out cached snapshots of several operating systems, that when you enter a URL, are cloned in milliseconds with copy-on-write, get the file downloaded from the URL mounted as a drive, and the executable inside autostarted. And have a *two-level* task bar. So not a separate tab bar somewhere else, but a task bar that has an always-visible subwindow bar on top o
Re: (Score:1)
OK, to be frank: Last time I posted this idea, I did two evenings of development afterwards, and half of the above already works. I only have to migrate to a proper hypervisor mode because otherwise qemu's tools are annoying and badly documented.
All that's missing now, is the URL bar. (Easy. a borderless terminal window with a shell script and fixed positions set in the window manager will do.) And that two-level tab bar. (The graphics side of that is already done. Only the controller/input is missing.)
And
Like everything from Mozilla (Score:2)
This is perfectly fine as long as it can be disabled. However, Firefox is getting very close to being totally unuseable with the last update that really and truly fucks up the UI beyond reconition and renders it completely unuseable (and cannot be disabled).
Mozilla Firefox is on life support and will disappear into the annals of history shortly.
--
The only good politician is a dead politician
Re: (Score:1)
No, "opt-out" is, legally, never perfectly fine. *Opt-IN* would be perfectly fine.
Just like you *first* ask you friend, before you decide to lock up his back door in his own home. Might be a good idea, but you're not his dominatrix, now are you?
You need to boycott CloudFlare (Score:1)
Thank you nanny Mozilla! But i don't trust YOU! (Score:1)
The fallacy behind the entire thing is, that Mozilla just arrogantly assumes it knows what is to be trusted, and knows better than me too.
Typical of such companies. They don't want to help you. They want to *dominate* you!
It's called a God complex.
Never Update (Score:2)
Shortsighted (Score:1)
First they remove support for FTP [slashdot.org].
Now they remove support for HTTP.
They are making it impossible to directly send/receive files between parties without needing to utilize a 3rd party source. This introduces as much vulnerability as it solves but also maximizes inconvenience and difficulty while minimizing privacy.
But that may be the point. Browsers have long supported the trend away from direct internet access and towards dependency on walled gardens. And to think we once thought AOL confusing the li