Re: [Wikitech-l] Firesheep
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). -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
Conrad Irwin 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.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Tue, Oct 26, 2010 at 2:23 AM, Ashar Voultoiz 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 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 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
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" 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 wikitec...@lists.wikimedia ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Tue, Oct 26, 2010 at 6:24 PM, George Herbert
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 11:59 PM, MZMcBride 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. -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 11:23 PM, Ashar Voultoiz 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 william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
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 :-) -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Tue, Oct 26, 2010 at 10:01 AM, Aryeh Gregor 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 5:26 PM, 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... > > 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". ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 1:37 PM, Aryeh Gregor 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. -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On 25 October 2010 21:37, Aryeh Gregor 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 1:15 PM, Hay (Husky) 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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep / HTTPS by default
On Mon, Oct 25, 2010 at 2:45 PM, Neil Kandalgaonkar 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep / HTTPS by default
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) 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 -- Neil Kandalgaonkar (| ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
2010/10/25 Marco Schuster : > 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) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Firesheep
On Mon, Oct 25, 2010 at 7:15 PM, Hay (Husky) 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 -- VMSoft GbR Nabburger Str. 15 81737 München Geschäftsführer: Marco Schuster, Volker Hemmert http://vmsoft-gbr.de ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Firesheep
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
