Authentifizierung im TCP/IP Netzwerk

[Valle]

Hallo DPler! :hi:

Da ich bei meinen Suchen im Internet nicht passendes gefunden habe, bin ich nun dabei mir ein eigenes Protokoll für mein Vorhaben zu schreiben. Das Protokoll ist für die Kommunikation von einem im Webserver laufendem PHP Prozess und einem als User root laufendem Python-Programm.

Die Kommunikation der beiden Komponenten (PHP & Python) ging schon immer über sogenannte Unix-Sockets. Diese werden nicht wie bei TCP/IP über Host und Port identifiziert, sondern über Dateien. Logische Konsequenz daraus ist, dass die Sockets nur auf der gleichen Maschine kommunizieren können. Das muss ich jetzt ändern, da wir demnächst weitere Server dazu bekommen. Funktionieren tut das ganze schon, da das Protokoll unabhängig von der darunter liegenden Schicht ist. Allerdings gibt es nun ein Problem mit der Sicherheit.

Bei Unix-Sockets hatte ich den Vorteil, dass ich der Socket-Datei einfach entsprechende Rechte (0770) geben konnte uns ihr eine bestimmte Gruppe zuordnete. Alle User in dieser Gruppe hatten damit Zugriff auf das Socket. Unter TCP/IP geht das schlecht. Daher brauche ich eine neue Form der Authentifizierung. Am einfachsten wäre es, einfach ein Passwort im Protokoll mit zu schicken. Ich bin mir aber nicht sicher, ob das so eine gute Idee ist. Der Datenverkehr ist ja auch nicht verschlüsselt. Und jetzt zur eigentlich Frage: Wie mache ich die Authentifizierung am besten und sichersten?

Hoffe ihr habt's verstanden, ansonsten natürlich einfach nachfragen! Danke im Voraus! :)

Mit freundlichen Grüßen,

Valle

[generic]

Da kann man viel bis wenig machen!

* einfach user/pw übertragen
* challange & response verfahren
* zertifikat basiert verfahren

und das alles mit und ohne verschlüsselung.

[Valle]

Hallo generic,

erstmal Danke für die Antwort! :)

Zertifikat-basiert klingt toll, finde ich. Bisher habe ich ziemlich wenig Ahnung von der Materie, was also eine ideale Möglichkeit wäre sich damit mal zu beschäftigen. Kannst du mir einige Stichworte oder so nennen, damit ich ausreichend Informationsstoff zum googlen habe? Wäre SSL in diesem Zusammenhang eine Wahl?

Mit freundlichen Grüßen,

Valle

[generic]

SSL kann diese Funktion auch abdecken.
Dann schnapp dir am besten die aktuellen Indy's und die OpenSSL Dlls und dann passt das schon.
Ich selbst habe sowas auch noch nicht programmiert. Habe bis jetzt immer den Webserver die Sache übernehmen lassen.

Was ist ich allerdings mal gemacht habe, war eine Domänenauthentifierung über TCP.
Allerdings benötigst du dafür ein Active-Directory. Das ist dann das Thema SSPI.

[Valle]

Zitat:

Zitat von generic

SSL kann diese Funktion auch abdecken.
Dann schnapp dir am besten die aktuellen Indy's und die OpenSSL Dlls und dann passt das schon.

Ich benutze Python und PHP. :stupid:

Zitat:

Zitat von generic

Ich selbst habe sowas auch noch nicht programmiert. Habe bis jetzt immer den Webserver die Sache übernehmen lassen.

Der Webserver ist in dem Fall gar nicht beteiligt. Lediglich der PHP Prozess wird vom Webserver ausgeführt, das hilft mir aber auch nicht weiter. Letztendlich muss ich das selbst machen. ;-)

Zitat:

Zitat von generic

Was ist ich allerdings mal gemacht habe, war eine Domänenauthentifierung über TCP.
Allerdings benötigst du dafür ein Active-Directory. Das ist dann das Thema SSPI.

Und ich benutze Linux. :mrgreen:

Mit freundlichen Grüßen,

Valle

[generic]

Na gut dann halt nicht Delphi in einem Delphi Forum.

Wir Delphianer können ALLES! Manche Dinge nur nicht besonders gut.

Aus Py halte ich mich mal raus, aber PHP sollte nicht so das Problem sein.

Dafür gibt es ja:
http://de.php.net/manual/en/book.openssl.php

[Apollonius]

Eigentlich müsste das doch mit beidseitig authentifiziertem SSL gehen, d.h. Server und Client haben beide ein Zertifikat und weisen sich damit aus. Jetzt ist nur noch die Frage, was für Zertifikate du verwendest. So wie es aussieht, müsstest du eigentlich deine eigenen Zertifikate erstellen können (d.h. du bastelst dir selbst eine Authority, der du dann per se vertraust). Die Frage ist dabei natürlich, inwiefern die SSL-Bibliothek deines Vertrauens dir erlaubt, selbst zu entscheiden, ob ein Zertifikat gültig ist.

[Valle]

Zitat:

Zitat von generic

Wir Delphianer können ALLES!

Deswegen bin ich doch hier. :thumb:

Zitat:

Zitat von Apollonius

Eigentlich müsste das doch mit beidseitig authentifiziertem SSL gehen, d.h. Server und Client haben beide ein Zertifikat und weisen sich damit aus. Jetzt ist nur noch die Frage, was für Zertifikate du verwendest. So wie es aussieht, müsstest du eigentlich deine eigenen Zertifikate erstellen können (d.h. du bastelst dir selbst eine Authority, der du dann per se vertraust). Die Frage ist dabei natürlich, inwiefern die SSL-Bibliothek deines Vertrauens dir erlaubt, selbst zu entscheiden, ob ein Zertifikat gültig ist.

Ich denke mal die erste Wahl ist wohl OpenSSL. Liegt wohl auch daran, dass ich bisher noch von nichts anderem gehört habe. Ansonsten Danke für die Info, dann wird's jetzt wohl (endlich) mal Zeit mich in die Materie einzuarbeiten. Bisher konnte ich mich da immer schön von fern halten. :mrgreen:

Edit:// Es wird wohl doch eher GnuTLS.

Zitat:

Zitat von Wikipedia

Zusätzlich zu den meisten in OpenSSL implementierten Funktionen unterstützt GnuTLS TLSv1.1, zlib- und LZO-Kompression, Authentifizierung über SRP, X.509- und OpenPGP-Keys.

Mit freundlichen Grüßen,

Valle

[Nikolas]

Wenn die Übertragung nicht verschlüsselt ist, warum machst du überhaupt eine Authentifizierung?
Wenn sich ein Rechner authentifiziert hat, kann man doch eine man-in-the-middle-Attacke fahren oder wird das irgendwie durch dein Protokoll verhindert?

Wenn sich deine Sockets per Datei identifizieren, könntest du diese Dateien doch per ssh/scp übertragen. So ganz habe ich die Dateien noch nicht verstanden. Wenn ein Rechner mit dem Server redet, haben dann beide die gleiche Datei oder ist das etwas in Richtung public/private Key wie bei ssh?

Wenn ein neuer Rechner kommt, könnte der doch eine Datei per scp in einen nur-schreiben-Ordner im Server legen, in der dann das Passwort und ID steht. Dann könnte der Server dem Rechner wieder per scp einen passenden Schlüssel/Authentifizierung, sonstwas schicken, mit der sich dann der Rechner von da an melden kann.

Nach einer gewissen Zeit kann dann der Server dieses Zertifikat wieder ungueltig machen und der Client muss sich wieder neu anmelden.

Und ein Pythonscript als root? Da musst du schon gut auf deine Rechte aufpassen, nicht dass dir jemand ein exec('rm -rf') (oder ist das Java?) reinschreibt : )

Also zusammengefasst: schau dir mal das public-Key anmelden per ssh an, damit müsstest du das eigentlich hinbekommen können.

Aber beschreib vielleicht mal ein bischen genauer, wer wann mit welchem Server reden muss.

[Valle]

Zitat:

Zitat von Nikolas

Wenn die Übertragung nicht verschlüsselt ist, warum machst du überhaupt eine Authentifizierung?
Wenn sich ein Rechner authentifiziert hat, kann man doch eine man-in-the-middle-Attacke fahren oder wird das irgendwie durch dein Protokoll verhindert?

Das versuche ich ja gerade zu ändern. Wobei ich mir nicht sicher bin, ob ich einer Man-in-the-Middle überhaupt vorbeugen muss, das die Server in versch. Rechenzentren stehen und nur über das Internet kommunizieren.

Zitat:

Zitat von Nikolas

Wenn sich deine Sockets per Datei identifizieren, könntest du diese Dateien doch per ssh/scp übertragen. So ganz habe ich die Dateien noch nicht verstanden. Wenn ein Rechner mit dem Server redet, haben dann beide die gleiche Datei oder ist das etwas in Richtung public/private Key wie bei ssh?

Wenn ein neuer Rechner kommt, könnte der doch eine Datei per scp in einen nur-schreiben-Ordner im Server legen, in der dann das Passwort und ID steht. Dann könnte der Server dem Rechner wieder per scp einen passenden Schlüssel/Authentifizierung, sonstwas schicken, mit der sich dann der Rechner von da an melden kann.

Nach einer gewissen Zeit kann dann der Server dieses Zertifikat wieder ungueltig machen und der Client muss sich wieder neu anmelden.

Nein, das funktioniert so nicht. Stell dir einfach vor es ist wie TCP/IP. Statt IP und Port gibst du allerdings einen einfachen Dateipfad an. Schau einfach mal hier, das ist ja nicht meine Erfindung. ;-)

Letztendlich ist das aber auch irrelevant, da das ja nun geändert wird.

Zitat:

Zitat von Nikolas

Und ein Pythonscript als root? Da musst du schon gut auf deine Rechte aufpassen, nicht dass dir jemand ein exec('rm -rf') (oder ist das Java?) reinschreibt : )

Python ist es jedenfalls nicht. :mrgreen: Dennoch hat das durchaus seinen Sinn, bzw. das ist ja der Grund, warum ich das ganze brauche. Ich könnte natürlich auch einfach PHP als root laufen lassen (da es die entsprechenden Rechte braucht), aber das ist ja nun noch 100 Mal hirnloser. Also lieber eine Kommunikation über's Netzwerk und nur das machen lassen, was es es soll. ;-)

Zitat:

Zitat von Nikolas

Also zusammengefasst: schau dir mal das public-Key anmelden per ssh an, damit müsstest du das eigentlich hinbekommen können.

Wie schon gesagt, das ist nicht das was ich will. Wie man Dateien per scp kopiert und sich per SSH über Passwort oder Public-Key einloggt weiß ich schon länger. :-)

Zitat:

Zitat von Nikolas

Aber beschreib vielleicht mal ein bischen genauer, wer wann mit welchem Server reden muss.

Ein PHP-Script soll sich über das Internet (TCP/IP) bei einen Python-Programm authentifizieren. Die beiden sollen ein wenig kommunizieren, anschließend macht mein Python-Programm etwas als root und dann kann das PHP-Script bei seiner Arbeit weiter machen. Und weil ich eben noch nie eine Authentifizierung programmiert habe, dachte ich, ich frage einfach mal nach. ;-)

Danke für deine Hilfe! :)

Mit freundlichen Grüßen,

Valle

[Nikolas]

Hey Valle

Sorry, ich glaub, ich hab dich n bischen unterschätzt. Wenn du schon ein solches Protokoll schreibst,
hätte ich eigentlich wissen können, dass du schon mal mit ssh/scp gearbeitet hast.

Ich habe einen Vorschlag für ein Verfahren, das ich mal DoppelHashingVerifizierung nenne.


Client und Server teilen sich als Geheimniss eine Zahl (64bit int) (symmetrisches Verfahren), der Client hat eine ID.


Wenn der Client einen Befehl absetzen will geht er folgendermaßen vor: Sei P die Nachricht, die er senden will:
Hash(P)=H_1
Hash(H_1+Geheimniss)=H_2 // wobei das Plus nicht unbedingt als Addition gelesen werden sollte!

Client: "P H_1 H_2"

Der Server berechnet beide HashWerte und verifiziert den Befehl. Jetzt fängt jemand das Packet ab und will seinen eigenen Befehl schicken.

Er verändert P. Deswegen muss er auch H_1 verändern, da Hash(P)==H_1 vom Server kontrolliert wird.
Damit müsste er auch H_2 verändern, was er aber nicht kann, da er das Geheimniss nicht kennt.

Mit einem Hash würde es wahrscheinlich auch gehen, wäre aber nicht so einfach. Irgendwie müsstest du das Geheimniss in den Befehl einknoten, was dann der Server wieder rückgängig machen müsste, mit dem Doppelhash geht das eigentlich recht elegant.

Ich weiss nicht genau, ob das ganze wirklich sicher ist, aber vielleicht dient es als Ansatz.

[Valle]

Hallo,

mittlerweile ist es zwar schon eine Weile her, aber das Thema ist noch nicht tot. ;-)

Ich habe jetzt einfach die Kommunikation mit RSA verschlüsselt. Jedes Datenpaket wird mit einem Counter versehen, der bei jedem Sende-Schritt inkrementiert wird. Das verhindert eine Packet-Replay Attacke. Der Counter wird von einem zufälligen Wert aus gestartet. Leider ist die Angelegenheit jetzt echt langsam geworden. :?

Mit freundlichen Grüßen,

Valle

[Apollonius]

Selbst schuld, wenn du ständig RSA verwendest. :P Asymmetrische Verschlüsselung ist nun mal langsam. Deshalb wird bei praktisch allen Protokollen RSA nur am Anfang verwendet, um sich auf einen gemeinsamen Session-Schlüssel zu einigen, mit dem dann symmetrisch verschlüsselt wird.

[Valle]

Zitat:

Zitat von Apollonius

Selbst schuld, wenn du ständig RSA verwendest. :P Asymmetrische Verschlüsselung ist nun mal langsam. Deshalb wird bei praktisch allen Protokollen RSA nur am Anfang verwendet, um sich auf einen gemeinsamen Session-Schlüssel zu einigen, mit dem dann symmetrisch verschlüsselt wird.

Wieder was gelernt. :thumb:

Ich hatte anfangs schön SSL benutzt, das ging relativ gut und ich war echt froh als das dann funktionierte. Aber als ich das gleiche dann auf PHP-Seite machen wollte musste ich mit entsetzen feststellen, dass es scheinbar nicht möglich ist mit PHP SSL-Sockets zu verwenden - zumindest nicht in dem Funktionsumfang wie ich ihn bei GnuTLS benutzt habe. Schade eigentlich, wo PHP doch im Funktionsumfang nicht viel missen lässt. :cry:

Mit freundlichen Grüßen,

Valle