RootForum Community

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

Solange der gesamte Bestellablauf, also auch die Anzeige der Bestellübersicht, via SSL abläuft (was sowieso immer der Fall sein sollte bis zum Beenden des Bestellvorgangs), ist auch der Traffic vom Server zum Client verschlüsselt.

Der SSL-Handshake wird ja noch vor dem Übermitteln des eigentlichen HTTP-Requests ausgehandelt. Alles, was danach an Daten zwischen Server und Client übermittelt wird, ist natürlich verschlüsselt und durch die Verifikation des Zertifikats abgedeckt.

Vielen Dank für die schnelle Antwort.
Aber da kann ich so (mit meinem aktuellen Kenntnisstand) nicht zustimmen.
Die Daten vom Server zum Client sind zwar auch verschlüsselt, aber nur mit dem Public Key, den auch jeder "Man in the middle" problemlos bekommen kann.
Somit ist die Datenübertragung vom Server zum Client auch mit SSL-Verschlüsselung fast genauso leicht lesbar, wie wenn sie im Klartext übetragen wird.
Durch SSL wird nur die andere Richtung (vom Client zum Server) wirklich abhörsicher, weil die nur der Server entschlüsseln kann.

Danke für die Antwort, aber was da in Wikipedia geschrieben steht, trifft so ja in der Regel nicht zu. (liest eigentlich jemand Bücher zu dem Thema??)
Natürlich findet eine zertifikatbasierte Authentifizierung statt.
Ein Zertifikat von einer CA ist vorhanden.

Wenn Daten von einem Client mit dem Public Key verschlüsselt werden, so sind diese verschlüsselten Daten nur mit dem Schlüssel auf dem Server wieder zu entschlüsseln.
Ein "Man in the middle" kann keinesfalls an den Schlüssel auf dem Server kommen (sofern er ihn nicht gehackt hat). Der Schlüssel wird nie übertragen und kann deshalb auch nicht abgehört oder gar getauscht werden.
Deshalb ist die SSL-Verschlüsselung für den Transport vom Client zum Server (in der neuesten Version derzeit) auch bei einem "Man in the middle" abhörsicher. Der "Man in the middle" kann die vom Client mit dem Public Key verschlüsselten Daten mitschneiden, aber nicht entschlüsseln.
Allerdings kann er den Verkehr vom Server zum Client entschlüsseln, wenn er den Public Key hat - und den bekommt man ja leicht.

Und für diesen Transportweg (vom Server zum Client) suche ich eine sichere Möglichkeit.
Ich will da nicht groß rumexperimentieren, sondern suche eine bewährte Lösung, die allgemein als sicher anerkannt ist. (Ich hoffe bei der Existenz von Millionen Onlineshops gibt es eine solche Lösung ?! )

Danke & Gruß,
Markus

coltseavers wrote:Danke für die Antwort, aber was da in Wikipedia geschrieben steht, trifft so ja in der Regel nicht zu. (liest eigentlich jemand Bücher zu dem Thema??)

Ich würde Dir "Unix Netzwerkprogrammierung mit Threads, Sockets und SSL" von Markus Zahn ans Herz legen, wenn Du die Details verstehen möchtest (und danach ein Blick auf s_server.c und s_client.c, finden sich beide im "apps" Verzeichnis der OpenSSL Sourcen). Für den Praxis-Einsatz für nicht-Programmierer empfehle ich "Praktische Kryptographie unter Linux" von Lars Packschies.

coltseavers wrote:Wenn Daten von einem Client mit dem Public Key verschlüsselt werden, so sind diese verschlüsselten Daten nur mit dem Schlüssel auf dem Server wieder zu entschlüsseln.
Ein "Man in the middle" kann keinesfalls an den Schlüssel auf dem Server kommen (sofern er ihn nicht gehackt hat). Der Schlüssel wird nie übertragen und kann deshalb auch nicht abgehört oder gar getauscht werden.
Deshalb ist die SSL-Verschlüsselung für den Transport vom Client zum Server (in der neuesten Version derzeit) auch bei einem "Man in the middle" abhörsicher. Der "Man in the middle" kann die vom Client mit dem Public Key verschlüsselten Daten mitschneiden, aber nicht entschlüsseln.
Allerdings kann er den Verkehr vom Server zum Client entschlüsseln, wenn er den Public Key hat - und den bekommt man ja leicht.

Das ist technisch nicht korrekt, sondern (mit Verlaub) hanebüchener Blödsinn. Zunächst einmal bezüglich Deiner Aussage, "kann er den Verkehr vom Server zum Client entschlüsseln, wenn er den Public Key hat": Public und Private Keys kennt man nur bei asymmetrischen Verfahren (z. B. RSA, DSA), wie sie tatsächlich in einem Teil des SSL-Protokolls zum Einsatz kommen. Der Clou bei solchen Verfahren ist aber gerade, dass Daten, die mit dem Public Key verschlüsselt wurden, nur mit dem Private Key wieder entschlüsselt werden können. Genau aufgrund dieser Eigenschaft ist ja überhaupt erst möglich, den Public Key öffentlich zu machen.

Aufgrund des relativ großen Berechnungsaufwands bei asymmetrischen Verfahren wird selbiges allerdings bei TLS und SSL nur für das Aushandeln eines (symmetrischen) Sitzungsschlüssels verwendet; die eigentliche Payload wird mit einem symmetrischen Verfahren wie AES, CAST oder 3DES verschlüsselt.

coltseavers wrote:Und für diesen Transportweg (vom Server zum Client) suche ich eine sichere Möglichkeit.
Ich will da nicht groß rumexperimentieren, sondern suche eine bewährte Lösung, die allgemein als sicher anerkannt ist. (Ich hoffe bei der Existenz von Millionen Onlineshops gibt es eine solche Lösung ?! )

SSLv3 oder TLS ist genau das, was Du suchst. Zur Verdeutlichung hier mal das Schema bei einem HTTP/1.0 Palaver:

1. Aufbau einer TCP-Verbindung vom Client zum Server
2. SSL-Handshake; Client prüft Server-Zertifikat (und je nach Konfiguration des Servers vice versa)
3. Aushandeln einer Cipher Suite (symmetrischer Algorithmus + Hash-Verfahren): der größte (sicherste) gemeinsame Nenner wird verwendet
4. Aushandeln eines symmetrischen Schlüssels für diese TCP-Verbindung und Verifikation mit einer Test-Nachricht
5. Jetzt steht die SSL-Verbindung
6. Client sendet HTTP Request (incl. POST oder GET Parametern)
7. Verbindung bleibt weiterhin bestehen
8. Server sendet Antwort
9. Verbindung wird geschlossen; der symmetrische Sitzungsschlüssel verfällt somit

Es gibt allerdings bei HTTPS ein anderes Sicherheitsrisiko, mit dem ein Man-in-the-Middle Angriff auf einen Einkaufsvorgang möglich ist. SSL garantiert nur für die bestehende Sitzung (also einen Request + zugehöriger Antwort) die Sicherheit der Verbindung. Im nächsten Bestellschritt wird erneut eine Verbindung aufgebaut; der Server hat aber keine Möglichkeit zu prüfen, ob es sich um denselben Client handelt (da bei HTTPS üblicherweise keine Client-Authentifizierung per Zertifikat stattfindet, auch wenn dieses technisch möglich wäre).

Stattdessen verwendet man für die Identifizierung eines Clients über mehrere Requests hinweg Session IDs. Errät nun ein Angreifer die richtige Session ID, kann er trotz SSL den nächsten Request an den Server stellen, ohne dass dieser merkt, dass er es nicht mit dem ursprünglichen Client zu tun hat. Dabei sind Session IDs wesentlich leichter zu brechen als asymmetrische oder symmetrische Verschlüsselungsverfahren (z. B. durch Cross-Site-Forgery oder -Scripting Angriffe). Das ist also die eigentliche Schwachstelle, über die Du Dir Gedanken machen solltest.

Die meisten Onlineshops verschicken auch noch eine Bestellbestätigung per E-Mail, in der noch einmal alle Daten stehen - das meist unverschlüsselt und unzensiert. Da würde ich als potentieller Angreifer viel eher versuchen anzusetzen...

SSLv3/TLS geht schon klar (und entspricht auch den Empfehlungen des Gesetzgebers und der Versicherungen), auch wenn Paranoia natürlich in solch kritischen Bereichen immer sinnvoll ist.

Und rein inhaltlich denke ich, dass die meisten Kriminellen in diesem Sektor tatsächlich nur Kreditkarten- und Bankdaten ausspähen wollen - mit Name und Anschrift kann man zwar auch Schindluder treiben, aber daran hat IMHO kaum jemand Interesse. Insofern ist das Ausblenden von mehr als 50% der Kontonummer bzw. Kreditkartennummer wahrscheinlich das Ausschlaggebendste. Mehr kannst du mit zumutbarem Arbeitsaufwand wahrscheinlich nicht machen, und selbst wenn das mal irgendwie schiefläuft, wird dir daraus niemand einen Strick drehen.

Aber das sind nur meine 2 Cent, ich möchte natürlich prinzipiell jederzeit zu so vielen Sicherheitsmaßnahmen wie möglich ermuntern. :)

jfreund wrote:
Das ist technisch nicht korrekt, sondern (mit Verlaub) hanebüchener Blödsinn. Zunächst einmal bezüglich Deiner Aussage, "kann er den Verkehr vom Server zum Client entschlüsseln, wenn er den Public Key hat": Public und Private Keys kennt man nur bei asymmetrischen Verfahren (z. B. RSA, DSA), wie sie tatsächlich in einem Teil des SSL-Protokolls zum Einsatz kommen. Der Clou bei solchen Verfahren ist aber gerade, dass Daten, die mit dem Public Key verschlüsselt wurden, nur mit dem Private Key wieder entschlüsselt werden können. Genau aufgrund dieser Eigenschaft ist ja überhaupt erst möglich, den Public Key öffentlich zu machen.

Ja ich red ja auch von dem Datentransfer vom Server zum Client.
Dieser wird ja mit dem Private Key verschlüsselt und vom Client mit dem Public Key entschlüsselt. Richtig?
Und diesen Public Key kann sich ja nun jeder vom Server geben lassen, und somit den Datentransfer vom Server zum Client auch entschlüsseln - oder nicht?
(Umgekehrt is klar: Client verschlüsselt seine Nachricht mit Public Key, und diese kann dann nur vom Server entschlüsselt werden)

coltseavers wrote:Ja ich red ja auch von dem Datentransfer vom Server zum Client.
Dieser wird ja mit dem Private Key verschlüsselt und vom Client mit dem Public Key entschlüsselt. Richtig?

Nein, falsch. Der Private-Key des Servers wird nur zum entschlüsseln und zum singnieren genutzt. Die Verbindung Server -> Client wird mit dem Public-Key des Clients oder mit einem vorher ausgehandelten symetrischen Schlüssel verschlüsselt.

Du machst den großen Denkfehler davon auszugehen, dass es nur ein Schlüsselpaar gäbe (das des Servers). Auch der Client hat ein eigenes Schlüsselpaar. Für eine bidirektionale Verbindung werden 4 Schlüssel in 2 Schlüsselpaaren benötigt.

Denkfehler - es wird nur der öffentliche Schlüssel des Servers ausgetauscht (tatsächlich benötigt der Client gar kein asymmetrisches Schlüsselpaar). Offenbar wollt Ihr es ganz genau wissen, und bevor hier gefährliche Halbwahrheiten in Umlauf kommen... Also, hier ist der genaue Ablauf beim Handshake:

TCP-Verbindung
Zuerst muss natürlich eine TCP-Verbindung aufgebaut werden. Der Client sendet SYN(seq=i) an den Server. Dieser antwortet mit SYN(seq=k), ACK(seq=i+1). Darauf hin sendet der Client ACK(seq=k+1). Damit ist die Verbindung aufgebaut und beiden Seiten sind die beide Paketsequenzzähler (der eigene und der der Gegenstelle) bekannt.

SSL- bzw. TLS Handshake
Phase 1
Zuerst schickt der Client die "Begrüßungsformel" ClientHello an den Server. Der Server antwortet mit ServerHello. Danach tauschen Client und Server je 28 Bytes an Zufallsdaten (ServerHello.random bzw. ClientHello.random) aus. Danach bietet der Client dem Server eine Liste der von ihm unterstützten Cipher Suites an, also eine Kombination aus (asymmetrischem) Schlüsselaustauschverfahren, (symmetrischem) Verschlüsselungsverfahren und Message Authentication Code. Der Server wählt aus dieser Liste gemäß seiner Konfiguration die bestmögliche Kombination aus. Sind die Mengen der client- und serverseitig unterstützten Cipher Suites disjunkt, bricht der Handshake ab.

Phase 2
Der Server überträgt sein Zertifikat (also öffentlicher Schlüssel + Identitäts- und Gültigkeitsinformationen + digitale Signatur der Zertifizierungsstelle) an den Client. Optional forder der Server auch vom Client ein Zertifikat an. Damit ließen sich auch Clients per Zertifikat authentifizieren (üblich bei VPNs, seltener bei Webseiten - aber es gibt Ausnahmen).

Phase 3
Der Client versucht, die Identität des Servers zu bestätigen, indem er an den Server ein 48 Byte langes Pre-Master-Secrect schickt, das vor der Übertragung mit dem Public Key des Servers verschlüsselt wurde.

Phase 4
Der Server entschlüsselt das Pre-Master-Secret mit seinem Private Key und berechnet daraus zusammen mit den in Phase 1 ausgetauschten Zufallsdaten das Master Secret. Nun generiert der Server eine ServerFinished-Meldung, in die auch MD5- und SHA1-Hashwerte aller zuvor mit dem Client ausgetauschten Nachrichten eingebettet werden. Diese ServerFinished-Meldung wird mit dem Master Secret und dem gewählten symmetrischen Algorithmus verschlüsselt und an den Client gesendet. Dem Client liegen ebenfalls alle Informationen zur Errechnung des Master Secret und der zu erwartenden ServerFinished-Meldung vor, so dass er die Antwort des Servers mit der erwarteten ServerFinished-Meldung vergleichen kann. Sind beide Finished-Meldungen identisch, so ist dies der Nachweis, dass der Server tatsächlich über den zu seinem Public Key passenden Private Key verfügt.

Im kryptographischen Sinne ist die Verbindung damit vertraulich und integer. Alle Informationen, die ab jetzt über die Verbindung übertragen werden (egal in welcher Richtung), werden zuvor mit dem Master Secret symmetrisch verschlüsselt und mit einem Message Authentication Code versehen. Sie sind so vor unbefugter Einsicht und Manipulation geschützt. Und obwohl der Client kein asymmetrisches Schlüsselpaar eingesetzt hat, wurde das Master Secret nie über die noch nicht gesicherte Verbindung übertragen, genauso wenig das Pre-Master-Secret!

Identitätsabgleich
Ein letzter Schritt fehlt allerdings noch, um für die Verbindung nicht nur Vertraulichkeit und Integrität, sondern auch Verbindlichkeit zu gewährleisten - sprich, die Identität der jeweiligen Gegenstelle zweifelsfrei festzustellen. Verglichen mit dem Handshake ist dieser Schritt jedoch vergleichsweise simpel: Der Client (und analog auch der Server, falls er ein Zertifikat vom Client angefordert hat) gleichen erst das Zertifikat mit einer Liste bekannter (und vertrauenswürdiger) Zertifikate ab. Falls es hierbei keinen Match gibt, wird die Zertifizierungsstelle mit einer Liste vertrauenswürdiger Zertifizierungsstellen abgeglichen. Dieser Vorgang wird notfalls rekursiv wiederholt, bis das Wurzelzertifikat der Zertifikatskette abgeglichen wurde. Wurde auch bis hierhin kein Match erzielt, hängt es an der Implementierung der Anwendung, wie sie reagiert. Entweder wird die Verbindung abgebrochen, oder (bei interaktiven Anwendungen) der Anwender muss entscheiden, ob der Verbindung trotzdem vertraut wird.

So, wenn Ihr es noch genauer wissen wollt, müsst Ihr Euch schon RFC 2246 durchlesen...