P2P vs serveroverdracht: wat is veiliger?

Peer-to-peer is niet inherent veiliger dan servergebaseerde overdracht — de beveiliging hangt af van het versleutelingsmodel, niet van de topologie. Een goed geïmplementeerde serveroverdracht met zero-knowledge AES-256-GCM-encryptie is qua vertrouwelijkheid niet te onderscheiden van P2P: de server ziet hoe dan ook alleen ciphertext. P2P voegt metadata-privacy toe (geen derde partij weet dat er een overdracht plaatsvond), maar introduceert uitdagingen rond beschikbaarheid, NAT-traversal en authenticatie. Servergebaseerde diensten gaan beter om met betrouwbaarheid en gemak voor de ontvanger. Het eerlijke antwoord: kies op basis van het dreigingsmodel en de omgeving van de ontvanger, niet op de theoretische intuïtie dat "P2P veiliger is".

Hoe de twee modellen daadwerkelijk werken

Bij serveroverdracht wordt een bestand geüpload naar een tussenpartij (objectopslag op S3, OVH, Backblaze B2 of Cloudflare R2), wordt een link teruggegeven, en downloadt de ontvanger vanaf diezelfde tussenpartij. Het bestand staat kort op een server die geen van beide partijen beheert. Als de server end-to-end encryptie gebruikt, bevat hij alleen ciphertext.

P2P-overdracht legt een directe verbinding tussen verzender en ontvanger, meestal via WebRTC-datakanalen. Het bestand komt nooit op een persistente server — alleen een signaalserver (om verbindingsinfo uit te wisselen) en eventueel een TURN-relay voor NAT-traversal. Voorbeelden zijn Wormhole.app (dat eigenlijk een server met E2EE gebruikt), ToffeeShare, FilePizza en klassiek BitTorrent voor grootschalig delen.

De term "peer-to-peer" dekt een spectrum. Echt P2P betekent dat het apparaat van de verzender direct verbinding maakt met dat van de ontvanger. In de praktijk valt WebRTC-P2P vaak terug op een TURN-relay als directe verbinding faalt, en dan lijkt het meer op een kortstondige serveroverdracht.

De vraag rond vertrouwelijkheid

Als beide modellen AES-256-GCM gebruiken met een sleutel die de server nooit ziet, is de vertrouwelijkheid gelijkwaardig. De inhoud van het bestand is in beide gevallen onleesbaar zonder de sleutel.

Wat verschilt is de metadata. Een serveroverdracht onthult dat "gebruiker X om tijd T een bestand van grootte Y uploadde, en gebruiker Z het downloadde". Een P2P-overdracht onthult alleen dat twee IP-adressen kort communiceerden — geen bestandsgrootte centraal gelogd, geen tijdcorrelatie tussen gebruikers. Voor dreigingsmodellen waarin metadata telt (onderzoeksjournalistiek, klokkenluiden, activisme in vijandige staten) is de kleinere metadata-voetafdruk van P2P reëel.

Voor het dreigingsmodel "voorkom dat een bestand uitlekt naar een aanvaller" is een server met client-side E2EE prima.

Asymmetrie in beschikbaarheid

Serveroverdracht is altijd beschikbaar binnen het bewaarvenster. Eenmaal uploaden, ontvanger downloadt op elk moment in de komende 7 dagen vanaf elk apparaat. De verzender kan zijn laptop dichtklappen, op vakantie gaan, wat dan ook.

P2P vereist dat beide partijen tegelijk online zijn (voor directe verbinding) of het gebruik van een relay die in feite een tijdelijke server wordt. Als je een 4 GB-bestand via WebRTC stuurt naar een ontvanger wiens laptop op 20% in slaapstand gaat, mislukt de overdracht. De ontvanger moet met je afstemmen om het opnieuw te proberen.

Voor asynchrone workflows — een freelancer levert bestanden af terwijl de klant in een andere tijdzone slaapt — is serveroverdracht simpelweg praktischer.

NAT- en firewall-realiteit

WebRTC NAT-traversal gebruikt ICE (Interactive Connectivity Establishment), STUN om publieke IP's te ontdekken, en TURN als relay wanneer directe verbinding niet kan. Bedrijfsfirewalls, strikte NATs, carrier-grade NAT op mobiele netwerken en gast-Wi-Fi blokkeren of belemmeren WebRTC vaak. In tests falen P2P-verbindingen of vallen ze terug op TURN bij ongeveer 15-20% van de praktijkpogingen.

Serveroverdracht gebruikt gewone HTTPS op poort 443. Het werkt overal waar HTTPS werkt, en dat is overal waar een browser werkt. Geen ICE, geen STUN, geen TURN, geen firewalldrama.

Tegenover elkaar

| Aspect | P2P-overdracht (WebRTC) | Serveroverdracht (E2EE) | |---|---|---| | Vertrouwelijkheid | End-to-end versleuteld | End-to-end versleuteld | | Metadata-lek | Laag (alleen signalering) | Matig (server ziet groottes/tijden) | | Gemak voor ontvanger | Beide partijen online | Asynchroon downloaden | | NAT/firewall-vriendelijkheid | Faalt 15-20% | Werkt overal waar HTTPS werkt | | Maximaal praktische bestandsgrootte | Theoretisch onbeperkt, fragiel op schaal | Dienstafhankelijk (2-50 GB gratis) | | Hervatting | Zelden | Standaard (tus.io, in chunks) | | Meerdere ontvangers | Per persoon opnieuw versturen | Eén link, vele downloads | | Serverkosten | Minimaal (alleen signalering) | Opslag + bandbreedte | | Vertrouwensaanname | Vertrouw de WebRTC-clientcode | Vertrouw de E2EE-implementatie |

Waar P2P echt wint

Grote eenmalige overdrachten tussen twee technisch capabele mensen in dezelfde tijdzone met meewerkende netwerken. Een ontwikkelaar die een 50 GB .iso naar een collega stuurt, beiden op thuisglasvezel, beiden met hun browser open — P2P is klaar in de tijd die hun uplinks nodig hebben om te verzadigen, met nul serverkosten.

Metadata-gevoelige scenario's profiteren van P2P. Een journalist die bronbestanden van een klokkenluider ontvangt, wint iets door geen externe server de overdracht te laten loggen. Zelfs met E2EE op een server worden het bestaan en de grootte van de overdracht vastgelegd.

BitTorrent-achtige distributie van één bestand naar duizenden ontvangers is een aparte P2P-toepassing waarbij het model elegant schaalt — de bandbreedtelast verdeelt zich over de zwerm. Niet relevant voor typische 1-op-1- of 1-op-weinig-overdrachten, maar het vermelden waard.

Waar serveroverdracht wint

Bijna elke gewone bestandslevering. De verzender uploadt eenmaal en loopt weg. De ontvanger downloadt op zijn eigen schema. De overdracht werkt vanaf elk netwerk, inclusief hotel-Wi-Fi en mobiel data. Meerdere ontvangers krijgen dezelfde link. Bewaartijd is automatisch. Er is een betaal-gateway en support.

Serveroverdracht wint ook op betrouwbaarheid. Een upload van 3 GB die op 2,8 GB faalt, hervat vanaf 2,8 GB op een server met tus.io chunked uploads. Een P2P-overdracht die op 2,8 GB faalt, begint meestal weer bij nul — browsergebaseerde WebRTC-implementaties zetten zelden checkpoints op de voortgang.

De marketingclaim "geen server"

Sommige P2P-tools claimen "uw bestanden raken nooit onze servers". Dat klopt slechts gedeeltelijk. Signaalservers wisselen SDP-aanbiedingen en ICE-kandidaten uit — niet het bestand zelf, maar voldoende metadata om de verbinding op te zetten. TURN-relays (indien gebruikt) dragen de versleutelde bestandsstroom kort door de infrastructuur van de aanbieder.

Tegelijk kan een correct geïmplementeerde zero-knowledge-serveroverdracht met client-side AES-256-GCM dezelfde functionele claim maken: "onze servers zien nooit de inhoud van uw bestand". De ciphertext gaat door de opslag, maar de plaintext bestaat alleen op de apparaten van verzender en ontvanger.

Het verschil tussen "bestandsbits gaan niet door onze infrastructuur" en "wij kunnen niet ontsleutelen wat door onze infrastructuur gaat" is reëel, maar vaak kleiner dan de marketing suggereert.

Authenticatie en verificatie van de ontvanger

Geen van beide modellen lost ontvangersauthenticatie automatisch op. Beide vertrouwen meestal op "wie de link heeft, kan het bestand ontvangen", eventueel aangevuld met een wachtwoord. Echte ontvangersauthenticatie (is dit bestand werkelijk door Alice ontvangen en niet door iemand die haar e-mail met de link onderschepte?) vereist out-of-band-kanalen — het wachtwoord delen via Signal, ontvangst telefonisch bevestigen.

Serverdiensten maken dit eenvoudiger met downloadmeldingen (de verzender krijgt een webhook of e-mail wanneer de link wordt gebruikt). P2P kan iets vergelijkbaars bieden via de UI van de verzender, maar alleen tijdens de sessie.

Implementatiekwaliteit telt zwaarder dan topologie

Een slordige P2P-tool die ECDH zonder geauthenticeerde sleuteluitwisseling gebruikt, verliest het van een zorgvuldige servergebaseerde tool met X25519 en geverifieerde peer-certificaten. Een server-tool met AES-128 in CBC-modus verliest het van een P2P-tool met AES-256-GCM. Topologie is minder belangrijk dan de cryptografie goed doen.

HexaTransfer gebruikt client-side AES-256-GCM met sleutels in URL-fragmenten, TLS 1.3 voor transport en serveropslag die alleen ciphertext bevat — een servertopologie met de vertrouwelijkheidseigenschappen van P2P voor de bestandsinhoud zelf.

Oordeel

Het beveiligingsvoordeel van P2P gaat vooral over metadata-privacy, niet over de vertrouwelijkheid van het bestand. Voor de meeste gebruikers — freelancers, kleine bedrijven, creatievelingen die opdrachten aan klanten leveren — wint serveroverdracht met zero-knowledge-encryptie op betrouwbaarheid, gemak en compatibiliteit, zonder noemenswaardig verlies aan vertrouwelijkheid. P2P heeft zin wanneer metadata-privacy een harde eis is of wanneer beide partijen tegelijk online zijn en het bestand te groot is voor het gratis tier van een server.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.