From my reading, it looks they're considering this for only non HTTPS downloads initiated from an HTTPS page
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.
That's not how I read it. The nonsecure download from a secure page is their starting point. The end goal is to block all unsecure downloads of high risk types.
Clever. This means users won't be able to easily download software from websites not plugged into CA tree. One more step towards eradicating the ability of people to independently host websites altogether.
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.
Couldn't you add additional certificate authorities to your browser at will?
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.
The point isn't what you can do as a user. The point is that Google adds more and more hurdles to running a website without plugging into the CA chain.
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.
How many websites do you actually use don't have a domain name?
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.
I dont understand why they are doing this.
.exe files are known to be dangerous so usually when one downloads it you make sure its from a safe website.
How is blocking non-https .exe downloads making this any safer for end-user?
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.
It doesn't matter if the website is "safe" if the download happens over plaintext HTTP. Any middleman could replace the executable with anything, or worse: just inject malicious code into the executable so you don't notice anything is amiss.
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.
A big problem is that it's so difficult (and expensive) to get a code signing certificate that's valid under Windows that many developers just don't bother:
>A big problem is that it's so difficult (and expensive) to get a code signing certificate that's valid under Windows that many developers just don't bother:
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.
> Certum also provides discounted certificates for open source projects (around $30).
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". ;)
>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.
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.
Just my general lack of trust in things stored "securely" in the Cloud, vs securing it locally offline ourselves. :)
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. ;)
If you download an exe from a nonsecure connection. You cannot be sure the exe is the one offered by the site or one provided by a man in the middle. I know there are CRC checks but, this protection is not for user that understand that.
As a PSA, CRC checks are insufficient to prevent tampering. CRC checks are designed to detect accidental corruption, not deliberate. Cryptographic hashes, provided over a secure connection (not http), are the basic minimum.
Do note that even then, there have been demonstrated exploits of package managers downloading over http, where the parsers were demonstrated to be compromised.
Google found a threat model where attackers inject http:// .exe links into https:// web pages. This exposes a flaw in mixed-content handling, where web pages don’t allow http:// resources to be loaded - but DO allow resources to be downloaded. Addressing that flaw for all file types would probably break a lot of the internet, but not for .exe (in their apparent estimation). I look forward to hearing what the Firefox and Edge teams think of this.
TLDR: In this approach, http:// sites can link http:// executables, but https:// sites cannot.
I don't see why a https:// site would serve up a http:// download link to an .exe in the first place.
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.
Malice is certainly possible, but someone simply making a mistake is another easily plausible cause. Many sites don't correctly redirect all URLs to from http to https.
Counter-example: Ubuntu serves their ISO via an HTTP link on an HTTPS page. They supply a gpg signature as a way to validate that the file was not tampered with.
The hostname resolves to a bunch of different mirrors run by different people who don’t all share a secret key between them.
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.
ISO files are not considered a common (if not most common) vector for malware delivery. While it’s dumb that they serve it over HTTP (don’t use CNAME-based mirror setups, everyone) it’s also neither putting anyone at significant risk to allow it nor under consideration for blocking.
Actually, right now, neither Google Chrome, nor Safari would warn the user at all, if you download ANY content via HTTP from a HTTPs encrypted website, it's a bug I filed for both browsers, but they didn't get resolved yet. I wrote in more depth about this topic over her https://krausefx.com/blog/trusting-sdks
> I am getting fed up with Google trying to steer how the web should be. Already changed to Firefox.
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).
You are baffled that they reacted this way, that you became the villain? It's hard sometimes, but I've found it helpful to try to perceive both myself and the digital obstacles from the shoes of users I'm trying to help (calibrating more as I proceed), and adjust myself accordingly.
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).
So, the thing is, they are working to ensure that is true. If you download it from a non-secure source, it can be changed on route. What you intend to download and what you actually download are different.
Hash checks, file signatures, etc. make that a non-issue.
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.
I actually read the URL in the status bar when I hover over things to click. Not once in my nearly 40 years of life have I ever fallen prey to clickjacking.
This seems like a direction Firefox would go in too. Web security is important, and preventing downloading of insecure executables is an easy win for security.
I wonder why the focus is just on downloads from https pages. I've not thought about this for very long but why is it ok for https pages to link to http pages? If I navigate to https://trustedsite.com, and they link to http://trustedsitesortof.com, my browser should warn me.
It used to warn you. IE6, I believe, used to say "you're about to leave a secure site", or something along those lines. But the world was different then, and HTTPS wasn't as common as it is today. I strongly suspect that that sort of warning will soon be coming back.
That doesn't make sense, think HN/Reddit/etc, which are HTTPS and primarily link to other sites which can (and very often are) HTTP. There is no security compromised here nor any other link between the two than one referring to another.
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.
Quiet discarding might not always be possible in a reasonable timeframe. You still have to get all the bytes to sha256 the payload, and so what? Do you expect the user to waste bandwidth and wait the check out? Often bandwidth and time both have costs attached.
It could still download it as normal, but show a warning at the end after it computes the hash and compares. Just like getting around a bad HTTPS cert, the browser could allow you to say "I know what I'm doing".
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.
Considering EXEs specifically (entirely dismissing tarballs and such packages which can easily go up to several gigabytes), you cannot rely on everybody being able to download files in a reasonable time frame. I'm lucky to reside in a country that allows me to download hundreds of megabytes in double-digit seconds, alas that is not true for everybody else out there.
Have we yet constructed a hashing algorithm that maps the file left to right onto the hash in a way that’s provably correct at milestones other than “entire file only”?
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.
The chaotic nature of hashing algorithms is desirable here because even a couple 'random' bytes changed in the assembly could yield drastically different computations. I don't think you can hash something without going through the whole blob.
Not to my knowledge, no. I don't even think that you could do that with the most basic checksum algorithm.
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
You are correct that there is no such single hash; there can't be without it being longer, because then the parts could be brute forced separately.
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.
Why is that a bad idea? I mean, if you're downloading 1GB, your file is split into 1MB chunks, and each hash is 256 bits, that's only 32KB. I doubt anyone would complain about that.
See also universal SRI, which is sadly not making progress at this time. It’s possible that’s because embedding hashes in pages doesn’t scale properly in practice (as CSP nonces also seem to reflect).
Now every time I want to update the contents of some file I am serving I need to also update my web content. This would work, but also be frustrating. Would managing this actually be easier than just serving the file over https?
Chances are, you're updating a version number in the filename anyway. Especially if you're using http to allow for distributed http caches. I dunno, does anybody run those to reduce network use when they have a low bandwidth connection anymore?
Years pass, we have sci-fi level technology, and the main method of distributing programs to users on Windows is still downloading .exes from random sites and being on the lookout for the browser toolbar trying to sneak by when installing. I don't know what's worse, this, or Google trying to wrestle yet another group of website owners into obedience.
Well, at least under Windows (and MacOS) you are still able to distribute your application using an installer which users can download from your own site, rather than being forced to use a centralized "app store". And policies like these are making this more difficult. However they won't stop shady sites which "re-bundle" open source applications and add spyware - those will have no problem getting an HTTPS certificate.
What would be a solution to that that wont end up giving 3rd parties practical control over what you can and cannot run in your own computer?
(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)
> $ man 5 exe
man: No entry for exe in section 5 of the manual.
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.
When all the HTTP security problem of the 1st download of VLC will get fixed?
It seems that they are really insisting with some not-declared reason, to go against any security analysis.
Is the VLC paid by EADS and/or French intelligence to enable man in the middle to inject malware in keeping HTTP in clear-text available?
With Alexa top-500 website, representing more than 80% of internet traffic, being in HTTPS i can only see nasty, hidden reasons to maintain the HTTP VULNERABILITY OF VLC
Given the negative response people got from the devs about that, it won't happen. They're just super sure every component in their HTTP distribution is secure and transport security will offer no benefit. Just like APT people.
Absolutely not. We said our updater using HTTP is secure, since the updates are cryptographically signed, like APT.
The first download is HTTPS-all-the-way since a long time: search engines get you the HTTPS version of videolan.org that redirects you to HTTPS-only mirrors (not controlled by us).
However, as we do not control the mirrors and the mirrors content, this is not secure, but so far, there is no solution (until universal SRI).
> We said our updater using HTTP is secure, since the updates are cryptographically signed, like APT.
With a 1024bit DSA key last I heard, not very secure. And that is assuming the updater doesn't contain other flaws. The same assumption APT people made, which, who the could have guessed, was wrong.
> there is no solution (until universal SRI).
For first initial download, indeed, unless you ship using Windows Store for example.
Malware authors are all already moving their payloads to https sites, so this will be useful for about a year until it's been worked around.
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!
96 comments
[ 3.5 ms ] story [ 159 ms ] threadRelevant 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...
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.
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.
[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:
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
(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.
It seems that they are really insisting with some not-declared reason, to go against any security analysis.
Is the VLC paid by EADS and/or French intelligence to enable man in the middle to inject malware in keeping HTTP in clear-text available?
With Alexa top-500 website, representing more than 80% of internet traffic, being in HTTPS i can only see nasty, hidden reasons to maintain the HTTP VULNERABILITY OF VLC
See https://gist.github.com/elimisteve/69077a93d21b8bf8a02a362c8...
Is VLC paid by French intelligence to maintain this vulnerability open?
The first download is HTTPS-all-the-way since a long time: search engines get you the HTTPS version of videolan.org that redirects you to HTTPS-only mirrors (not controlled by us).
However, as we do not control the mirrors and the mirrors content, this is not secure, but so far, there is no solution (until universal SRI).
With a 1024bit DSA key last I heard, not very secure. And that is assuming the updater doesn't contain other flaws. The same assumption APT people made, which, who the could have guessed, was wrong.
> there is no solution (until universal SRI).
For first initial download, indeed, unless you ship using Windows Store for example.
Breaking encryption of DSA and doing fake DSA messages are 2 very different tasks.
> And that is assuming the updater doesn't contain other flaws.
And you believe that a full TLS stack will have less flaws than a DSA-check? That Gnutls is simpler than gcrypt?
Your argument about flaws would push to have simpler code, not more complex one.
When you will stop doing those kind of accusations all the time, maybe some people will listen to you. Until then, not so much.
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!