nicht angemeldet
Daten-Verifikation oder Verschlüsselung ohne Zertifikat möglich?
Hallo!
Ich sitze an einem Projekt (AutoIt) für einen Webserver, über den eine lokale Anwendung gesteuert werden soll.
Für das Login habe ich schon die Authentifizierung mit Http-Auth Digest umgesetzt.
Nun stehe ich vor der Frage, wie ich die Komunikation absichern kann.
SSL setzt ein Zertifikat voraus, das um sicher zu sein, von einer der vertrauenswürdigen Zertifizierungsstellen stammen muss.
Das würde Kosten verursachen und die Beschaffung wäre für den normalen Nutzer mit relativ hohem Aufwand verbunden.
Ausserdem, was noch viel schwerer wiegt, ist die Komunikation über SSL alles andere als trivial.
Der genutze Mechanismus muss auf jeden Fall im Browser selbst implementiert sein, weil z.b. in Javascript implementierte Methoden durch die Übertragung des Codes über das Netz als kompromitiert anzusehen sind.
Eine Möglichkeit wäre es, für jeden Request, der sensible Daten enthält, eine neue Authentifizierung per Digest anzufordern, also jedes mal die Passworteingabe zu verlangen.
Eine elegantere Lösung wäre mir allerdings lieber. Gibt es Verfahren, die ohne Zertifikate auskommen und in den modernen Brwosern verfügbar sind?
freundl. Grüsse aus Berlin, Raik
-
Hallo,
SSL setzt ein Zertifikat voraus, das um sicher zu sein, von einer der vertrauenswürdigen Zertifizierungsstellen stammen muss.
Du kannst das Zertifikat auch selbst signieren, verschlüsselt werden dann die Daten trotzdem bei der Übertragung. Nur das Zertifikat wird halt beim User als "Nicht sicher" angezeigt, weil Du als Zertifizierungsstelle nicht vertrauensvoll bist.
Die Signierung durch eine Zertifizierungsstelle dient ja "nur" dazu, zu versichern, dass der Server, von dem die Daten stammen, auch wirklich der ist, der er behauptet zu sein. Die Verschlüsselung selbst hat aber nichts mit der Signierung des Zertifikats zu tun.Es hängt aber natürlich vom konkreten Anwendungsfall ab, ob das was ausmacht oder nicht. Für einen Webshop würde ich sowas sicher nicht machen, wenn ich aber z.b. meinen eigenen Server daheim damit steuern will und nur sicher gehen möchte, dass niemand die Verbinudng abhört, ist das IMO völlig ausreichend.
Ausserdem, was noch viel schwerer wiegt, ist die Komunikation über SSL alles andere als trivial.
Inwiefern? Musst Du in der Anwendung unter die HTTP-Schicht, also ISO/OSI-Layer 5 oder tiefer?
Viele Grüße,
Jörg-
Hallo mrjerk!
Die Signierung durch eine Zertifizierungsstelle dient ja "nur" dazu, zu versichern, dass der Server, von dem die Daten stammen, auch wirklich der ist, der er behauptet zu sein. Die Verschlüsselung selbst hat aber nichts mit der Signierung des Zertifikats zu tun.
Wenn ich es richtig verstanden habe, fragt ja der Browser bei einem umbekannten Zertifikat die Zertifizierungsserver ab, ob das Zertifikat gültig ist. dazu wird eine zweite Http-Verbindung aufgebaut, für die es extrem umwarscheinlich ist, dass sie zufällig über die gleichen Server im Netz aufgebaut wird, wie die erste und auf denen potentiell der "Man in the Middle" sitzen könnte.
Ohne diese Prüfung kann das von meinem Webserver übermittelte Zertifikat ja einfach vom Angreifer gegen sein eigenes ausgetauscht werden, so dass er die Client-Antworten entschlüsseln und mit dem ursprünglichen Zertifikat zur Weiterleitung an den Webserver wieder verschlüsseln könnte.
Ergo, sichere Übertragung kompromitiert.Ehe ich SSL "nur so halb" anwende, gehe ich lieber über den umständlicheren Weg der Bestätigung jedes sensiblen Requests per Auth-Digest.
Das wäre doch, als würde man eine dicke Kette um Fahrradrahmen und Laterne legen, aber das Schloss nicht zudrücken.Ausserdem, was noch viel schwerer wiegt, ist die Komunikation über SSL alles andere als trivial.
Inwiefern? Musst Du in der Anwendung unter die HTTP-Schicht, also ISO/OSI-Layer 5 oder tiefer?Ich würde die Funktionen in den SSL-dlls ansprechen und richtig gebrauchen können müssen. Im AutoIt-Forum hab ich bisher selbst von den "Gurus" immer die Antwort bekommen: zu komplex.
wüstest du, welche funktion man in welcher reihenfolge mit welchen parametern in welchem format ansprechen müsste?freundl. Grüsse aus Berlin, Raik
-
Hallo,
Wenn ich es richtig verstanden habe, fragt ja der Browser bei einem umbekannten Zertifikat die Zertifizierungsserver ab, ob das Zertifikat gültig ist. dazu wird eine zweite Http-Verbindung aufgebaut, für die es extrem umwarscheinlich ist, dass sie zufällig über die gleichen Server im Netz aufgebaut wird, wie die erste und auf denen potentiell der "Man in the Middle" sitzen könnte.
So weit ich weiß, wird hierzu keine zweite HTTP-Verbindung aufgebaut - die Information, ob Dein Host vertrauenswürdig ist, steckt bereits im Sicherheitszertifikat, welches Dir die CA (oder eben Du selbst :)) ausstellt. Mag mich täuschen, aber hier siehts auch so aus.
Der Rest stimmt allerdings. Der Einsatz eines selbst-signierten Zertifikats schützt Dich nur davor, dass Daten unverschlüsselt über die Leitung gehen und "mitgelesen" werden können - es verhindert aber keine Man-in-the-middle-Attacken, bei denen jemand seinen Server als Deinen ausgibt.
wüstest du, welche funktion man in welcher reihenfolge mit welchen parametern in welchem format ansprechen müsste?
Nein. Deswegen frug ich ja, ob eine Kommunikation auf HTTPS-Ebene nicht reichen würde. Wenn Du natürlich so tief hinunter musst, dass Du an die Roh-Daten heran musst, wirds natürlich knifflig.
Viele Grüße,
Jörg-
Hallo mrjerk!
Der Rest stimmt allerdings. Der Einsatz eines selbst-signierten Zertifikats schützt Dich nur davor, dass Daten unverschlüsselt über die Leitung gehen und "mitgelesen" werden können - es verhindert aber keine Man-in-the-middle-Attacken, bei denen jemand seinen Server als Deinen ausgibt.
da mit zugriff auf doie komunikation schon viel schaden angerichtet werden könnte, muss ich diese schon absichern.
wüstest du, welche funktion man in welcher reihenfolge mit welchen parametern in welchem format ansprechen müsste?
Nein. Deswegen frug ich ja, ob eine Kommunikation auf HTTPS-Ebene nicht reichen würde. Wenn Du natürlich so tief hinunter musst, dass Du an die Roh-Daten heran musst, wirds natürlich knifflig.das ansprechen der dlls ist nicht schwer, wenn man die richtigen parameter kennt. die und die reihenfolge sind das problem.
und das unsichere zertifikat natürlich.freundl. Grüsse aus Berlin, Raik
-
Tach,
Der Rest stimmt allerdings. Der Einsatz eines selbst-signierten Zertifikats schützt Dich nur davor, dass Daten unverschlüsselt über die Leitung gehen und "mitgelesen" werden können - es verhindert aber keine Man-in-the-middle-Attacken, bei denen jemand seinen Server als Deinen ausgibt.
da mit zugriff auf doie komunikation schon viel schaden angerichtet werden könnte, muss ich diese schon absichern.also entweder ein eigenes Zertifikat und dessen Fingerprint über einen anderen sicheren Kanal austauschen oder einer Zertifizierungsstelle vertrauen, das gibt es dann auch bei StartSSl kostenlos, wie ich erwähnte. Inwieweit man den Zertifizurungsstellen vertauen möchte, ist dann noch ein anderes Thema, siehe z.B. http://blog.fefe.de/?ts=b25933c5 und http://blog.fefe.de/?ts=b2570a98.
mfg
Woodfighter-
Hallo Jens!
vielen dank für die links, sehr erhellend.
deshalb wäre es das beste, der browser hätte eine technik integriert, mit der man durch eingabe eines passwortes in einen programmeigenen dialog eine verschlüsselte komunkation herstellen könnte. ähnlich wie http-auth digest, nur eben ab da für die ganze komunikation. dann käme es nur noch auf die stärke des passwortes an.
wenn sich auf die art wenigstens die sensiblen (steuerbefehle für die ferngesteuerte anwendung enthaltenden) requests gegen manipulation absichern liessen, würde mir das ja auch schon reichen.freundl. Grüsse aus Berlin, Raik
-
Tach,
deshalb wäre es das beste, der browser hätte eine technik integriert, mit der man durch eingabe eines passwortes in einen programmeigenen dialog eine verschlüsselte komunkation herstellen könnte.
haben wir ja https, nur mit Zertifikaten statt Paßworten (es gibt ja auch Client-Zertifikate für die Authentifizierung von Clients); da ich denke, dass Paßworte als Technik für wichtige Dinge eh verschwinden werden (lange Paßworte sind nicht merkbar, kurze sind inzwischen viel zu leicht knackbar), werden wir in dem Bereich in näherer Zukunft einiges an Neuerungen sehen.
mfg
Woodfighter
-
-
-
-
-
-
-
Tach,
SSL setzt ein Zertifikat voraus, das um sicher zu sein, von einer der vertrauenswürdigen Zertifizierungsstellen stammen muss.
Das würde Kosten verursachen und die Beschaffung wäre für den normalen Nutzer mit relativ hohem Aufwand verbunden.mfg
Woodfighter
