Verhindern, dass der Mensch in der Mitte Angriff, während mit https

Question

Ich bin ein wenig app ähnlich wie omegle zu schreiben. Ich habe einen HTTP-Server in Java geschrieben und einen Client, ein HTML-Dokument ist. Die wichtigste Methode der Kommunikation ist von HTTP-Anfragen (long Polling).

habe ich eine Art von Sicherheit implementiert, indem das https-Protokoll und ich habe einen securityid für jeden Kunden, dass die Verbindung zum Server. Wenn der Client eine Verbindung herstellt, wird der Server eine securityid gibt, die muss der Kunde immer zurückschicken, wenn es eine Anforderung will.

Ich habe Angst vor dem Mann in der Mitte Angriff hier, haben Sie Vorschläge haben, wie ich die App von einem solchen Angriff schützen können.

Beachten Sie, dass diese App Build für theoretische Zwecke, wird es nicht immer aus praktischen Gründen verwendet werden, so dass Ihre Lösungen müssen nicht unbedingt praktisch sein.

Answer 1

HTTPS nicht nur die Verschlüsselung tun, sondern auch die Authentifizierung des Servers. Wenn ein Client eine Verbindung herstellt, hat der Server zeigt es einen gültigen und vertrauenswürdiges Zertifikat für seine Domäne. Dieses Zertifikat kann nicht einfach durch ein Man-in-the-Middle-Spoofing oder wiedergegeben werden.

Answer 2

Einfach ermöglicht HTTPS ist nicht gut genug, weil die Bahn zu viele Komplikationen bringt.

Für eine Sache, stellen Sie sicher, stellen Sie die sichere Flagge auf die Cookies, sonst können sie gestohlen werden.

Es ist auch eine gute Idee, die Benutzer Zugriff auf die Website über die Eingabe https://<yourdomain> in der Adressleiste nur, um sicherzustellen, das ist der einzige Weg, um eine HTTPS-Sitzung, um sicherzustellen, ist mit einem gültigen Zertifikat hergestellt. Wenn Sie https://<yourdomain> geben, wird sich weigern, den Browser, den Sie auf der Website zu lassen, wenn der Server ein gültiges Zertifikat für <yourdomain> bietet.

Wenn Sie nur <yourdomain> eingeben, ohne https: // vor, würde nicht der Browser egal, was passiert. Dies hat zwei Folgen ich aus der Spitze von meinem Kopf denken kann:

1. Der Angreifer Umleitungen zu einem gewissen Unicode-Domäne mit einem ähnlichen Namen (dh: sieht gleich aus, aber hat eine andere Binärkette und ist somit eine andere Domäne), und dann stellt der Angreifer ein gültiges Zertifikat für die Domäne (da er es besitzt), der Benutzer wahrscheinlich nicht diese ...

würde es merken

2. Der Angreifer könnte den Server emulieren, aber ohne HTTPS, würde er seine eigene gesicherte Verbindung an den realen Server machen und ein unverschlüsselt Proxy zwischen Ihnen wird und der Server, kann er jetzt erfaßt alle Ihren Verkehr und tut, was er will denn er besitzt die Sitzung.