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
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
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 &
* 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
It looks like styles and scripts are loaded fairly consistently through
, 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:
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
It looks like pretty much all on-wiki images get loaded via
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).
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.
-- 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
-- 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
-- brion vibber (brion @ pobox.com