https://bugzilla.wikimedia.org/show_bug.cgi?id=47832
Ryan Lane <rlan...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rlan...@gmail.com
--- Comment #8 from Ryan Lane <rlan...@gmail.com> ---
Well, this bug seems a little politically charged...
Are we considering the users that will completely lose access when this action
occurs? Some countries completely block HTTPS, but allow HTTP. I dislike
eavedropping by governments, but I also dislike not providing access to people
too.
The rough steps ops was looking at (but hadn't fully decided upon) were:
1. Redirect logged in users to HTTPS. Protecting credentials is important. I
think forcing HTTPS here is sane.
2. Expand the HTTPS infrastructure, moving the terminators directly onto the
frontends. Put in engineering effort so that we can distribute the SSL cache
and switch to a round robin load balancer rather than the source hash one we're
currently using.
3. Slowly soft-enable HTTPS for anons, by default, for smaller projects moving
towards soft-enabling it on the larger projects as well. We can do this by
using rel=canonical, with the https link being given.
4. Consider force enabling HTTPS via redirects. This action is difficult. We'll
lock out users with this action. I think this should be a community decision
(maybe per-wiki) and isn't up for discussion on bugzilla.
5. If HTTPS is force enabled, then enable HSTS to protect against downgrade
attacks.
Maybe we could offer a warning to folks on HTTP, saying that they should
consider using HTTPS and that their communications can be monitored? Of course,
we shouldn't do this until we can properly handle all anon traffic on HTTPS.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
