P2P vs Server-Transfer: was ist sicherer?

Weder Peer-to-Peer- noch serverbasierter Transfer ist von Natur aus sicherer — die Sicherheit hängt vom Verschlüsselungsmodell ab, nicht von der Topologie. Ein gut implementierter Server-Transfer mit Zero-Knowledge-AES-256-GCM-Verschlüsselung ist für die Vertraulichkeit ununterscheidbar von P2P: der Server sieht in beiden Fällen nur Chiffretext. P2P fügt Metadaten-Datenschutz hinzu (kein Dritter erfährt, dass ein Transfer stattgefunden hat), bringt aber Verfügbarkeits-, NAT-Traversal- und Authentifizierungsprobleme mit sich. Serverbasierte Dienste liefern in puncto Zuverlässigkeit und Empfänger-Komfort bessere Ergebnisse. Die ehrliche Antwort: Wählen Sie basierend auf Ihrem Bedrohungsmodell und der Empfängerumgebung, nicht auf der intuitiven Annahme, „P2P ist sicherer".

Wie die beiden Modelle tatsächlich funktionieren

Server-Transfer lädt eine Datei auf einen Vermittler (Objekt-Speicher auf Basis von S3, OVH, Backblaze B2 oder Cloudflare R2) hoch, gibt einen Link zurück, und der Empfänger lädt vom selben Vermittler herunter. Die Datei existiert kurz auf einem Server, den keine Partei kontrolliert. Wenn der Server Ende-zu-Ende-Verschlüsselung nutzt, hält er nur Chiffretext.

P2P-Transfer stellt eine direkte Verbindung zwischen Absender und Empfänger her, meist über WebRTC-Datenkanäle. Die Datei berührt keinen dauerhaften Server — nur einen Signalisierungsserver (zum Austausch von Verbindungsinformationen) und möglicherweise einen TURN-Relay für NAT-Traversal. Beispiele sind Wormhole.app (das tatsächlich einen Server mit E2EE nutzt), ToffeeShare, FilePizza und klassisches BitTorrent für große Verteilungen.

Das Wort „Peer-to-Peer" umfasst ein Spektrum. Echtes P2P bedeutet, dass das Gerät des Absenders direkt mit dem Gerät des Empfängers verbindet. Praktisches WebRTC-P2P fällt oft auf einen TURN-Relay zurück, wenn eine direkte Verbindung scheitert — was es dann einem kurzlebigen Server-Transfer näher bringt.

Die Vertraulichkeitsfrage

Wenn beide Modelle AES-256-GCM mit einem Schlüssel nutzen, den der Server nie sieht, ist die Vertraulichkeit gleichwertig. Der Dateiinhalt kann ohne den Schlüssel in keinem Fall gelesen werden.

Was sich unterscheidet, sind Metadaten. Ein Server-Transfer verrät, dass „Nutzer X eine Datei der Größe Y zum Zeitpunkt T hochgeladen hat und Nutzer Z sie heruntergeladen hat." Ein P2P-Transfer verrät nur, dass zwei IP-Adressen kurz kommuniziert haben — keine zentral protokollierte Dateigröße, keine Timing-Korrelation zwischen Nutzern. Für Bedrohungsmodelle, bei denen Metadaten eine Rolle spielen (investigativer Journalismus, Whistleblowing, Aktivismus in adversariellen Staaten), ist P2P's kleinerer Metadaten-Fußabdruck real.

Für das Bedrohungsmodell „Datei nicht an einen Angreifer gelangen lassen" ist Server mit clientseitigem E2EE völlig ausreichend.

Asymmetrie der Verfügbarkeit

Server-Transfer ist innerhalb seines Aufbewahrungsfensters immer verfügbar. Einmal hochladen, Empfänger lädt jederzeit in den nächsten 7 Tagen von jedem Gerät herunter. Der Absender kann seinen Laptop schließen, in den Urlaub fahren — kein Problem.

P2P erfordert, dass beide Parteien gleichzeitig online sind (für direkte Verbindung) oder die Nutzung eines Relays, das ohnehin zu einem temporären Server wird. Wenn Sie eine 4-GB-Datei über WebRTC an einen Empfänger senden, dessen Laptop 20 % des Weges in den Ruhezustand geht, schlägt der Transfer fehl. Der Empfänger muss sich mit Ihnen abstimmen, um es erneut zu versuchen.

Für asynchrone Workflows — Freiberufler liefert Dateien, während der Kunde in einer anderen Zeitzone schläft — ist Server-Transfer schlicht praktischer.

NAT- und Firewall-Realität

WebRTC-NAT-Traversal verwendet ICE (Interactive Connectivity Establishment), STUN zum Entdecken öffentlicher IPs und TURN als Relay, wenn keine direkte Verbindung möglich ist. Unternehmens-Firewalls, strenge NATs, Carrier-grade NAT in Mobilnetzen und Gäste-WLANs blockieren oder beeinträchtigen WebRTC oft. In Tests scheitern P2P-Verbindungen vollständig oder fallen in etwa 15–20 % der realen Versuche auf TURN zurück.

Server-Transfer nutzt normales HTTPS auf Port 443. Es funktioniert überall, wo HTTPS funktioniert — also überall, wo ein Browser funktioniert. Kein ICE, kein STUN, kein TURN, kein Firewall-Drama.

Direktvergleich

| Dimension | P2P-Transfer (WebRTC) | Server-Transfer (E2EE) | |---|---|---| | Vertraulichkeit | Ende-zu-Ende verschlüsselt | Ende-zu-Ende verschlüsselt | | Metadaten-Leak | Gering (nur Signalisierung) | Mittel (Server sieht Größen/Zeiten) | | Empfänger-Komfort | Beide Parteien online | Asynchroner Download | | NAT/Firewall-Freundlichkeit | Kann in 15–20 % scheitern | Funktioniert überall mit HTTPS | | Max. praktische Dateigröße | Theoretisch unbegrenzt, bei großen fragil | Dienstabhängig (2–50 GB kostenlos) | | Wiederaufnahme-Unterstützung | Selten | Standard (tus.io, Chunks) | | Mehrere Empfänger | Jeweils erneut senden | Ein Link, viele Downloads | | Server-Kosten | Minimal (nur Signalisierung) | Speicher + Bandbreite | | Vertrauensannahme | WebRTC-Client-Code vertrauen | E2EE-Implementierung vertrauen |

Wo P2P wirklich gewinnt

Große Einmalübertragungen zwischen zwei technisch versierten Personen in derselben Zeitzone mit kooperativen Netzwerken. Ein Entwickler sendet ein 50-GB-.iso an einen Kollegen — beide auf Heimglasfaser, beide mit offenem Browser — P2P ist fertig, sobald ihre Uplinks gesättigt sind, ohne Serverkosten.

Metadaten-sensible Szenarien profitieren von P2P. Ein Journalist, der Quelldateien von einem Whistleblower erhält, gewinnt etwas dadurch, dass kein Drittanbieter-Server den Transfer protokolliert. Selbst mit E2EE auf einem Server wird die Existenz und Größe des Transfers festgehalten.

BitTorrent-ähnliche Verteilung einer Datei an Tausende von Empfängern ist ein separater P2P-Anwendungsfall, bei dem das Modell elegant skaliert — die Bandbreitenbelastung verteilt sich im Schwarm. Für typische 1-zu-1- oder 1-zu-wenige-Transfers nicht relevant, aber erwähnenswert.

Wo Server-Transfer gewinnt

Fast jede gewöhnliche Dateizustellung. Der Absender lädt einmal hoch und macht weiter. Der Empfänger lädt nach seinem eigenen Zeitplan herunter. Der Transfer funktioniert von jedem Netzwerk aus, einschließlich Hotel-WLAN und mobiler Daten. Mehrere Empfänger erhalten denselben Link. Die Aufbewahrung ist automatisch. Zahlung und Support existieren.

Server-Transfer gewinnt auch bei Zuverlässigkeit. Ein 3-GB-Upload, der bei 2,8 GB scheitert, nimmt auf einem Server mit tus.io-Chunked-Uploads bei 2,8 GB wieder auf. Ein P2P-Transfer, der bei 2,8 GB scheitert, startet meist bei null neu — browserbasierte WebRTC-Implementierungen speichern den Fortschritt selten zwischen.

Die „kein Server"-Marketingbehauptung

Einige P2P-Tools behaupten, „Ihre Dateien berühren nie unsere Server." Das ist nur teilweise korrekt. Signalisierungsserver tauschen SDP-Angebote und ICE-Kandidaten aus — nicht die Datei selbst, aber genug Metadaten, um die Verbindung herzustellen. TURN-Relays (wenn genutzt) tragen den verschlüsselten Dateistream kurz durch die Infrastruktur des Anbieters.

Unterdessen kann ein ordentlich implementierter Zero-Knowledge-Server-Transfer mit clientseitigem AES-256-GCM dieselbe funktionale Aussage machen: „Unsere Server sehen Ihren Dateiinhalt nie." Der Chiffretext passiert den Speicher, aber der Klartext existiert nur auf den Geräten von Absender und Empfänger.

Der Unterschied zwischen „Datei-Bits passieren unsere Infrastruktur nicht" und „Wir können nicht entschlüsseln, was unsere Infrastruktur passiert" ist real, aber oft kleiner als das Marketing andeutet.

Authentifizierung und Empfängerverifikation

Keines der Modelle löst die Empfängerauthentifizierung automatisch. Beide verlassen sich typischerweise auf „Wer den Link hat, kann die Datei empfangen", optional ergänzt durch ein Passwort. Echte Empfängerauthentifizierung (wurde diese Datei tatsächlich von Alice empfangen und nicht von jemandem, der ihre E-Mail mit dem Link abgefangen hat?) erfordert Out-of-Band-Kanäle — das Passwort über Signal teilen, den Empfang telefonisch bestätigen.

Server-Dienste machen das mit Download-Benachrichtigungen einfacher (der Absender erhält einen Webhook oder eine E-Mail, wenn der Link genutzt wird). P2P kann Ähnliches über die Absender-UI anbieten, aber nur während der Session.

Implementierungsqualität ist wichtiger als Topologie

Ein nachlässiges P2P-Tool mit ECDH ohne authentifizierten Schlüsselaustausch verliert gegen ein sorgfältiges serverbasiertes Tool mit X25519 und verifizierten Peer-Zertifikaten. Ein Server-Tool mit AES-128 im CBC-Modus verliert gegen ein P2P-Tool mit AES-256-GCM. Topologie ist weniger wichtig als die korrekte Kryptographie.

HexaTransfer nutzt clientseitiges AES-256-GCM mit Schlüsseln in URL-Fragmenten, TLS 1.3 für den Transport und Server-Speicher, der nur Chiffretext hält — eine Server-Topologie mit den Vertraulichkeitseigenschaften von P2P für den Dateiinhalt selbst.

Fazit

P2P's Sicherheitsvorteil betrifft primär den Metadaten-Datenschutz, nicht die Dateivertraulichkeit. Für die meisten Nutzer — Freiberufler, Kleinunternehmen, Kreative, die Assets an Kunden liefern — gewinnt Server-Transfer mit Zero-Knowledge-Verschlüsselung bei Zuverlässigkeit, Komfort und Kompatibilität, ohne nennenswerten Vertraulichkeitsverlust. P2P ergibt Sinn, wenn Metadaten-Datenschutz eine harte Anforderung ist oder wenn beide Parteien gleichzeitig online sind und die Datei zu groß für den kostenlosen Tarif eines Servers ist.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.