Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

secure slower and slower

 

 

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


william.allen.simpson at gmail

Jul 1, 2009, 12:25 AM

Post #1 of 28 (767 views)
Permalink
secure slower and slower

I've been using secure for login for months now, and at first it seemed
pretty good, other than the inability to switch sites easily. (And always
editing links from secure.wikimedia.org/.../w to en.wikipedia.org/w, but
I've gotten used to doing that extra bit by hand.)

Anyway, it's just been a dog lately. During EDT daylight hours, it often
gives an error not able to access page, especially saving.

So, I've reverted to the old practice from the dog days of 2005-06, and
mostly edit in very off hours. Yet it slowed down drastically again!

The logs show a problem some hours ago. But nothing recent. Are there too
many secure users? I've found no way to see the status.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 1, 2009, 10:39 AM

Post #2 of 28 (735 views)
Permalink
Re: secure slower and slower [In reply to]

William Allen Simpson wrote:
> So, I've reverted to the old practice from the dog days of 2005-06, and
> mostly edit in very off hours. Yet it slowed down drastically again!
>
Here's my test log, edits queued and ready to go, demonstrating roughly how
long they take to come back and display:

;off hours last night
# 2009-07-01T06:54:45
# 2009-07-01T06:55:59 1 minute 14 seconds

;peak time today
# 2009-07-01T17:05:24
# 2009-07-01T17:06:17 53 seconds
# 2009-07-01T17:06:53 36 seconds
# 2009-07-01T17:08:00 1 minute 7 seconds
# 2009-07-01T17:08:40 40 seconds
# 2009-07-01T17:09:45 1 minute 5 seconds
# 2009-07-01T17:11:49 2 minutes 4 seconds
# 2009-07-01T17:12:44 55 seconds
# 2009-07-01T17:13:49 1 minute 5 seconds
# 2009-07-01T17:15:00 1 minute 11 seconds
# 2009-07-01T17:16:10 1 minute 10 seconds

In short, just as slow today at peak as off peak. Something wrong!


> The logs show a problem some hours ago. But nothing recent. Are there too
> many secure users? I've found no way to see the status.
>
https://wikitech.leuksman.com/view/Server_admin_log
linked from http://ganglia.wikimedia.org/ no longer works, bad certificate.

http://wikitech.wikimedia.org/view/Server_admin_log
Last entry at 16:13.

http://www.thewritingpot.com/wikistatus/
Fast/Fast, no changes since 19 hours ago




_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


stevagewp at gmail

Jul 2, 2009, 6:58 AM

Post #3 of 28 (732 views)
Permalink
Re: secure slower and slower [In reply to]

On Thu, Jul 2, 2009 at 3:39 AM, William Allen
Simpson<william.allen.simpson[at]gmail.com> wrote:
> William Allen Simpson wrote:
>> So, I've reverted to the old practice from the dog days of 2005-06, and
>> mostly edit in very off hours. Yet it slowed down drastically again!
>>
> Here's my test log, edits queued and ready to go, demonstrating roughly how
> long they take to come back and display:
>
> ;off hours last night
> # 2009-07-01T06:54:45
> # 2009-07-01T06:55:59 1 minute 14 seconds

For my own information, I tried secure, and made an edit. It wasn't
much slower than a normal non-secure edit (eg, 2 seconds). Or am I
missing something? What I do notice is IE spits up a "this page
contains nonsecure items" dialog on every single page...

Steve

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 4, 2009, 10:13 AM

Post #4 of 28 (707 views)
Permalink
Re: secure slower and slower [In reply to]

Steve Bennett wrote:
> For my own information, I tried secure, and made an edit. It wasn't
> much slower than a normal non-secure edit (eg, 2 seconds). Or am I
> missing something? What I do notice is IE spits up a "this page
> contains nonsecure items" dialog on every single page...
>
I tried again circa 06:00 and had pretty good throughput until about 11:30
today (a US holiday), when it fell off a cliff again. My guess is severely
overloaded in some fashion, or very sensitive to transient load elsewhere.

Yes, I had to turn off that warning in Firefox, too. Annoying.

All the Wiki links need to come through the secure server! That means a
re-write of every link. That would fix the current problem with doing
inter-wiki work, as interwiki links also come up http instead of https.

Obviously, links not to wikipedia/wikimedia should not be re-written, so
the external links go directly.

Is there anywhere that configuration and usage of secure is listed?

I really think this is a superb idea, but....

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


stevagewp at gmail

Jul 5, 2009, 7:19 PM

Post #5 of 28 (693 views)
Permalink
Re: secure slower and slower [In reply to]

On Sun, Jul 5, 2009 at 3:13 AM, William Allen
Simpson<william.allen.simpson[at]gmail.com> wrote:
> I really think this is a superb idea, but....

Really? Personally, security is of no concern to my use of Wikipedia,
but I guess I can imagine contexts where it might be.

Steve

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rememberthedot at gmail

Jul 6, 2009, 6:47 PM

Post #6 of 28 (680 views)
Permalink
Re: secure slower and slower [In reply to]

On Sun, Jul 5, 2009 at 8:19 PM, Steve Bennett<stevagewp[at]gmail.com> wrote:
> Really? Personally, security is of no concern to my use of Wikipedia,
> but I guess I can imagine contexts where it might be.

Theoretically, a man-in-the-middle attack could allow a malicious
person to hijack your session cookies and take over your account.
HTTPS makes this practically impossible.

--
Remember the dot
http://en.wikipedia.org/wiki/User:Remember_the_dot

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


stevagewp at gmail

Jul 6, 2009, 6:50 PM

Post #7 of 28 (680 views)
Permalink
Re: secure slower and slower [In reply to]

On Tue, Jul 7, 2009 at 11:47 AM, Remember the
dot<rememberthedot[at]gmail.com> wrote:
> Theoretically, a man-in-the-middle attack could allow a malicious
> person to hijack your session cookies and take over your account.
> HTTPS makes this practically impossible.

Yeah, and so what? OMG THEY MADE EDITS UNDER MY ACCOUNT.

Steve

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jul 6, 2009, 7:03 PM

Post #8 of 28 (680 views)
Permalink
Re: secure slower and slower [In reply to]

On Mon, Jul 6, 2009 at 9:47 PM, Remember the
dot<rememberthedot[at]gmail.com> wrote:
> Theoretically, a man-in-the-middle attack could allow a malicious
> person to hijack your session cookies and take over your account.

. . . but even if it mattered a little (like if you had an admin
account), nobody would bother. If you're going to go to the trouble
of setting up a malicious wireless access point or something, you're
probably going to be doing something profitable like spoofing Amazon
and stealing credit card numbers. It would be pretty stupid to take
that much risk and then blow your cover to mess with someone's
Wikipedia account.

But really -- have there been *any* confirmed incidents of MITMing an
Internet connection in, say, the past decade? Real malicious attacks
in the wild, not proof-of-concepts or white-hat experimentation? I'd
imagine so, but for all people emphasize SSL, I can't think of any
specific case I've heard of, ever. It's not something normal people
need to worry much about, least of all for Wikipedia.

(Not to mention, of course, that even with HTTP over SSL you're using
DNS unencrypted. Depending on how you access the site, it might be
possible for the attacker to simply stay on HTTP instead of switching
to HTTPS. The only indication you'd get is if you happen to notice
your URL bar is the normal color -- which you'd probably ignore as a
fluke misconfiguration, if you did notice.)

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


marco at harddisk

Jul 6, 2009, 10:19 PM

Post #9 of 28 (678 views)
Permalink
Re: secure slower and slower [In reply to]

On Tue, Jul 7, 2009 at 4:03 AM, Aryeh Gregor
<Simetrical+wikilist[at]gmail.com<Simetrical%2Bwikilist[at]gmail.com>
> wrote:

> But really -- have there been *any* confirmed incidents of MITMing an
> Internet connection in, say, the past decade? Real malicious attacks
> in the wild, not proof-of-concepts or white-hat experimentation? I'd
> imagine so, but for all people emphasize SSL, I can't think of any
> specific case I've heard of, ever. It's not something normal people
> need to worry much about, least of all for Wikipedia.
>

Public congresses, schools without protection for ARP spoofing (I got 0wned
this way myself), maybe corporate networks w/o proper network setup... they
all allow sniffing or in-line traffic manipulation.
Not that uncommon attacks, and when you know the colleague you do not like
is WP admin, you simply have to wait for him to visit WP logged in, and you
have either his pass or the cookies.

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[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jul 6, 2009, 11:00 PM

Post #10 of 28 (675 views)
Permalink
Re: secure slower and slower [In reply to]

On Tue, Jul 7, 2009 at 1:19 AM, Marco
Schuster<marco[at]harddisk.is-a-geek.org> wrote:
> Public congresses, schools without protection for ARP spoofing (I got 0wned
> this way myself), maybe corporate networks w/o proper network setup... they
> all allow sniffing or in-line traffic manipulation.
> Not that uncommon attacks, and when you know the colleague you do not like
> is WP admin, you simply have to wait for him to visit WP logged in, and you
> have either his pass or the cookies.

Yes, I'm aware all this is possible in theory. Even more trivially,
just set up a nice high-quality wireless hotspot and do whatever you
want with the traffic. But do you know of any time this has
*actually* *happened*? Where a malicious person has successfully
staged a MITM attack in the wild against a typical person using the
Internet, in the last decade or two?

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 7, 2009, 6:35 AM

Post #11 of 28 (665 views)
Permalink
Re: secure slower and slower [In reply to]

Aryeh Gregor wrote:
> Yes, I'm aware all this is possible in theory. Even more trivially,
> just set up a nice high-quality wireless hotspot and do whatever you
> want with the traffic. But do you know of any time this has
> *actually* *happened*? Where a malicious person has successfully
> staged a MITM attack in the wild against a typical person using the
> Internet, in the last decade or two?
>
*Yes.* Of course, I've long been involved in Internet security, so I'm
privy to information that is discussed more privately by the vetted....

Moreover, there have certainly been *claims* that Wikipedia accounts have
been hijacked. Folks have been adding ownership hashes to their user
pages, to be able to re-establish ownership.

You may be thinking about the various proofs of concept for MITM against
SSL, which is certainly possible (although impractical without financing).
But MITM against disclosing passwords and cleartext cookies is known.

A fairly public example that comes to mind -- for a considerably less well
known site than Wikipedia (but very popular in its day) -- was a MUD. An
Immortal account was hijacked, and through a known software bug,
privileges were escalated to God.

The miscreants actually wiped the entire user account database, causing
thousands to lose their accumulated belongings and status. The daily
backups were inconsistent, and after several days of examining the static
data for trapdoors and other problems, the site was restored with all
players having to start over....

Now, think about that being Wikipedia.... Does anybody really think the
software here is bug free? Defense in depth helps.

Some may not think that this site is critical, or valuable, or whatever.
But I joined this list back when ISP support calls were escalating
because of lag. Imagine the monetary cost to the world for complete site
failure or massive disruption.

Those with administrator or other privileges should use the secure server.
Heck, they should be prohibited from logging in by any other means.


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 7, 2009, 6:43 AM

Post #12 of 28 (665 views)
Permalink
Re: secure slower and slower [In reply to]

Marco Schuster wrote:
> Public congresses, schools without protection for ARP spoofing (I got 0wned
> this way myself), maybe corporate networks w/o proper network setup... they
> all allow sniffing or in-line traffic manipulation.
> Not that uncommon attacks, and when you know the colleague you do not like
> is WP admin, you simply have to wait for him to visit WP logged in, and you
> have either his pass or the cookies.
>
(heavy sigh) The use of disclosing passwords (and plaintext cookies) is the
bane of Internet security. Getting the secure server working is important.

===

Meantime, here's an error message that happens frequently during editing:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /wikipedia/en/w/index.php.

Reason: Error reading from remote server

===

I get a similar error sometimes on Preview or just reading a page:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /wikipedia/en/wiki/Wikipedia talk:Biographies of living persons.

Reason: Error reading from remote server


_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


stevagewp at gmail

Jul 7, 2009, 9:11 PM

Post #13 of 28 (656 views)
Permalink
Re: secure slower and slower [In reply to]

On Tue, Jul 7, 2009 at 11:35 PM, William Allen
Simpson<william.allen.simpson[at]gmail.com> wrote:
> Some may not think that this site is critical, or valuable, or whatever.

That's a horrible strawman argument. "Some" simply think that the
amount of damage that can be caused by hijacking a non-admin account
is fairly low. Maybe for admins the risk is higher. Pretty much all
damage is reversible though.

Steve

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 8, 2009, 4:13 AM

Post #14 of 28 (649 views)
Permalink
Re: secure slower and slower [In reply to]

Steve Bennett wrote:
> On Tue, Jul 7, 2009 at 11:35 PM, William Allen
> Simpson<william.allen.simpson[at]gmail.com> wrote:
>> Some may not think that this site is critical, or valuable, or whatever.
>
> That's a horrible strawman argument. "Some" simply think that the
> amount of damage that can be caused by hijacking a non-admin account
> is fairly low. Maybe for admins the risk is higher. Pretty much all
> damage is reversible though.
>
You are the person that I'd had in mind, based on your actual comment:

# Yeah, and so what? OMG THEY MADE EDITS UNDER MY ACCOUNT.
#

Thus, not a strawman at all....

However, (assuming you are a developer) that makes 2 developers indicating
this is not a priority. Please remove the link to the secure server on the
login page, so that common editors are not confused by it, thinking that
this is a supported service....

I've given you some timing notes, and some error messages. Let us all know
about future improvements, should they ever happen.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


agarrett at wikimedia

Jul 8, 2009, 5:47 AM

Post #15 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

On 08/07/2009, at 12:13 PM, William Allen Simpson wrote:
> However, (assuming you are a developer) that makes 2 developers
> indicating
> this is not a priority. Please remove the link to the secure server
> on the
> login page, so that common editors are not confused by it, thinking
> that
> this is a supported service....


Expanding the role of secure access to the site for privileged users
is one of our ongoing priorities, you should not take the word of two
random people involved in MediaWiki development (nor mine, for that
matter) on a server issue such as that.

If you want something done other than endless argument over the use of
SSL on Wikimedia projects, you should file a bug in bugzilla, and
assign it to Brion (brion[at]wikimedia.org) or Rob
(rhalsell[at]wikimedia.org), who are actually maintaining that part of
the site.

--
Andrew Garrett
agarrett[at]wikimedia.org
http://werdn.us




_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


william.allen.simpson at gmail

Jul 8, 2009, 6:02 AM

Post #16 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

Andrew Garrett wrote:
> Expanding the role of secure access to the site for privileged users
> is one of our ongoing priorities, you should not take the word of two
> random people involved in MediaWiki development (nor mine, for that
> matter) on a server issue such as that.
>
Thank you. I'd no idea these were "random" people, as I've seen
considerable traffic about development from each. It seemed they were
writing authoritatively. And Brion didn't respond.


> If you want something done other than endless argument over the use of
> SSL on Wikimedia projects, you should file a bug in bugzilla, and
> assign it to Brion (brion[at]wikimedia.org) or Rob
> (rhalsell[at]wikimedia.org), who are actually maintaining that part of
> the site.
>
Will do. Was unaware bugzilla was being used for server and operational
issues, those used to be the province of this list.

And I'm willing to help as much as I can....

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jul 8, 2009, 6:05 AM

Post #17 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

2009/7/7 Aryeh Gregor <Simetrical+wikilist[at]gmail.com>:

> But really -- have there been *any* confirmed incidents of MITMing an
> Internet connection in, say, the past decade?  Real malicious attacks
> in the wild, not proof-of-concepts or white-hat experimentation?  I'd
> imagine so, but for all people emphasize SSL, I can't think of any
> specific case I've heard of, ever.  It's not something normal people
> need to worry much about, least of all for Wikipedia.


Nope. The SSL threat model is completely arse-backwards. It assumes
secure endpoints and a vulnerable network. Whereas what we see in
practice is Trojaned endpoints and no-one much bothering with the
network.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


gmaxwell at gmail

Jul 8, 2009, 7:45 AM

Post #18 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

On Wed, Jul 8, 2009 at 9:05 AM, David Gerard<dgerard[at]gmail.com> wrote:
> 2009/7/7 Aryeh Gregor <Simetrical+wikilist[at]gmail.com>:
>
>> But really -- have there been *any* confirmed incidents of MITMing an
>> Internet connection in, say, the past decade?  Real malicious attacks
>> in the wild, not proof-of-concepts or white-hat experimentation?  I'd
>> imagine so, but for all people emphasize SSL, I can't think of any
>> specific case I've heard of, ever.  It's not something normal people
>> need to worry much about, least of all for Wikipedia.
>
> Nope. The SSL threat model is completely arse-backwards. It assumes
> secure endpoints and a vulnerable network. Whereas what we see in
> practice is Trojaned endpoints and no-one much bothering with the
> network.

Actually, there is a lot of screwing with the network.

For instance, take the UK service providers surreptitiously modifying
Wikipedia's responses on the fly to create a fake 404 when you hit
particular articles.

I believe it's a common practice for US service providers to sell
information feeds about user's browsing data (believe because I know
it's done, but don't have concrete information about how common it
is). Your use of Wikipedia likely has less privacy than your use of a
public library.

SSL kills these attacks dead.

People whom try to read via Tor to avoid the above mentioned problems
subject themselves to naughty activities by unscrupulous exit
operators. MITM activities by Tor exit operators are common and well
documented. SSL would remove some of the incentive to use Tor (since
your local network/ISP could no longer spy on you if you used SSL) and
would remove most of Tor's grievous hazard for those who continue to
use it to read.

There are some truly nasty things you can do with an enwiki admin
account. They can be undone, sure, but a lot of damage can be done.
They are obvious enough, and have been discussed in backrooms enough
that I don't think I'll do much harm by listing a few of them:

(1) By twiddling site JS you can likely knock any site off the
internet by scripting clients to connect to the sites frequently.
Although this can be deactivated once it was discovered, due to
caching it would hang around for a while. Well timed even a short
outage could cause significant dollar value real damage.

(2) You could script clients to kick users to a malware installer.
Again, it could be quickly undone, but a lot of damage could be caused
with only a few minutes of script placement. Generally you could use
WP as a nice launching ground for any kind of XSS vulnerability that
you're already aware of.

Any of these JS attacks could be enhanced by only making them
effective for anons, reducing their visibility, and by making the JS
modify the display of the Mediawiki: pages to both hide the bad JS
from users and to make it impossible to remove without disabling
client JS. Provided your changes didn't break the site, I'd take a
bet that you could have a malware installer running for days before it
was discovered.

(3) You could rapidly merge page histories for large numbers of
articles, converting their histories into jumbled messes. I don't
believe we yet have any automated solution to fix that beyond "restore
the site from backups".

(4) Any admin account can be used to capture bureaucrat and/or
checkuser access by injecting user JS to one of these users and using
it to steal their session cookie (unless the change to SUL stopped
this, but I don't see how it could have; even if so you could remote
pilot them). With checkuser access you can quickly dump out decent
amounts of private data. The leak of private data can never be undone.
(or, alternatively, you can just MTIM a real steward, checkuser, or
bureaucrat (say, at wikimania or a wiki meetup :) ) and get their
access directly).


These are just a few things… I'm sure if you think creatively you can
come up with more. The use of SSL makes attacks harder and some types
of attack effectively impossible. It should be considered important.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jul 8, 2009, 7:50 AM

Post #19 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

2009/7/8 Gregory Maxwell <gmaxwell[at]gmail.com>:
> On Wed, Jul 8, 2009 at 9:05 AM, David Gerard<dgerard[at]gmail.com> wrote:

>> Nope. The SSL threat model is completely arse-backwards. It assumes

> Actually, there is a lot of screwing with the network.
> For instance, take the UK service providers surreptitiously modifying
> Wikipedia's responses on the fly to create a fake 404 when you hit
> particular articles.


*cough* OK, I'm completely wrong :-)


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Jul 8, 2009, 7:57 AM

Post #20 of 28 (647 views)
Permalink
Re: secure slower and slower [In reply to]

On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwell<gmaxwell[at]gmail.com> wrote:
> (3) You could rapidly merge page histories for large numbers of
> articles, converting their histories into jumbled messes.  I don't
> believe we yet have any automated solution to fix that beyond "restore
> the site from backups".
>

Quite possibly the only sysop activity (afaik?) that cannot be reversed
yet. Merging the top-revisioned articles on enwiki in less than a minute
before anyone catches on (certainly doable) would cause such a
massive clusterfuck. Without relying on a backup to restore to, it would
require inspection of almost every edit in that page's history to make sure
they get restored properly.

I've thought of this issue before, and it's probably the single most damaging
thing that could be done with a sysop account (to the wiki itself, this isn't
including JS subtleties and external resources).

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


scs at eskimo

Jul 8, 2009, 8:44 AM

Post #21 of 28 (645 views)
Permalink
Re: secure slower and slower [In reply to]

Gregory Maxwell wrote:
> For instance, take the UK service providers surreptitiously modifying
> Wikipedia's responses on the fly to create a fake 404 when you hit
> particular articles.

Urk. (Can someone cite the details?)

> (2) You could script clients to kick users to a malware installer...
> ...and to make it impossible to remove without disabling client JS.

Remind me why client-side JavaScript is a good idea?
(Boy, am I glad I use NoScript.)

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jul 8, 2009, 9:37 AM

Post #22 of 28 (646 views)
Permalink
Re: secure slower and slower [In reply to]

2009/7/8 Steve Summit <scs[at]eskimo.com>:
> Gregory Maxwell wrote:

>> For instance, take the UK service providers surreptitiously modifying
>> Wikipedia's responses on the fly to create a fake 404 when you hit
>> particular articles.

> Urk.  (Can someone cite the details?)


http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


dgerard at gmail

Jul 8, 2009, 11:07 AM

Post #23 of 28 (643 views)
Permalink
Re: secure slower and slower [In reply to]

2009/7/8 David Gerard <dgerard[at]gmail.com>:
> 2009/7/8 Steve Summit <scs[at]eskimo.com>:
>> Gregory Maxwell wrote:

>>> For instance, take the UK service providers surreptitiously modifying
>>> Wikipedia's responses on the fly to create a fake 404 when you hit
>>> particular articles.

>> Urk.  (Can someone cite the details?)

> http://en.wikipedia.org/wiki/Internet_Watch_Foundation_and_Wikipedia


The interesting thing, by the way, is that (a) we spotted the
interception *immediately* (b) we spotted a later interception, a
month or two later, immediately as well - and the IWF denied
involvement in the second interception when we asked them directly
(and we have no reason not to believe them on this), suggesting the
ISPs in question were testing the CleanFeed filter to see how it
affected a major site (we don't actually know the reason, that's the
most plausible thing anyone could come up with).

This suggests the best thing we can do about this style of censorship
is default SSL for all. Which won't be cheap, but would serve our
editors well.


- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Simetrical+wikilist at gmail

Jul 8, 2009, 1:04 PM

Post #24 of 28 (641 views)
Permalink
Re: secure slower and slower [In reply to]

On Wed, Jul 8, 2009 at 7:13 AM, William Allen
Simpson<william.allen.simpson[at]gmail.com> wrote:
> However, (assuming you are a developer) that makes 2 developers indicating
> this is not a priority.  Please remove the link to the secure server on the
> login page, so that common editors are not confused by it, thinking that
> this is a supported service....

Steve Bennett is not a developer (as far as I can tell). And while I
am a developer, I'm not a sysadmin and have nothing to do with
configuring or maintaining the secure server. As a general rule, I've
found that with open-source stuff you usually can't tell apart the
decision-makers from random opinionated hangers-on without actually
doing research or asking . . . it's kind of annoying, but fun! :)

For what it's worth, I also don't think SSL is worthless. I don't
personally see any reason to go out of my way to use it, and think
it's a little odd for someone else to do that given the marginal
benefit it would provide by any metric. But I'd definitely agree that
if it could be enabled for all Wikipedia users by *default* that would
be great. A small benefit times millions of users can be a very big
benefit. An ideal Internet would encrypt *and* sign all
communications with no opt-out. (One of the things I'm looking
forward to if Google Wave takes off!)

On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwell<gmaxwell[at]gmail.com> wrote:
> Provided your changes didn't break the site, I'd take a
> bet that you could have a malware installer running for days before it
> was discovered.

What, on enwiki? I'd bet ten minutes before it's noticed someone
using NoScript configured to prompt about cross-site loads or
something. (Maybe not if it just includes an image for DoS purposes,
but then the target would notice soon enough, you'd think . . .)

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


marco at harddisk

Jul 8, 2009, 3:15 PM

Post #25 of 28 (641 views)
Permalink
Re: secure slower and slower [In reply to]

On Wed, Jul 8, 2009 at 10:04 PM, Aryeh Gregor
<Simetrical+wikilist[at]gmail.com<Simetrical%2Bwikilist[at]gmail.com>
> wrote:

> On Wed, Jul 8, 2009 at 10:45 AM, Gregory Maxwell<gmaxwell[at]gmail.com>
> wrote:
> > Provided your changes didn't break the site, I'd take a
> > bet that you could have a malware installer running for days before it
> > was discovered.
>
> What, on enwiki? I'd bet ten minutes before it's noticed someone
> using NoScript configured to prompt about cross-site loads or
> something.


And if you're not a real technical expert who sees "aha, the site where the
js comes from is surely NOT wikipedia", it doesn't help anyone. People click
away these warnings very often and don't bother to actually read them...
this is something most people forget in security themes.

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[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

First page Previous page 1 2 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.