Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Alec Muffett]

On 16 June 2017 at 19:12, Faidon Liambotis  wrote:

> hi Alec,


Hi Faidon!


On Wed, Jun 14, 2017 at 04:12:49PM +0100, Alec Muffett wrote:
> > I'd love to know more about the security issues in particular.  Do please
> > tell?
>
> I don't recall finding a specific vulnerability,


That's excellent!



> but last time I had a
> look at EOTK a while ago, it generated an nginx config that performed a
> series of steps to manipulate HTTP headers and body (HTML & Javascript)
> using (hard to audit) regexps. This is not a great security practice
> IMHO, as it can result in all kinds of unexpected output, especially
> with user-controlled untrusted input. It's the kind of thing that has

runs the risk of generating XSS, header CRLF injection vulnerabilities
> etc.
>

I concur; that's why I am working on an additional template which takes an
all-or-nothing approach, where the regexps and expectations are much
simpler to reason about.




> More broadly, using regexps to manipulate content means that you either
> replace mentions of "upload.wikimedia.org" blindly, even
> legitimate/non-href ones like a mention of it in the article text, or
> you attempt to parse the syntax of HTML and Javascript with regexps,
> including quotes, escape sequences, comments etc. Neither are the right
> thing to do.
>

Depending upon expectations and threat-models, I can see that perspective.




> EOTK as I understand it also pre-generates an nginx config with a very
> specific site-specific configuration, such as CSP, TLS ciphers etc.
> These may are secure, but are the kind of settings we are paying a close
> attention to and manage ourselves, so delegating them to a tool like
> EOTK is not something we can do.


Indeed.

Part of the point of EOTK being available on Github is the expectation that
sites will fork it and tune it to meet their needs.

I am confident that Wikipedia are equipped and expert enough to tweak a
NGINX cipher suite config without much fuss.

Request: whist we're here, I would be delighted to see/plagiarise the
cipher suites that Wikipedia uses - could you point me at them, please?

Also, I suppose it's worth noting that - to a fair first approximation -
anyone accessing a Wikipedia Onion is doing it from one of:

  - Tor Browser
  - Orfox
  - Tails

…so the number of cipher suites which EOTK needs to optimise for, are
actually quite small.



> That said, it may be possible to use
> EOTK to bootstrap our configuration and then remove the bits that we
> manually manage and care about, so I don't think this is by itself
> hindering our usage of it.
>

Concur. There is nothing stopping you using it.



> Note that there is a distinction between "the [e.g. English] Wikipedia
> community" and the WMF. We are all part of the same movement but the
> various wiki communities have decision-making capabilities of their own,
> especially when it comes to matters such as who's allowed to edit what,
> when and how.


I did not know that! That is very interesting, thank you.  TIL.


Allowing edits over Tor is not the kind of decision the
> Foundation can unilaterally make, while setting up the Onion service
> would be something that the Foundation would do, since it would just be
> part of our infrastructure and thus our mandate.
>

Understood. Is it safe to extrapolate this to (say) Wikibooks, also?

Are they likewise geographically distinct?



> Granted, serving the site over an Onion service is orthogonal to being
> able to edit it, so it's something we may eventually do anyway, even if
> the situation around editing remains the same. It does limit its scope
> and usefulness though, and is thus a factor that contributes to our
> prioritization (or lack thereof).
>

Cristian is making a good case around this matter, so I will leave that to
him for a while.

Thanks again!

- alec

-- 
http://dropsafe.crypticide.com/aboutalecm
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Alec Muffett]

On 14 June 2017 at 16:08, Brad Jorsch (Anomie) 
wrote:

> That part reminds me a bit of https://phabricator.wikimedia.org/T156847,
> which is about outputting different addresses in links for the mobile site
> versus the desktop site. The same solution might work for both onion links
> and mobile site links.


This is basically what we did at Facebook; architecture and other tips are
published at https://storify.com/AlecMuffett/tor-tips

The only real "gotcha" with such an approach is to only "onionify" links
which are in the process of being rendered to go to the user's browser; if
your software stack also makes site-internal fetches (eg: for database
access) in order to render a page, then onionifying *those* will result in
badness.

The other nice thing to bear in mind is that onionification is generally
best done with 1:1 mappings between onion addresses and DNS domains, and
that consistency is beneficial; in other words:

foo.com <-> .onion
bar.com <-> .onion

...and even if you are rendering a page for foo.com/, you'll get a
nicer experience by also fixing-up the bar.com/ HREFs, should you
happen to generate any.

This is one point where EOTK wins-out, because it operates after-the-fact
of content generation & site caching, so has a marginally easier time; the
demo EOTK config for a Wikipedia onion currently performs 11 simultaneous
mappings, as documented at:
https://github.com/alecmuffett/eotk/blob/master/demo.d/wikipedia.tconf

- alec

-- 
http://dropsafe.crypticide.com/aboutalecm
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Alec Muffett]

On 14 June 2017 at 15:57, Faidon Liambotis  wrote:

> The EOTK stuff are interesting but not really an option for us -- they
> rely on a edge (nginx) server performing content manipulation blindly,
> which is a bad idea for many reasons, security amongst them.
>

Hi again Faidon!

I'd love to know more about the security issues in particular.  Do please
tell?


However, it hasn't been a priority for me or my team for these reasons:
> - As long as communities feel so-and-so about Tor overall, and e.g.
>   block edits from Tor users, it's hard to justify us in the Foundation
>   investing more time into it,


Concur.

I would love to know more about what you see as the inhibitors - especially
so that I can go fix them for the internet-community-at-large - however
this decision is one for the Wikipedia community to take.

I'll still happily help if you decide "yes", but WMF should make and own
the decision.

-a

ps: reminder, I'd love to know more about the security issues. :-)


-- 
http://dropsafe.crypticide.com/aboutalecm
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Let's set up a Tor onion service for Wikipedia

[Alec Muffett]

If it helps, I built an betatest onion for Wikipedia and all(?) the
Wikimedia Foundation websites using EOTK* a few months ago, and documented
the build process at:

https://github.com/alecmuffett/eotk/blob/master/docs.d/RUNBOOK.md

A basic test onion takes about 5..10 minutes to set up on Ubuntu or
OSX/Homebrew.

A scalable full production loadbalanced deployment on some kind of cloud or
server(s) should take a day or two, plus time to buy an Onion SSL
Certificate where appropriate.

- alec



* Enterprise Onion Toolkit
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,