Why doesn't your website enforce https?

Frequently Asked Questions about the Pale Moon browser and their answers.

Moderator: satrow

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 24869
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Why doesn't your website enforce https?

Unread post by Moonchild » 2019-08-03, 20:25

Why doesn't www.palemoon.org enforce https?

This is a question that regularly pops up by people who have been given a lot of Kool Aid to drink. The answer is extremely simple: Accessibility.

The slightly longer answer is: Accessibility, https is optional and available for those who want/need it, binaries are signed, and not in the least also because https isn't a magic wand to "make everything secure", especially not in the current age where certain projects have completely trivialized DV https.

The full answer:
This is a multi-factor issue that does need some understanding of how attacks against http work. I'll address this by taking the common arguments made by people posing the frequently-asked question in this post.

Argument: "Everyone should always be using https"

The main issue is that people want to enforce https. Not just have available but actually enforce it for all visitors and all types of content.
This is problematic in a few circumstances that are, in fact, very common for our visitors:
  • Restricted/monitored local networks:
    Many corporate networks (and in some cases nation-wide networks) are not allowed to have un-checked or encrypted connections to the outside. In many cases this means that end-to-end encryption (like https) isn't allowed to be used, is flat-out blocked, or otherwise can't be used. Pale Moon is a web client that can be used in such environments perfectly fine, and should be accessible to those users. Enforcing https would make it impossible for those users to visit the website and download the browser.
  • Outdated/obsolete web client:
    In many cases, Pale Moon is downloaded as one of the first things after a new installation of an O.S. with potentially very outdated standard software installed. To be able to allow access by very outdated software, the choice for us would then boil down to either providing http as a protocol, or provide insecure/weak https to cater to old clients trying to download the browser. The latter is always worse because it would impact clients with proper security as well. It's always better to know something is insecure than to think it is secure while it actually is not. So: we offer http for access to the website and downloads from outdated software.
The Pale Moon website is public information. There is no reason to enforce encryption on it (unlike, say, this forum, automatic updates or the Sync server, all dealing with personal information or automatic processes with high impact), and we are offering https on the website for those who want/need/prefer it. I recommend you use https if you intend to use the information on the site to download and verify the browser downloads, as manipulation of data is more difficult that way. However, we will not be forcing https here for the reasons above, so the website and browser remains accessible to all.

The issue is complicated by the fact that there is no easy way to detect https capabilities without trying to serve https content, so it's a bit of an all-or-nothing scenario here. Either forward all traffic to https (like people are demanding asking) or don't, and allow visitors to switch to https themselves.

Argument: "Downloading executables over http is dangerous"

We offer downloads from our mirrors over http (update: https downloads are offered from the EU mirror now if you visit the download page over https). This is for performance reasons but also not in the least because we rely on third parties providing the mirror servers that we don't necessarily entrust with our private keys for web server certificates (since we use a wildcard certificate for the domain as individual certificates for subdomains would be too costly for us and have a lot of maintenance overhead to boot). Additionally, it's no guarantee that downloads are safe over https (see next argument).
Aside from a small risk (see below) of someone actually intercepting such a download and modifying/replacing what has been downloaded, downloading over http is perfectly fine. After all, we do offer the download page (website) over https as an option, so the links to download (the most common attack to try and have users download malware instead) are guaranteed to be correct and pointing to the correct installers/binaries if you request the website over https. If you are in a situation where http is the only protocol available, you should of course be more careful and verify your downloads.
While downloading over http in itself does have a risk of manipulation by a man-in-the-middle for the actual downloads, since unencrypted connections can be manipulated in such a way that a user actually downloads something hosted by an attacker instead of the software vendor, we offer several ways for users to check the authenticity of software after download:
  • Code-signing: Automatic in all supported O.S.es, the UAC prompt will inform users when they run the installer that it has been signed, with the appropriate name of the signer ("Mark Straver"). Code-signing certificates are not issued lightly and require company registration or a face-to-face process and notarization of I.D. and other documents unambiguously proving your personal or legal identity. This process is made cumbersome and non-trivial on purpose.
  • File hashes: For a quick and convenient check, we also provide hashes of the downloads (SHA256) for manual checking.
    Safety of this is limited since anyone can easily make a hash of malware, as well, and post it on a hijacked page. It's recommended to use the https version of the website for this reason, since it will provide a verifiable https connection to the page and the contents of it can't be altered by a man-in-the-middle.
  • For added verification, we also provide PGP signatures to manually check the downloaded files against. Unlike file hashes, PGP signatures cannot be generated by anyone else because it requires possession of the private key of the key pair. They are hashes and authentication in one. So even if a website would be hijacked and a download faked, the PGP signature won't match the downloaded executable, and no fake signature can be created without having the private key (which is properly protected in my keyring).
Argument: "Downloading executables over https is always safe"

The people arguing that http is evil are generally complacent with anything being safe as long as it's https. Unfortunately that's an increasingly incorrect statement. Https is often set up with weak encryption, and has been largely trivialized by the likes of Let's Encrypt and its automated, single-factor certificate issuance without verification with the domain owner (for domain-validated, the most common type -- allowing certificates to be issued for a palemoon.org subdomain without our knowledge or consent), so if an attacker uses any of the many avenues available on insecure networks to intercept and manipulate traffic (e.g. DNS, wildcard interception) and redirects an https download URL to their own server, it's trivial for them to offer a valid https connection to whatever client is connecting, with a valid palemoon.org host name.
In this day and age of distributed content, there's also the fact that few people will question it if the server offering the download is on a different domain than the main website of a product. Users won't have any real way to know if such an external URL is an official mirror or not. So, no, https is not a magic wand to ensure trust or safety for downloads, at all.
Additionally, tying in with the first argument, if a software vendor would offer weak/insecure https to cater to old clients, then even a valid https connection to a domain-controlled server (on the same domain as the product website) could be hijacked in other ways.
There are more reasons beyond the scope of this post why https is not a magic wand and does not necessarily provide safe downloads.



So, to the evangelists out there: While I fully agree with making https available to all as an option, your evangelism shouldn't be targeting website owners for keeping public information accessible to all; you should instead educate users that checking signatures is a good thing (even if downloaded over https!). Use your influence for that, if you're going to, instead of trying to push the envelope that https should be used always and everywhere, which is a misconception for several reasons and causes problems of its own, like undue centralization of traffic and control gating.
"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne
Image

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 24869
Joined: 2011-08-28, 17:27
Location: 58°2'16"N 14°58'31"E
Contact:

Re: Why doesn't your website enforce https?

Unread post by Moonchild » 2019-08-04, 14:34

As a general improvement and to work around the all-or-nothing nature of forwarding to https, I've enabled some smart server-side scripting to automatically forward browsers to https that explicitly indicate their preference for it, as well as enabled https for binaries on the European download mirror. We still will not enforce https because of what has been indicated above in this FAQ entry, but this will automate switching to https browsing for those browsers that explicitly prefer it (e.g. Firefox). (And no, this does not use the bad practice of user-agent sniffing).
"If you want to build a better world for yourself, you have to be willing to build one for everybody." -- Coyote Osborne
Image

User avatar
RealityRipple
Moonbather
Moonbather
Posts: 50
Joined: 2018-05-17, 02:34
Contact:

Re: Why doesn't your website enforce https?

Unread post by RealityRipple » 2019-08-22, 17:16

Regarding Enforceability, the solution I came up with is a mix of Upgrade-Insecure-Requests and a JS file that's only loaded on the HTTP version of the site, served over HTTPS, that redirects to the HTTPS version of the site. This way, any browser that requests an upgrade will get the upgrade, any any browser that supports the version of HTTPS my site uses is also capable of loading the JS file and gets the upgrade, while any browser that doesn't support TLS 1.2 will fail to load the JS file and nothing happens. While this results in the soft error of a script that can't be loaded, it effectively solves the support detection issue.

That being said, I agree with every conclusion drawn here. HTTPS is overblown by a ridiculous factor.

Post Reply