Page MenuHomePhabricator

Mandate only-SSL for accounts with access to private information
Closed, ResolvedPublic

Description

Making it an option for users is nice, but for users with sysop, checkuser, oversight and researchers (for enwiki; other wikis configurations my vary) SSL access should not be an option, but the only way to access the servers.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
https://bugzilla.wikimedia.org/show_bug.cgi?id=47832
https://bugzilla.wikimedia.org/show_bug.cgi?id=29898

Details

Reference
bz31323

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:53 PM
bzimport added a project: HTTPS.
bzimport set Reference to bz31323.

If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.

(In reply to comment #1)

If we can require SSL for some logins, it would be irresponsible not to require
SSL for *all* logins.

What about requiring HTTPS for all logins, and HTTPS for all further pages of special users?

Sorry, to clarify I meant persistent HTTPS for all activity from the account, not just log-ins. But I agree with Brion's comment that the best case would be to require HTTPS for the log-in process for all accounts, at the very least.

And now that all that code is in place, I think it should be trivial in the login to say if a user is a member of a particular group, force stickHTTPS to true.

(In reply to comment #5)

And now that all that code is in place, I think it should be trivial in the
login to say if a user is a member of a particular group, force stickHTTPS to
true.

What about global groups? Ombudsmen, Staff, founder, steward and sysadmin all give access to private information.

Please forgive me for my ignorance, but doesn't having a cookie at all sent in HTTP mode mean that the user has logged in at least once *not* using HTTPS? Isn't it already too late to redirect him to HTTPS?

All HTTP cookies have a "Secure" attribute that determines whether the browser will send them over HTTP or not. So, in other words, the actual protocol under which the cookie was sent is irrelevant, it's the Secure flag on the cookie that matters.

When you log in using HTTPS in MediaWiki, almost every cookie is set to Secure so that it only goes over HTTPS. However, if you look in User::setCookies, you'll see that the forceHTTPS cookie is explicitly set without the Secure attribute so that it'll be visible regardless of protocol.

(In reply to comment #9)

All HTTP cookies have a "Secure" attribute that determines whether the
browser
will send them over HTTP or not. So, in other words, the actual protocol
under
which the cookie was sent is irrelevant, it's the Secure flag on the cookie
that matters.

When you log in using HTTPS in MediaWiki, almost every cookie is set to
Secure
so that it only goes over HTTPS. However, if you look in User::setCookies,
you'll see that the forceHTTPS cookie is explicitly set without the Secure
attribute so that it'll be visible regardless of protocol.

That's a crystal clear explanation, thank you!

Chmarkine subscribed.

Resolved since HTTPS has been enforced for everyone.