text: Datenschutz mit SSL und . - administrator.de
  Kommentar vom Moderator masterG am 23.01.2010 um 11:09:47 Uhr
  verschoben nach "Verschlüsselung&Zertifikate"
  Datenschutz mit SSL und ... ?
  23.01.2010, aktualisiert 11:09 Uhr, 4115 Aufrufe, 9 Kommentare
  LÖSUNG kopie0123 schreibt am 23.01.2010 um 02:32:45 Uhr
  LÖSUNG coltseavers schreibt am 23.01.2010 um 02:39:28 Uhr
  LÖSUNG StefanKittel schreibt am 23.01.2010 um 02:42:06 Uhr
  LÖSUNG coltseavers schreibt am 23.01.2010 um 02:52:42 Uhr
  LÖSUNG Cubic83 schreibt am 23.01.2010 um 12:35:35 Uhr
  LÖSUNG dog schreibt am 23.01.2010 um 16:09:46 Uhr
  LÖSUNG kopie0123 schreibt am 23.01.2010 um 17:22:37 Uhr
  LÖSUNG dog schreibt am 23.01.2010 um 17:31:15 Uhr
  LÖSUNG ollembyssan schreibt am 26.01.2010 um 14:04:02 Uhr
  LÖSUNG 23.01.2010 um 02:32 Uhr
  SSL erzeugt eine verschlüsselte Verbindung -> also ist ein sicheres Übertragen in beide Richtungen möglich.
  LÖSUNG 23.01.2010 um 02:39 Uhr
  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... )
  LÖSUNG 23.01.2010 um 02:42 Uhr
  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.
  LÖSUNG 23.01.2010 um 02:52 Uhr
  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....
  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.
  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.
  LÖSUNG 23.01.2010 um 12:35 Uhr
  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.
  LÖSUNG 23.01.2010 um 16:09 Uhr
  was mit SSL ja nicht abhörsicher machbar ist
  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..
  (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!
  LÖSUNG 23.01.2010 um 17:22 Uhr
  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.
  LÖSUNG 23.01.2010 um 17:31 Uhr
  Das habe ich erwähnt
  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...
  LÖSUNG 26.01.2010 um 14:04 Uhr
  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.