On 16 June 2017 at 19:12, Faidon Liambotis <faidon(a)wikimedia.org> 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