On Tue, Oct 26, 2010 at 2:23 AM, Ashar Voultoiz hashar+wmf@free.fr 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
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 george.herbert@gmail.com wrote:
Any "login" should be protected. The casual "eh" attitude here is unprofessional, as it were. The nature of the site means that this isn't something I would rush a crash program and redirect major resources to fix immediately, but it's not something to think of as desirable and continue propogating for more years.
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 smolensk@eunet.rs wrote:
For a maximum security and minimal overhead, let the login always be over https. If a logged-in user is an admin or higher, use https for everything. Expand to all editors if easily possible.
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.