You're right that it's archaic. We have recently removed support for this mode from CentralAuth: T348852: Remove CentralAuth support for mixed-protocol HTTP/HTTPS wikis. But that was easier than doing it in MediaWiki, since we didn't need to worry about users other than Wikimedia wikis.

There is quite a bit of code for supporting wikis hosted on both HTTP and HTTPS protocols, especially in the auth components, including several config options and public interfaces that will need to be deprecated first.

Code to review (not necessarily all of this should be deleted): https://codesearch.wmcloud.org/core/?q=SecureLogin|ForceHTTPS|CookieSecure|prefershttps|stickHTTPS|requiresHTTPS&files=php&excludeFiles=&repos=&i=fosho

From the original task description:

See also: https://www.jefftk.com/p/history-of-https-usage

...which links to Let's Encrypt stats which has this nice chart based on Firefox telemetry:

(I feel like we already had a task about this but couldn't find it.)

Some issues that this would resolve or obsolete:

• T55197: OATH should use $wgSecureLogin
• {T219350}
• T180886: AuthManager special pages should honor $wgSecureLogin
• T149977: After login, user not logged in when "prefershttps" set to false and "wgSecureLogin" set to true
• T270596: SpecialPage::checkLoginSecurityLevel unconditionally uses PROTO_HTTPS
• T41676: Links in MediaWiki emails should respect the user's https preference

and some issues would become simpler to solve:

• T160387: Support Strict Secure Cookies
• T54253: Protocol-relative URLs are poorly supported or unsupported by a number of HTTP clients
• T111135: Installer should set wgSecureLogin, wgCookieHttpOnly and wgCookieSecure from generated LocalSettings.php

Also related: T118413: Wikimedia wikis should use https:// in $wgServer

One of the reasons why we might need to support HTTP mode is the TLS overhead (performance cost) but I don't think it justifies the additional complexity we need to maintain. I wonder if we have any use cases or requirements to support mixed mode? Only thing that comes to my mind is dev environments - but those are just HTTP mode (without SSL).

Individual cases may vary, but the delay and overhead of TLS is generally believed to be outweighed by the performance benefits of HTTP/2 and QUIC, which in practice only work over TLS.

From my experience, the only reason to operate a site over HTTP exclusively is sysadmin simplicity. I believe this is an important and worthy reason to support HTTP for. However this task is not about dropping HTTP support. It is about supporting specific sites to simultaneously decide to provide TLS and yet not want to make it an enforced default.

That would imho only make sense if there are significant server or client costs, where there no longer appear to be, with the exception of the costs associated with providing it at all, which as said are sound but not what the task is about.

One use case I can think of is a wiki that works over HTTPS but has an invalid certificate (and cannot easily get a valid one, e.g. because it has an intranet domain name, making Let’s Encrypt no option), to avoid readers being faced by scary error pages. However,

• this use case is purely theoretical, I don’t know of any actual examples,
• and actually I wish (non-localhost) HTTP pages would have at least as scary error pages in all browsers as invalid certs, as they aren’t any safer. (I’ve been using HTTPS-only mode in Firefox ever since it appeared, which does roughly this.)

In T372396#10666004, @Tacsipacsi wrote:

One use case I can think of is a wiki that works over HTTPS but has an invalid certificate [..], to avoid readers being faced by scary error pages.

This scenario should work fine.

MediaWiki only knows about HTTPS support if you as sysadmin specifically want and tell MediaWiki to use this, by editing LocalSettings.php and setting wgServer to a protocol-relative origin, and enable wgSecureLogin. Neither of these happen by default or automatically.

If your underlying web server happens to have TLS enabled (by accident, or forgotten, or for an unrelated application, etc), MediaWiki will not on its own detect or decide to make use of that.

If TLS works and you want MW to use it, set wgServer to https. Otherwise it will use http.

Regarding latest Firefox (or another HTTPS-Everywhere/Happy-Eyeballs implementation) discovering this client-side on its own, that's a problem indeed. If your server has TLS turned on for the wiki domain, but the cert is invalid, Firefox will discover that and show you the error. This is however not something we can change inside MediaWiki. This happens even if you set wgServer to http, and wgSecureLogin=false. MediaWiki will try to redirect from https to http in this case, we do that already. But, if you have an invalid or expired certificate, the redirect will never make it to the browser because it won't even be able to connect to the web server in the first place. The only solution there is either to turn off TLS on the server, or for clients to turn off HTTPS-only.

In T372396#10666168, @Krinkle wrote:

This scenario should work fine.

Sorry, I wasn’t clear: I imagined that some people want to use HTTPS despite the invalid cert (e.g. for login), potentially after manually making it trusted. However, as I wrote, this is purely theoretical, so we shouldn’t spend too much time figuring out the perfect configuration for this scenario.