mirror of
https://git.deuxfleurs.fr/Deuxfleurs/garage.git
synced 2024-11-21 23:51:00 +00:00
Add a page about encryption (fix #416)
This commit is contained in:
parent
7169ee6ee6
commit
39c3738a07
1 changed files with 105 additions and 0 deletions
105
doc/book/cookbook/encryption.md
Normal file
105
doc/book/cookbook/encryption.md
Normal file
|
@ -0,0 +1,105 @@
|
|||
+++
|
||||
title = "Encryption"
|
||||
weight = 50
|
||||
+++
|
||||
|
||||
Encryption is a recurring subject when discussing Garage.
|
||||
Garage does not handle data encryption by itself, but many things can
|
||||
already be done with Garage's current feature set and the existing ecosystem.
|
||||
|
||||
This page takes a high level approach to security in general and data encryption
|
||||
in particular.
|
||||
|
||||
|
||||
# Examining your need for encryption
|
||||
|
||||
- Why do you want encryption in Garage?
|
||||
|
||||
- What is your threat model? What are you fearing?
|
||||
- A stolen HDD?
|
||||
- A curious administrator?
|
||||
- A malicious administrator?
|
||||
- A remote attacker?
|
||||
- etc.
|
||||
|
||||
- What services do you want to protect with encryption?
|
||||
- An existing application? Which one? (eg. Nextcloud)
|
||||
- An application that you are writing
|
||||
|
||||
- Any expertise you may have on the subject
|
||||
|
||||
This page explains what Garage provides, and how you can improve the situation by yourself
|
||||
by adding encryption at different levels.
|
||||
|
||||
We would be very curious to know your needs and thougs about ideas such as
|
||||
encryption practices and things like key management, as we want Garage to be a
|
||||
serious base platform for the developpment of secure, encrypted applications.
|
||||
Do not hesitate to come talk to us if you have any thoughts or questions on the
|
||||
subject.
|
||||
|
||||
|
||||
# Capabilities provided by Garage
|
||||
|
||||
## Traffic is encrypted between Garage nodes
|
||||
|
||||
RPCs between Garage nodes are encrypted. More specifically, contrary to many
|
||||
distributed software, it is impossible in Garage to have clear-text RPC. We
|
||||
use the [kuska handshake](https://github.com/Kuska-ssb/handshake) library which
|
||||
implements a protocol that has been clearly reviewed, Secure ScuttleButt's
|
||||
Secret Handshake protocol. This is why setting a `rpc_secret` is mandatory,
|
||||
and that's also why your nodes have super long identifiers.
|
||||
|
||||
## Encrypting traffic between a Garage node and your client
|
||||
|
||||
HTTP API endpoints provided by Garage are in clear text.
|
||||
You have multiple options to have encryption between your client and a node:
|
||||
|
||||
- Setup a reverse proxy with TLS / ACME / Let's encrypt
|
||||
- Setup a Garage gateway locally, and only contact the garage daemon on `localhost`
|
||||
- Only contact your Garage daemon over a secure, encrypted overlay network such as Wireguard
|
||||
|
||||
## Garage stores data in plain text on the filesystem
|
||||
|
||||
Garage does not handle data encryption at rest by itself, and instead delegates
|
||||
to the user to add encryption, either at the storage layer (LUKS, etc) or on
|
||||
the client side (or both). There are no current plans to add data encryption
|
||||
directly in Garage.
|
||||
|
||||
Implementing data encryption directly in Garage might make things simpler for
|
||||
end users, but also raises many more questions, especially around key
|
||||
management: for encryption of data, where could Garage get the encryption keys
|
||||
from ? If we encrypt data but keep the keys in a plaintext file next to them,
|
||||
it's useless. We probably don't want to have to manage secrets in garage as it
|
||||
would be very hard to do in a secure way. Maybe integrate with an external
|
||||
system such as Hashicorp Vault?
|
||||
|
||||
|
||||
# Adding data encryption using external tools
|
||||
|
||||
## Encrypting data at rest
|
||||
|
||||
Protects against the following threats:
|
||||
|
||||
- Stolen HDD
|
||||
|
||||
Crucially, does not protect againt malicious sysadmins or remote attackers that
|
||||
might gain access to your servers.
|
||||
|
||||
Methods include full-disk encryption with tools such as LUKS.
|
||||
|
||||
## Encrypting data on the client side
|
||||
|
||||
Protects againt the following threats:
|
||||
|
||||
- A honest-but-curious administrator
|
||||
- A malicious administrator that tries to corrupt your data
|
||||
- A remote attacker that can read your server's data
|
||||
|
||||
Implementations are very specific to the various applications. Examples:
|
||||
|
||||
- Matrix: uses the OLM protocol for E2EE of user messages. Media files stored
|
||||
in Matrix are probably encrypted using symmetric encryption, with a key that is
|
||||
distributed in the end-to-end encrypted message that contains the link to the object.
|
||||
|
||||
- Aerogramme: use the user's password as a key to decrypt data in the user's bucket
|
||||
|
Loading…
Reference in a new issue