Blocking high-risk non-secure downloads
lists.w3.org
lists.w3.org
Relevant quotes:
> ... we will likely start by treating certain high-risk downloads initiated from secure contexts as active mixed content and block them.
> We're not planning to focus on non-secure downloads initiated from non-secure contexts at the moment, because users at least see the "Not Secure" omnibox badge on those pages.
They closed the old bug for no real reason:
https://github.com/EFForg/https-everywhere/issues/1775
Then let the new bug rot:
https://github.com/EFForg/https-everywhere/issues/12232
They've now started deleting new comments on the new bug. I'm just not using it anymore.
¹ https://chrome.google.com/webstore/detail/duckduckgo-privacy...
Increasingly, I see that the web no longer fulfills any of its original goals. On the other hand, if I look at it as a software delivery/execution platform I see a horrible mess that could have been designed a zillion times better if that was the goal to begin with.
How would you design it a "zillion times better"?
The CA system is decentralized by nature. If the existing authorities start trying to manipulate your internet by controlling who they verify, which hasn't really happened that I'm aware of, you can always add a new root certificate. Or consumer browsers can offer new CA roots out of box.
CA chain is centralized. Plus, it requires you to have a domain name. DNS is also centralized (although to a somewhat lesser extent).
Effectively, we're seeing yet another step in hyper-centralization of the web.
also, as above, there is no one root CA. you can add and remove any ca from your system. most users don't because why would you trust a random ca from some random site.
What's the actual problem here?
Note the one you asked, but i have the same issues with the certificate mafia.
The moment anyone starts a community CA for this they'll just blacklist it.
I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
Also when I think about this, this only hurts legacy windows applications which probably is hosted on a non-http site. I dont like this move at all.
I don't know any normal user who would think twice about clicking "Yes" on a prompt like that when they're trying to install a program they just downloaded. There are plenty of legitimate programs that don't have a signature, and plenty of malicious programs that do.
https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
That's for EV certificates. Regular certificates are a lot more affordable: https://comodosslstore.com/ca/code-signing (~$100/yr). For comparison, apple developer program is also around $100/yr. Certum also provides discounted certificates for open source projects (around $30).
>Here's hoping that something like LetsEncrypt comes along for code signing or EV certificates, or that Microsoft makes the process easier somehow.
The only reason that letsencrypt can be free is that domains can be validated at 0 marginal cost. Code signing certificates are issued to persons or corporations, not domains. Because of that, the issuer has to do a bunch of manual checks that drives up the marginal cost of each certificate.
Also, letsencrypt has many corporate sponsors who directly benefit from https adoption. Who benefits from microsoft code signing certificate adoption? Only microsoft.
The Certum ones turn out to be about 135 Euro, after the mandatory super expensive (and super slow) postage for the key fob to store the key on is included.
They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
I heard that you could use any smartcard/hsm, not just their fob, so there might be same savings there.
>They do have "Cloud hosted" ones available too, which don't need the electronic fob. But I don't know anyone who'd trust their electronic signing keys to "the cloud". ;)
What's the issue here? Certum is the CA so they can already issue whatever certificates they want. They don't need to steal your cloud keys. The only real threat is if their service gets hacked, but at that point the hacker could also re-issue your certificate with his keys.
There are plenty of examples of stuff that should be secure, being leaked.
Also, if Certum "gets hacked" that's not a generic blanket giving complete access to every one of their systems. It's entirely possible they could get "hacked" and the hackers would only obtain read only access to stuff, without penetrating whatever signing systems there are.
Using a local fob circumvents several of those particular threats.
The weirdly expensive and slow postage option makes me curious about other things though. But that's probably just my paranoia revealing itself. ;)
Do note that even then, there have been demonstrated exploits of package managers downloading over http, where the parsers were demonstrated to be compromised.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3462
(nice summary of the above CVE https://www.securityweek.com/code-execution-vulnerability-im...)
TLDR: In this approach, http:// sites can link http:// executables, but https:// sites cannot.
Mixed-content rules would block even loading http:// images on a https:// page, so wouldn't you think that blocking .exe downloads from http:// sources on an https:// location would also be blocked?
I don't love Google, but this doesn't seem like a bad idea.
There are workarounds for this (using a redirector service and unique hostnames) but that is an additional request of donors who are providing them a lot of bandwidth for free.
It’s not a great reason, but it is a reason.
I second this. Their market share affords them far too much luxury with not nearly enough impartial oversight.
> I dont understand why they are doing this.
I do understand why they're doing this. Me and you are smart enough to know to only trust a download from a secure connection. Others don't. I've fixed two computers THIS MONTH from people who opened email attachments and then proceeded to click past all of the Office security warnings. Both of them were Kovter droppers. The average user doesn't know what the padlock means, and if you hid a non secure download behind an https redirect they wouldn't even know.
Another story, just last week, my town of 9k people has a "social network" based on dotNetNuke on some sketchy shared/co-hosted server without HTTPS. They tried to spam their network on a local FB group recently and they don't even have an SSL cert. Still, the sheer volume of idiots who visited and posted comments like "there's a bug, I can't create an account" or "just signed up!" was disgusting. I posted a stark warning and chewed out the spammer for not taking the 10 minutes to get a free SSL cert, which was when I learned of their sketchy hosting situation.
So you see, not only do regular users not know what their looking at on the internet; other web developers also have no idea and don't really care. They insisted to me they have their own security measures which negate the liablity of not encrypting traffic; to which I responded that I could setup a fake AP at the local coffee shop and start stealing passwords if he didn't beleive me. The post was deleted after that, but most of the country bumpkins in my town stood BEHIND HIM!!! They thought I was being mean to a local business.
The boogey-man can't sneak up on us, but many people are just going through life and need someone to watch their back digitally. Besides, the only time you initiate a non-secure download of an application from a secure connection is when you've injected payload fetching code into an XSS vulnerability. I can see literally no other use-case unless the developer is an idiot (see paragraph 3).
Affording someone the ability to save face is among the reasons to consider making a private approach. And when irritated, slighted or indignant, when amped up somehow, not disengaging to cool down is the sort of thing I tend to regret.
It's a tall order to expect people to interpret an offer to steal passwords in a coffee shop to assert their need of your acumen as a beneficent act.
They want people to fear the desktop since they have no control over it nor way to monetize it and move them to the web where the only way to monetize software is through ads and subscriptions and they provide solutions for both (as well as the hosting/infrastructure for implementing those applications).
Here is a reply from Mozilla representative in that very thread:
"I would be very happy to push in this direction, limited by the amount of breakage and user-pushback we can expect."
http://lists.w3.org/Archives/Public/public-webappsec/2019Apr...
[A HREF="http://example.com/SomeProgram.exe" ExpectedSha256="..."]Download[/A]
If clicked, the download is checked and is quietly discarded if the hash is wrong.
Edit: To clarify, I mean it could show the warning before the browser does the rename of the file from the temporary download file to the final filename.
If I could prove that the first 5% of a file is intact given the final hash, and repeat that proof continuously as the download proceeds, then it wouldn’t be wasteful.
IANAC
100% hash: 12344567
10% hash: 7251abed
That the 10% hash is a valid candidate for eventually becoming 12344567, assuming the other 90% checks out?
Courtesy of Wikipedia on the matter, at the MD5 page:
MD5("The quick brown fox jumps over the lazy dog") =
9e107d9d372bb6826bd81d3542a419d6
MD5("The quick brown fox jumps over the lazy dog.") =
e4d909c290d0fb1ca068ffaddf22cbd0
The addition of the . at the end has indeterminable effects on the resulting hash. Unless the protocol is defined such that the blob is hashed in blocks of known size and that's what's being checked against (as opposed to the full-blob hash), I don't think it's solvable.Someone with more street cred on this matter, please correct me if I'm wrong!
EDIT: What about a "Hey, server! I'm 2MBs in, and I got hash blahblohblablablaaah; am I doing fine?" protocol? #terribleideas
However, a second hash of 10% of the file would work fine. You can even truncate it if saving a few bytes is that important (since you will check the full file hash later), although I suspect even a page with a bunch of downloads would be fine with a couple of extra hashes per file. While most APIs don't expose this possibility, most hash algorithms can spit out the full hash of the file up to any intermediary points with very little additional work. Or there could be seperate hashes for different blocks of data like P2P protocols do and store them all in a separate file on the https site.
However, the main issue is that these days it is very easy to just use https, most likely easier than any other solution. Browsers encouraging people to care by showing warnings should be very helpful in increasing the number of sites using https.
/s
Fun fact: https is a great way to mask your malware payload from filtering proxies. So now corporate laptops have client-side HTTPS filtering, which have really stupid filter rules that break existing valid use cases of downloading files. So the users then turn the filters off, and now all the malware gets through. Yay https! We may not be secure, but we've got privacy, damn it!
I remember those dialogs in Netscape 4. They were incredibly annoying.
Linking resources (like images, files, etc) is another topic, but it doesn't make much sense to put a barrier for pages. If nothing else, you get annoying warnings that people learn to ignore.
This is why I use FireFox.
Https protects you against network MITMs, not evil sites sending you evil executables.
At this point, with all the restrictions happening, how about we just require a license to use the internet? Just skip all this crap because that's about where we're heading now.
(the practical bit is because in theory you can blessed repositories/app stores that users can setup, but in practice this means that the vast majority of users will keep the default repositories and thus if you want your program to be used you'll need the permission of whoever owns these default repositories - ending up with a walled garden even if in theory the walls are low and you can jump over to other gardens)
Looks like I'm safe.
Though seriously, I don't see how this is going to stop people from getting infected. For a short time I did computer "repair" which was 99% removing malware/reinstalling Windows or fixing some silly configuration error the user made. One dude had downloaded 'jessia_alba_nude.exe' or something like that and infected his machine. I can totally see him following directions like "download jessica_alba_nude.jpg, rename to .exe, and double click to view" People are woefully ignorant and just want the carrot on the stick.