TCP/IP: Sicher und unsicher zugleich:

​

SSL ist die Abkürzung für Secure Socket Layer. Mit Layer sind die Transportschichten angesprochen, mit denen der Datenaustausch zwischen zwei Rechner bildhaft dargestellt wird. Auf der obersten Ebene sind die Anwendungen angeordnet. Ganz unten befindet sich in dem Modell die Hardware. Im Idealfall lassen sich sieben Schichten definieren, denen sich wiederum im Idealfall jeweils ein Protokoll oder Programm zuordnen läßt. Alle Schichten tragen dazu bei, den Datenfluß zwischen den beiden Rechnern sicherzustellen.

Im wirklichen Leben paßt das Modell nicht immer so ideal. Das Übertragungsprotokoll TCP/IP deckt mit seinen zwei Komponenten (TCP und IP) mindestens vier Schichten ab. Das Protokoll ist eine Art Esperanto in der Rechnerwelt. Mit Ausnahme der Zuse-Rechner unterstützen wohl alle Rechner und Betriebssysteme TCP/IP (findige Tüftler haben sogar dem ZX81 TCP/IP beigebracht). Es ist einfach zu implementieren, robust und sicher -- betriebssicher. Als TCP/IP vor fast 30 Jahren erfunden wurde, stand vor allem die Absicht im Vordergrund, eine ausfallsichere und stabile Verbindung mit hoher Betriebssicherheit zu schaffen. Die Sicherheit und Authenzität der übermittelten Daten spielte eine untergeordnete Rolle.

 

Neue Schichten:

​

Mit TCP/IP war der Wunsch nach sicheren Verbindungen im Sinne von Datensicherheit nicht zu verwirklichen. Ohne TCP/IP gibt es kein Internet. Die Firma Netscape löste das Problem auf folgende elegante Weise: Die Entwickler erweiterten TCP/IP um zwei weitere Schichten.

• SSL Record Protokoll

• SSL Handshake Protocol

Das erklärt auch die Bezeichnung »Layer«; Sie liegen funktional zwischen dem Aufgabenbereich von TCP/IP und den Anwendungen. Diese beiden Schichten liegen bildlich betrachtet unmittelbar aufeinander und werden darum von einigen Autoren auch als eine einzige Schicht angesprochen. Obgleich sich in diesen beiden Schichten während einer sicheren Verbindung allerlei Software-Know-How austobt, ist sie für die angrenzenden Schichten transparent: Weder die Anwendung (der Browser, noch die unter der dem SLL-Protokoll liegende Transportschicht bemerken das Wirken des SLL-Protokoll. Im Klartext: SSL erfordert weder Änderungen vorhandener Anwendungen noch neue Transportprotokolle.

Während einer sicheren Verbindung kommunizieren die beteiligten Rechner ausschließlich über den Mechanismus, der von SSL bereit gestellt wird. Steht die sichere Verbindung nicht zur Verfügung, schaltet sich das SSL-Protokoll aus.

 

Zertifizierung:

​

Im Zentrum des SSL-Protokoll steht das digitale Schüsselpaar aus öffentlichem und privaten Schlüssel des Servers sowie die ID der Zertifizierungsstelle. Jeder virtuelle Webserver benötigt ein eigenes Schlüsselpaar, weil bei der ID unter anderem der Domain-Namen einfließt. Jede SSL-geschützte Homepage benötigt eine eigene IP-Adresse. Provider, die auf ihren Servern tausende und abertausende Präsenzen auf einer einzigen Maschine und unter einer einzigen IP-Adresse betreiben, müssen darum beim Bereitstellen eines SSL-Zertifikates passen oder zu technischen Hilfsmittel greifen.

So funktioniert der Trick: Der Browser des Besuchers verbindet sich nicht mit der eigentlichen Bestellseite, sondern mit einem Spezialserver (SSL-Proxy) des Providers. Nur bis dahin ist die Verbindung dann gesichert. Der Proxy-Server leitet die Informationen des Besuchers dann auf das eigentliche Ziel, zum Beispiel eine Bestellseite, weiter. Die Weiterleitung von dem SSL-Proxy zur Bestellseite ist dann nicht mehr gesichert. Das kann schon eine Einbuße an Sicherheit bedeuten, wenn im Netz des Providers viele Kundenserver untergebracht werden, die gegebenfalls den nunmehr ungeschützen Datenstrom abhören können.

 

Was nicht gesichert ist:

​

Das SSL-Protokoll sichert die Übertragung zwischen einer Domain auf einem Webserver und dem Besucher dieser Domain. Der On-Line-Kunde (Besucher) kann sich ziemlich sicher sein, daß seine Kreditkartennummer auf dem Weg von seinem Rechner zum Server des Shop-Betreiber gegen Ausforschung geschützt ist. Was dann mit den gesichert übertragenen Daten weiter passiert, ist jenseits dessen, was durch das SSL-Protokoll geregelt ist. Für den Kunden, der im Vertrauen auf die SSL-Sicherung seine Kontoinformationen kundgibt, ist nicht erkennbar, wie der Shop-Betreiber diese Informationen weiterverarbeitet. Es sind Fälle bekannt geworden, bei denen der Datenverarbeiter die gesichert übertagenen Daten anschließend ungesichert auf dem Server gespeichert hat. Nach einem erfolgreichen Hacker-Angriff waren die sensiblen Daten plötzlich in falschen Händen. Wir lernen daraus: SSL-Schützt nicht vor Schlamperei und Leichtsinn.

​

• Online per SSL
  Sicher ist es, wenn der Empfänger die Daten über eine gleichfalls SSL-gesicherte Verbindung über den Browser oder per SSL-gesichertem POP3-Abruf abruft und anschließend auf dem Server löscht. Ob der Empfänger Ihrer Kreditkartennummer das auch wirklich tut, kann er Ihnen nur selber sagen. Das SSL-Protokoll ist nur für die Anlieferung der Daten zum Server zuständig, nicht für das Ausliefern. Das bedeutet allerdings, daß der Shop-Betreiber regelmäßig manuell tätig werden muß. Das ist natürlich etwas unpraktisch und lästig.

​​

• eMail
  Bequemer ist es, wenn die Bestellung mit den Bezahlinformationen in einem Abwasch per eMail ins Büro kommt. Viele Shop-Betreiber und andere Nutzer von SSL-gesicherter Datenübertragung fassen die übermittelten Daten mit den anderen Bestelldaten zu einer handlichen Textdatei zusammen, die als eMail den Empfänger erreicht. Das ist ungefähr so, als ob man seine wertvolle Fracht mit großem Aufwand durch alle Fährnisse dieser Welt geschafft hätte, um sie dann unbewacht im Wartesaal des Hauptbahnhofes abzustellen.

​​

• PGP-verschlüsselt
  Besser ist es, die gesammelten Informationen vor dem Versenden als eMail auf dem Server per PGP zu verschlüsseln. Die so gesicherte Datei kann man getrost versenden. Niemand, mit Ausnahme des Empfängers, kann die Informationen lesen. Das erfordert seitens des Shop-Anbieters beziehungsweise seitens des Providers einen gewissen Mehraufwand. Allerdings handelt es sich um einen einmaligen Vorgang. Der laufende Betrieb ist so einfach wie eMails abholen.

Wer für vertrauliche Informationen eine SSL-gesicherte Übertragung nutzt, kann leider nicht erkennen, ob dem Empfänger diese Daten solchen Mehraufwand wert sind. Wenn Shop-Betreiber die Sicherheit der Kundendaten mehr wert ist, sollten sie dieses auf der Homepage deutlich hervorheben. Denn das SSL-Protokoll ist nur die halbe Sicherheit. Folgende Faustregeln bieten einen ersten Anhalt, welche Sicherheit der Betreiber einer Webseite bieten kann.

• Websites, die auf den Servern bekannter Massenhostern liegen, bieten wegen der dort üblichen Mehrfachnutzung der IP-Adressen nur die Nutzung eines SSL-Proxy. Das ist ein SSL-Server, der vor alle anderen Webpräsenzen geschaltet ist. Die Daten werden nur bis zu diesem Server gesichert übertragen und dann ungesichert an die Webpräsenz weitergereicht.

• Die Fertig-Shops der Massenhoster bieten im Regelfall die Möglichkeit, die Daten per SSL-gesicherten Web-Interface abzufragen oder sich die Informationen per SSL-gesicherter eMail zusenden zu lassen.

• Informationen, die auf www.ssl.de gesammelt werden, gehen dem Empfänger standardmäßig PGP-verschlüsselt zu.

​