User preference for enforcing HTTPS
Closed, ResolvedPublic

Description

With the early protocol-relative link HTTP+HTTPS parallel deployments starting (bug 20643), we notice there's not currently any way to specify that, as a particular user account, you want to make sure you log in on HTTPS only. This means it's easy to accidentally log in insecurely even though you wanted to log in securely.

(This should also be sometimes on by default to force all sessions to be secure -- $wgSecureLogin sorta goes in this direction but doesn't force everything.)

In addition to making sure you're automatically sent through to the secure version (or not), this will allow users to receive the appropriate URL scheme in their email notifications: bug 29878.

Bonus points for being able to redirect from http to https links in order to bump over to a live SSL login session when following generic links found elsewhere. (may need another bug)


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31323
https://bugzilla.wikimedia.org/show_bug.cgi?id=52283

bzimport set Reference to bz29898.
brion created this task.Via LegacyJul 14 2011, 6:22 PM
werdna added a comment.Via ConduitJul 15 2011, 7:04 PM

(In reply to comment #0)

With the early protocol-relative link HTTP+HTTPS parallel deployments starting
(bug 20643), we notice there's not currently any way to specify that, as a
particular user account, you want to make sure you log in on HTTPS only. This
means it's easy to accidentally log in insecurely even though you wanted to log
in securely.

Remember that this requires our login form to first ask for the user's name, and then their password on a different page. I think I'd rather we just ran all logins through HTTPS to begin with.

brion added a comment.Via ConduitJul 15 2011, 7:06 PM

Running all login forms through HTTPS, then after that either keeping you in secure HTTPS-land or giving you an insecure cookie and shoving you back to HTTP, is common practice.

Forcing all logged-in sessions EVER onto HTTPS is my real preference, but I don't know if we're ready for that yet. :)

MZMcBride added a comment.Via ConduitJul 15 2011, 7:47 PM

(In reply to comment #2)

Forcing all logged-in sessions EVER onto HTTPS is my real preference, but I
don't know if we're ready for that yet. :)

Yes, same.

I'm a bit unsure why an (intermediate) user preference would be good here. User preferences are generally fairly evil; they're made worse by a lack of support for global (Wikimedia-wide) user preferences.

It'd be simpler and saner to switch all e-mail links to be https when the time comes rather than going down the road of different messages based on user preferences. The only thing stopping people from using the secure server currently are the ugly URL scheme and the speed. I think waiting until both of these are resolved (hopefully in short order) and then forcing all users through https makes more sense than a user preference here. Admittedly other sites such as Facebook and Twitter have user preferences for https support. Some sites such as Gmail do not.

MZMcBride added a comment.Via ConduitJul 15 2011, 7:58 PM

(In reply to comment #3)

Admittedly other sites such as Facebook and Twitter have user
preferences for https support. Some sites such as Gmail do not.

Casey tells me I'm wrong about this, and I am. http://mail.google.com/support/bin/answer.py?hl=en&ctx=mail&answer=74765 explains that there is a user preference in Gmail, but that the default is for https.

I guess the common practice is to offer an option. I'm still unclear on the virtue of making this optional, though.

Catrope added a comment.Via ConduitOct 25 2011, 1:19 PM
  • Bug 31432 has been marked as a duplicate of this bug. ***
Catrope added a comment.Via ConduitOct 25 2011, 1:23 PM

(In reply to comment #0)

Bonus points for being able to redirect from http to https links in order to
bump over to a live SSL login session when following generic links found
elsewhere. (may need another bug)

This was filed as bug 31432 and then duped to this bug. To accomplish this securely, we would need to do the following:

  • When logging in over HTTPS and the pref is set, set the login cookies securely (as always) but set an insecure cookie that specifies that the user wants HTTPS
  • On every HTTP request, check for the presence of this cookie and redirect to HTTPS if so. This also requires that the name of this cookie be added to the XVO header.

It appears that Liangent (in filing bug 31432) and Ryan (through an in-person conversation with me) both came up with the same plan separately.

Catrope added a comment.Via ConduitOct 31 2011, 8:33 AM
  • Bug 32061 has been marked as a duplicate of this bug. ***
jayvdb added a comment.Via ConduitMar 10 2012, 10:30 PM

This can be done on the client side for Firefox and Chrome.
https://www.eff.org/https-everywhere

Nemo_bis added a comment.Via ConduitMar 15 2012, 9:14 AM
  • Bug 12807 has been marked as a duplicate of this bug. ***
Aklapper added a comment.Via ConduitJun 3 2012, 9:54 AM

Does this report depend on bug 36456?

Krinkle added a comment.Via ConduitJul 20 2012, 4:17 PM

This preference would be similar to GMail's preference I suppose.

It would:

  • Affect e-mail notifications and other communication outside the site
  • Make sure that logging-in forwards you to HTTPS if not already
  • Set a non-secure cookie with the same expiration and domain that indicates the user is logged in on HTTPS and will make mediawiki redirect whenever a HTTP url is used (bug 36456)

Note that this option is only available if the site is configured with a protocol relative url as wgServer. And if the wgCanonicalServer has https, we may want to treat this preference as a hidden pref that is always true.

Krinkle added a comment.Via ConduitJul 20 2012, 4:18 PM
  • Bug 36456 has been marked as a duplicate of this bug. ***
MZMcBride added a comment.Via ConduitSep 17 2012, 11:42 PM

Related: change I60f44a10.

csteipp added a comment.Via ConduitSep 28 2012, 8:57 PM

Change I60f44a10, which implements the functionality described by Roan in comment #6 has been merged. It's triggered by selecting the "Stay connected to HTTPS after login" checkbox when logging in, which is visible when $wgSecureLogin is true. Is there any work remaining on this bug?

MZMcBride added a comment.Via ConduitSep 28 2012, 11:16 PM

(In reply to comment #14)

Change I60f44a10, which implements the functionality described by Roan in
comment #6 has been merged. It's triggered by selecting the "Stay connected to
HTTPS after login" checkbox when logging in, which is visible when
$wgSecureLogin is true. Is there any work remaining on this bug?

There still doesn't appear to be a way, as a user, to specify that you want to receive communications that specify a particular protocol (cf. comment 0, comment 11, and bug 29878 comment 8).

Your patch addresses the cookie portion and the user option _at login_, but the general user preference is not implemented (or alternately, a particular protocol is not mandated), as far as I can tell. This may or may not be the subject of a separate bug, though.

Generally, I'm not sure the approach of using a "Stay connected to HTTPS after login" is a good idea. It doesn't serve a second use-case well (e-mail and other communications) and it seems like weird clutter on the login form UI. If any preference is to be implemented at all (and I'm not sure that mandating for logged-in users and user communications is really that bad), I think it should be done in the same place as every other user preference. This also gives it the benefit of having an easy-to-set default value.

Billinghurst added a comment.Via ConduitSep 28 2012, 11:26 PM

Fully agree that my component that was marked as duplicate( [[Bugzilla:32061]] send emails with https urls) does not seem to be implemented. Of course, I would be comfortable with all urls to be https, and my problem goes away (and for those who prefer secure login)

MarkAHershberger added a comment.Via ConduitSep 30 2012, 4:30 PM

The MW issue isn't going to be solved any time soon, so bumping to future.

brion added a comment.Via ConduitApr 29 2013, 3:52 PM

Any reason not to WONTFIX this and simply force HTTPS for all sessions?

The other 'big sites' like Gmail and Facebook have long since moved to HTTPS-only for all logins.

Parent5446 added a comment.Via ConduitApr 29 2013, 4:01 PM

(In reply to comment #19)

Any reason not to WONTFIX this and simply force HTTPS for all sessions?

The other 'big sites' like Gmail and Facebook have long since moved to
HTTPS-only for all logins.

This isn't for logins, but for HTTPS all the time while logged in. And both Gmail and Facebook still have user preferences for whether users want to use HTTPS or not after login.

brion added a comment.Via ConduitApr 29 2013, 4:03 PM

Please show me the preference in Gmail to turn off SSL; I'm pretty sure they removed it years ago. Facebook does have one hidden, which is a pretty bad practice since it allows session hijacking.

Parent5446 added a comment.Via ConduitApr 29 2013, 4:06 PM

Screenshots aren't working for me at the moment, but I see the option right now in my general settings for Gmail. (And here's the help page it links me to as well: http://support.google.com/mail/answer/74765?hl=en&ctx=mail).

brion added a comment.Via ConduitApr 29 2013, 4:09 PM

Ah, thankfully that option is entirely disabled for our corporate account, and only HTTPS is allowed. *shudder*

Guess I'm no longer surprised that people get their gmail accounts hijacked in China, eh?

Billinghurst added a comment.Via ConduitApr 29 2013, 4:51 PM

What is preventing us from 'leading' and turning it off? What are the consequences of turning it off and not giving choice?

gerritbot added a comment.Via ConduitAug 20 2013, 12:08 AM

Change 47089 merged by jenkins-bot:
Change secure login to use a user preference

https://gerrit.wikimedia.org/r/47089

gerritbot added a comment.Via ConduitAug 20 2013, 1:01 AM

Change 79960 had a related patch set uploaded by Demon:
Change secure login to use a user preference

https://gerrit.wikimedia.org/r/79960

gerritbot added a comment.Via ConduitAug 20 2013, 1:03 AM

Change 79963 had a related patch set uploaded by Demon:
Change secure login to use a user preference

https://gerrit.wikimedia.org/r/79963

gerritbot added a comment.Via ConduitAug 20 2013, 7:19 PM

Change 79963 merged by jenkins-bot:
Change secure login to use a user preference

https://gerrit.wikimedia.org/r/79963

gerritbot added a comment.Via ConduitAug 20 2013, 7:25 PM

Change 79960 merged by jenkins-bot:
Change secure login to use a user preference

https://gerrit.wikimedia.org/r/79960

Krinkle removed a project: Future-Release.Via WebNov 25 2014, 9:06 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.