Requests for comment/Login security

There is some ambiguity about how MediaWiki supports, and should support in the future, HTTPS. This is to clarify the current architecture, and request feedback on the future direction.

There are several different scenarios that "using HTTPS" covers: 1. Everyone using HTTPS, including anonymous readers 2. Using HTTPS for the MediaWiki login, which is the actual submission of your username and password 3. Using HTTPS while logged in to MediaWiki 4. Requiring HTTPS for security critical, non-core features (CentralAuth SUL, OAuth tokens, etc)

The Wikimedia plan to "enable HTTPS" on Aug 21 was for the second item only. As part of that, how we had previously handled #3, and gave the option to a user to not use HTTPS while logged in was also updated. Additionally, a feature was added to selectively turn on/off HTTPS for #2 based on geography. Several bugs resulted due to misinterpretation of the design, which this document will attempt to clarify.

This document is not to discuss:
 * The, "only https" scenario, where everything is (that would be a political and ops issue, not MediaWiki)
 * Details of the HTTPS configuration (ciphers, PFS, and other ops considerations)

Groups of people affected

 * Editors with no restrictions on HTTPS usage whatsoever
 * Editors who live in places where HTTPS usage is restricted and need HTTP access
 * Editors who may chose to use HTTP over HTTPS due to performance considerations (latency, old devices, etc)

Architecture prior to MediaWiki 1.22wmf13 (mid-August, 2013)

 * MediaWiki has supported setting up a wiki to be http only, https only, or a mixed environment where users can use either one, but are not intended to switch protocols. To support this, all urls are written out protocol-relative, etc.
 * When https is used to login, all cookies are set to "secure", so they are only sent on requests to https urls
 * For sites that use both http and https, a feature flag was added, $wgSecureLogin, which would
 * Change all login/create-account links to https:// links
 * Redirect a user who attempted to access a login/create-account page over http to https
 * Add a checkbox to the login form allowing the user to choose if they wanted their logged-in session to be over http or https
 * If the user decided to continue using https for their logged-in session, an insecure cookie (forceHTTPS) was set which would cause MediaWiki to redirect any request with that cookie on http to https
 * CentralAuth was updated to also respect the checkbox'es choice on login
 * However, CentralAuth forces users to use HTTPS for all requests to login.wikimedia.org, which verifies cross-project logins as part of the "SUL2" work.

Issues with using $wgSecureLogin in this setup:
 * If a user wants to use http while logged in, they must unselect the checkbox on every login
 * If a user can't use https, they cannot login since Special:Userlogin must be accessed over https

Updates to MediaWiki in 1.22wmf13

 * Due to concerns with the checkbox UI, set by $wgSecureLogin, the functionality was moved to a preference in https://gerrit.wikimedia.org/r/#/c/47089/
 * The patch also enforced a redirect from http to https on ever page view based on the preference, in addition to the insecure forceHTTPS cookie
 * Due to concerns about users from China/Iran, https://gerrit.wikimedia.org/r/#/c/80166/ and https://gerrit.wikimedia.org/r/#/c/80175/ were proposed so that for connections from these countries (based on GeoIP):
 * Disable requiring HTTPS for the login page
 * Disable redirecting to https based on the user's preference

Issues:
 * gerrit 47089 wasn't complete, so a few bugs were introduced
 * CentralAuth wasn't updated for the preference
 * Does not support requring HTTPS for Admins vs unprivileged editors

Proposed Solution (Short Term)
The current plan is to:
 * Fix issues with gerrit 47089
 * Finish and deploy GeoIP patches

Longer Term Questions

 * Should MediaWiki (core) support allowing some users to use http for their login, while most users use https? If yes, what are reasonable criteria for determining who can use http?
 * Should MediaWiki support user who can use HTTPS, but don't want to (typically for performance reasons-- low end devices, lack of caching, etc)?
 * Should MediaWiki support requiring HTTPS for users with advanced privileges?

Use of GeoIP to disable HTTPS for the MediaWiki login vs enabling on per wiki basis
GeoIP allows us to target individual countries/regions for requiring HTTPS for the MediaWiki login instead of doing it per project. Per-wiki basis requires no additional changes for us to do it, but it's a far from ideal solution. The downside to doing it per-project is the English Wikipedian living in China or the Chinese Wikipedian who wants to edit Meta (which would be impossible after https://gerrit.wikimedia.org/r/#/c/47089/, which enforces using HTTPS after login according to the user's preference).

Core work for GeoIP in progress: https://gerrit.wikimedia.org/r/#/c/80166/

Use of a preference vs login form checkbox vs hidden option vs sensible default
As of this writing, our implementation of HTTPS allows for a way of opting out of using SSL for using MediaWiki while logged in, in preferences. The problem with this approach is that a user who doesn't have SSL access to a site (such as a Chinese Wikipedian) will not be able to access this preference.

A previous implementation placed this option in a checkbox in the login form. This approach allows a user who does not want to use SSL after logging in to change the preference (for duration of the session) prior to logging in, but clutters our login form.

How interactions with login.wikimedia.org will work
login.wikimedia.org is the host that we now use for Single User Login (SUL). It was deployed in July 2013. This uses SSL for everyone (even in China and Iran), and has ever since it was first launched. Based on everything we know, this has not been a problem. We have received reports that blocking has not been an issue for this, even in China (we have not validated whether Iran similarly allows this traffic).

Validation of our HTTPS test methodology
We have done some testing to determine which geographies block SSL traffic to *.wikipedia.org. We were able to show that China and Iran are most likely blocked. We discovered possible issues in other countries as well, but we believe those issues are more related to latency than with intentional interferance with SSL. Moreover, in scrutinizing our methodology, we have come to realize that our tests may overemphasize latency issues relative to the problems we would actually see in real use of HTTPS.