Has anyone seen this?
http://codebutler.com/firesheep
A new Firefox plugin that makes it trivially easy to hijack cookies from a website that's using HTTP for login over an unencrypted wireless network. Wikipedia isn't in the standard installation as a site (lots of other sites, such as Facebook, Twitter, etc. are). We are using HTTP login by default, so i guess we're vulnerable as well (please say so if we're using some other kind of defensive mechanism i'm not aware of). Might it be a good idea to se HTTPS as the standard login? Gmail has been doing this since april this year.
-- Hay
On Mon, Oct 25, 2010 at 7:15 PM, Hay (Husky) huskyr@gmail.com wrote:
Has anyone seen this?
http://codebutler.com/firesheep
A new Firefox plugin that makes it trivially easy to hijack cookies from a website that's using HTTP for login over an unencrypted wireless network. Wikipedia isn't in the standard installation as a site (lots of other sites, such as Facebook, Twitter, etc. are). We are using HTTP login by default, so i guess we're vulnerable as well (please say so if we're using some other kind of defensive mechanism i'm not aware of). Might it be a good idea to se HTTPS as the standard login? Gmail has been doing this since april this year.
Firesheep works by snooping cookies, not login processes, and it's even without software like this incredibly easy to own someone. All it needs to own a Wikipedia admin or user is being in the same network as him. The admin in question doesn't even have to visit Wikipedia directly, there are enough pages hotlinking to upload.wikimedia.org, which should cause the browser to transmit session data.
If you're in need of using secure login, then you can use the secure webserver, but in the past it had some load issues.
Marco
2010/10/25 Marco Schuster marco@harddisk.is-a-geek.org:
The admin in question doesn't even have to visit Wikipedia directly, there are enough pages hotlinking to upload.wikimedia.org, which should cause the browser to transmit session data.
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)
To really fix the problem we would have to go HTTPS by default. I don't know what that means to our resource usage, as well as how it affects people who cannot use HTTPS for whatever reason.
By the way, there is a plugin for Firefox called HTTPS Everywhere, which will attempt to switch to HTTPS whenever possible for many sites. Wikipedia is among the supported sites.
https://www.eff.org/https-everywhere
The author of that plugin reached out to the foundation some months ago complaining that upload.wikimedia.org and commons.wikimedia.org had no HTTPS equivalents. I honestly don't know all of the security implications there -- upload.wikimedia.org seems okay (from a login hijacking perspective), since we never transmit any login credentials there, but we do with commons.wikimedia.org, and there's no HTTPS equivalent.
On 10/25/10 10:26 AM, Marco Schuster wrote:
On Mon, Oct 25, 2010 at 7:15 PM, Hay (Husky)huskyr@gmail.com wrote:
Has anyone seen this?
http://codebutler.com/firesheep
A new Firefox plugin that makes it trivially easy to hijack cookies from a website that's using HTTP for login over an unencrypted wireless network. Wikipedia isn't in the standard installation as a site (lots of other sites, such as Facebook, Twitter, etc. are). We are using HTTP login by default, so i guess we're vulnerable as well (please say so if we're using some other kind of defensive mechanism i'm not aware of). Might it be a good idea to se HTTPS as the standard login? Gmail has been doing this since april this year.
Firesheep works by snooping cookies, not login processes, and it's even without software like this incredibly easy to own someone. All it needs to own a Wikipedia admin or user is being in the same network as him. The admin in question doesn't even have to visit Wikipedia directly, there are enough pages hotlinking to upload.wikimedia.org, which should cause the browser to transmit session data.
If you're in need of using secure login, then you can use the secure webserver, but in the past it had some load issues.
Marco
On Mon, Oct 25, 2010 at 2:45 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
[snip] but we do with commons.wikimedia.org, and there's no HTTPS equivalent.
It's on secure.wikimedia.org, like all the other sites
https://secure.wikimedia.org/wikipedia/commons/wiki/Main_Page
-Chad
On Mon, Oct 25, 2010 at 1:15 PM, Hay (Husky) huskyr@gmail.com wrote:
A new Firefox plugin that makes it trivially easy to hijack cookies from a website that's using HTTP for login over an unencrypted wireless network.
It doesn't hijack login, it hijacks cookies, so we're only protected if we serve all pages over HTTPS. The major problem with this is that it's hard to serve different domains over HTTPS from the same server, because the server has to present the certificate before the client says what domain it's trying to log into. We could probably work around this somehow, e.g., have a different IP address for different second-level domains (which represent different virtual IP addresses of the same server) and then have a wildcard domain certificate for each second-level domain. In principle there are also spiffier ways to do it, like SNI or maybe subjectAltName:
http://en.wikipedia.org/wiki/Server_Name_Indication
But those might not be reliably usable yet.
Anyway, this is all doable in principle, yes. It will probably impose no significant processing overhead, CPUs are powerful enough today that TLS shouldn't be a big deal. (I recall hearing that Google noticed no increase in CPU usage after enabling TLS by default for Gmail.) But it's not necessarily trivial to set up. My impression is that the ops have "get proper TLS working" somewhere fairly low on their priority list.
On 25 October 2010 21:37, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
http://en.wikipedia.org/wiki/Server_Name_Indication But those might not be reliably usable yet.
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 1:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
[...] Anyway, this is all doable in principle, yes. It will probably impose no significant processing overhead, CPUs are powerful enough today that TLS shouldn't be a big deal. (I recall hearing that Google noticed no increase in CPU usage after enabling TLS by default for Gmail.) But it's not necessarily trivial to set up. My impression is that the ops have "get proper TLS working" somewhere fairly low on their priority list.
I for one only use secure.wikimedia.org; I would like to urge as a general course that the Foundation switch to a HTTPS by default strategy...
It was necessary for Gmail; it's a really good idea for WMF.
On Mon, Oct 25, 2010 at 5:26 PM, George Herbert george.herbert@gmail.com wrote:
I for one only use secure.wikimedia.org; I would like to urge as a general course that the Foundation switch to a HTTPS by default strategy...
It was necessary for Gmail; it's a really good idea for WMF.
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 Tue, Oct 26, 2010 at 10:01 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Gmail typically contains things like credit card numbers, passwords, maybe state secrets if you pick the right person .. at most you could compromise an admin account
.. or an account with checkuser or revdel-suppression, which provides access to all sorts of goodies like the above.
but anyone with these tools should know to only use the insecure site. yesterday was a problem, with secure down, meaning we needed to log into the insecure site in order to handle oversight requests. I guess I need to change my password now ;-(
-- John Vandenberg
On 25/10/10 23:26, George Herbert wrote:
I for one only use secure.wikimedia.org; I would like to urge as a general course that the Foundation switch to a HTTPS by default strategy...
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 :-)
On Mon, Oct 25, 2010 at 11:23 PM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 25/10/10 23:26, George Herbert wrote:
I for one only use secure.wikimedia.org; I would like to urge as a general course that the Foundation switch to a HTTPS by default strategy...
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 :-)
I don't want to be rude, but I'm a professional large website infrastructure architect for my paying day job.
The current WMF situation is becoming "quaint" - pros use secure.wikimedia.org, amateurs don't realize what they're exposing. By professional standards, we're not keeping up with professional industry expectations. It's not nuclear bomb secrets (cough) or missile designs (cough) but our internal function (in terms of keeping more sensitive accounts private and not hacked) and our ability to reassure people that they're using a modern and reliable site are falling slowly.
It's just CPU cycles. Those, of all the things today, are the cheapest by far... Please, hand me a tough problem, like needing database storage bandwidth that only SSD can match and yet will last for 5+ years reliably, or an N^2 or N^M or N! problem in the core logic, or even using a database to store all the file-like objects and not being able to clean up the database indexes. Those are hard. CPU time, raw cycles? Easy.
George Herbert wrote:
The current WMF situation is becoming "quaint" - pros use secure.wikimedia.org, amateurs don't realize what they're exposing. By professional standards, we're not keeping up with professional industry expectations. It's not nuclear bomb secrets (cough) or missile designs (cough) but our internal function (in terms of keeping more sensitive accounts private and not hacked) and our ability to reassure people that they're using a modern and reliable site are falling slowly.
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 Mon, Oct 25, 2010 at 11:59 PM, MZMcBride z@mzmcbride.com wrote:
George Herbert wrote:
The current WMF situation is becoming "quaint" - pros use secure.wikimedia.org, amateurs don't realize what they're exposing. By professional standards, we're not keeping up with professional industry expectations. It's not nuclear bomb secrets (cough) or missile designs (cough) but our internal function (in terms of keeping more sensitive accounts private and not hacked) and our ability to reassure people that they're using a modern and reliable site are falling slowly.
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
I have no objection to us serving http traffic, especially as default to logged-out users. There's security sensitivity, and then there's paranoia.
But I would prefer to move towards a logged-in user by default goes to secure connection model. That would include making secure a multi-system, fully redundantly supported part of the environment, or alternately just making https work on all the front ends.
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.
On Tue, Oct 26, 2010 at 6:24 PM, George Herbert george.herbert@gmail.com wrote:
.. But I would prefer to move towards a logged-in user by default goes to secure connection model. That would include making secure a multi-system, fully redundantly supported part of the environment, or alternately just making https work on all the front ends.
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.
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 10/26/2010 08:59 AM, MZMcBride wrote:
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.
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.
On 26.10.2010 09:36, Nikola Smolenski wrote:
On 10/26/2010 08:59 AM, MZMcBride wrote:
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.
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 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
There is no real massive load caused by https at runtime. There is however a significant chink of developer and sysadmin time needed to implement this and make it work.
For now, at least, the only optimisations that should be considered are those that make it easier all round.
Conrad
On 26 Oct 2010 08:44, "Daniel Kinzler" daniel@brightbyte.de wrote:
On 26.10.2010 09:36, Nikola Smolenski wrote:
On 10/26/2010 08:59 AM, MZMcBride wrote:
As Aryeh ...
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
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia....
Conrad Irwin <conrad.irwin <at> gmail.com> writes:
There is no real massive load caused by https at runtime. There is however a significant chink of developer and sysadmin time needed to implement this and make it work.
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 26/10/10 08:45, George Herbert wrote:
The current WMF situation is becoming "quaint" - pros use secure.wikimedia.org, amateurs don't realize what they're exposing.
I released a small patch today that let a user login with HTTPS. It is in trunk as r75585 :
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75585
The feature is optional with $wgSecureLogin (ala Aryeh, default false).
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.
wikitech-l@lists.wikimedia.org