Last modified: 2014-11-17 10:36:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33323, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31323 - Mandate only-SSL for accounts with access to private information
Mandate only-SSL for accounts with access to private information
Status: PATCH_TO_REVIEW
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Tyler Romeo
:
Depends on:
Blocks: ssl
  Show dependency treegraph
 
Reported: 2011-10-03 12:33 UTC by James F.
Modified: 2014-11-17 10:36 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description James F. 2011-10-03 12:33:32 UTC
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.
Comment 1 Brion Vibber 2011-10-03 16:13:55 UTC
If we can require SSL for some logins, it would be irresponsible not to require SSL for *all* logins.
Comment 2 Liangent 2011-10-03 16:19:52 UTC
(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?
Comment 3 James F. 2011-10-03 17:12:45 UTC
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.
Comment 4 Tyler Romeo 2013-02-01 17:02:05 UTC
FYI, here's the bug for secure login for all users: https://bugzilla.wikimedia.org/show_bug.cgi?id=39380
Comment 5 Chris Steipp 2013-02-01 17:08:59 UTC
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.
Comment 6 Alex Monk 2013-02-01 17:18:40 UTC
(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.
Comment 7 Tyler Romeo 2013-02-01 17:54:12 UTC
https://gerrit.wikimedia.org/r/47089
Comment 8 Jérémie Roquet 2013-02-01 18:05:09 UTC
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?
Comment 9 Tyler Romeo 2013-02-01 18:28:55 UTC
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.
Comment 10 Jérémie Roquet 2013-02-01 18:40:54 UTC
(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!

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links