Autenticazione strong su collegamenti non sicuri

Se il tuo livello di incapsulamento non è sicuro, puoi adattarlo creando un livello sicuro all'interno se hai un ID di chiave pubblica noto per l'host remoto.

Dato che l'IP non è sicuro, eseguiamo SSL al suo interno. Poiché le tue sessioni SSL vengono forzatamente interrotte a un host indesiderato rendendole insicuri, esegui un altro livello sicuro in esse come SSL. SSL su SSL, SSH su SSL o qualsiasi altra combinazione di tunneling dovrebbero fornire una connessione affidabile purché si verifichi la chiave host.

all traffic on the network between the client and the server is being intercepted and viewed

... implica che può anche essere modificato - quindi nessuna sessione, nessun javascript.

along the lines of a web-application

Quindi l'unico modo in cui posso pensare di implementarlo è tramite OTP, e dovresti disabilitare il lato client javascript per impedire le falsificazioni delle richieste di MITB. Ma dal momento che non è possibile fare affidamento sull'integrità della sessione, è necessario aggiungere una nuova password a ciascuna richiesta HTTP per poterla autenticare. Ma se stai parlando di un'applicazione HTML5 installata in modo sicuro, allora questa è una storia diversa: puoi semplicemente implementare la tua incapsulamento del traffico AJAX utilizzando la crittografia simmetrica + PSK o uno dei crescenti numeri di javascript librerie asimmetriche .

Since these are being actively MITM'd

Quindi stai tentando di aggirare la politica di sicurezza locale?

Ecco come lo facciamo: link . Fondamentalmente, il token software convalida che il certificato SSL mirato che l'utente ottiene è uguale a quello memorizzato sul server OTP. Se non è valido, l'OTP non viene visualizzato. I token utilizzano chiavi asimmetriche per comunicare con il server, non con SSL. Fammi sapere se vuoi maggiori informazioni.

PSK potrebbe, in alcune circostanze, essere una soluzione. Cripta tutti i dati con il PSK. Solo gli host consentiti saranno in grado di comunicare.