Sto sviluppando un server di inoltro VoIP pubblico, che aiuterà a bypassare i firewall Internet consentendo a due client di connettersi con esso e quindi trasmetterà i dati tra i due. Entrambi i client si connetteranno con un endpoint API per autenticare prima e richiedere una sessione VoIP, chiavi di crittografia, ecc. L'unico compito del server VoIP è quello di ritrasmettere i dati. Stavo pensando di fornire un numero casuale (ID) a 64 bit utilizzando un CNG per entrambi i client con le chiavi di crittografia - dall'endpoint API. Il modo in cui funziona è che quando i client si connettono con il server VoIP si identificheranno semplicemente fornendo l'ID in testo semplice (senza SSL). Il relay server controllerà gli ID (e se sono validi, non usati già ecc.) E accoppierà le due connessioni internamente e risponderà con un messaggio di conferma ad entrambi i client che il collegamento è attivo. Quindi i client possono utilizzare le chiavi di crittografia (AES) per avviare l'invio reciproco dei dati crittografati. Il vantaggio che vedo di questo approccio è che non devo scrivere alcun codice di crittografia per il server di inoltro VoIP e semplificherò lo sviluppo del VoIP con un grande margine! Ragazzi, pensate che questa sia una configurazione sicura? Questo è soggetto agli attacchi Man-in-the-middle?
Alcuni chiarimenti: inizialmente entrambi i client si connetteranno con l'API EndPoint (servizio RestFul) tramite una connessione protetta (SSL) per autenticarsi, richiedere una chiamata VoIP, che creerà due ID univoci (la coppia verrebbe inviata al VoIP) Server di inoltro) e chiavi di crittografia AES (inviate solo ai client). L'idea è che il server VoIP non abbia bisogno di sapere nulla sulla connessione, quindi perché sprecare tempo e sforzi di sviluppo con l'impostazione di SSL. Accoppierà solo due connessioni l'una all'altra, quindi basta verificare gli ID che ogni connessione in ingresso sta fornendo e quindi accoppiare le due connessioni insieme (cioè inoltrare i dati da A- > B e B- > A). I client utilizzeranno la crittografia AES alle proprie estremità per crittografare i dati che inviano al server relay ma non saranno il protocollo TLS / SSL. Per quanto riguarda gli ID, entrambi i client otterranno un ID univoco, ma il server di ritrasmissione avrà entrambi gli ID, quindi può accoppiarli.