Il posto dove guardare è lo standard proposto TURN, RFC 5766. Lo standard fornisce un mezzo per la trasmissione di pacchetti UDP contenenti dati applicativi tra un client e un peer:
volta creato un'allocazione, il client può inviare dati dell'applicazione al server insieme con l'indicazione di cui scrutare i dati deve essere inviato e il server trasmetterà questi dati al peer appropriato. Il client invia i dati dell'applicazione al server all'interno di un messaggio TURN; sul server, i dati vengono estratti dal messaggio TURN e inviati al peer in un datagramma UDP. Nella direzione opposta, un peer può inviare i dati dell'applicazione in un datagramma UDP all'indirizzo di trasporto inoltrato per l'allocazione; il server quindi incapsulerà questi dati all'interno di un messaggio TURN e lo invierà al client insieme a un'indicazione di quale peer ha inviato i dati.
Il livello più alto analizzato da TURN è il livello UDP. Non capisce o modifica il livello dati dell'applicazione (nel tuo caso, il protocollo WebRTC). Lo standard dice:
Una domanda che desideri garantire che i suoi dati non siano alterati o falsificati deve proteggere i dati a livello di applicazione.
Questo implica che si può integrità-proteggere i dati delle applicazioni, e sua volta trasmetterlo senza modifiche. Puoi anche guardare i dettagli del protocollo TURN (che non ripeterò qui) che dimostrano che si limita a racchiudere e inoltrare i dati dell'applicazione.
Infine, la norma dice questo su intercettazioni:
riservatezza per i dati delle applicazioni inoltrati da sua volta è migliore fornito dal protocollo di applicazione in sé, dal momento che l'esecuzione girare TLS non protegge i dati delle applicazioni tra il server e il peer . Se la riservatezza dei dati dell'applicazione è importante, l'applicazione deve crittografare o proteggere in altro modo i propri dati.Per esempio , per i supporti in tempo reale, la riservatezza può essere fornita da tramite SRTP.
La raccomandazione in questo estratto è quello di proteggere la riservatezza cifrando i dati delle applicazioni con un protocollo come DTLS-SRTP, che utilizza WebRTC.
Poiché TUR non interpreta o modifica i dati dell'applicazione, non aggiunge alcuna vulnerabilità di sicurezza al traffico dati dell'applicazione WebRTC che non sarebbe presente senza utilizzare TURN. I dati WebRTC sono crittografati tra gli endpoint WebRTC.
Ora, nessuno può garantire che non vi sia "nessuna possibilità per il server TURN di accedere al segreto". Un server TURN errato può tentare un attacco man-in-the-middle sulla tua connessione con la stessa facilità con cui chiunque può intercettare i tuoi pacchetti di rete. È vero solo che l'utilizzo di un relè TURN non indebolisce la sicurezza WebRTC.
Finché DTLS è implementato e utilizzato correttamente e presupponendo che gli algoritmi e le cifre del DTLS siano sicuri, il traffico WebRTC deve essere protetto end-to-end. Parte dell'utilizzo di qualsiasi schema basato su SSL richiede la verifica del certificato dell'altro endpoint, proprio come HTTPS. E proprio come HTTPS, questo richiederà uno scambio fuori banda prioritario di identità del certificato o l'uso di una terza parte attendibile. E proprio come HTTPS, se i certificati non vengono verificati correttamente, la porta sarà aperta per un attacco MITM (da parte di chiunque, non solo dei server TURN).
Questa risposta va sicuramente nella giusta direzione. È chiaro che la crittografia deve essere eseguita a livello di applicazione, affinché funzioni la crittografia end-to-end. Ma 1. Non sono sicuro al 100%, se "Il livello più alto che TURN analizza è il livello UDP.": Ci sono le opzioni dtls e tls in https://code.google.com/p/rfc5766-turn-server/wiki/turnserver. E 2. Non sono sicuro al 100% se WebRTC esegue lo scambio di chiavi per DTLS con il server TURN o con l'altro client. Non ho trovato nulla a riguardo nelle specifiche WebRTC. –
@ChrisLercher, Il protocollo TURN stesso può essere protetto da TLS o DTLS per la connessione tra client e server (TLS è consentito nella RFC 5766, DTLS è un evidente miglioramento). Questa crittografia incapsula il traffico tra client e server e si trova in cima a qualsiasi crittografia nel livello applicazione. Nel codice open source, la descrizione delle opzioni '--no-tls' e' --no-dtls' (definita in mainrelay.c, usata in netengine.c) dice in realtà che questo si applica a * listener client *, indicando le prese per il livello del protocollo TURN. – rhashimoto
@ChrisLercher, WebRTC non specifica l'handshaking DTLS perché fa parte di DTLS. DTLS è solo una versione UDP di TLS, quindi può garantire la crittografia end-to-end. Ma proprio come HTTPS, funziona solo se verifichi il certificato del tuo pari - altrimenti, come temi, qualcuno può usare un attacco MITM. E, proprio come HTTPS, le implementazioni WebRTC devono verificare i certificati per essere sicuri. Questo è trattato nella sezione 8.3.5 della bozza del W3C: in attesa che tutte le connessioni DTLS siano stabilite e controllando che le impronte digitali dei certificati su tutte le connessioni corrispondano a quelle fornite dall'IdP. – rhashimoto