Page MenuHomePhabricator

Login and account creation should be by secure http.
Closed, ResolvedPublic

Description

Author: hissongcle

Description:
When I login or, even worse, when I create an account, I do so in an unsecure environment. There's no automatic encryption; the site reads "http" not "https". It's all well and good to urge people to make a secure password, but I, for one, am unwilling to trust a secure password to vagaries of an unencrypted web.


Version: unspecified
Severity: enhancement

Details

Reference
bz12884

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
InvalidNone
DeclinedTgr
ResolvedNone
ResolvedNone
ResolvedRyanLane
ResolvedNone
ResolvedReedy
ResolvedNone
ResolvedNone
ResolvedCatrope
ResolvedNone
ResolvedNone
InvalidNone
ResolvedNone
DeclinedNone
ResolvedNone
Resolved demon
Resolvedkostajh
OpenNone
OpenNone
ResolvedNone
OpenNone
ResolvedShivanshbindal9
ResolvedShivanshbindal9
OpenNone
ResolvedShivanshbindal9
ResolvedShivanshbindal9
ResolvedShivanshbindal9
OpenNone
DuplicateNone
Resolved JMinor
OpenBUG REPORTNone
StalledNone
Resolvedkaldari
Resolved Niharika
Resolved Niharika
ResolvedBawolff
ResolvedBawolff
DeclinedNone
Resolvedkaldari
Resolved Niharika
ResolvedMusikAnimal
Resolved Niharika
Resolved Niharika
ResolvedReedy
ResolvedMaxSem
ResolvedJohan
OpenNone
Resolved csteipp
ResolvedNone
ResolvedAnomie
ResolvedJoe
ResolvedJoe
Resolvedhashar
Resolvedbd808
ResolvedAnomie
ResolvedKrinkle
ResolvedNone
ResolvedJanZerebecki
ResolvedKrinkle
ResolvedTgr
DeclinedNone
OpenNone
OpenNone
ResolvedNone
ResolvedNone
ResolvedTgr
DeclinedNone
Resolvedsbassett
Resolvedsbassett
ResolvedTgr
ResolvedAndrew

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:04 PM
bzimport set Reference to bz12884.
bzimport added a subscriber: Unknown Object (MLST).

Isn't there an address where you could log in to Wikipedia through HTTPS? INVALID?

Yeah, I think DefaultSettings.php checks if HTTPS is available to be used for such actions. If it is not available, it will fallback to HTTP.

hissongcle wrote:

(In reply to comment #0)

When I login or, even worse, when I create an account, I do so in an unsecure
environment. There's no automatic encryption; the site reads "http" not
"https". It's all well and good to urge people to make a secure password, but
I, for one, am unwilling to trust a secure password to vagaries of an
unencrypted web.

(In reply to comment #2)

Yeah, I think DefaultSettings.php checks if HTTPS is available to be used for
such actions. If it is not available, it will fallback to HTTP.

This didn't work for me. My browser (Safari) fully supports https.

robert wrote:

(In reply to comment #3)

(In reply to comment #2)

Yeah, I think DefaultSettings.php checks if HTTPS is available to be used for
such actions. If it is not available, it will fallback to HTTP.

This didn't work for me. My browser (Safari) fully supports https.

I believe the comment #2 is refering to server side availability of HTTPS , as opposed to client side. Not all servers have it installed as there are potential patent issues and it is difficult to configure (plus getting an SSL key with one of the main providers often costs a hefty ammount of money).

(In reply to comment #2)

Yeah, I think DefaultSettings.php checks if HTTPS is available to be used for
such actions. If it is not available, it will fallback to HTTP.

According to http://us.php.net/reserved.variables:

'HTTPS'

Set to a non-empty value if the script was queried through the HTTPS protocol.

So $_SERVER['HTTPS'] is only set if the user specifically types in https://... Default settings checks if the browser requested https, not if the server is capable of https.

So $_SERVER['HTTPS'] is only set if the user specifically types in https://

Or, if the software uses a https:// link or form action! I rechecked and to my enthusiasm, it appears that MediaWiki (even its Wikimedia installation) is "not" using an HTTPS address for the action of loing/registration forms. I guess it would be a good idea to add another global setting variable in LocalSettings.php so people who do have HTTPS server up and running can force MediaWiki to use it for logins.

Even if the login/registration page were set up to use SSL you would still be vulnerable to sidejacking (http://arstechnica.com/news.ars/post/20080201-report-google-mail-vulnerable-to-sidejacking-despite-ssl.html). You probably have to force the whole site into SSL, which you can do by manually setting $wgServer in LocalSettings. For a WikiMedia wiki, yeah you can use the link in comment #7.

Is this request for the functionality (which was introduced by hashar in r75585) or for an implementation on Wikimedia wikis? If it's the former, this bug is resolved. If it's the latter, this bug probably needs to be split (or at least have a clarified bug summary / component).

This bug is also possibly a duplicate of bug 225.

Issues are already split:

bug 12884 (this one) is for the MediaWiki product. The code I wrote is pending revision and might or might not be included in 1.17. Nonetheless, I think it should be closed as FIXED.

bug 225 is an operation on WMF cluster.

Support for an alternate URL schema is a different matter, might need a new enhancement bug.

Marking fixed.