Hallo,

ich bin dabei ein Server-Client system zu entwickeln. Die eigentliche Verbindung und Datenkommunikation funktioniert auch. Nun möchte ich, dass sich die Clients per Handshake authentifizieren.

Über google konnte ich nur eine C# methode für einen Seriellen Port finden. Diese hilft mir jedoch nicht.

Wie kann ich einen Handshake für ein TCP Netzwerk entwickeln?

Vielen Dank im vorraus.

TCP Kommunikation heisst, dass du das inhaltliche Protokoll selbst definieren musst. Ergo auch deinen eigenen Handshake.
Aber warum meinst du, dass das eine gute Idee ist? Glaubst du wirklich, dass du das Wissen hast eine eigene Authentifizierung mit Handshake zu schreiben?

Komponenten sollten über standardisierte Kommunikationsprotokolle arbeiten, wieso verwendest du einen solchen wie http zB REST oder gRPC nicht?
Da ist alles eingebaut.

Wenn du glaubst "ich schreib Mal kurz ein auth TCP Handshake" dann hast du nicht verstanden, welches Fass du öffnen willst ;-)

Ich arbeite als Softwareentwickler C# und habe den Auftrag erhalten einen Handshake zu entwickeln. Leider darf ich auf die Details nicht eingehen aber soviel kann ich sagen.
Es wird keine Websache entwickelt. Allgeimein gesprochen soll ein Serverdienst laufen (läuft auch) welcher auf Clients zum anmelden wartet. Der Verbindungsaufbau an sich funktioniert und auch der Datenaustausch.

Nun soll sich der Client erst anmelden und und der Server (Dienst) die Anmeldung bestätigen.

Du meisten hier im Forum arbeiten als Software Entwickler; deswegen sind wir hier. Und die meisten hier haben >10-15 Jahre Erfahrung.
Ob nun eine Websache entwickelt wird oder nicht ist egal; Protokolle wie HTTP bzw. Aufsätze wie REST und gRPC basieren auf TCP und können überall verwendet werden, wo TCP funktioniert.

Willst Du das nicht, dann musst Du eben Dein eigenes Protokoll entwickeln, und darauf achten, dass auch der Handshake an für sich sicher ist.
Dir reicht dann auch kein nacktes TCP mehr, sondern Du musst einen sicheren Kanal aufbauen, zB über TLS wie es HTTP für den Authentifizierungshandshake macht (und denk dran TLS 1.3 zu nutzen, da 1.0 und 1.1 bereits veraltet sind und auch von Betriebssystemen bald geblockt werden).

Ansonsten hast Du eben ein Handshake über einen unsicheren Kanal, der einfach abgefangen werden kann.

Daher nochmal der Hinweis: wenn Du denkst "mal kurz" nen TCP Auth Handshake zu bauen, dann viel Erfolg :-)
In TCP gibt es keine eingebaute Authentifizierungsmechanismen, das musst Du alles komplett alleine und selbst umsetzen. Siehe dazu https://tools.ietf.org/html/rfc793 wenn Du es nicht glaubst.
Dass das alles andere als "mal kurz" passiert und es dafür keine fertigen Komponenten gibt, weil so halt TCP nicht funktioniert, wirst dann irgendwann merken, denke ich ;-)

TCP als Layer 4 ist verantwortlich für die Kommunikation zwischen Geräten, und dass die Pakete ankommen; nicht für Applikationsauthentifizierung.
Das passiert im Layer 5. Siehe Basics: Internetprotokollfamilie

Daher entwickelt man - vor allem mit wenig Erfahrung - sowas auch nicht selbst, sondern verwendet Standards.

Zitat

Nun soll sich der Client erst anmelden und und der Server (Dienst) die Anmeldung bestätigen.

So funktioniert jede Webanwendung, quasi jede Web / HTTP Api und jeder Datenbank-Server.
Das ist Alltag :-)

Wenn Du den Auftrag hast eine Handshake zu entwickeln, dann hast Du auch eine Anforderung.
Und dann musst Du eben - wenn Du das willst - ein eigenes Protokoll entwickeln und darin Authentifizierung einbauen, wie es zB. in HTTP implementiert ist.
Kannst Dir ja Dinge von https://tools.ietf.org/html/rfc2616 abschauen
Alternativ kannst Du Dich ja von how-to-build-a-protocol-on-top-of-tcp inspirieren lassen.

Das ist das, was Du mit HTTP und Dingen wie OAuth standardisiert mit wenigen Zeilen Code umsetzen kannst.

Hallo Loofsy,

wenn Abts Vorschläge nicht angewandt werden können*, so kann der ASP.NET Core WebServer Kestrel dazu verwendet werden. Als Beispiel siehe MultiProtocolAspNetCore. D.h. Kestrel, als verifizierter WebServer, übernimmt die ganze Arbeit für dich und du brauchst nur via ConnectionHandler die Logik hinzufügen.

* sollte das ein Vorgesetzter so vorschreiben, so hat dieser keine Ahnung und betreibt Geld- / Ressourcenvernichtung

mfG Gü

Hallo Loofsy,

das TCP Protokoll hat im Securitybereich einen 3-Wege-Handshake

Besser wäre es der Expertise von Abt und gfoidl zu folgen. Du bewegst dich damit in Layer 4 sprich dem Transportlayer - da würde ich tunlichst die Finger von lassen
wenn ich nicht weiß was ich da mache. Und da du offensichtlich, wie vermutlich viele von uns, einer davon bist - tu dir das nicht an.

Nutze wie gfoidl oder Abt das vorgeschlagen haben einen Vermittler.

gfoidl bekräftige ich in der Aussage - wenn jemand dazu drängt ein Handshake selbst zu entwickeln, dann ist er entweder in den Layern unterwegs und kennt sich damit aus
oder er hat schlicht keine Ahnung.

Wenn möglich - bau auf der Gegenseite einen Service auf (Kestrel oder ähnlich) auf auf der handelt das dann...

Da du aber über die Details nicht schreiben kannst / darfst, musst du letztendlich argumentieren :-).

Grootjes,
D.

Zitat von dscNRW

das TCP Protokoll hat im Securitybereich einen 3-Wege-Handshake

Der Drei-Wege-Handshake ist kein Sicherheitsmechanismus, sondern wird für den garantierten Transport von Paketen verwendet.

Danke für die Korrektur @Abt - ich ging bisher davon aus, dass ein 3-Wege-Handshake ein Teil der Sicherheit ausmacht und somit zur Sicherheit beiträgt.....

Zitat

Aus dem RFC 793 Seite 30 / 31 The three-way handshake reduces the possibility of false connections. It is the implementation of a trade-off between memory and messages to provide information for this checking.....

TCP hat keinerlei Sicherheitsmechanismus, was die Identitätsverwaltung betrifft. Also wirklich: gar keine. Dafür ist TCP nicht da.
Der erste Sicherheitsmechanismus existiert in Layer 5 (also eines über der TCP-Verantwortung), sehr weit verbreitet ist hier -> Transport Layer Security
Das UDP äquivalent ist Datagram Transport Layer Security

TLS hat dabei einen eigenen Handshake, der aber mit dem TCP Handshake nichts zutun hat.
Während der TCP Handshake die garantierte Übertragung verantwortet, verantwortet der TLS Handshake die verschlüsselte Übertragung.

Der verschlüsselte, sichere Kanal kann dann für inhaltliche Protokolle verwendet werden, wie zB. HTTP um darin eine Applikationsauthentifizierung, wie sie hier der Threadersteller wünscht, umzusetzen.
Es macht nämlich keinen Sinn irgendeine Authentifizierung auf dem nackten TCP Kanal zu übertragen, weil er ansonsten mit einfachsten mitteln im Klartext abgefangen werden kann.

Er, so beschreibt er es, will die Applikationsebene authentifizieren, also zwei Applikationsteilnehmer.
Und das macht man auf der Applikationsebene mit Hilfe der darunter befindlichen Kommunikationsbasis, zB. mit OAuth auf HTTP Basis.
Basierend auf seiner Antwort "Es ist keine Websache" vermute ich, und das ist wirklich nur eine Vermutung, dass er nicht weiß, was HTTP wirklich ist und dass man das auch ausserhalb des Internets verwenden kann, weil es ein einfaches Netzwerkprotokoll ist - und dass dies mittlerweile das Standard-Protokoll für genau so eine Client-Server Kommunikation ist.

Anders kann ich mir nicht erklären, wie man auf die Idee kommt, dass es eine gute Idee ist, ein eigenes Protokoll mit einem eigenen Authentifizierungsmechanismus zu entwickeln.
In meinen Augen ist das auf einer Skala von 0 bis 10 für schlechte Ideen mindestens eine 11.

Fazit:
Wie man sehen kann bewegt sich der Thread-Ersteller in einer völlig falschen Ebene, um sein Vorhaben sicher umzusetzen.

Edit: ja, Dein RFC zeigt genau meine Aussage: es geht nur um die Verbindungsverwaltung.
Es geht nicht um die Authentifizierung zweier Kommunikationsendpunkte.

Und wie man sehen kann: Ich bewegte mich bisher auch auf der völlig falschen Spur - danke Abt für den Hinweis.

Vllt ist der Begriff "Handshake" inkorrekt.

Der Prozess soll im Wesentlichen folgendes machen.

1. Starte Server -> Server wartet auf anfrage
2. Client sendet Anfrage an den Server (inhalt: Clientname und einen Identifier)
3. Server nimmt Anfrage entgegen und prüft ob sich der Client anmelden darf. Ist das der Fall geht der Client sammt Tcp-Verbindung in den Cache (in meinem Fall ein Dictionary)
4. Client sendet nun anfrage an anderen Client und der Server leitet die anfrage weiter.
5. Angefragter Client verarbeitet die Anfrage und sendet antwort über den Server an den Anfragenden Client.


soll soll der grobe Ablauf sein.

Jo, das ist im Endeffekt ein Handshake.
Meine Beiträge oben, dass man sowas nicht blauäugig selbst erfinden sollte, hab weiter seine Gültigkeit :-)

Ich habs bereits gemerkt XD. Das ist ein echtes Brett