2010/10/25 Marco Schuster <marco(a)harddisk.is-a-geek.org>rg>: Actually it won't, because upload.wikimedia.org is a cookieless domain. As opposed to other domains like wikipedia.org and wikibooks.org , wikimedia.org doesn't get domain-wide cookies either, because there are wikimedia.org subdomains not controlled by WMF. Roan Kattouw (Catrope)

On Mon, Oct 25, 2010 at 2:45 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote: It's on secure.wikimedia.org, like all the other sites https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page -Chad

On 25 October 2010 21:37, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: Per the article, approximately no-one uses SNI as yet because IE on XP will never be capable of it. (Firefox and Chrome on XP are.) So they'd need to be dropped back to the present situation and security. - d.

On Mon, Oct 25, 2010 at 5:26 PM, George Herbert <george.herbert(a)gmail.com> wrote: Gmail typically contains things like credit card numbers, passwords, maybe state secrets if you pick the right person, lots of stuff that attackers would be highly motivated to steal. But there's basically nothing of significance you could get from taking over someone's Wikipedia account -- at most you could compromise an admin account (which is hard on open wi-fi, unless you get really lucky or are at a Wikimedia conference) and cause a small amount of havoc before getting desysopped and having all your vandalism undone. No profit motive, not likely to happen much. So I'd classify this as "nice to have", but not "a really good idea".

On 25/10/10 23:26, George Herbert wrote: HTTPS means full encryption, that is either : - a ton of CPU cycles : those are wasted cycles for something else. - SSL ASIC : costly, specially given our gets/ bandwidth levels Meanwhile, use secure.wikimedia.org :-) -- Ashar Voultoiz

George Herbert wrote: I don't understand what you're saying here. Most Wikimedia content is intended to be distributed openly and widely. Certainly serving every page view over HTTPS makes no sense given the cost vs. benefit currently. As Aryeh notes, even those who act in an editing role (rather than in simply a reader role) don't generally have valuable accounts. The "pros" you're talking about are free to use secure.wikimedia.org (which is already set up and has been for quite some time). If there were a secure site alternative, I think you'd have a point. As it stands, I don't see what's very quaint about this situation. It'd be great to one day have http://en.wikipedia.org be the same as https://en.wikipedia.org with the only noticeable difference being the little lock icon in your browser. But there are a finite amount of resources and this really isn't and shouldn't be a high priority. If the goal is to reassure people that they're using a "modern and reliable site," there are lot of other features that could and should be implemented first in my view, though the goal itself seems a bit dubious in any case. MZMcBride

On Tue, Oct 26, 2010 at 6:24 PM, George Herbert <george.herbert(a)gmail.com> wrote: I agree. Even if we still do drop users back to http after authentication, and the cookies can be sniffed, that is preferable to having authentication over http. People often use the same password for many sites. Their password may not have much value on WMF projects ('at worst they access admin functions'), but it could be used to access their gmail or similar. -- John Vandenberg

On 26.10.2010 09:36, Nikola Smolenski wrote: This sounds like a sensible compromise. It protects the sensitive bits, and doesn't cause massive load on https handling. I would very much like to see this on the official roadmap. By the way... where's the official road map? -- daniel

Conrad Irwin <conrad.irwin <at> gmail.com> writes: Secure login in itself shouldn't require reconfiguration of the SSL architecture, though. The login form could simply redirect to a page on the secure server, and use the image cookie method already in use for global logins. That would take care of password stealing without requiring extensive configuration or development efforts, and cookie stealing in itself is not that much of an issue: only admin sessions are worth stealing, and the chances of an attacker happening to be next to an admin on open wifi are very small. (Sure, it would be better to provide a decent https interface and require them to use it, because script injection is not a good thing, but apparently it won't happen anytime soon, and we shouldn't hold back on implementing secure login because of that.)

On Tue, Oct 26, 2010 at 2:23 AM, Ashar Voultoiz &lt;hashar+wmf(a)free.fr&gt; wrote: HTTPS uses very few CPU cycles by today's standards. See here: """ In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. """ http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html On Tue, Oct 26, 2010 at 3:24 AM, George Herbert &lt;george.herbert(a)gmail.com&gt; wrote: It's not desirable, but given limited resources, undesirable things are inevitable. I don't know what the sysadmins are spending their time on, but presumably it's something that they feel takes precedence over this. (None has commented so far here . . .) On Tue, Oct 26, 2010 at 3:36 AM, Nikola Smolenski &lt;smolensk(a)eunet.rs&gt; wrote: This is an improvement, but not an ideal solution, because a MITM could just change the HTTPS login link to be HTTP instead, and translate the request to HTTPS themselves so Wikimedia doesn't see the difference. HTTPS for everything makes more sense, ideally with Strict-Transport-Security.