Szyfrowany transfer peer-to-peer: przewodnik techniczny
Buduj systemy szyfrowanego transferu plików peer-to-peer. NAT traversal, serwery sygnalizacyjne i implementacja szyfrowania end-to-end.
Transfer peer-to-peer wysyła bajty bezpośrednio między dwiema przeglądarkami lub urządzeniami bez zapisywania pliku na serwerze — co odpowiada wymogom minimalizacji danych wynikającym z RODO. CSIRT NASK w swoich rekomendacjach dla polskich organizacji wskazuje, że transfer danych wrażliwych powinien ograniczać liczbę pośredników przetwarzających informacje. WebRTC, zdefiniowany w RFC 8825–8837, dostarcza transport: szyfrowane kanały danych przez UDP z DTLS 1.3, NAT traversal przez ICE, STUN i TURN, a sygnalizacja odbywa się przez WebSocket lub HTTP. Narzędzia takie jak Snapdrop, Wormhole.app i Magic Wormhole potwierdzają, że model działa.
Dlaczego P2P do transferu plików
Przewaga jest prosta: żaden serwer nie przechowuje twojego pliku, nie ma rachunku za przepustowość, a upload nadawcy to jednocześnie download odbiorcy bez żadnej pośredniej kopii. Przy transferze 10 GB między dwoma użytkownikami w tej samej sieci gigabitowej P2P może zakończyć się w 80 sekund, podczas gdy chmura wymagałaby uploadu do zdalnego serwera i ponownego downloadu, podwajając zużycie przepustowości i opóźnienie. Prywatność to kolejny atut — bajty pliku istnieją wyłącznie na urządzeniach nadawcy i odbiorcy. Kompromisy: obie strony muszą być jednocześnie online, NAT traversal od czasu do czasu zawodzi, a połączenie jest tak szybkie jak wolniejszy uczestnik.
Kanały danych WebRTC jako transport
WebRTC zaczął jako protokół wideo i audio, ale RTCDataChannel zapewnia transport dowolnych binarnych wiadomości z dostarczaniem niezawodnym uporządkowanym (jak TCP) lub zawodnym nieuporządkowanym (jak UDP). Pod spodem kanały danych działają przez SCTP over DTLS 1.3 over UDP. Warstwa DTLS zapewnia poufność i uwierzytelnioną integralność przez AES-128-GCM lub ChaCha20-Poly1305 negocjowane podczas handshake. Do transferu plików utwórz niezawodny uporządkowany kanał, podziel plik na fragmenty po 16 KB lub 64 KB i wysyłaj je sekwencyjnie z kontrolą przepływu przez próg bufferedAmountLowThreshold.
Rola serwera sygnalizacyjnego
WebRTC potrzebuje serwera sygnalizacyjnego do wymiany informacji o połączeniu — oferty i odpowiedzi SDP oraz kandydatów ICE — między węzłami. Serwer sygnalizacyjny nie przekazuje bajtów pliku, tylko około 5 KB metadanych połączenia. Usługa sygnalizacyjna oparta na WebSocket w Node.js, Pythonie lub Go obsłuży to w kilkuset liniach kodu. Firebase Realtime Database, Supabase Realtime i Pusher działają jako backendy sygnalizacyjne. Serwer widzi kto z kim rozmawia i kiedy, ale nigdy nie widzi zawartości pliku. Większość usług transferu P2P uruchamia sygnalizację za darmo, bo przepustowość jest znikoma.
NAT Traversal: STUN, TURN i ICE
Większość urządzeń siedzi za NAT, co uniemożliwia bezpośrednie połączenia IP. ICE (Interactive Connectivity Establishment, RFC 8445) próbuje wielu ścieżek połączeń. STUN (RFC 8489) pozwala węzłowi odkryć swój publiczny adres IP i port przez publiczny serwer STUN — Google udostępnia stun.l.google.com za darmo. Jeśli oba węzły mają rozsądne NAT (full-cone lub restricted-cone), bezpośrednie połączenie UDP działa, może w 70 procentach prób. Dla symetrycznych NAT, firmowych zapór i CGNAT TURN (RFC 8656) przekazuje ruch przez serwer. Serwery TURN są drogie, bo przenoszą rzeczywiste bajty pliku. Oczekuj, że 10 do 30 procent transferów P2P wróci do TURN w rzeczywistych warunkach.
Nakładanie szyfrowania na DTLS
DTLS już szyfruje dane WebRTC, więc dodatkowe szyfrowanie end-to-end na poziomie aplikacji to zasada podwójnego zabezpieczenia. Handshake DTLS uwierzytelnia certyfikaty węzłów, ale WebRTC zazwyczaj używa certyfikatów samopodpisanych, które nie weryfikują tożsamości. Szyfrowanie na poziomie aplikacji z AES-256-GCM i wspólnym sekretem pochodnym z sygnalizacyjnego rendezvous dodaje zapewnienie tożsamości. SPAKE2 PAKE (Password-Authenticated Key Exchange) z Magic Wormhole wyprowadza silny klucz z krótkiej, czytelnej dla człowieka frazy — nawet skompromitowany serwer sygnalizacyjny nie może odszyfrować przesyłanych danych.
Strategia podziału na fragmenty w transferze P2P
Kanały danych WebRTC mają limit rozmiaru wiadomości (256 KB w większości przeglądarek, z fragmentacją większych wiadomości działającą ale zawodną). Dziel pliki na fragmenty po 16 KB do 64 KB na wiadomość dla kompatybilności. Śledź wypełnienie bufora przez bufferedAmount i bufferedAmountLowThreshold, żeby zaimplementować backpressure — wstrzymaj wysyłanie gdy bufor przekroczy 1 MB, wznów gdy spadnie poniżej 256 KB. Dla integralności haszuj każdy fragment SHA-256 i uwzględnij skrót w manifeście wysyłanym na początku. Odbiorca składa ponownie, weryfikuje hasze i zapisuje na dysk przez File System Access API lub pobieranie Blob.
Kwestie mobilne i wielourządzeniowe
P2P desktop-do-desktop działa dobrze. Mobile-do-desktop wprowadza komplikacje: mobilne przeglądarki wymuszają agresywne zawieszanie kart, więc nadawca musi utrzymywać kartę przeglądarki na pierwszym planie. Historycznie implementacja kanałów danych w iOS Safari była mniej niezawodna niż w Chromium. Trwałe uploady na mobilnych wymagają implementacji wspieranych przez aplikację natywną. Wpływ na baterię ma znaczenie — utrzymywane sesje WebRTC rozładowują baterie szybciej niż pobieranie HTTPS. Przy transferach mobile-do-mobile w tej samej sieci Wi-Fi AirDrop i Nearby Share przewyższają P2P przez przeglądarkę, używając bezpośrednich protokołów urządzeń.
Odkrywanie węzłów bez centralnych kont
Kilka wzorców działa. Krótki kod jak "4-truck-roger" z Magic Wormhole służy zarówno jako adres rendezvous, jak i hasło — serwer sygnalizacyjny mapuje kody na sesje. Kody QR kodujące adres URL sesji działają przy transferach na żywo. NFC tap-to-connect na Androidzie łączy przez bliskość. Dla większych sieci DHT jak Mainline DHT BitTorrenta może bootstrapować odkrywanie węzłów bez centralnego serwera, ale wyszukiwania DHT zajmują sekundy i nie nadają się do przypadkowego udostępniania plików.
Zagrożenia bezpieczeństwa specyficzne dla P2P
P2P wprowadza zagrożenia, których przekaźniki chmurowe nie mają. Ujawnienie adresu IP: bezpośrednie połączenia ujawniają każdemu węzłowi publiczny adres IP drugiego, co może identyfikować użytkowników w kontekstach wrażliwych na prywatność — sygnalistów, aktywistów. Niektóre usługi P2P wymuszają przekaźnik TURN, żeby ukryć IP kosztem wydajności. Dystrybucja złośliwego oprogramowania jest trudniejsza do moderowania, ponieważ operator usługi nigdy nie widzi zawartości pliku. Ataki DoS przez wyczerpanie połączeń na serwerze sygnalizacyjnym wymagają ograniczania liczby żądań.
Kiedy przekaźnik chmurowy nadal wygrywa
Dla transferów asynchronicznych, gdzie nadawca i odbiorca nie są jednocześnie online, P2P w ogóle nie działa — nie ma węzła, który mógłby odbierać. Dla dużych transferów przekraczających okno sesji model "wgraj i udostępnij link" przekaźnika chmurowego jest po prostu bardziej praktyczny. Dla dystrybucji jeden-do-wielu jeden upload plus fanout przez CDN bije uruchamianie N jednoczesnych sesji P2P. HexaTransfer używa modelu przekaźnika chmurowego z szyfrowaniem AES-256-GCM po stronie klienta, zapewniając większość prywatności P2P przy znacznie lepszej obsłudze asynchronicznej i wielu odbiorców.
Wypróbuj na https://hexatransfer.com — za darmo, bez konta, maks. 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik