[TCP/IP] Verstaendnissfrage zu "Authentication Handshake"

[Loetkolben]

Hallo zusammen,

 

wenn ich den Authentication Handshake richtig verstanden habe, wird ueber ein Secret (Schluessel) eine Tuer geoeffnet, aber alle weitere Kommunikation laeuft dann ohne Schluessel oder Verschluesselung ab?

 

Dass heisst, dass jemand zwar eine laufende Kommunikation zum Stack mitlesen kann, aber diese weder uebernehmen noch selbst starten kann, weil ihm das Secret (Schluessel) fehlt.

 

Liege ich da richtig?

 

Der Loetkolben

[borg]

Das ist komplett richtig. Wir authentifizieren den Verbindungsaufbau. Wir verwenden keine Verschlüsselung.

 

Für jemanden der unsere Hardware in öffentlichen Netzen betreibt und dem der Inhalt der Nachrichten wichtig ist empfehlen wir weiterhin ein VPN oder vergleichbares zu verwenden.

[Stefan]

Digest access authentication ist normalerweise durch einen Man-in-the-middle-Angriff verwundbar.

 

Ich konnte in http://www.tinkerforge.com/de/doc/Low_Level_Protocols/TCPIP.html#llproto-tcpip-authentication auf die Schnelle auch keine Maßnahme, die dies verhindert, finden. Ist dies richtig oder habe ich etwas übersehen?

[borg]

Wenn der Man-in-the-middle vollständige Kontrolle über die Daten hat die über die Leitung gehen kann er eine bestehende Verbindung übernehmen und sie nutzen.

[Stefan]

Heißt dies, dass der Man-in-the-middle Angreifer auch nach dem Verbindungsaufbau die bestehende Verbindung übernehmen kann?

 

Beim Verbindungsaufbau kann er ohne Probleme die Verbindung übernehmen.

Hier gäbe es aber eine Lösungsmöglichkeiten.

Der HMAC-SHA1 würde asymmetrisch verschlüsselt übertragen. Ich kann aber nicht einschätzen, ob ein Brick mit Ethernet bzw. Wifi-Extension in der Lage ist, dies zu machen. Man könnte die Verschlüsselung auch optional anbieten, falls Brickd (dieser läuft ja meistens auf relativ potente Hardware) eingesetzt wird.

 

Optional könnte man in Verbindung mit Brickd  auch eine vollständige symmetrische Verschlüsselung (nach asymmetrischem Schlüsselaustausch) anbieten. Dies müsste auch sicher sein, wenn der Man-in-the-middle Angreifer auch nach dem Verbindungsaufbau die bestehende Verbindung übernehmen kann.

[borg]

Die Authentifiakation wie wir sie betreiben verhindert das eine aus dem Internet aufgerufene Webseite Zugriff auf Bricks/Bricklets bekommt.

 

Wenn dein Projekt so wichtig ist dass du Angst davor hast das ein Netzwerkadministrator oder die NSA dir in einer bestehenden Verbindung rumpfuscht würde ich empfehlen die Kommunikation über ein VPN laufen zu lassen. Das ist viel sicherer als alles was wir auf dem Microcontroller implementieren könnten.

[Stefan]

Jetzt verstehe ich den Einsatzzweck für die Authentifiakation.

 

Ich persönlich habe mein Brick nicht im Internet (z.B. per dyndns) hängen. Da müsste sich der Angreifer in meinem Heimnetzwerk befinden. Natürlich wäre es besser, wenn dagegen auch das Brick geschützt wäre, aber dies ist nur ein "nice to have" und nicht unbedingt nötig.

 

Ich würde diese Problematik und die Lösung mit dem VPN in die Dokumentation eintragen. Anfänger könnten denken, dass die Authentifikation unknackbar ist und so z.B. das Brick direkt per dyndns betreiben.

[Loetkolben]

Da müsste sich der Angreifer in meinem Heimnetzwerk befinden

 

Richtig, und den holst du dir sozusagen selbst ins Haus. 

Weil das durch die Websockets bzw. www.brickv.com moeglich ist, ist dieser Schutz hinzugekommen.

 

Es dient aber auch dazu, dass in einem lokalen Netz nicht der Sohn ausversehen sich zu dem Stack connected der die Gartenteichfontaene steuert. 

 

Der Loetkolben.