Mailing List Archive

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
Re: Firesheep [ In reply to ]
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
--
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
Re: Firesheep [ In reply to ]
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)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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.


--
-george william herbert
george.herbert@gmail.com

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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".

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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: Firesheep [ In reply to ]
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 william herbert
george.herbert@gmail.com

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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: Firesheep [ In reply to ]
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.


--
-george william herbert
george.herbert@gmail.com

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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: Firesheep [ In reply to ]
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

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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: Firesheep [ In reply to ]
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....
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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.)


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Firesheep [ In reply to ]
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