WWW + SSL = HTTPS
Der steinige Weg zum sicheren Surfen

von Alexander Talos (Ausgabe 06/2, Juni 2006)

 

Bei all dem Tamtam, das in dieser Ausgabe des Comment um TLS bzw. SSL gemacht wird1), drängt sich eine Frage auf: Was, ganz konkret, habe ich davon? - Verständlich, denn bei TLS/SSL ist es durchaus eine Tugend, gleich einem Butler völlig unbemerkt zu dienen. Das vergleichsweise auffälligste Anwendungsgebiet soll hier näher beschrieben werden: der Aufruf von Webseiten mit dem Protokoll HTTPS.

Was ist HTTPS?

TLS/SSL (Transport Layer Security / Secure Sockets Layer) fungiert als "digitale Eskorte" für die beim Websurfen übertragenen Bits und Bytes. Es wird als Sicherheitsschicht zwischen dem für den Webseiten-Transport zuständigen HTTP (Hypertext Transport Protocol) und dem Transportprotokoll TCP (Transmission Control Protocol) eingefügt.

 

HTTP (WWW-Inhalt)

HTTP (WWW-Inhalt)

SSL (Crypto)

TCP (Transport)

TCP (Transport)

IP (Internet-Fundament)

IP (Internet-Fundament)

normales Websurfen

mit TLS/SSL gesichertes Surfen

Da sozusagen das HTTP mit Security angereichert wird, nennt man das Duo dann HTTPS (Secure HTTP). Das können Sie bereits am URL in Ihrem Browser erkennen, z.B. wenn Sie das Webmail-Service der Universität Wien aufrufen (https://webmail.univie.ac.at/).

Was das für die Sicherheit bedeutet, sieht man am besten an den konkreten Bedrohungen, die damit abgewehrt werden - oder eben nicht. Dabei werden gewöhnlich drei Kategorien betrachtet:

  • Vertraulichkeit,
  • Integrität (die Daten müssen unverändert sein und von der richtigen Quelle stammen) und
  • Verfügbarkeit (Daten, die man nicht bekommt, nützen einem nichts).

Durch Verschlüsselung kann die Vertraulichkeit geschützt werden, aber das setzt, wie dieser Artikel zeigen wird, die ohnehin geforderte Sicherung der Integrität voraus. In diesem Bereich hat TLS/SSL einiges zu bieten. Zur Verfügbarkeit, das sei gleich vorweggenommen, kann TLS/SSL nichts beitragen. Eher im Gegenteil: Das System wird durch seinen Einsatz komplexer und damit etwas verwundbarer.

Lauschen - geht das denn?

Die Verbindung zwischen Browser und Webserver ist nichts anderes als eine Folge von Datenpaketen, jedes mit einer Zieladresse - je nach Richtung ist das die des Servers oder die des Browsers - beschriftet, die von den einzelnen Internet-Knoten etappenweise näher zum Ziel transportiert werden, bis sie dort angekommen sind. Damit sie belauscht oder manipuliert werden können, müssen diese Datenpakete beim Langohr vorbeikommen. Betrachten wir zunächst einen einfachen Rechner (in dieser Hinsicht sind der Webserver und der PC weitestgehend gleich). Dieser "sieht" natürlich sämtliche Pakete von Verbindungen, an denen er selbst teilnimmt.

  • Lokale Netze (LANs, z.B. Institutsnetze oder das lokale Netz daheim) werden heutzutage durch so genannte Switches verbunden, die aus Effizienzgründen Daten stets nur zum bestimmungsgemäßen Empfänger-PC oder dem Router, dem Tor zur Außenwelt, weitersenden. Damit sind jedoch keinerlei Sicherheitsgarantien verbunden, und es sind verschiedene Methoden bekannt, einen Switch dazu zu überreden, seine Datenpakete anderswohin umzuleiten.2) In einem lokalen Netz kann mit etwas Glück auch ein Rechner einen anderen dazu verleiten, ihm seine Pakete zu schicken.3) Wer einen Rechner belauschen möchte, der nicht im selben LAN angeschlossen ist, kann sich z.B. durch Verwendung verwaister Netzwerksteckdosen, Anzapfen von Leitungen etc. Zugang dazu verschaffen.

  • Aus der Ferne kann ein Angreifer sozusagen einen Agenten in das abzuhörende lokale Netzwerk entsenden: Entweder er infiltriert damit einen Rechner, der sich in diesem Netz befindet - dafür steht eine reiche Auswahl von Viren, Trojanern und fertigen Scripts zur Verfügung - oder er zielt unmittelbar auf den abzuhörenden Rechner. Wenn lediglich Zugriff auf dessen Konversation mit einem bestimmten anderen Rechner erlangt werden soll, gibt es auch die Möglichkeit, die Namensauflösung zu manipulieren.4) Gelingt dies, dann sendet das Opfer seine Daten unwissentlich direkt zum Lauscher.

Wer zentrale Knoten des Internet betreibt, verfügt über Geräte, die viele (wenn auch nicht alle) Daten verarbeiten, die international oder weitläufig national transportiert werden. Während die Internet Service Provider selbst keinerlei Interesse an diesen Daten haben, sind die Begehrlichkeiten mehr oder weniger rechtsstaatlicher Instanzen im Zunehmen.5) Im Internet ist es also für Unbefugte zwar unterschiedlich schwierig, aber keinesfalls unmöglich, auf fremden Datenverkehr zuzugreifen.

Schutz der Vertraulichkeit

Die Vorstellung, dass beim Online-Shoppen mehr oder weniger jeder die Kreditkartennummer und das Gültigkeitsdatum mithören und dann damit einkaufen gehen kann, lässt einem kalte Schauer über den Rücken laufen. Der folgerichtige Schluss ist der Ruf nach Verschlüsselung, getreu dem Motto: Gefahr erkannt, Gefahr gebannt. Das Verschlüsseln von Daten hat jedoch mit zahlreichen Problemen zu kämpfen. Eines der prominentesten davon ist folgendes: Wie vereinbaren die Gesprächspartner den Schlüssel? Daran haben sich die Kryptologen jahrtausendelang die Zähne ausgebissen, bis Computer jene komplizierten mathematischen Verfahren alltagstauglich gemacht haben, auf denen die Public Key-Kryptosysteme (auch asymmetrische Verschlüsselung genannt) beruhen.6) Der Gag daran ist, dass ein Schlüssel hier aus zwei Teilen besteht, einem öffentlichen und einem privaten Schlüssel, und was der eine Teil verschlüsselt hat, kann nur der andere entschlüsseln. Bei HTTPS geben beide Gesprächspartner zu Beginn der Verbindung ihren öffentlichen Schlüssel bekannt. Der jeweils andere kann damit Nachrichten verschlüsseln, die nur der berechtigte Empfänger entschlüsseln kann, weil er allein den zweiten Teil, den privaten Schlüssel, besitzt. Das Verfahren ist genial: Es ermöglicht abhörsichere Kommunikation, ohne dass im Vorhinein ein gemeinsames Geheimnis mühsam vereinbart werden müsste. Einen Schönheitsfehler hat die Sache: Diese asymmetrischen Verfahren sind viel zu rechenaufwendig, um im großen Stil (etwa auf einem Webserver zur Verschlüsselung der gesamten Kommunikation) eingesetzt zu werden. Daher wird - mit dieser Methode geschützt - zu Beginn der Verbindung ein so genannter Session Key ausgehandelt, ein Schlüssel für symmetrische Verschlüsselung, der (bzw. die) anschließend für die Dauer der Verbindung verwendet wird. Da symmetrische Verschlüsselung deutlich schneller und ebenfalls sehr sicher ist, sofern der Schlüssel geheim vereinbart wurde, hat man dadurch das Beste aus allen Welten unter einen Hut gebracht. Verschlüsselung ist gut, man muss aber auch darauf achten, dass der Schlüssel zufällig gewählt und nicht vorhersagbar ist (das stellt TLS/SSL sicher), dass er ausreichend lang ist, um nicht durch Ausprobieren geknackt zu werden, und dass das gewählte Verfahren ausreichend sicher ist. Bei den zur Zeit üblicherweise eingesetzten Systemen kann man sich an die Faustregel7) halten: Wenn die Schlüssellänge mindestens 128 Bit beträgt, ist alles gut. Das überprüft man mit Hilfe des geschlossenen Schloss-Symbols rechts unten im Browserfenster, das bei jeder verschlüsselten Seite angezeigt wird: Nach einem Doppelklick auf dieses Schloss erscheint das Fenster Seiteninformation, und auf der Registerkarte Sicherheit ist der verwendete Algorithmus angeführt (siehe Abb. 1).

Abb. 1: Durch Doppelklick auf das Schloss-Symbol rechts unten im Browserfenster erscheint

 

An dieser Stelle ist ein Hinweis angebracht: Alle "Klickanweisungen" und Abbildungen in diesem Artikel beziehen sich, sofern nicht anders angegeben, auf den Open Source-Browser Firefox, dessen deutsche Version unter dem URL www.mozilla-europe.org/de/products/firefox/ kostenlos erhältlich ist. Es handelt sich dabei um eine "abgespeckte", auf die Browser-Funktionalitäten reduzierte Version der Mozilla Application Suite, die mittlerweile in vollem Umfang - d.h. inklusive Browser, Mail- und Chatprogramm, Newsreader, HTML-Editor - unter dem Namen SeaMonkey weiterentwickelt wird und von der Webseite mozilla.kairo.at bezogen werden kann. SeaMonkey ist also sozusagen ein viergängiges Menü, Firefox die Hauptspeise daraus - mit etwas weniger Beilagen (sprich Einstellungsoptionen), aber für den durchschnittlichen Hunger durchaus ausreichend.

SeaMonkey-AnwenderInnen haben z.B. die Möglichkeit (das ist eine der Beilagen), alle "schwachen" Schlüssel in der Browserkonfiguration zu verbieten: Unter Preferences - Privacy & Security - SSL findet sich dort die Schaltfläche Edit Ciphers. Dahinter kann (und sollte) man für SSL2, SSL3/TLS und Extra SSL3/TLS jeweils alle Schlüssel deaktivieren, die weniger als 128 Bit verwenden (siehe Abb. 2). In Firefox geht das leider nicht, oder zumindest nicht so einfach.

Abb. 2: Auswählen von "starken" Schlüsseln in SeaMonkey

 

Also wenn wir mit ganz vielen Bits verschlüsseln, dann ist alles sicher?

Leider nein, aber danke fürs Mitspielen - um es mit den Worten von Mr. Keating im Club der toten Dichter zu sagen. Ebensowenig wie sich der Wert eines Gedichts einfach durch Berechnung von Perfektion in der X-Achse und Ausdruck in der Y-Achse bewerten lässt, kann man Sicherheit allein an der Schlüssellänge ermessen. Es gibt noch viel mehr zu bedenken.

Eine Gefahr, die trotz Verschlüsselung noch nicht gebannt ist, besteht darin, dass eine Webseite in der Regel aus mehreren Teilen besteht (z.B. Bilder, Frames, Stylesheets, Flash-Animationen, Hintergrundmusik), die separat transportiert werden. Was nützt es, wenn ein Teil davon gesichert übertragen wird, aber vielleicht genau dort, wo es ums Eingemachte geht, die Verschlüsselung leider nicht angewendet wird? Klar, dann hat der Seitenverantwortliche einen Fehler gemacht, und bei einer professionell gestalteten Site sollte das nicht passieren - aber das hilft uns nicht weiter. Immerhin zeigen Webbrowser eine Warnung an (siehe Abb. 3), wenn HTTPS und unverschlüsseltes HTTP gemischt werden. Die Browserhersteller neigen hier jedoch zum Unter-den-Teppich-Kehren: Browser jüngeren Datums warnen nicht, wenn Stylesheets und Bilder unverschlüsselt übertragen werden, wohl aber bei Hintergrundmusik und Frames.

Abb. 3: Warnmeldung bei Seiten, die sowohl verschlüsselte

 

Das Kontrollkästchen unterhalb dieser und ähnlicher Warnungen hat leider einen fatalen Designfehler: Es muss beim ersten Auftauchen angeklickt werden, damit die Warnung bei gegebenem Anlass auch in Zukunft erscheint. Bitte achten Sie also darauf, dieses Kästchen zu aktivieren, sobald Sie es zu Gesicht bekommen! Auch hier haben SeaMonkey-AnwenderInnen einen Vorteil: Sie können diese Warnungen nachträglich unter Preferences - Privacy & Security - SSL aktivieren (siehe Abb. 4).

Abb. 4: Aktivieren von Warnmeldungen in SeaMonkey

 

Gerade die Warnung bei Webseiten mit "Protokollmixtur" bringt die AnwenderInnen in eine unangenehme Situation: Zwar ist offenbar irgendetwas nicht koscher, aber es erfordert ein fundiertes Verständnis von HTML, um beurteilen zu können, ob ein ernsthaftes Problem vorliegt. Wir können nur empfehlen, in solchen Fällen vorsichtig zu sein und keine sensiblen Daten zu übertragen, ohne vorher jemanden um Rat zu fragen - etwa den Seitenbetreiber selbst, der sich des Problems möglicherweise gar nicht bewusst ist. Die Warnung einfach zu ignorieren, ist eher keine gute Idee.

Was auf diese Weise leider nicht festgestellt werden kann, ist, ob Teile der Seite von einem anderen Server stammen. Das kann absolut erwünscht sein - etwa bei großen Sites, die statische Bilder auf anderen Servern ablegen als die Seiten-Bestandteile, die von Datenbanken generiert werden. Es kann aber auch sein, dass fremde Inhalte ihren Weg auf die Seite gefunden haben, was gar nicht geplant war. Der Browser hat leider keine Chance, das zu beurteilen, und kann also auch nicht davor warnen. Wovor Ihr Browser jedoch warnt: Wenn ein gesicherter Bereich verlassen wird (siehe Abb. 5).

Abb. 5: Warnmeldung bei Verlassen einer verschlüsselten Seite

 

Besonders kritisch ist das dann, wenn Sie beispielsweise auf einer sicheren Seite ein Formular finden, dort Ihre Kreditkartendaten eingeben, diese aber beim Klick auf Absenden oder Bestellen unverschlüsselt übertragen werden (siehe Abb. 6).

Abb. 6: Warnmeldung bei Versenden von Formulardaten

 

Schutz der Integrität

In der chinesischen Schrift gibt es verschiedene Sätze von Zahlzeichen: einfache Zeichen für den alltäglichen Gebrauch und eine Langform aus komplizierteren Graphemen, die wegen ihrer Fälschungssicherheit bei Verträgen verwendet werden (siehe dazu http://de.wikipedia.org/wiki/Chinesische_Zahlen). Ein Webbrowser kommuniziert mit dem Webserver nicht mittels Pinsel und Tusche, sondern mittels elektronischer Signale, die völlig ohne Farbkleckse oder Kratzspuren zu fälschen sind. Dennoch kann und muss die weise Voraussicht der ehrwürdigen Chinesen ins Zeitalter des Internet übertragen werden.

Plumpe Fälschung

Ein gängiger Irrglaube ist, dass durch die Verschlüsselung auch die Manipulation verhindert wird. Zwar wird die freie Gestaltung beim Fälschen durch die Verschlüsselung deutlich erschwert, aber je nach den konkreten Umständen gibt es doch die Möglichkeit, etwas Sinnvolles einzufügen. Es mag einem Saboteur aber auch genügen, die Nachricht einfach nur zu verstümmeln.

Technisch kann zwar die Manipulation nicht verhindert werden, aber es ist möglich, sie zu erkennen. Dazu werden die übertragenen Datenpakete ganz einfach digital unterschrieben. Das funktioniert so: Der Absender bildet eine kryptographische Prüfsumme aus der Nachricht und dem Session Key und sendet das Ergebnis mit, das vom Empfänger nachgerechnet wird. Da außer Sender und Empfänger niemand den Session Key kennt, kann niemand die zur einer gefälschten Nachricht passende Prüfsumme berechnen. Wenn Prüfsumme und Nachricht nicht übereinstimmen, wird die Verbindung sofort beendet.

Bis repetita non placent8)

Trotz all dieser Sicherungen sind die Cyberbetrüger noch nicht mit ihrem Latein am Ende. Mit so genannten Replay Attacks kann man, indem man die gesamte Verbindung oder einen Teil davon wie mit einem Kassettenrekorder aufnimmt und später wieder abspielt, zumindest jede Menge Schaden anrichten. Aber auch eine tausendfach wiederholte Überweisung ist denkbar, oder dass irgendjemand nur den Loginvorgang aus der Konserve abspielt und die Account-Daten dann für seine Zwecke missbraucht. Bei menschlicher Konversation würden solche Wiederholungen schnell auffallen; ein Computer führt jedoch bereitwillig ad nauseam9) denselben Dialog immer wieder, ohne sich zu wundern.

Das Protokoll HTTPS wehrt sich gegen Replay-Attacken, indem jeder Nachrichtenblock innerhalb einer Verbindung eine fortlaufende Nummer erhält. Da sowohl der Session Key als auch die Blocknummern in die Berechnung der integritätsschützenden Prüfsumme einbezogen werden, wird jeder Versuch des Daten-Recyclings sofort erkannt und führt zur Beendigung der Verbindung.

Da aß der Wolf etwas Kreide und machte seine Stimme ganz fein...

Zum Schutz der Integrität gehört es auch, die Authentizität einer Nachricht oder eines Kommunikationspartners sicher-zustellen. Wenn der Wolf Teig auf seine Pfoten streichen lässt und Kreide frisst, will er damit eines erreichen: Dass die Geißlein ihn für ihre Mutter halten und ihm vertrauen.

Ein Internet-Wolf würde damit anfangen, z.B. die Telebanking-Startseite auf seinem eigenen Server nachzubauen. Mittels Kopieren und Einfügen ist das eine weitgehend triviale Angelegenheit. Eine andere Methode, die noch subtilere Manipulationen ermöglicht, besteht darin, ähnlich dem bekannten Stille-Post-Spiel alle Anfragen an den zu imitierenden Server weiter- und dessen Antworten zurückzureichen. Auf seinem Klon-Server hat der Bösewicht dabei die volle Kontrolle über das Geschehen: Er kann Daten (z.B. Passwörter) mitschneiden, Kontonummern austauschen - der Phantasie sind da keine Grenzen gesetzt.

Um einen Browser zu diesem falschen Server zu locken, kann man sich der eingangs beschriebenen Umleitungsver-fahren bedienen. Wie wirkt nun der TLS/SSL-Schutz, soweit er bisher beschrieben wurde, angesichts dieser Fälschung?

Verschlüsselung und Integritätsschutz beruhen auf asymmetrischen Schlüsseln, die Server und Client jeweils selbst bekanntgeben. Das kann der gefälschte Server genauso gut wie das Original. Die Tarnung ist also fast perfekt - eine verschlüsselte Verbindung wird aufgebaut und transportiert die Geheimnisse des Users abhör- und manipulationssicher direkt in die Arme des Abhörers bzw. Fälschers.

Jede Hoffnung auf Sicherheit wäre damit endgültig dahin, hätten nicht findige Kryptologen auch für dieses Problem eine (allerdings relativ aufwendige) Lösung gefunden. Diese besteht darin, dass der Webserver erst seine Identität nachweisen muss.10) Hätten die Geißlein Ausweise mit Fingerabdrücken gekannt, wären sie nicht gefressen worden; man braucht also einen solchen Mechanismus auch für HTTPS.

Das Zertifikat - der "Reisepass" für Webserver

Der elektronische Ausweis für den Server, das so genannte TLS/SSL-Zertifikat, ist eine normierte Datenstruktur, die unter anderem folgende Angaben enthält: Rechnername, Organisation, Gültigkeitszeitraum, öffentlicher Schlüssel des Rechners, Bezeichnung der Stelle, die das Zertifikat ausgestellt hat (Certificate Authority, kurz CA), sowie deren Signatur. Zur Kontrolle eines Zertifikats entschlüsselt der Browser die Unterschrift der Zertifizierungsstelle mit deren öffentlichem Schlüssel, berechnet selbst die Prüfsumme aus den Angaben im Zertifikat und vergleicht die Ergebnisse. Stimmen sie überein, kann man sich auf die Identität des Servers verlassen - vorausgesetzt, man vertraut dem Zertifikatsaussteller.

Sie können den genauen Zertifikatsinhalt abrufen, indem Sie - wie bei Abb. 1 beschrieben - einen Doppelklick auf das Schloss-Symbol rechts unten im Browserfenster machen und anschließend auf der Registerkarte Sicherheit auf die Schaltfläche Anzeigen klicken (siehe Abb. 7).

Abb. 7: Anzeigen des Zertifikats einer HTTPS-geschützten Webseite

 

Ein Henne-und-Ei-Problem bleibt aber noch zu lösen: Wie kommt Ihr Browser zum öffentlichen Schlüssel der Zertifizierungsinstanz? Es gibt zweieinhalb Möglichkeiten:

  • Große Zertifizierungsfirmen wie Thawte oder Globalsign haben Verträge mit Browser- bzw. Betriebssystem-Herstellern abgeschlossen, damit diese deren Zertifikate fix in ihre Software einbauen. Die Voraussetzungen für die Ausstellung eines Zertifikats sind ausgesprochen streng, und es ist zu hoffen, dass die Softwarehersteller deren Einhaltung auch kontrollieren, da Fehler zu nennenswerten Schadenersatzforderungen führen können. Ihren Zertifizierungsdienst lassen sich solche Firmen auch gut bezahlen: Es ist mit Kosten von 250 Euro pro Jahr und Rechnername zu rechnen. Daher wurde das Projekt SCS (Server Certificate Service) ins Leben gerufen, durch das im Universitätsbereich Zertifikate ohne weitere Kosten für den Endverbraucher bezogen werden können.

  • Sie importieren das Zertifikat selbst, weil Sie dem Aussteller trauen. Dieser Schritt sollte aber wohl überlegt werden und wird hier nicht weiter beschrieben.

  • Die zweieinhalbte Variante ist ein mehrstufiges Verfahren: Das Server-Zertifikat ist mit einem Schlüssel unter-schrieben, welcher durch ein zweites Zertifikat bestätigt wird, das seinerseits von einem dem Browser bekannten Zertifikat unterschrieben wurde. Diese Variante ist insofern erwähnenswert, als beim SCS-Projekt genau so verfahren wird.

Um nachzuverfolgen, woraus sich die Identität einer gerade angezeigten Seite ergibt, klicken Sie - wie bei Abb. 1 und Abb. 7 beschrieben - auf das Schloss-Symbol im Browserfenster und anschließend auf der Registerkarte Sicherheit der Seiteninformation auf die Schaltfläche Anzeigen. Diesmal müssen Sie zusätzlich die Registerkarte Details auswählen. Abb. 8 zeigt den hierarchischen Aufbau dieser Registerkarte: Wenn Sie im ersten Bereich (Zertifikatshierarchie) einen Punkt anklicken, erscheinen die dazu verfügbaren Informationen im Bereich Zertifikats-Layout darunter. Wählen Sie hier einen Eintrag aus, so werden die Details dazu im Bereich Feld-Wert angezeigt.

Abb. 8: Anzeigen der Zertifikat-Details einer HTTPS-geschützten Webseite

 

Wenn Sie mit HTTPS auf eine Seite gelangen, deren Identität nicht durch eine lückenlose Kette zu einem dieser Zertifikate führt, zeigt der Browser eine Warnung an (siehe Abb. 9).

Abb. 9: Warnmeldung bei zweifelhaftem Zertifikat

 

Das vom Server präsentierte Zertifikat können Sie mit Hilfe dieses Dialogfensters auch wider besseres Wissen akzeptieren. Das sollten Sie jedoch nur unter gewissen Randbedingungen machen, nämlich wenn

  • der dargestellte Fingerprint mit dem des gewünschten Servers (den Sie natürlich über einen sicheren - also zumindest anderen - Weg erhalten haben als den, der Sie auf diese Seite geführt hat) verglichen wurde oder

  • Sie auf dieser Seite keine sensiblen Daten, insbesondere keine Passwörter, eingeben (wozu dann aber die Verschlüsselung?). Sofern Ihr Browser die Möglichkeit bietet, sollten Sie den Schlüssel nur für diese Sitzung annehmen.

Welche Zertifizierungsinstanzen und welche individuellen Serverzertifikate Ihr Browser akzeptiert, sehen Sie in Firefox unter Einstellungen - Erweitert - Sicherheit - Zertifikate anzeigen. Die Zertifikate so genannter "Vertrauenswürdiger Dritter" sind auf der Registerkarte Zertifizierungsstellen aufgelistet und werden durch einen Klick auf Ansicht angezeigt (siehe Abb. 10).

Abb. 10: Anzeigen der vom Browser anerkannten Zertifizierungsinstanzen

 

Ein ähnlicher Fall wie bei lückenhaften Zertifizierungsketten liegt vor, wenn das Zertifikat abgelaufen ist. Das sollte durch den Seitenbetreiber zügig behoben werden; geschieht dies nicht, wirkt der Server ohnehin nicht vertrauenswürdig. Gänzlich die Finger lassen sollten Sie von einem Server, der anders heißt als sein Zertifikat angibt (siehe Abb. 11): Wenn ein Server sich als jemand ausgibt, der er nicht ist, ist ganz sicher etwas faul. Eine solche Situation ist durchaus einen Anruf bei der Hotline des Betreibers wert, dem sein Problem vielleicht gar nicht bewusst ist. Zwar ist es durchaus üblich, dass ein Server berechtigterweise mehrere Namen hat (beispielsweise bei virtuellen Servern), aber auch diese Situation müssen AdministratorInnen von Services, die den Schutz von TLS/SSL benötigen, zu meistern in der Lage sein.

Abb. 11: Warnmeldung, wenn Servername und Zertifikatsbesitzer nicht übereinstimmen

 

Mit all diesen Vorkehrungen aber ist HTTPS endlich wirklich sicher.11) Der Datenverkehr kann weder belauscht noch manipuliert werden, und es ist sichergestellt, dass sich kein falscher Server einschmuggelt.

Grenzen von TLS/SSL

Es klingt zu gut, um wahr zu sein: TLS/SSL hat sich in über einem Jahrzehnt in höchstem Maße bewährt. Schwächen in manchen Details wurden ausgebessert, haben aber nicht zu spektakulären Einbrüchen geführt. Manche Schlüssel, speziell die von den US-Exportbestimmungen erlaubten Schlüssel mit weniger als 128 Bit, sind unbefriedigend und sollten nicht verwendet werden. Das Konzept selbst aber ist reif und erfolgreich.

Dank TLS/SSL ist das Internet also völlig sicher? Leider immer noch nicht: Nicht das Surfen ist sicher, sondern nur die HTTPS-Verbindung zwischen den Endpunkten einer bestimmten Verbindung - und das ist etwas entscheidend anderes als das gesamte Internet. Dort gibt es noch ein paar weitere Risikofaktoren.

Der Server

Was nutzt es, wenn die Daten bombensicher transportiert werden, aber der Server nicht dichthält? Leider nichts. Und gerade hier existiert eine ganze Reihe von Problemzonen:

  • Menschliches Versagen - eine der größten Bedrohungen der EDV - gibt es auch bei Server-AdministratorInnen.

  • Es ist möglich (und auch bereits passiert), dass Fehler in der Server-Software den Schutz zumindest schwächen.

  • Der Server könnte gehackt werden. Bei einem gut gewarteten Server ist die Wahrscheinlichkeit dafür zwar gering, aber völlig ausschließen kann das niemand.

  • Nachdem in einen Server eingebrochen wurde, kann auch sein privater Schlüssel gestohlen worden sein. Damit ist auch der Zertifikatsschutz hinfällig. Deshalb muss im Fall eines Einbruchs unbedingt das Zertifikat widerrufen und ein neues bestellt werden. Leider prüfen real existierende Browser die so genannten Certificate Revocation Lists (CRLs), in denen die widerrufenen Zertifikate aufgelistet werden, derzeit nicht.

  • Der Serverbetreiber könnte in Konkurs gehen oder eine seiner Wartungsfirmen könnte den Datenschutz nicht ganz ernst nehmen. Wer aus Konkursmassen oder bei eBay gebrauchte Festplatten kauft, bekommt oft unglaubliche Mengen an Kreditkartendaten oder sonstigen vertraulichen Informationen gratis dazu.12)

  • Webmail, Onlineforen und ähnliche Systeme werden immer wieder durch das so genannte Cross Site Scripting missbraucht. Hierbei wird ausgenützt, dass die Inhalte solcher Systeme teilweise vom Benutzer eingefügt werden können, obwohl die Website insgesamt - TLS/SSL-geschützt - unter der Flagge des Betreibers segelt. Bei eBay werden immer wieder Fälle bekannt, wo Benutzer-Passwörter auf diese Weise ausgespäht wurden.

Die Anwenderseite

Der Erfolg des TLS-Schutzes kann ebenso zunichte gemacht werden, wenn beim Webbrowser etwas schief läuft:

  • Das beim Server über menschliches Versagen und Softwarefehler Gesagte gilt natürlich auch für den Client.

  • Wenn der Benutzer dazu überredet wird, ohne das S in HTTPS sensible Daten zu übertragen, ist TLS/SSL machtlos - da es ja nicht zum Einsatz kommt. Ob es sich hierbei um Fahrlässigkeit oder mangelnde Schulung handelt, ist ein ergiebiges Thema für Schuldzuweisungen.

  • Die TLS/SSL-Warnungen werden häufig nicht aktiviert.

  • Den Zugang zu Daten oder Diensten mittels UserID und Passwort zu regulieren, ist eine relativ verständliche und bewährte Methode.13) Sie wird jedoch in der Praxis dadurch unpraktikabel, dass es so viele Anwendungsgebiete dafür gibt: Einerseits sollte für jeden Dienst ein eigenes Passwort gewählt werden, andererseits wären das zu viele, um sie im Kopf zu behalten. Ein Mindestmaß an Trennung ist dennoch anzuraten: Beispielsweise sollte das Unet- bzw. Mailbox-Passwort nirgendwo sonst verwendet werden.

  • Fatal ist es natürlich, wenn der Benutzer ausdrücklich einen anderen Webserver aufruft, als er aufzurufen glaubt. Um das zu erreichen, genügt es oft, eine eMail mit einem plausiblen Vorwand, einen darin enthaltenen Link anzuklicken, zu versenden. Wenn der dort angegebene - vom Angreifer gewählte - Rechnername eine auch nur entfernte Ähnlichkeit mit dem Original hat, werden allzu viele BenutzerInnen darauf reinfallen. (Dem Thema Phishing, das sich im Wesentlichen genau darum dreht, widmet sich der Artikel Phishing: Bitte nicht anbeißen!.)

  • Der Rechner könnte kompromittiert oder durch einen Trojaner missbraucht werden. In diesem Fall kann man davon ausgehen, dass jede Tastatureingabe (und damit jedes Passwort) abgehört wird, bevor sie noch im Webbrowser ankommt oder gar von TLS/SSL geschützt werden könnte.

  • Dasselbe gilt für im Browser gespeicherte Passwörter und alles, was in Formular-Ausfüllhilfen hinterlegt ist.

Nebenwirkungen

Die Nebenwirkungen von TLS/SSL sind erfreulich gering. Der zusätzliche Rechenaufwand hält sich, zumal bei den heutzutage sehr schnellen Rechnern, in Grenzen. Einen möglicherweise negativen Effekt kann die gesamte Verschlüsselung aber haben: In Netzwerken, wo der HTTP-Verkehr durch einen Proxy geleitet wird, der auch eine Virenscanner-Funktion enthält, wird eben diese umgangen. Es ist einleuchtend, dass der Virenscanner dort nicht scannen kann, wo er nicht hineinsehen kann. Daher kann er in diesem Fall auch keine Viren aus dem Verkehr ziehen.

Fazit

Durch TLS/SSL bzw. HTTPS können Datenverbindungen für Webservices überaus wirkungsvoll gegen Abhören und Fälschen gesichert werden. Das ist ein wichtiger Puzzlestein, zu dem aber noch sichere Server, sichere Clients und die richtige Handhabung durch den Anwender kommen müssen, damit das Bild eines sicheren Webservice komplett wird.

 

 

1) siehe Artikel SSL-Zertifikate: Ein "Reisepass" für Webseiten, Was ist TLS/SSL?, Der Weg zum SSL-Zertifikat für Uni-Server und Das Postamt zieht um: Ein neues Mailsystem für die Uni Wien

2) CAM Table Flooding, Näheres siehe www.packetwatch.net/documents/papers/layer2sniffing.pdf

3) ARP Cache Poisoning, siehe ebenfalls www.packetwatch.net/documents/papers/layer2sniffing.pdf

4) z.B. DNS Cache Poisoning (erklärt im Wikipedia-Artikel http://de.wikipedia.org/wiki/DNS-Spoofing), gefälschte Einträge in der hosts-Datei (siehe www.heise.de/security/news/meldung/52935)

5) siehe EU-Richtlinie 2006/24/EG: Vorratsspeicherung von Daten (www.bmvit.gv.at/telekommunikation/recht/europa/richtlinien/rl2006-24.html)

6)Nähere Informationen dazu finden Sie z.B. im Artikel Grundbegriffe der Kryptographie in Comment 00/3.

7) Die mit einer bestimmten Schlüssellänge erzielte Sicherheit kann von Verfahren zu Verfahren variieren: 3DES mit 160 Bit gilt als weniger sicher als AES mit 128 Bit.

8) "Wiederholungen gefallen nicht" - Julius Cäsar zu Tullius Firlefanzus, als er einen erneuten Angriff auf Gergovia ablehnt (Asterix XI/46; www.comedix.de/lexikon/db/bisrepet.htm)

9) "bis zur Übelkeit"

10) Bei TLS/SSL handelt es sich hierbei um ein konfigurierbares Feature, ebenso optional wie die Ausweispflicht für den Client. Bei HTTPS ist das Serverzertifikat allerdings Pflicht.

11) Um der Wahrheit die Ehre zu geben, müssen wir einräumen, dass immer ein Restrisiko bleibt - das aber so gering ist, dass es in deutscher Sprache nicht mehr formulierbar ist.

12) Garfinkel, Simson L.: Zero-Klick Security

13) Die vielgerühmten Chipkarten, Iris-Scans, Fingerabdrucksensoren und dergleichen haben ebenfalls mit gravierenden Problemen und Beschränkungen zu kämpfen, sodass in jedem Einzelfall geprüft werden muss, ob sich ihr Einsatz für die geplante Anwendung lohnt.