439299 - If you're going to do security, do it right

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: User management, task)

Description

[[e-mail]]

Some idiot decided to redirect only the above URL to https but all other URLs under devmo (and also wikimo, but I can't find a component for that) to http so not only does password manager not fill in my saved password any more (which I admit is a one-time annoyance) but I now get a broken lock icon because all the scripts (and other content) get redirected back to http.

In order of preference I would like to see
a) no https to http redirections except for the logout page
b) always redirect to https
c) never redirect to https
d) some sort of kludge so at least the login pages aren't broken

Comment 1

[Reed Loden [:reed]]

"Some idiot" would be me, and I was told that I couldn't put the entire wikis behind SSL due to load reasons, but I still wanted to protect users' passwords, so I did the next best thing by making pages that use a password use HTTPS. The only option feasible in your list that works with both my restrictions and security wants is D), and I might be able to fix the broken lock problem. Not a high priority, though.

Comment 2

[Mike Shaver (:shaver emeritus)]

Are the credentials in the cookies generated by mediawiki subject to session theft?  If so, there's only marginal gain in having the u/p encrypted if the rest isn't.

But the login pages shouldn't be broken-lock -- if they are, then there's _no_ gain to this change!  We should at least be loading the resources used by the login page via https, obviously.  (Was this tested on a staging server somewhere before being deployed?)

Comment 3

[Reed Loden [:reed]]

(In reply to comment #2)
> Are the credentials in the cookies generated by mediawiki subject to session
> theft?  If so, there's only marginal gain in having the u/p encrypted if the
> rest isn't.

I'm not sure I understand the question.... Do you mean are the cookies set to HTTPS only or something?

> But the login pages shouldn't be broken-lock -- if they are, then there's _no_
> gain to this change!  We should at least be loading the resources used by the
> login page via https, obviously.

I agree. I'll get the skin to use the appropriate protocol (http vs. https) very soon. Not high on my priority list, though, as it "works" (for some definition of works) currently. If you feel you'd rather see the entire change reverted until such time (later this week, most likely) that I can fix the skin, then that can be done. Otherwise, it will get fixed soon.

>  (Was this tested on a staging server
> somewhere before being deployed?)

Yes (as seen in bug 397125), but it's possible I didn't notice the broken lock, since it's not obvious to notice nowadays.

Comment 4

[[e-mail]]

(In reply to comment #3)
>it's possible I didn't notice the broken lock, since it's not obvious to notice nowadays.
It's not obvious that the lock is broken, or that there is a lock at all?

Comment 5

[Mike Shaver (:shaver emeritus)]

I mean "if an attacker can see the cookie, do they need the u/p?". I don't know how the cookie is encoded.  (I suspect they don't need the u/p, just like in bugzilla, which is why all of bugzilla is on https and not just the login URLs.) 

Yes, we do want this reverted as soon as possible; I'm disappointed that it'll be at some unspecified "later this week" time, when it was put in place without proper testing or approval from the app owners.  It doesn't work right now, for the definition of work that matters -- increased security versus pure http -- and it gives a false sense of security through the https: URL prefix, which means that it is worse than before the https changes were made at all.

It wasn't obvious to me from 397125 that it was tested on staging or another production-like environment, since it broke production twice (once due to the :80 thing and once due to the bad pattern leading to an "http" injected into the URL in certain places).  "A random installation of the MDC software" isn't staging, for exactly these reasons.

Comment 6

[Reed Loden [:reed]]

Swapped back to http for now. devmo has its own issues to deal with (bug 441289), but they both just need some skin fixes to use the correct protocol. However, until that's done, bug 397125 has been backed out. I'll revisit this in the future.