Well, I do not have unlimited resources, which is why I asked for thoughts on a solution
within my limits (virtual server with its host not under my control).
After a bit of further thought on this I think any solution would not be MW specific so
off topic here. The problem is that indeed I do not trust the hosting provider, neither of
the file server, nor of the web server. So the obvious solution would have been to encrypt
all files client-side. But doing that in browser is not (easily) feasible, as any script
may have been tempered with. As far as I can see there are really only two possible
solutions: Change to a trusted hosting environment as you proposed or encrypt outside the
browser before uploading.
I do not share your optimism regarding trust in Google and friends. Of course, they will
weigh the gains of any action against the possible damage. If the possible gains are high
enough they will do it anyway and in case somebody really notices, they just hunker down
and wait out the storm. Apart from Cambridge Analytica I am not right now aware of any
high profile company that ever went out of business or even suffered significant damage
because they lost or misused data (some bitcoin exchanges not counted). And in their case
it required a state-level actor to get involved and it might have been worth it for the
involved people even so.
Our credit cards? Who really cares if some Google employee went shopping with my credit
card (for which I regularly give out the data to odd webshops anyway)? If anything, it
will be me who will be blamed for my negligence. See
for a
higher profile case which still did not have any significant consequences for the service
provider as far as I can tell and in the end it was the customer who was blamed.
In any case, thank you and Brian for your thoughts. If I cannot avoid having to secure
access to the files above what I have right now I will probably just put a server in a
lockable cupboard and serve those 27 users from there.
Cheers
Stephan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On 30 May 2018 7:52 AM, Martin Urbanec <martin.urbanec(a)wikimedia.cz> wrote:
By the way, dont ask "is it possible".
Everything is technically possible, provided you have unlimited resources.
Instead, describe what you want to do (eg prevent everybody but you and those you trust
from accessing your files) without talking about technical implementation (in this case,
encryption).
Solution for your problem as I understand it is: Change your host company to a company
you trust. If you don't trust any company nor physical hosting providers (they can
control your computers too, althrough it will require downtime probably), the only way is
to build own DC (still technically possible but you probably do not want to have such an
expensive solution provided you don't have very very very sensitive materials such as
top secret government materials).
The rule is "I control it physically, I have full access to it if I want".
Yeah, you can encrypt everything but RAM and boot sector. But still, when booting, how
would you give the computer its decryption key? Stored in boot sector? Host can copy it
and decrypt your files just as your computer does. Enrypted with a password being entered
during booting? Who would enter the password then? If a company technical, the host can
decrypt your files just as your computer can. If you, they can add small keylogger between
keyboard and computer and do the same process your computer does.
I know I'm talking about extremes, I really cannot imagine a VPS provider nor
physical servers hosting provider that read its customer's data, as long as it is big
enough. Why? Imagine I can prove that Google technical noticed I have my credit card
details in my Google Drive (no, I don't, but my ID card is there) and bought something
without my authorization. Nice newspaper title can be "Google abuses your data".
Google do not want such newspaper article, of course.
As Brian said, this can make sense when you have separate file server and web server. Or
in another cases, which may or may not be relevant to MediaWiki.
Best,
Martin
Dne po 28. kvě 2018 16:30 uživatel Brian Wolff <bawolff(a)gmail.com> napsal:
> It is possible - You would probably want to implement your own
>
> FileBackend subclass -
>
>
https://doc.wikimedia.org/mediawiki-core/master/php/classFileBackend.html
>
> . I am not aware of anyone else doing something like this.
>
> However, conceptually you need to consider your threat model carefully
>
> here. As with most "encryption at rest" schemes, the sticking point is
>
> where is the key stored. To do something like this, you would probably
>
> put your encryption key in LocalSettings.php (Even if you do something
>
> more complex, MediaWiki would have to have access to the key at some
>
> point in order to decrypt the files to send them to your users). If
>
> you don't have control to the host, the attacker could just read the
>
> key out of your LocalSettings.php (or in more complex schemes, PHP's
>
> memory), and thus defeat the encryption.
>
> The type of system where this sort of thing makes more sense, is if
>
> you are storing files on a different server then your main web server
>
> (Say amazon S3 or whatever). If you don't trust the file server, but
>
> do trust your web server, then encrypting the files could make sense
>
> as long as the key stays only on the server you trust.
>
> --
>
> Brian
>
> On Mon, May 28, 2018 at 2:08 PM, Stephan Gambke <s7eph4n(a)protonmail.com>
wrote:
>
> > To prevent unauthorized access I may have to ensure that uploaded files are
stored encrypted. Wiki pages themselves are less critical, and may remain in clear text.
>
> > The scenario is a relatively small wiki (30,000 pages, 10,000 files, but only
27 users) on a virtual server where I have full remote root access. The host of the
virtual machine is not under my control.
>
> >
>
> > - Is there any obvious problem that makes this conceptionally impossible?
>
> > - Is anybody already doing this or working in that direction?
>
> > - What could be viable approaches and what limitations would there be?
>
> >
>
> > I know, it's a rather broad topic. Still, any pointers would be welcome.
>
> >
>
> > Cheers
>
> > Stephan
>
> >
>
> > _______________________________________________
>
> > MediaWiki-l mailing list
>
> > To unsubscribe, go to:
>
> >
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> _______________________________________________
>
> MediaWiki-l mailing list
>
> To unsubscribe, go to:
>
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l