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
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@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
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@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@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
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 https://www.nytimes.com/2017/07/25/world/europe/ibm-sweden-data-outsourcing.... 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@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@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@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:
MediaWiki-l mailing list
To unsubscribe, go to:
mediawiki-l@lists.wikimedia.org