On 16 June 2017 at 19:12, Faidon Liambotis faidon@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