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)