Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious attack on Wikipedia – what we know and what we’re doing

wikimediafoundation.org

Post reply on HN
Print view View original

291–300 of 320 posts

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#291

Post by acdha »

SahAssar wrote: post #285
acdha wrote: post #241

Earlier quoted context omitted.

That’s not what MITM means. I get that you don’t like Cloudflare but voluntary use of a CDN isn’t a MITM any more than, say, Amazon is a MITM because you host on EC2.

Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain. That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basic…

If you don’t trust Cloudflare, don’t use them but there’s no meaningful security distinction between what they do and what AWS does: in both cases you have a vendor with the capability of violating your security and a promise that they won’t abuse that access.

This is why having a threat model is so important: it keeps you from wasting effort on things which sound like security but aren’t actually changing anything meaningful.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#292

Post by whenchamenia »

wwright wrote: post #284
the8472 wrote: post #279

Earlier quoted context omitted.

The political tends to encompass or at least subsume the moral and ethical aspects, as I tried to allude to with the realpolitik aspect. But again, this is just a tangent. The core argument is that it is best not to rely on providers that have the freedom to make political/moral decisions who they deal with because that freedom makes them susceptible to moral denial of service attacks. You are one moral outrage away…

I can see that mentality, but what I’m saying is that, personally, if I become a Nazi, I think I should be deplatformed.

Then who decides what is a Nazi? Deplatforming someone for their speech makes them one in my book. How far down do we go?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#293

Post by dangxiaopin »

nl wrote: post #270
gruez wrote: post #234

Earlier quoted context omitted.

>The cloudfare 8chan action was based on a direct link with multiple actual mass-shootings What is this "direct link" you speak of? Did the shooters plan/recruit/organize their attacks on 8chan?

There are multiple instances of them announcing them and implying they are follow-ups of previous discussions on 8chan. These include the Christchurch shootings, the Poway synagogue shooting and the El Paso Walmart shootin. The Christchurch shooter shared his Facebook stream to 8chan before the shooting started, and it was spread from there. The Poway shooter blamed/thanked 8chan for his views.

So FB's internet peers should depeer Facebook then in their routers, since the original material (the stream) was on FB? Or you prefer your justice selective?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#294

Post by floriol »

chillydawg wrote: post #222
blauditore wrote: post #137

Earlier quoted context omitted.

> Serving giant websites isn't all that hard if you're just spewing out SQL queries into html templates. It all scales in all directions with a properly thought through architecture. No. 1. Your comment makes it sound like Wikipedia is just, or mostly, serving read-only content, which is far from true. Yes, static read-only content is significantly easier to serve than dynamic, editable one, but Wikipedia is the latt…

I have, actually, worked on very large and interactive websites at the very core. Notably: betfair.com which has a very busy API and website and used to be something like a 1:10 write:read ratio with multiple clusters and layers of fancy caching to keep it all coherent down to millisecond scales. Wikipedia does not need to be globally consistent like Betfair does and the ratio of writes to reads is nothing like 10%,…

Hi, I am interested in this project. Could you please provide some minor detail about the architecture, like what framework was used for serving that many requests?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#295

Post by chillydawg »

floriol wrote: post #294
chillydawg wrote: post #222

Earlier quoted context omitted.

I have, actually, worked on very large and interactive websites at the very core. Notably: betfair.com which has a very busy API and website and used to be something like a 1:10 write:read ratio with multiple clusters and layers of fancy caching to keep it all coherent down to millisecond scales. Wikipedia does not need to be globally consistent like Betfair does and the ratio of writes to reads is nothing like 10%,…

Hi, I am interested in this project. Could you please provide some minor detail about the architecture, like what framework was used for serving that many requests?

Oracle and java and a whole lotta optimisations.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#296

Post by SahAssar »

acdha wrote: post #291
SahAssar wrote: post #285

Earlier quoted context omitted.

Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain. That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basic…

If you don’t trust Cloudflare, don’t use them but there’s no meaningful security distinction between what they do and what AWS does: in both cases you have a vendor with the capability of violating your security and a promise that they won’t abuse that access. This is why having a threat model is so important: it keeps you from wasting effort on things which sound like security but aren’t actually changing anything m…

There is a security distinction, and this has been shown by for example cloudbleed. Every step that has access to plaintext data is a potential attack vector and might be logging/leaking information.

There has also been times where cloudflare (when setup improperly as I mentioned in the previous comment) has misrepresented the security of a connection, as shown by https://www.theregister.co.uk/2016/07/14/cloudflare_investig...

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#297

Post by SahAssar »

cramforce wrote: post #289
SahAssar wrote: post #285

Earlier quoted context omitted.

Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain. That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basic…

The MITM can be avoided by using Signed Exchanges. https://developers.google.com/web/updates/2018/11/signed-exc...

That only works for static content, right?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#298

Post by SahAssar »

snazz wrote: post #288
SahAssar wrote: post #285

Earlier quoted context omitted.

Cloudflare is in between the client and the server, decrypting, rewriting and (if set up right) re-encrypting the request/response. It masquerades as the server by presenting a proper certificate for the domain even though it is not the entity that is actually controlling the domain. That to me sounds very much like MITM, although it is not a MITM attack since the entity controlling the domain opted into it, so basic…

Cloudflare’s business also depends on not messing with your traffic, right? It would certainly be easier for them to get your users’ content than for Amazon to do the same, but I think you still have to accept that risk with either. “Hypothetically being able to but not doing it” isn’t a whole lot of confidence if I were hosting some kind of shady website.

Sure, but since Cloudflare’s business is actively "messing" with all your traffic, all the time it's a smaller technical step to do it some more, and can also lead to accidents like cloudbleed. Every step that has access to unencrypted data is a potential attack vector or might be logging/leaking data.

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#299

Post by claudiawerner »

bitwize wrote: post #175
wwright wrote: post #157

Earlier quoted context omitted.

I think it’s somewhat misleading to refer to those who support genocide and child abuse as simply “political undesirables.”

It's not just supporting. Taking a neutral stance on censoring these things, or not being adequately proactive on hate speech, is now seen as condoning. You either censor your user base, or upstream will censor you. Gone are the days of "The net interprets censorship as damage and routes around it." The new policy is "The net interprets wrongthink as noise and filters it out."

> Gone are the days of "The net interprets censorship as damage and routes around it."

But it's clear that it matters just what's being censored. Surely you wouldn't say the same trite clever-sounding hackerspeak if we're talking about censorship of threats, assault and child pornography, would you?

Re: Malicious attack on Wikipedia – what we know and what we’re doing

#300

Post by [deleted] »

dangxiaopin wrote: post #148
lkoolma wrote: post #144

Earlier quoted context omitted.

After working with a few large corporations and their DDoS protection solutions, I did not have a good experience with Verisign, and they were not able to handle attacks or get things working. However, I have great experiences with Akamai and Cloudflare. I trust the people at Wikimedia will choose wisely. I would I have learned that Verisign has one of the worst BGP mitigation/scraping solutions out there. There are…

Any serious mitigation solution must be BGP based, not proxy. Besides its technical merits and convenience, it also minimizes the risk of a benevolent controller (e.g. Matthew Prince of Cloudflare) ruining your company, because it becomes your upstream provider only during the attacks. Otherwise the GRE tunnels are not in use. The IP addresses are still yours always. We used Verisign for mitigation of a 44Gbps volume…

[deleted]
Post reply on HN