Trasferimento file peer-to-peer crittografato: guida tecnica
Costruisci sistemi di trasferimento file peer-to-peer crittografato. Attraversamento NAT, server di signaling e implementazione della crittografia end-to-end.
Il trasferimento file peer-to-peer invia i byte direttamente tra due browser o dispositivi senza che il file tocchi mai un server. WebRTC, standardizzato nei RFC 8825-8837, fornisce il trasporto: canali dati cifrati su UDP con DTLS 1.3, attraversamento NAT tramite ICE, STUN e TURN, e segnalazione su WebSocket o HTTP. Strumenti come Snapdrop, Wormhole.app e Magic Wormhole dimostrano che il modello funziona. Dal punto di vista del GDPR e del Garante per la protezione dei dati personali, il P2P offre un vantaggio strutturale: i byte del file non transitano mai su server di terze parti, eliminando una categoria di rischio di violazione dei dati. Ecco come costruirlo: l'handshake di segnalazione, le insidie dell'attraversamento NAT, il layering della crittografia e cosa si guadagna o perde rispetto ai servizi di relay cloud.
Perché P2P per il Trasferimento File
L'attrattiva è semplice: nessun server memorizza il tuo file, nessuna bolletta di larghezza di banda per il servizio di trasferimento, e l'upload del mittente È il download del destinatario senza copia intermedia. Per un trasferimento da 10 GB tra due utenti sulla stessa LAN gigabit, P2P può finire in 80 secondi mentre un relay cloud caricherebbe su un server distante e scaricherebbe di nuovo, raddoppiando l'utilizzo della larghezza di banda e la latenza. La privacy è anche un punto di forza: i byte del file esistono solo sui dispositivi del mittente e del destinatario. I compromessi: entrambe le parti devono essere online simultaneamente, l'attraversamento NAT fallisce occasionalmente e la connessione è veloce quanto il link di upload del partecipante più lento.
Canali Dati WebRTC come Trasporto
WebRTC è iniziato come protocollo video/audio ma RTCDataChannel fornisce trasporto binario di messaggi arbitrari con consegna affidabile ordinata (come TCP) o non affidabile non ordinata (come UDP). Sotto il cofano, i canali dati girano su SCTP su DTLS 1.3 su UDP. Il layer DTLS fornisce riservatezza e integrità autenticata tramite AES-128-GCM o ChaCha20-Poly1305, negoziati durante l'handshake. Per il trasferimento file, creare un canale affidabile ordinato, suddividere il file in messaggi da 16 KB o 64 KB (Chrome ha storicamente limitato la dimensione dei messaggi a 256 KB) e inviarli sequenzialmente con controllo del flusso tramite la soglia bufferedAmount.
Il Ruolo del Server di Signaling
WebRTC ha bisogno di un server di signaling per scambiare le informazioni di connessione (SDP offer e answer, candidati ICE) tra i peer. Il server di signaling non fa relay dei byte dei file, solo circa 5 KB di metadati di connessione. Un servizio di signaling basato su WebSocket in Node.js, Python o Go lo gestisce in poche centinaia di righe di codice. Firebase Realtime Database, Supabase Realtime e Pusher funzionano tutti come backend di signaling. Il server di signaling vede chi sta parlando con chi e quando, ma mai i contenuti dei file. La maggior parte dei servizi di trasferimento file P2P gestisce il proprio signaling gratuitamente perché la larghezza di banda è trascurabile.
Attraversamento NAT: STUN, TURN e ICE
La maggior parte dei dispositivi si trova dietro NAT, rendendo impossibili le connessioni IP dirette. ICE (Interactive Connectivity Establishment, RFC 8445) prova molteplici percorsi di connessione. STUN (RFC 8489) permette a un peer di scoprire il proprio IP pubblico e porta tramite un server STUN pubblico; Google gestisce stun.l.google.com gratuitamente. Se entrambi i peer hanno NAT ragionevoli (full-cone o restricted-cone), la connessione UDP diretta funziona, forse nel 70% dei tentativi. Per i NAT simmetrici, i firewall aziendali e CGNAT, TURN (RFC 8656) fa relay del traffico attraverso un server. I server TURN sono costosi perché portano i byte effettivi dei file. Self-hosted coturn, twilio.com/stun o Cloudflare Calls forniscono opzioni. Aspettarsi dal 10 al 30% dei trasferimenti P2P che cadono su TURN sul campo.
Layering della Crittografia sopra DTLS
DTLS cifra già i dati WebRTC, quindi la crittografia aggiuntiva a livello applicazione è cinture e bretelle. L'handshake DTLS autentica i certificati dei peer, ma WebRTC usa tipicamente certificati auto-firmati che non verificano l'identità, verificano solo che la connessione sia con lo stesso peer che ha firmato l'SDP. La crittografia end-to-end a livello applicazione con AES-256-GCM e un segreto condiviso derivato dal rendezvous di signaling aggiunge garanzia di identità. SPAKE2 PAKE (Password-Authenticated Key Exchange) di Magic Wormhole deriva una chiave forte da una breve frase leggibile dall'uomo, così anche un server di signaling compromesso non può decifrare.
Strategia di Chunking per il Trasferimento File P2P
I canali dati WebRTC hanno un limite di dimensione dei messaggi (256 KB nella maggior parte dei browser, con frammentazione di messaggi più grandi che funziona ma è inaffidabile). Suddividere i file a 16 KB-64 KB per messaggio per la compatibilità. Tracciare l'importo del buffer tramite bufferedAmount e bufferedAmountLowThreshold per implementare la backpressure: mettere in pausa l'invio quando il buffer supera 1 MB, riprendere quando scende sotto 256 KB. Per l'integrità, hashare ogni chunk con SHA-256 e includere l'hash in un manifesto inviato per primo. Il ricevente riassembla, verifica gli hash e scrive su disco tramite la File System Access API o un download Blob.
Considerazioni su Mobile e Cross-Device
P2P da desktop a desktop funziona bene. Mobile-to-desktop introduce complicazioni: i browser mobile applicano una sospensione aggressiva delle tab, così il mittente deve mantenere la tab del browser in primo piano. L'implementazione del canale dati di iOS Safari è storicamente stata meno affidabile di Chromium. Gli upload in background su mobile richiedono implementazioni backed da app (Snapdrop Relay, ShareDrop). L'impatto sulla batteria conta anche: le sessioni WebRTC sostenute scaricano le batterie più velocemente dei download HTTPS. Per i trasferimenti mobile-to-mobile sulla stessa Wi-Fi, AirDrop (iOS/macOS) e Nearby Share (Android) superano il P2P browser usando protocolli di dispositivo diretti.
Minacce di Sicurezza Specifiche al P2P
Il P2P introduce minacce che i relay cloud non hanno. Divulgazione dell'indirizzo IP: le connessioni dirette rivelano l'IP pubblico di ciascun peer all'altro, potenzialmente doxxando gli utenti in contesti sensibili alla privacy (whistleblowing, attivismo). Alcuni servizi P2P forzano il relay TURN per nascondere gli IP al costo delle prestazioni. La distribuzione di malware è più difficile da moderare perché l'operatore del servizio non vede mai i contenuti dei file. Il denial-of-service tramite esaurimento delle connessioni sul server di signaling necessita di rate limiting. Per trasferimenti extra-sensibili, un onion service Tor può fronteggiare il signaling per nascondere entrambi gli IP a pesante costo di latenza.
Verifica Realistica delle Prestazioni
La velocità P2P è limitata dalla larghezza di banda di upload del peer più lento e dalla latenza round-trip. Sulle connessioni residenziali, i limiti di upload sono spesso 20-50 Mbps anche quando il download è gigabit. Un trasferimento P2P da 10 GB da un upload domestico a 20 Mbps a un destinatario gigabit richiede almeno 68 minuti. Il relay cloud con un uplink veloce e download CDN-backed può battere quello caricando una volta su un server ben connesso. P2P vince per i trasferimenti stesso-LAN (gigabit o più veloci), i dati sensibili dove nessuna copia lato server è accettabile e l'ottimizzazione dei costi quando le bollette di larghezza di banda sarebbero dolorose.
Quando il Relay Cloud Vince Ancora
Per i trasferimenti asincroni dove mittente e destinatario non sono online simultaneamente, P2P fallisce completamente: non c'è peer per ricevere. Per i grandi trasferimenti che superano la finestra di sessione (le tab del browser mobile si chiudono, i laptop vanno in standby), il modello "carica e condividi un link" del relay cloud è semplicemente più pratico. Per la distribuzione uno-a-molti, un singolo upload più fanout CDN batte l'esecuzione di N sessioni P2P simultanee. HexaTransfer usa il modello di relay cloud con crittografia AES-256-GCM lato client tramite crittografia end-to-end, ottenendo la maggior parte del beneficio di privacy del P2P con un supporto molto migliore per i trasferimenti asincroni e multi-destinatario.
Prova su https://hexatransfer.com — gratuito, senza account, massimo 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file