Wie funktioniert Verschluesselung bzw. sichere Datenuebertragung

[Sven Rautenberg]

Moin!

sagen wir mal ich moechte Dir z.B. ein XML-Dokument per http zukommen lassen und moechte dieses Verschluesseln. Wie lasse ich Dir den Schluessel zum Entschluesseln zukommen?

Die Möglichkeit, per PGP zu verschlüsseln, hat Peter Kaufmann bereits erwähnt.

Die grundsätzliche Frage ist: Woher weißt du, an wen du das schicken mußt? Wie kannst du sicher sein, dass der Ort, an dem du die Daten wie-auch-immer ablieferst, unter meiner Kontrolle steht, bzw. nur mir Einsicht gewährt.

Antwort: Du kannst es nicht wissen, ohne dass es dir jemand sagt. Beispielsweise ich. Oder jemand anderes. Aber gerade weil jemand anderes ja auch sagen könnte: "Schick das per Mail an [e-mail], das kommt immer an!", mußt du diese Angaben irgendwie verifizieren.

Ich sehe bei SSL in der Tat ein Problem. Machst du Online-Banking? Deine Bank hat für den Kontozugang ein signiertes SSL-Zertifikat. Das war nicht billig, und die Bank hat dafür alle möglichen Nachweise bringen müssen, dass die zu zertifizierende Domain auch wirklich ihr gehört bzw. dass das alles mit rechten Dingen zugeht.

Wenn jetzt ein böser Angreifer einen "bankserver2" eröffnet und dafür ein Zertifikat einer anderen Stelle kriegen würde, würde kein Browser der Welt Alarm schlagen. Und wenn er es schafft, für das gesamte Internet, oder zumindest für einen kleineren Teil diesen "bankserver2" anstelle des Originals zu platzieren, würde niemand Verdacht schöpfen.

Die Zertifizierungsstellen sind also wirklich ziemlich wichtige Institutionen, welchen alle Welt gezwungenermaßen gehöriges Vertrauen entgegenbringt, ohne dass sie davon weiß.

Das ist aber auch nur deswegen der Fall, weil SSL eben nicht nur zum Verschlüsseln, sondern auch zum Authentifizieren benutzt werden kann.

Wenn du hingegen SSH (Secure Shell) benutzt, wird der Datenverkehr zwar verschlüsselt, aber irgendwelche obskuren Zertifizierungsstellen sind nicht involviert. Der Server hat sich bei der Installation des SSH-Servers einen möglichst eindeutigen Fingerprint zugelegt, und beim ersten Kontakt (bei dem man selbst sicherstellen muß, dass dieser zum richtigen Server erfolgt - indem man beispielsweise den per Papierpost übermittelten Fingerprint vergleicht) wird man gebeten, den Fingerprint zu bestätigen, damit der Server in die Liste bekannter Server aufgenommen wird. Auch ohne die Aufnahme ist der Datenverkehr verschlüsselt - dieser Mechanismus soll einfach verhindern, dass man arglos einen ausgetauschten und untergeschobenen Server kontaktiert und dem das Passwort mitteilt.

Sie ist deswegen vorhanden, um SSL-Zertifikate auf den Webservern digital zu unterschreiben. Zusammen mit den in eigentlich allen Browsern installierten Zertifikaten dieser Stellen kann der Browser nicht nur die Verschlüsselung aktivieren, sondern automatisch auch die Authentizität des Servers feststellen. Denn nur der Server, der ist, wofür er sich ausgibt, wird eine gültige Unterschrift haben.

Das interesiert mich. Habe ich die o.g. Funktionalitaet in meinem Ausgangsposting treffend beschrieben?

Nein, weil der Browser und der Server nicht in Kontakt mit einer dritten Stelle stehen.

Und es ist auch problemlos möglich, ohne eine dritte Stelle eine eigene Unterschrift zu benutzen.

Zurzeit bezweifle ich diese Aussage stark.

Ganz einfach: Du kannst deine eigene Zertifizierungsstelle eröffnen. Dann spielst du beispielsweise "Thawte" oder "Verisign" in klein. Und kannst deinen eigenen SSL-Serverschlüssel unterschreiben.

Dein Zertifikat installierst du dann noch auf deinem benutzten Browser, und künftig meckert der nicht mehr darüber, dass er das Zertifikat des HTTPS-Servers seltsam findet.

Wenn du die Sicherheit aller Übermittlungskanäle sicherstellen kannst, auf denen die Zertifikate etc. übermittelt werden, dann kann dir mit sehr hoher Wahrscheinlichkeit niemand falsche Daten unterschieben.

Nun, ich habe gute Erfahrung damit gemacht bestimmte Konzept-Implementation, ja ich traue mich sogar, bestimmte Produkte zu schreiben, nachzubauen. - Z.B. DB-Replikationen oder das gute alte Sitzungskonzept. Das ist gut fuer's Verstaendnis, glaub's mir einfach mal.

Das sei dir unbenommen. Aber so, wie es sich für mich zur Zeit darstellt, willst du das Rad ein zweites Mal erfinden. Was hälst du davon, stattdessen erstmal die traditionellen Anwendungen zum Laufen zu kriegen? Also Apache mit mod_ssl (welches seinerseits OpenSSL benötigt), dann die ganze Geschichte mit den Schlüsseln und Zertifikaten etc. - da ist zum Lernen wirklich reichlich Potential, auch ohne Neuerfindungen. :) Und zum Verzweifeln, weil irgendwas nicht geht, vermutlich auch.

- Sven Rautenberg