Wat een relay ziet, en waarom het risico niet vertrouwelijkheid is

De gebruiker vroeg of iemand met kennis van de API zijn labels kan opvragen zodra
de relay op een domein staat. Nee, en de reden is scherper dan "het is
versleuteld". Uit een OwnerSecret worden met SLIP-21 drie onafhankelijke waarden
afgeleid: een publieke OwnerId, een encryptiesleutel en een rotatable write key.
Alleen de eerste gaat naar de relay.

Het aardige is dat de OwnerId expres niet geheim is. De beveiliging leunt er niet
op dat je adres onbekend blijft, en dat is het tegenovergestelde van een systeem
waar een onraadbare URL de grens vormt. Daarom kan deze relay bij een onbekende
partij staan.

Twee dingen expres niet gladgestreken. Of iemand die een OwnerId kent de
versleutelde blobs kan ophalen staat nergens gedocumenteerd; kan het, dan lekt dat
bestaan, activiteit en bij benadering omvang, niet inhoud. En onraadbaarheid van
de OwnerId beschermt tegen het aflopen van een relay, niet tegen lezen.

Dat verschuift waar Bereikbaarheid over gaat. Het risico van een open eindpunt is
misbruik als gratis versleutelde opslag: een kale relay kent geen accounts en kan
per definitie niet weten van wie de data is. Dat is met terugwerkende kracht de
tweede functie van Trezor's quota-manager, naast facturering, en die haalden wij
eruit.

Het voorstel van de gebruiker voor een eigen quota-manager met een allowlist van
OwnerId's staat erin, met drie uitvoeringen en hun prijs. De netste is createRelay
uit @evolu/nodejs, dat auth expliciet als reden noemt om die API te gebruiken,
maar dan bouw je weer een eigen image en verlies je de winst van de gepubliceerde.
Met een detail dat het lastiger maakt dan het klinkt: je moet je eigen OwnerId
kennen om hem te vlaggen, en Suite toont die waarschijnlijk nergens. Uitweg is niet
laten typen maar laten leren: de eerste eigenaar die verbindt wordt toegelaten.

Meegenomen uit de vorige bevinding: open punt 2 is beantwoord, Suite eist geen TLS.

Tests: niet gedraaid, dit raakt alleen documentatie.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Harmen
2026-08-26 07:51:52 +02:00
co-authored by Claude Opus 5
parent 373c02bfd4
commit c80d587100
3 changed files with 111 additions and 3 deletions
+1 -1
View File
@@ -61,7 +61,7 @@ daaronder, dus deze tabel en de mapinhoud kunnen niet uit elkaar lopen.
| Plan | App | Afhankelijk van | Waarover het gaat |
|-|-|-|-|
| [Bereikbaarheid.PLAN.md](Plannen/Masterplannen/Bereikbaarheid.PLAN.md) | Relay | Umbrelapp: er valt niets bereikbaar te maken zolang er niets draait | Synchroniseren buiten het thuisnetwerk, zonder een poort op de router open te zetten. Voorstel is Tailscale; of dat volstaat hangt ervan af of Suite TLS eist. De gebruiker maakt een subdomein aan, wat op de reverse-proxy-route wijst |
| [Bereikbaarheid.PLAN.md](Plannen/Masterplannen/Bereikbaarheid.PLAN.md) | Relay | Umbrelapp: er valt niets bereikbaar te maken zolang er niets draait | Synchroniseren buiten het thuisnetwerk. **Suite eist geen TLS**, dus Tailscale blijft open en een certificaat is geen voorwaarde. Het risico van een publiek eindpunt is niet vertrouwelijkheid (dat regelt de versleuteling) maar misbruik als gratis opslag: een kale relay kent geen accounts. Wil je tóch open, dan is een eigenaars-allowlist nodig; drie manieren in §4b |
| [Publicatie-Relay.PLAN.md](Plannen/Masterplannen/Publicatie-Relay.PLAN.md) | Relay | Umbrelapp, plus een image die te pinnen valt | Inleveren bij de officiële appstore. Twee dingen kunnen dit blokkeren: een image die niet als multi-arch digest in een registry bestaat, en de eis dat de umbrelOS-inlog aan blijft terwijl de relay een cliënt zonder sessie moet bedienen |
| [Publicatie-Gate.PLAN.md](Plannen/Masterplannen/Publicatie-Gate.PLAN.md) | Gate | Appstore: de herstart-controle | **Doel van de gebruiker sinds 20-08-2026:** de app inleveren als standaard-app voor Umbrel. Dat verandert de maatstaf van "hij werkt hier" naar "iemand anders keurt het pakket goed". Het meeste is al goed; wat er nog moet is de images pinnen, het app-id kaal maken en de manifestvelden op orde. Het risico zit niet in die lijst maar in de leesmount op de certificaten van Zoraxy |
| [Configuratie.PLAN.md](Plannen/Masterplannen/Configuratie.PLAN.md) | Gate | | **Grotendeels ingehaald op 19-08-2026** en moet opgeschoond worden voordat promotie nog zin heeft: de agent doet de certificaatbronnen en de keuze al, en het hardgecodeerde domein is uit de compose en uit `nginx.conf.template` verdwenen. Wat er nog in zit is een configuratiebestand voor de poort- en padoverstemmingen, plus de README |
@@ -32,6 +32,61 @@ buiten het netwerk niets kan synchroniseren, moet dat binnen het netwerk nog wel
## 4. Ontwerp
### 4a. Waar het risico wél en niet zit
**Bijgewerkt 25-08-2026**, nadat de gebruiker vroeg of iedereen met kennis van de API zijn labels kan
opvragen zodra de relay op een domein staat. Dat antwoord is nee, en het verandert waar dit plan over gaat.
**Vertrouwelijkheid is geen probleem, ook niet op een open eindpunt.** Uit één `OwnerSecret` worden met
SLIP-21 drie onafhankelijke waarden afgeleid: een publieke `OwnerId`, een `OwnerEncryptionKey` die
ontsleutelt en een `OwnerWriteKey` die schrijven autoriseert. Alleen de eerste gaat naar de relay. De
beveiliging leunt er dus niet op dat je adres onbekend blijft. Uitgeschreven met bron in
[Upstream-evolu-relay.md](../../Referenties/Upstream-evolu-relay.md) §1b.
**Het echte risico is misbruik als opslag.** Een kale Evolu-relay kent geen accounts en geen
toegangscontrole. Wie hem kan bereiken, kan een eigen owner aanmaken en hem als gratis versleutelde opslag
gebruiken, en je kunt niet zien van wie het is: dat is het ontwerp en geen tekortkoming. Je schijf groeit
en er is geen knop.
**Dat is met terugwerkende kracht de tweede functie van Trezor's quota-manager**, naast facturering. Wij
haalden hem eruit omdat hij bij betaalde hosting hoort. Dat klopt, maar dan neem je de misbruikbeheersing
mee weg.
Gevolg voor dit plan: **de keuze tussen Tailscale en een reverse proxy gaat niet meer over gemak maar over
of er überhaupt een open eindpunt komt.** Zolang alleen jouw eigen apparaten erbij moeten, is een netwerk
dat vreemden buiten houdt de simpelste en beste oplossing, en is een publiek domein een risico dat niets
oplevert.
### 4b. Wil je tóch een open eindpunt, dan is er een eigenaars-allowlist nodig
Voorstel van de gebruiker op 25-08-2026: een eigen quota-manager, met een interface waarin je `OwnerId`'s
kunt vlaggen en alleen die van jezelf mag schrijven. Dat is de juiste gedachte, en er zijn drie manieren om
het te doen die sterk in prijs verschillen.
1. **De relay uitbreiden via `createRelay`.** De README van Evolu noemt de Node-bibliotheek
`@evolu/nodejs` met een `createRelay`-API, en noemt expliciet "custom logging, **auth**, or tight server
integration" als reden om die te gebruiken in plaats van de kant-en-klare image. Dat is het bedoelde
uitbreidpunt en vrijwel zeker wat Trezor gedaan heeft. Prijs: je schrijft en onderhoudt een eigen kleine
dienst, en je bouwt weer een eigen image. Dan verlies je precies de winst uit open punt 6 van
**Umbrelapp**.
2. **Terug naar de relay van Trezor**, met een eigen interface die rijen in de limietentabel zet in plaats
van hun quota-manager. De handhaving bestaat daar al (`isOwnerAllowed`). Prijs: schrijven in andermans
schema, dus breekbaar bij elke bovenstroomse wijziging, plus de Postgres en de eigen image terug.
3. **Geen allowlist, maar het netwerk.** Tailscale of een IP-beperking op de reverse proxy. Grover, want
het beperkt wie er mag verbinden en niet welke eigenaar mag schrijven. Voor één huishouden is dat
praktisch hetzelfde, en het kost geen regel code.
**Een detail dat optie 1 en 2 lastiger maakt dan ze klinken: je moet je eigen `OwnerId` kennen om hem te
kunnen vlaggen.** Trezor Suite toont die waarschijnlijk nergens. De uitweg is de allowlist niet te laten
typen maar te laten leren: **de eerste eigenaar die verbindt wordt toegelaten, de rest geweigerd**, met een
knop om die keuze te wissen. Dat is dezelfde gedachte als een sleutel die je bij de eerste verbinding
vastlegt, het vraagt geen interface om een id in te tikken, en het is precies genoeg voor het doel.
**Voorstel: doe optie 3 eerst.** Hij is gratis, hij lost het echte risico op, en hij houdt de deur open
voor optie 1 als er ooit iemand anders bij moet.
### 4c. De twee wegen naar buiten
Twee wegen, en ze sluiten elkaar niet uit.
**Tailscale.** umbrelOS heeft er een officiële app voor, en het is de weg van de minste weerstand: geen
@@ -65,8 +120,14 @@ daarna controleren dat het thuis nog steeds werkt.
1. **Welke apparaten moeten buitenshuis kunnen synchroniseren?** Alleen een laptop is iets anders dan een
telefoon, en het bepaalt of Tailscale volstaat.
**Moment:** fase 1 · **Eigenaar:** gebruiker
2. **Eist Trezor Suite TLS?** Zie hierboven.
**Moment:** komt uit Proefopstelling · **Eigenaar:** volgt uit dat plan
2. **Eist Trezor Suite TLS?** - **nee, `http://` volstaat** (25-08-2026). Afgelezen uit de e2e-test van de
mobiele app in de broncode van Suite, die `http://10.0.2.2:4000` invult. Daarmee blijft de kale
Tailscale-route open en is een certificaat geen voorwaarde. Nog niet met de hand nagedaan, en het is
alleen gecontroleerd voor `suite-native`; de desktopversie is niet nagekeken.
3. **Komt er een eigenaars-allowlist, en zo ja welke van de drie uit §4b?**
Alleen aan de orde als er een open eindpunt komt. Bij Tailscale of een IP-beperking is de vraag niet
nodig, en dat is meteen het argument om daarmee te beginnen.
**Moment:** pas als fase 1 uitwijst dat een apparaat geen Tailscale kan draaien · **Eigenaar:** gebruiker
## 7. Verificatie
+47
View File
@@ -84,6 +84,53 @@ doorgeefluik voor versleutelde wijzigingen. Volgens Trezor is de data client-sid
dus de relay ziet niets leesbaars. **Zelf hosten haalt Trezor uit de vergelijking, het verandert de
privacygaranties niet.**
## 1b. Wat een relay is, wat hij ziet, en waarom hij niets hoeft te vertrouwen
Uitgezocht op 25-08-2026 op de vraag van de gebruiker of iemand met kennis van de API de labels kan
opvragen als de relay op een domein staat. Bronnen: [evolu.dev/docs/privacy](https://www.evolu.dev/docs/privacy),
[Owner](https://www.evolu.dev/docs/api-reference/common/local-first/Owner) en
[Protocol](https://www.evolu.dev/docs/api-reference/common/local-first/Protocol).
**Het is geen key-value-store.** De cliënt houdt zijn eigen SQLite bij; de relay bewaart versleutelde
CRDT-berichten per eigenaar en helpt twee kanten met range-based set reconciliation uitzoeken wat ze
allebei al hebben. Dichter bij een append-only berichtenlog dan bij een sleutel-waardetabel.
**Wat de relay ziet:** een `OwnerId`, tijdstempels, IP-adressen, en versleutelde blobs die gevuld zijn om
hun omvang te verhullen. Meer niet.
**Drie waarden, met SLIP-21 afgeleid uit één `OwnerSecret`:**
| Waarde | Wat het doet |
|-|-|
| `OwnerId` | de **publieke** identificatie |
| `OwnerEncryptionKey` | ontsleutelt de data |
| `OwnerWriteKey` | rotatable token dat schrijven autoriseert; zonder is een cliënt `ReadonlyOwner` |
**Het antwoord op de vraag is dus nee**, en de reden is scherper dan "het is versleuteld". De `OwnerId` is
expres niet geheim: hij gaat onversleuteld naar de relay en de beheerder ziet hem. De beveiliging leunt er
niet op dat niemand hem kent. Dat is het tegenovergestelde van een systeem waar een onraadbare URL de grens
is, en het is precies waarom je deze relay bij een onbekende partij kunt neerzetten.
Dat de drie waarden **onafhankelijk** zijn, is wat dat mogelijk maakt: je geeft de relay je identiteit
zonder iets over je sleutel prijs te geven, en je kunt de write key roteren zonder je identiteit te
verliezen. De protocol-documentatie zegt dat de write key gecontroleerd wordt **vóór** het verwerken van
berichten.
**Twee dingen die hier níet uit volgen, en die je niet moet gladstrijken:**
1. **Of iemand die een `OwnerId` kent de versleutelde blobs kan ophálen, staat nergens.** De
protocolpagina zwijgt erover. Kan het, dan leert zo iemand dat die eigenaar bestaat, wanneer hij actief
is en bij benadering hoeveel data er is. Niet de inhoud.
2. **Onraadbaarheid van de `OwnerId` beschermt tegen aflopen van de relay, niet tegen lezen.** Het is
verkeersbescherming en geen vertrouwelijkheid.
**En het echte risico van een publieke relay is een ander dan vertrouwelijkheid: misbruik als opslag.** Een
kale Evolu-relay kent geen accounts en geen toegangscontrole, dus iedereen kan een eigen owner aanmaken en
hem als gratis versleutelde opslag gebruiken. Je schijf groeit en je kunt niet zien van wie het is, want
dat is nu juist het ontwerp. Dit verklaart met terugwerkende kracht waarom Trezor een quota-manager heeft:
die is niet alleen voor facturering maar ook hun misbruikbeheersing. Wie hem eruit haalt, haalt die tweede
functie mee weg. Zie het masterplan **Bereikbaarheid**.
## 2. Eén codebase, vier processen, en een compose die de app niet draait
**Correctie op het vooronderzoek.** Daar stond dat er een `Dockerfile` en een `docker-compose.yaml` in de