1303739 - Warn when downloading executable files over HTTP

Status: RESOLVED DUPLICATE of bug 1877195

(Firefox :: Downloads Panel, defect, P5)

Description

[Eldmannen]

Attachment: warning.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

Clicked on a hyperlink to download a .exe file that was requested over HTTP.


Actual results:

It offer to download it normally.


Expected results:

Should display a warning when the user attempts to download a executable file (.exe, .msi, .deb, .rpm) over HTTP.

Since HTTP is not trusted and vulnerable to MITM attacks. This would encourage websites to host files over HTTPS and encourage users to beware.

Comment 1

[Eldmannen]

Attachment: more_warning.png

Mock up illustration of potential design for warning.

Comment 2

[Fabio Pietrosanti (naif)]

It's critical that Browser vendor protect end-users against irresponsible software distribution of executable over HTTP subject to MITM attacks in 2017.

Steps to reproduce the problem:
1. Open www.videolan.org website that's in HTTP in clear
2. Click download and follow one of their mirror in HTTP
3. Starts downloading executable

What is the expected behaviour?
Chrome should prevent e provide a big alert windows users that downloading executable files over an insecure channel like HTTP can be subject to man in the middle attacks, regardless of the digital signing of the .exe file (that would be substituted by the attacker).

What went wrong?
Considering the HTTPS deployment strategy of Chrome that now provide warning against mixed HTTPS/HTTP content and warn of providing password over HTTP in clear, it would be a reasonable moves going in the same direction to provide security warning for download of executable codes over insecure HTTP to prevent malware injection attacks.

Comment 3

[Fabio Pietrosanti (naif)]

ooops, sorry for copy and paste, opened the very same ticket to Chromium bugtracker and didn't sed /Chrome/Firefox

Comment 4

[Fabio Pietrosanti (naif)]

Also cross-linked on Tor Project for Tor Browser:
Tor Browser does not provide red security warning for downloading executable in HTTP https://trac.torproject.org/projects/tor/ticket/22809

Hopefully a cooperation would make this work out in a relatively quick way.

Comment 5

[Giorgio Maone [:ma1]]

Please notice that many projects, including some very sensitive to privacy and security such as Tails, adopt alternate measures (e.g. more or less automated hash verification at the end of the download) to validate the integrity of their downloads and still allow a flexible deployment model including insecure mirrors.
However in this age of free certificates (Let's Encrypt), encouraging HTTPS everywhere makes much sense, even though the effectiveness of a warning at the bottom of the download prompt is debatable.

Putting in CC :dvetitz and :gerv, who might want to have a say in this matter.

Comment 6

[Fabio Pietrosanti (naif)]

Thanks for putting in CC interested people, i don't know well the mozilla security community.

While i understand and acknowledge the usefulness of manual hash verification at the end of download for Security Sensitive software such as Tails used by Security Aware persons, the main issues i perceive is that massively used software such as VLC (2.3 billion downloads) are being downloaded from HTTP in clear-text from non-security-aware users just following click-next-click procedures.

I would prevent downloading of executable from HTTP clear-text as a default security settings, but i understand that it would break a certain amount of situations.

Assuming that software distribution of installers over HTTP in clear in 2017 is an unacceptable security risks due to MITM attacks to inject malware (by governments or criminals), i think that would be a reasonable security measure to be put in place.

Reasonable in the same way it's reasonable to warn the uses of logging in with a password in HTTP in clear-text.

Comment 7

[Daniele "Mte90" Scasciafratte]

Actually Firefox provide an alert for HTTP only on form where is the a password field and created issue with many users that was thinking that the website was not secure.

So I think that the first step is to create a mockup in the download view where firefox ask the path to save the file with a text that explain the issue in a simple way.

I don't think that is difficult to implement but will be helpful for alert about MITM attack or inform users that is better to use HTTPS.

We need to forget that one of the most reason for users to use Firefox is privacy and safety and we need to inform them.

Comment 8

[Fabio Pietrosanti (naif)]

Having the same conversation also on Tor Project TorBrowser link https://trac.torproject.org/projects/tor/ticket/22809

The definition of executable could be:
"any installer file that can be directly executed on the target machine"

By having a feature like that in Firefox we will foresee a *huge* increase in software distribution security worldwide.

Especially this feature would bring a complete take-down to Infection Appliance provided by Surveillance companies such as HackingTeam and Finfisher (see ​https://twitter.com/botherder/status/882243803448561665 ) that works by substituting executable files on the file in HTTP.

Comment 9

[Gervase Markham [:gerv]]

As a UX question, this should probably be in the Firefox product.

I see the problem you are raising; the trouble is that we will be putting warnings in front of millions and millions of users to save a small handful. Perhaps our UX team can come up with a better way.

Another option would be to push again on getting Subresource Integrity specced for <a> elements:
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

This seems like the direction people are moving in to fix this, but there's spec work that needs to be done. At the time it was initially defined, they said "<a> is a bit complicated; we'll do that in v2", but it could be that it's all stalled.

Gerv

Comment 10

[Gervase Markham [:gerv]]

https://lists.w3.org/Archives/Public/public-webappsec/2017May/0003.html

Looks like it's still an idea, but no-one seems to be working on it right now.

Gerv

Comment 11

[Fabio Pietrosanti (naif)]

I feel that as we come up with a security warning that's done as a copy-paste to the invalid/expired/wrong TLS/certificates one.

End-users will be informed of the security risks and be able to go forward downloading it if they really understand/knows what they area doing, but the entity doing the software distribution will upgrade it's URL to HTTPS in relatively small amount of time.

Today upgrading to HTTPS is cheap, HTTP->HTTPS is about +2% CPU costs and actually with LetsEncrypt certificates are free and easy to be setup with apache/nginx integrated utilities.

I see this security improvement so beneficial that i'm willing to put efforts in terms of work and fundraising for that, for the great positive impact it will have worldwide! :-)

Comment 12

[Fabio Pietrosanti (naif)]

This kind of security issues is now actively being exploited by Turla Russian APT Group:
https://www.darkreading.com/attacks-breaches/turla-cyberespionage-gang-employs-adobe-flash-installer/d/d-id/1330788

I updated the tickets to achieve that specific improvement also on Google Chromium and Tor issues trackers:
https://bugs.chromium.org/p/chromium/issues/detail?id=739090
https://trac.torproject.org/projects/tor/ticket/22809#comment:4

Comment 13

[Darkspirit]

We are not talking about a JPG, but about an executable that probably will be run as admin: One is warned about an insecure password form (https://goo.gl/fkomLb), but not about being one step away from beheading oneself?

If I google "Flash player download", the second result is the well-known german computer magazine CHIP:
http://www.chip.de/downloads/Adobe-Flash-Player_13003561.html
The exe will be downloaded via http:
http://dl.cdn.chip.de/downloads/60718/FP_win_28137.zip?cid=54382746&platform=chip&1516455285-1516462785-1a1d-B-a92cc5029a072343cb5fe7444f4c1ea0
(https://dl.cdn.chip.de = SSL_ERROR_BAD_CERT_DOMAIN, Akamai)
There wasn't any broken padlock, for example. There is no incentive for CHIP to switch to https at the moment. :/

Comment 14

[Fabio Pietrosanti (naif)]

When software does not provide full HTTPS delivery chain, people can die.

Please let's close this loop-hope by preventing download of executable over HTTP in clear-text.

https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/

Comment 18

[Eldmannen]

Chrome is now implementing this in version 82.
https://www.theverge.com/2020/2/10/21132099/google-chrome-users-block-insecure-downloads-https-android-ios

This was reported 4 years ago, and Firefox could have been a pioneer, instead it looks like Chrome will get there first.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:mak, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 21

[Christoph Kerschbaumer [:ckerschb]]

Once Bug 1877195 has landed, this Bug renders as a DUPLICATE.

Comment 22

[Pascal Chevrel:pascalc]

Can we mark it as duplicate now that bug 1877195 landed?

Comment 23

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Pascal Chevrel:pascalc from comment #22)

Can we mark it as duplicate now that bug 1877195 landed?

I think we can. Please note that we warn for all downloads that happen over HTTP, not only executeables. Either way, warning when downloading files over HTTP instead of HTTPS fits our overall more https adoption strategy. I'll mark this as a duplicate.