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.

Request for comment (RFC)

Login security
Component	Security
Creation date	21 August 2013
Author(s)	CSteipp, Tim Starling
Document status	in draft

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 28 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 countries where HTTPS usage is restricted and need HTTP access
• Editors who cannot use HTTPS for some local reason, such as a poorly-configured corporate firewall
• 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 Gerrit change 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, Gerrit change 80166 and Gerrit change 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 change 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 change 47089
• Finish and deploy GeoIP patches

Longer Term Questions

In the context of a MediaWiki installation where both http and https are supported for accessing the wiki, I'd like to decide if MediaWiki core should support (either directly, or by having the hooks to allow an extension):

• Should MediaWiki 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 (e.g., user groups, GeoIP, or some other criteria)?
• Should MediaWiki support logged in users using HTTP, when HTTPS is available to them but they don't want to use it (typically for performance reasons-- low end devices, lack of caching, etc)?
• Should MediaWiki support requiring HTTPS for users with advanced privileges?

Considerations

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 Gerrit change 47089, which enforces using HTTPS after login according to the user's preference).

Core work for GeoIP in progress: Gerrit change 80166

Plan of record: Implement GeoIP-based exclusion from the HTTPS default for China and Iran for all wikis, and rely exclusively on GeoIP for exclusion strategy (do not vary based on wiki).

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 user who cannot access HTTPS for miscellaneous local reasons) 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.

Plan of record: Have a preference (default: on) for always using a secure HTTPS connection as a logged user. This preference will be hidden for users in China and Iran, where the behavior will be off.

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. Access to login.wikimedia.org from China via HTTPS is currently allowed, since it is on the wikimedia-lb IP address which is not blocked. We have not validated whether Iran similarly allows this traffic.

It may be possible to protect password entry for users in China by moving the following pages to login.wikimedia.org:

• Special:Userlogin
• Special:ChangePassword
• Special:ChangeEmail

This was not done originally because it makes it more difficult to present a consistent user interface, especially navigation links. In this scenario, session cookies would be insecure, so it would be possible for an attacker to act as the user, except for changing their password or email address.

Plan of record: we'll keep the status quo for Wednesday, August 28, but this will be the next item we explore.

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.

Plan of record: TBD.