9
Datenschutz mit SSL und ... ?
Moin moin!
Ich mache mir gerade Gedanken, wie man Daten ahörsicher übertragen kann.
Konkret geht es um einen Webshop, bei dem eine Bestellung getätigt wird.
(Programmiert mit PHP)
Die Kundendaten sollen abhörsicher übertragen werden.
Vom Client zum Server(Apache) ist das mit SSL natürlich kein Problem.
Aber wie löst man das Problem des erneuten Anzeigens der Daten - z.B. bei einer Bestellübersicht vor Absenden der Bestellung.
In diesem Fall müssen ja wieder die Daten vom Server auf den Client gelangen, was mit SSL ja nicht abhörsicher machbar ist.
Frage: Wie löst man sowas in der Praxis?
Kenne nur den Trick bei z.B. Kreditkartendaten nicht die ganze Zahl zu übermitteln - also als "xxx xxxx xxxx 4567" - aber bei Adressdaten, die auch gesichert übertragen werden sollen - geht das ja nicht.
Gruß,
Colt Seavers
Ich mache mir gerade Gedanken, wie man Daten ahörsicher übertragen kann.
Konkret geht es um einen Webshop, bei dem eine Bestellung getätigt wird.
(Programmiert mit PHP)
Die Kundendaten sollen abhörsicher übertragen werden.
Vom Client zum Server(Apache) ist das mit SSL natürlich kein Problem.
Aber wie löst man das Problem des erneuten Anzeigens der Daten - z.B. bei einer Bestellübersicht vor Absenden der Bestellung.
In diesem Fall müssen ja wieder die Daten vom Server auf den Client gelangen, was mit SSL ja nicht abhörsicher machbar ist.
Frage: Wie löst man sowas in der Praxis?
Kenne nur den Trick bei z.B. Kreditkartendaten nicht die ganze Zahl zu übermitteln - also als "xxx xxxx xxxx 4567" - aber bei Adressdaten, die auch gesichert übertragen werden sollen - geht das ja nicht.
Gruß,
Colt Seavers
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Kommentar vom Moderator masterG am 23.01.2010 um 11:09:47 Uhr
verschoben nach "Verschlüsselung&Zertifikate"
Content-ID: 134168
Url: https://administrator.de/forum/datenschutz-mit-ssl-und-134168.html
Ausgedruckt am: 04.04.2025 um 11:04 Uhr
9 Kommentare
Neuester Kommentar
Hey!
SSL erzeugt eine verschlüsselte Verbindung -> also ist ein sicheres Übertragen in beide Richtungen möglich.
Gruß
SSL erzeugt eine verschlüsselte Verbindung -> also ist ein sicheres Übertragen in beide Richtungen möglich.
Gruß
Vielen Dank für die schnelle Antwort.
Aber leider stimmt das so nicht ganz.
Die Verbindung ist in beide Richtungen verschlüsselt, das stimmt wohl. Aber die Daten vom Server zum Client sind mit dem Public-Key verschlüsselt, den jeder "Man in the middle" auch bekommt.
Von daher sind die Daten bei der Übertragung vom Server zum Client fast genauso "sicher", wie wenn man sie im Klartext überträgt...
(Deshalb ja auch die abgehackten Kreditkartennummern... )
Gruß,
Markus
Aber leider stimmt das so nicht ganz.
Die Verbindung ist in beide Richtungen verschlüsselt, das stimmt wohl. Aber die Daten vom Server zum Client sind mit dem Public-Key verschlüsselt, den jeder "Man in the middle" auch bekommt.
Von daher sind die Daten bei der Übertragung vom Server zum Client fast genauso "sicher", wie wenn man sie im Klartext überträgt...
(Deshalb ja auch die abgehackten Kreditkartennummern... )
Gruß,
Markus
Hallo Markus,
dies geht in der Tat nur wenn der Client auch ein eigenes Zertifikat hat.
Ob es eine Möglichkeit, dass der Client sich selber ein temporäres auszustellt und dem Client den Public Key gibts, weiß ich leider nicht.
Stefan
dies geht in der Tat nur wenn der Client auch ein eigenes Zertifikat hat.
Ob es eine Möglichkeit, dass der Client sich selber ein temporäres auszustellt und dem Client den Public Key gibts, weiß ich leider nicht.
Stefan
Servus Stefan,
naja, aber da muss es doch irgendein workaround geben. gibt ja schliesslich millionen onlineshops - die werden die daten an dieser stelle ja nicht alle unverschlüsselt vom server laden....
alternative 1:
hab schon überlegt, ob man vielleicht zu beginn des bestellabschlusses die adressdaten in nem cookie speichert, und dieses cookie (oder die daten darin) nach erfolgter bestellung wieder löscht.
alternative 2:
oder gibts vielleicht ne praktikable möglichkeit, dass der server die daten nur an die IP rausrückt, von der sie auch gekommen sind. das würde ja ebenfalls den "Man in the middle" aussperren.
Das sind alles so Ideen, die ich dazu habe. Will da aber nicht rumexperimentieren, sondern suche nach einer bewährten Methode, die allgemein als sicher anerkannt ist.
Gruß,
Markus
naja, aber da muss es doch irgendein workaround geben. gibt ja schliesslich millionen onlineshops - die werden die daten an dieser stelle ja nicht alle unverschlüsselt vom server laden....
alternative 1:
hab schon überlegt, ob man vielleicht zu beginn des bestellabschlusses die adressdaten in nem cookie speichert, und dieses cookie (oder die daten darin) nach erfolgter bestellung wieder löscht.
alternative 2:
oder gibts vielleicht ne praktikable möglichkeit, dass der server die daten nur an die IP rausrückt, von der sie auch gekommen sind. das würde ja ebenfalls den "Man in the middle" aussperren.
Das sind alles so Ideen, die ich dazu habe. Will da aber nicht rumexperimentieren, sondern suche nach einer bewährten Methode, die allgemein als sicher anerkannt ist.
Gruß,
Markus
Hallo,
Also Alternative 1 ist sehr riskant. Kreditkartendaten in einem Cookie abzulegen. Jeder Trojaner auf dem Client könnte die ja auslesen. Alternative 2 klappt auch nicht. Der Server antwortet sowieso nur an die IP von der die Anfrage kommt. Der Trick liegt ja darin unsichtbar dazwischen zu liegen.
Meiner Meinung ist die Anzeige mit den XXXX-XXXX-XXXX-1234 die einzig wirksame Methode. Client Authentifizierung fällt auch weg, weil ein eingreifen am Client erforderlich ist. Und das ist bei einem Onlineshop nicht zumutbar.
mfG
Also Alternative 1 ist sehr riskant. Kreditkartendaten in einem Cookie abzulegen. Jeder Trojaner auf dem Client könnte die ja auslesen. Alternative 2 klappt auch nicht. Der Server antwortet sowieso nur an die IP von der die Anfrage kommt. Der Trick liegt ja darin unsichtbar dazwischen zu liegen.
Meiner Meinung ist die Anzeige mit den XXXX-XXXX-XXXX-1234 die einzig wirksame Methode. Client Authentifizierung fällt auch weg, weil ein eingreifen am Client erforderlich ist. Und das ist bei einem Onlineshop nicht zumutbar.
mfG
was mit SSL ja nicht abhörsicher machbar ist
Das ist Quark.
Eine SSL-Session ist immer gegen Man-In-The-Middle-Attacken sicher.
Es ist dabei völlig unerheblich ob die Daten vom Client zum Server oder zurückwandern, die Session-Negotiation macht das Abhören unmöglich.
Die einzige Chance SSL abzuhören besteht durch Termination und Wiederaufbau, wie es z.B. Forefront TMG kann..
Unter Verwendung des SSL-Handshake-Protokolls findet zunächst eine geschützte Identifikation und Authentifizierung der Kommunikationspartner statt. Anschließend wird mit Hilfe asymmetrischer Verschlüsselung oder des Diffie-Hellman-Schlüsselaustauschs ein gemeinsamer symmetrischer Sitzungsschlüssel ausgetauscht. Dieser wird schließlich zur Verschlüsselung der Nutzdaten verwendet.
(Wikipedia: http://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol_Secure )Der Pubkey des Servers dient lediglich dazu den Server zu identifizieren, das verwechseln wir jetzt mal bitte nicht mit Verschlüsselung!
Grüße
Max
Leider ist das nicht ganz richtig dog:
Es ist möglich eine SSL Verbindung mitzusniffen. Habe es dieses Semster im Praktikum selber durchgeführt. Ettercap ist in der Lage SSL Zertifikate on-the-fly zu fälschen. Es öndert sich nur der Fingerprint des Zertifikats. Darauf wird man zwar aufmerksam gemacht, aber seien wir ehrlich, 99% der Nutzer übergehen diese Meldung.
@coltseavers:
Die Übertragung ist in beide Richtungen gleich sicher, ein Unterschied der Übertragungsrichtungen gibt es nicht. Dafür sorgt, wie dog schon erwähnt, zb. das Diffie-Hellmann-Protokoll. Mit asymetrischer Kryptografie wird ein gemeinsamer Schlüssel für eine symmetrische Verschlüsselung ausgehandelt, der nur dem Server und dem Client bekannt sind.
Gruß
Es ist möglich eine SSL Verbindung mitzusniffen. Habe es dieses Semster im Praktikum selber durchgeführt. Ettercap ist in der Lage SSL Zertifikate on-the-fly zu fälschen. Es öndert sich nur der Fingerprint des Zertifikats. Darauf wird man zwar aufmerksam gemacht, aber seien wir ehrlich, 99% der Nutzer übergehen diese Meldung.
@coltseavers:
Die Übertragung ist in beide Richtungen gleich sicher, ein Unterschied der Übertragungsrichtungen gibt es nicht. Dafür sorgt, wie dog schon erwähnt, zb. das Diffie-Hellmann-Protokoll. Mit asymetrischer Kryptografie wird ein gemeinsamer Schlüssel für eine symmetrische Verschlüsselung ausgehandelt, der nur dem Server und dem Client bekannt sind.
Gruß
Das habe ich erwähnt 
Die Aussage ist aber falsch. Gesnifft wird hier nur die unverschlüsselte Verbindung, da SSL vorher terminiert und nachher wieder aufgebaut wird.
SSL per se ist nicht abhörbar (korrekter: der Inhalt einer SSL-Verbindung ist nicht abhöhrbar)
Und da wären wir beim eigentlichen Problem von SSL:
Es macht zwei grundverschiedene Dinge auf einmal: Nämlich Partner zu identifizieren und die Verbindung zu verschlüsseln. Das ist aber kaum jemandem bewusst und sorgt für eine Menge Chaos...
Die einzige Chance SSL abzuhören besteht durch Termination und Wiederaufbau, wie es z.B. Forefront TMG kann..
Es ist möglich eine SSL Verbindung mitzusniffen.
Die Aussage ist aber falsch. Gesnifft wird hier nur die unverschlüsselte Verbindung, da SSL vorher terminiert und nachher wieder aufgebaut wird.
SSL per se ist nicht abhörbar (korrekter: der Inhalt einer SSL-Verbindung ist nicht abhöhrbar)
Darauf wird man zwar aufmerksam gemacht, aber seien wir ehrlich, 99% der Nutzer übergehen diese Meldung.
Und da wären wir beim eigentlichen Problem von SSL:
Es macht zwei grundverschiedene Dinge auf einmal: Nämlich Partner zu identifizieren und die Verbindung zu verschlüsseln. Das ist aber kaum jemandem bewusst und sorgt für eine Menge Chaos...
Ohje, was hier so alles geschrieben wird...
Um eine Verbindung zum Web-Server einmal trivial zu erklären, unter anderem auch die Art der Verschlüsselung im Bezug auf symmetrischer und asymmetrischer Verschlüsselung - Folgendes:
Zunächst baut der Client eine Verbindung zum Webserver auf.
Da er eine sichere Verbindung aufbauen möchte, greift er auf den Port für HTTP über SSL zu. Dies ist im Allgemeinen Port 443.
Der Server "antwortet" mit einer Kopie seines öffentlichen Zertifikatsschlüssels (Public Key)
Danach überprüft der Client, ob dieser Zertifikatsschlüssel von einem Herausgeber (d. h. einer Stammzertifizierungsstelle) stammt, dem er vertraut.
Diese Prüfung endet nur dann positiv, wenn das Zertifikat der Stammzertifizierungsstelle im Zertifikatsspeicher für "vertauenswürdige Stammzertifizierungsstellen" des Clients hinterlegt ist.
Kurz gesagt, ist die Logik folgende: Ich vertraue der Stammzertifizierungsstelle, also traue ich auch allen Zertifikaten, welche diese Zertifizierungsstelle herausgegeben hat / herausgibt!.
Der Nachweis, dass ein Zertifikat wirklich von einer Stammzertifizierungsstelle kommt, funktioniert über kryptografische Methoden....
Nun handeln Client und Server einen Sitzungsschlüssel aus.
Da der Client über den ASYMMETRISCHEN! öffentlichen Schlüssel des Servers verfügt, kann er den Sitzungsschlüssel so verschlüsseln, dass dieser nur vom Server mit dessen privatem Schlüssel decodiert werden kann!
Mit dem SYMMETRISCHEN! Sitzungsschlüssel können nun die Daten verschlüsselt werden, die ausgetauscht werden sollen.
Gruß,
Ole
Um eine Verbindung zum Web-Server einmal trivial zu erklären, unter anderem auch die Art der Verschlüsselung im Bezug auf symmetrischer und asymmetrischer Verschlüsselung
- Folgendes:Zunächst baut der Client eine Verbindung zum Webserver auf.
Da er eine sichere Verbindung aufbauen möchte, greift er auf den Port für HTTP über SSL zu. Dies ist im Allgemeinen Port 443.
Der Server "antwortet" mit einer Kopie seines öffentlichen Zertifikatsschlüssels (Public Key)
Danach überprüft der Client, ob dieser Zertifikatsschlüssel von einem Herausgeber (d. h. einer Stammzertifizierungsstelle) stammt, dem er vertraut.
Diese Prüfung endet nur dann positiv, wenn das Zertifikat der Stammzertifizierungsstelle im Zertifikatsspeicher für "vertauenswürdige Stammzertifizierungsstellen" des Clients hinterlegt ist.
Kurz gesagt, ist die Logik folgende: Ich vertraue der Stammzertifizierungsstelle, also traue ich auch allen Zertifikaten, welche diese Zertifizierungsstelle herausgegeben hat / herausgibt!.
Der Nachweis, dass ein Zertifikat wirklich von einer Stammzertifizierungsstelle kommt, funktioniert über kryptografische Methoden....
Nun handeln Client und Server einen Sitzungsschlüssel aus.
Da der Client über den ASYMMETRISCHEN! öffentlichen Schlüssel des Servers verfügt, kann er den Sitzungsschlüssel so verschlüsseln, dass dieser nur vom Server mit dessen privatem Schlüssel decodiert werden kann!
Mit dem SYMMETRISCHEN! Sitzungsschlüssel können nun die Daten verschlüsselt werden, die ausgetauscht werden sollen.
Gruß,
Ole
