Just a quick check-in on the status of SSL access to Wikipedia...
We've still got the old SSL proxy on http://secure.wikimedia.org which allows reaching most (hopefully all?) Wikimedia wikis over SSL on an alternate URL, but Wikimedia ops currently considers this an 'unsupported' service, which gives it a lower priority for fixes and keeps it off status.wikimedia.org.
The general problems with it can be summed up under: * SECURITY: most images and some scripts are still loaded over insecure channels; some MITM vectors may remain. * RELIABILITY: the actual proxy setup has performance/reliability & maintainability issues * HUMAN FACTORS: the alternate URLs are a pain for humans to deal with (and make maintenance harder as matching rules often need to be adjusted)
I believe Ryan's working on improvements on the actual proxy setup and maintenance.
It looks like styles and scripts are loaded fairly consistently through secure.wikimedia.org, either via load.php (ResourceLoader) or index.php (action=raw stuff using traditional importScript etc). There may be some bad site, user, or gadget scripts that explicitly load code or styles over non-SSL -- those if found should be fixed.
The only script I see loaded over non-SSL on a few random hits on English Wikipedia are hits to http://geoiplookup.wikimedia.org
Some bugzilla entries with relevant issues:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=16822 -- upload.wikimedia.org needs SSL interface
That shouldn't be super-hard to set up in theory -- it doesn't need to use the same domain name -- but of course it'll increase load on the SSL proxies.
It looks like pretty much all on-wiki images get loaded via http://upload.wikimedia.org currently, which can trigger mixed-mode content warnings in some browsers. While it in theory doesn't have a huge direct risk, images can be spied upon (attacker guesses what you're reading/doing based on what images you're loading) or sometimes replaced with alternate content (annoyance factor mostly).
* https://bugzilla.wikimedia.org/show_bug.cgi?id=27968 -- JavaScript (geoip lookups) included via plain HTTP on HTTPS sites
This ought to again be a matter of making sure the service is reachable over SSL and using it.
* https://bugzilla.wikimedia.org/show_bug.cgi?id=225 -- secure login on wikimedia via ssl
While many of our sites have added custom helper links to send people to the secure site from the login page, it's still optional, unofficial, and inconsistently shown.
* https://bugzilla.wikimedia.org/show_bug.cgi?id=20643 -- Serve SSL/HTTPS sites out of same domain names as HTTP access: https://en.wikipedia.org/
This'll need more work as it has to deal with the offsite proxies, multiple domains, etc. But it's been on the slate for a long time and we did some live experiments in 2007 that looked positive; if done it'll make the SSL views of the site friendlier to use, and smart session/cookie management could keep people form having to manually bounce themselves between SSL and non-SSL links.
-- brion vibber (brion @ pobox.com)
- https://bugzilla.wikimedia.org/show_bug.cgi?id=20643 -- Serve SSL/HTTPS
sites out of same domain names as HTTP access: https://en.wikipedia.org/
This'll need more work as it has to deal with the offsite proxies, multiple domains, etc. But it's been on the slate for a long time and we did some live experiments in 2007 that looked positive; if done it'll make the SSL views of the site friendlier to use, and smart session/cookie management could keep people form having to manually bounce themselves between SSL and non-SSL links.
This is the only reliable way of doing HTTPS, and will be the method I use to attack this problem. Basic SSL termination should work fairly well with this, but we will likely need to do some network trickery to make this work as we want. We don't want to run the SSL termination on the same hardware as our non-SSL proxies, as we'd have to optimize for two different workloads, so we are currently looking at doing this as a separate cluster.
I don't have a timeframe for completion, but I hope to work on this at some point soon.
- Ryan
On Mon, Apr 25, 2011 at 12:33 PM, Ryan Lane rlane32@gmail.com wrote:
SSL/HTTPS
sites out of same domain names as HTTP access: https://en.wikipedia.org/
This'll need more work as it has to deal with the offsite proxies,
multiple
domains, etc. But it's been on the slate for a long time and we did some live experiments in 2007 that looked positive; if done it'll make the SSL views of the site friendlier to use, and smart session/cookie management could keep people form having to manually bounce themselves between SSL
and
non-SSL links.
This is the only reliable way of doing HTTPS, and will be the method I use to attack this problem. Basic SSL termination should work fairly well with this, but we will likely need to do some network trickery to make this work as we want. We don't want to run the SSL termination on the same hardware as our non-SSL proxies, as we'd have to optimize for two different workloads, so we are currently looking at doing this as a separate cluster.
+1
I don't have a timeframe for completion, but I hope to work on this at some point soon.
Thanks for the update!
-- brion
Some bugzilla entries with relevant issues:
You missed https://bugzilla.wikimedia.org/show_bug.cgi?id=20852 "Setup internal wikis as https only", spawned from a previous thread of this list.
On Mon, Apr 25, 2011 at 4:44 PM, Platonides Platonides@gmail.com wrote:
Some bugzilla entries with relevant issues:
You missed https://bugzilla.wikimedia.org/show_bug.cgi?id=20852 "Setup internal wikis as https only", spawned from a previous thread of this list.
Good catch! They'll be easier to migrate on their own since there's a limited number.
-- brion
Secure server tracking bug goodness: https://bugzilla.wikimedia.org/show_bug.cgi?id=27946 (Tree Goodness: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=27946)
and all the open bugs in the SSL section: https://bugzilla.wikimedia.org/buglist.cgi?component=SSL%20related&resolution=---&product=Wikimedia&list_id=3897
wikitech-l@lists.wikimedia.org