Prevenire attacco man in the middle durante l'utilizzo di HTTPS

Question

Sto scrivendo una piccola applicazione simile a Omegle. Ho un server http scritto in Java e un client che è un documento HTML. La principale via di comunicazione è di richieste HTTP (polling lungo).

Ho implementato una sorta di sicurezza utilizzando il protocollo https e ho un IDsicurezza per ogni client che si connette al server. Quando il collega client, il server dà un IDsicurezza, che il cliente deve sempre mandare indietro quando vuole una richiesta.

ho paura di un uomo in mezzo l'attacco qui, hai qualche suggerimento come potrei proteggere l'applicazione da un simile attacco.

Si noti che questa applicazione è costruire per scopi teorici, non sarà mai utilizzato per ragioni pratiche in modo che le soluzioni non devono essere necessariamente pratico.

Answer 1

HTTPS non fare solo la crittografia, ma l'autenticazione anche del server. Quando un client si connette, gli spettacoli del server ha un certificato valido e affidabile per il suo dominio. Questo certificato non può essere semplicemente falsificato o riprodotto da un man-in-the-middle.

Answer 2

Semplicemente consentendo HTTPS non è abbastanza buono perché il web porta troppe complicazioni.

Per prima cosa, assicurarsi di impostare il flag sicuro i biscotti, o altro che possono essere rubati.

E 'anche una buona idea per garantire agli utenti l'accesso solo il sito tramite digitazione https://<yourdomain> nella barra degli indirizzi, questo è l'unico modo per garantire una sessione HTTPS è fatto con un certificato valido. Quando si digita https://<yourdomain>, il browser si rifiuterà di farvi sul sito a meno che il server fornisce un certificato valido per <yourdomain>.

Se è sufficiente digitare <yourdomain> senza https: // nella parte anteriore, il browser wont importa cosa succede. Questo ha due implicazioni che posso pensare fuori della parte superiore della mia testa:

1. I redirect malintenzionato di qualche dominio unicode con un nome simile (vale a dire: sembra la stessa, ma ha una stringa binaria diversa ed è quindi un dominio diverso) e poi l'attaccante fornisce un certificato valido per il dominio (da quando ha lo possiede), l'utente probabilmente non notare questo ...

2. L'attaccante potrebbe emulare il server ma senza HTTPS, che avrebbe fatto la propria connessione protetta al server reale e diventare un proxy cifrato tra te e il server, può ora catturare tutto il traffico e fare tutto quello che vuole perché egli possiede la sessione.