In questo momento, sembra che nessuno dei principali browser esistenti supporti TLS-PSK e nessuno dei due supporta < a href="http://tools.ietf.org/html/rfc5054"> TLS-SRP . Nel tuo caso, entrambi sono applicabili, ma SRP è "più strong" in quanto tollera molto meglio un segreto condiviso a bassa entropia (diciamo, una password). Ci sono stati alcuni sforzo iniziale nel rendere consapevole di Chrome SRP; Non so quanto è andata lontano. Poiché tutto ciò che PSK offre può essere fatto da SRP e probabilmente in un modo migliore e più strong, è plausibile che i browser avranno il supporto SRP prima di ottenere il supporto PSK. Ma non è ancora finito.
Nel frattempo, puoi avere alcuni rimedi parziali:
-
Chiedi ai tuoi utenti di utilizzare Firefox, con un profilo specifico. Un profilo Firefox include, in particolare, il set di CA radice che il browser utilizzerà per convalidare i certificati del server; consenti loro di utilizzare un profilo "vuoto" contenente solo la tua CA.
-
Fai in modo che gli utenti si connettano tramite una VPN. In particolare un tunnel SSH: SSH può essere utilizzato come proxy SOCKS, che il browser può essere istruito per utilizzare per ogni connessione. Il modello a chiave pubblica di SSH non ha CA; ogni utente decide quale chiave accetta o meno.
-
Trasforma l'applicazione Web in un'applicazione vera e propria, installata sul sistema client. L'applicazione eseguirà quindi l'SSL con il tuo server e potrà quindi scegliere qualsiasi meccanismo di autenticazione desideri utilizzare.
-
Non fare nulla: è il problema del client, non del tuo.
L'ultima "soluzione" merita qualche riflessione in più. In effetti, il problema con la potenziale CA canaglia è che questi CA sono considerati dal client . In un riuscito attacco Man-in-the-Middle , l'attaccante si pone come un server falso, e il cliente sta parlando con l'attaccante, non con te. Pertanto, come prima approssimazione, non c'è nulla che tu possa fare nel server che cambierà ciò che accade tra il client e l'attaccante. In SSL / TLS, il client annuncia tutti i pacchetti di crittografia che è disposto a utilizzare e il server ne seleziona uno. Anche se il tuo server vuole usare SRP o PSK, puoi scommettere che il server dell'attaccante preferirà un'altra suite di crittografia.
Pertanto, supponendo di trovare un browser compatibile con SRP, la sicurezza della connessione contro gli aggressori MitM (che potrebbero corrompere una CA) non dipende dall'utilizzo di SRP sul server, ma dall'utente : quel sacchetto di carne deve aspettarsi SRP (o PSK) e chiamare fallo se non lo capisce. MitM sarà sconfitto solo nella misura in cui l'utente umano, presentato con un lucchetto verde e una bella pagina di login con il tuo logo e chiedendo la sua password ottenuta tramite SMS, dirà a se stesso: "hey, questa è una pagina Web , non un popup del browser ! " e quindi rifiutare di connettersi. Se riesci a far sì che i tuoi utenti reagiscano in modo affidabile in questo modo, puoi probabilmente addestrare un gatto a fare il bucato e pulire a vuoto i tappeti (e quindi sono molto interessato ai tuoi servizi).
Ciò equivale al seguente deprimente riassunto : se i tuoi utenti si fidano della CA canaglia, allora sono già stati colpiti; e non c'è nulla che il tuo server possa fare per proteggerli davvero. Il primo passo è insegnare loro a non fidarsi della CA esistente, che ripristinerà la protezione (supponendo che le loro macchine non siano già dirottate), ma "interromperà Internet" dal loro punto di vista.