$>
you're reading...
Tutorial

Tutor: SSL im Visier Nicht immer liegt es am Protokoll


Dieser Artikel setzt sich mit Man-In-The-Middle-Angriffen auseinander und befasst sich mit der Rolle von SSL in diesem Zusammenhang. Man ist versucht, SSL ins Visier zu nehmen, wenn es um Man-in-the-Middle-Angriffe geht. Die Schelte verdient aber eigentlich weniger das Protokoll, sondern Schwächen im Browser.

IN DIESEM ARTIKEL ERFAHREN SIE…

•     Warum Man-In-The-Middle-Angriffe eigentlich kein SSL-Problem sind
•     Welche grundsätzlichen    Vertrauensfragen    sicherheitsrelevant sind

WAS SIE VORHER WISSEN SOLLTEN…

•     Ein grundlegendes Verständnis von Man-In-The-Middle-Angriffe

Der Mann in der Mitte. Das für sich allein klingt schon irgendwie gespenstisch, und das ist es letztlich auch. Denn der unsichtbare Man-inthe-Middle will in erster Linie ja nur eins: mithören und sobald sich die Chance dazu bietet, einen Vorteil daraus ziehen. Dabei kann es um die hohe Politik gehen, es kann aber auch um ganz profane Angelegenheiten wie Industriespionage oder Diebstahl gehen.

Aber wie gelingt es einem Eindringling sich zwischen zwei Systeme zu mogeln? Im Endeffekt setzt er dabei einfach auf die Selbstbeschwichtigung der Benutzer. Denn die können mit ihrem Browser unglücklicherweise Vorgänge zulassen, ohne dass sie verstehen, was sie da eigentlich erlauben. Und das gelingt, weil die Benutzer sich selbst einreden, dass alles schon seine Ordnung habe. Im Kern geht es jedoch um das Netzwerk-Design:

Ein Proxy gaukelt dem Browser vor, dass der Server an einem anderen Ort stünde. Quasi als Ersatz stellt der dann ein unterschiedliches Zertifikat für beide Seiten aus. SSL ist dabei das Protokoll  zwischen zwei Punkten, in der Regel Browser und Server. Die Schwächen des Systems sind so gesehen meist auf den Browser, und nicht auf das Protokoll, zurückzuführen. Das Protokoll vermittelt nur eine gegenseitige Erkennung der Server, die Zustimmung obliegt den Benutzern, unabhängig davon um was für eine Website es geht.

Damit könnte man also die Vertrauensfrage als die eigentlich kritische ins Zentrum rücken. Die wiederum tritt aber vor allem wegen Designschwächen im Browser auf, wegen derer sich Browser und letztlich auch Server vormachen lassen, dass das falsche Zertifikat eigentlich doch das richtige sei. Natürlich muss dabei sofort der Eindruck entstehen, als ob das Protokoll fehlerhaft sei. Jedoch ist nicht das Protokoll korrumpiert, sondern es wurde nur an der falschen Stelle geschlossen. Benutzer sehen über abgelaufene SSL-Zertifikate einfach hinweg Wenn aber der Browser der „Übeltäter“ ist, muss man fragen, warum die Schuld vielfach auf SSL zurückfällt. Und dabei stellt sich automatisch auch die Frage, welchem Zertifikat der Browser vertrauen darf und welchem nicht.

Gleichwohl melden sich Benutzer trotz aller Warnungen immer wieder bei Internetseiten an, die nur über ein abgelaufenes SSL-Zertifikat verfügen. Und das bedeutet ein ernsthaftes Problem. Dieser Kampf tobt schon seit den frühen Internettagen: Aber was soll man Anwendern sagen? Wie können oder müssen sie mit abgelaufenen Zertifikaten umgehen?
Sicherheitsexperten liegen bei derlei Fragen immer im Clinch mit der Öffentlichkeit, weil es hier einerseits um die naheliegende und notwendige Usability und andererseits um ein für die Benutzer schwer durchschaubares Bedrohungsszenarium geht. Letztlich gewinnt hier eben immer die Usability – das ist durchaus nachvollziehbar. Aus der Sicht des Seitenbetreibers dürfte sich die Frage des Umgangs mit abgelaufenen Zertifikaten wahrscheinlich eher einfach beantworten lassen: Sie wollen den Benutzern auf ihrer Seite keine unnötigen Steine in den Weg legen. Sie in irgendeiner Weise zu beschränken, liegt also wohl kaum in ihrem Sinn.

Aber natürlich ließe sich auch auf „neutrale“ Instanzen setzen. Denn dass es beinahe gleichgültig ist, was sich hinter dem Protokoll tatsächlich verbirgt, kann niemand wünschen. Viele Nutzer können aber keine Einordnung vornehmen. Also sollten sich die Bowser-Hersteller ernsthafte Gedanken darüber machen.

Aber würde ein Hersteller wohl eine Site mit ungültigem Zertifikat „abstellen“? Das bleibt mehr als fraglich. Denn vielleicht arbeiten die Betreiber ja daran, die Gültigkeit zu verlängern und würden eine halbe Millionen Euro verlieren, wenn ihre Seite aufgrund einer solchen Maßnahme offline ginge. Eben diese kommerziellen Aspekte machen die Frage mehr als heikel.
Aus technischer Sicht müsste die Praxis so aussehen, dass ein Zertifikat den Webserver benachrichtigt, dass es in einer bestimmten Zeit abläuft und deshalb erneuert werden muss. Am besten sollte all das natürlich automatisiert geschehen.

Sicherheitszonen alleine genügen nicht

Man braucht aber noch weitere Sicherheitsmerkmale im Browser. Zum Beispiel eine Funktionalität, die bei wichtigen Websites wie Banking oder Bezahlungssystemen den Benutzer davon abhält, Transaktionen abzuwickeln, wenn es auf der Seite Ungereimtheiten gibt. Auf weniger relevanten, reinen Informationsseiten kann man Benutzern unter Umständen die Möglichkeit geben, ohne Einschränkungen fortzufahren.

Verschiedene Browseranbieter verfolgen die Idee von Sicherheitszonen. Dabei differenziert man nach verschiedenen Kategorien von Websites. Aus der Perspektive der Endanwender gestaltet sich aber auch das eher schwierig. Denn sie verstehen nicht, was sie sich unter einer Sicherheitszone vorzustellen haben. Sie sind dazu oft auch nicht besonders versiert in Sicherheitsfragen. Vielfach besteht für sie kein Unterschied, ob sie in die Filiale einer Bank gehen oder sich auf das Online-Angebot der Bank begeben.

Sicherheit braucht Team-Work
Der Payment Card Industry Data Security Standard (PCI DSS) ist ein sinnvoller Vorstoß, der zum Beispiel von Visa und MasterCard forciert wird. PCI DSS zwingt Websitebetreiber zu umfangreichen Sicherheitstests und zur Verbesserung der Site.
Es bedarf aber vor allem einer gemeinsamen Anstrengung. Ob dabei Regierungen, Geschäftspartner, Branchen oder Verbände zusammenarbeiten ist eher nebensächlich, der Team-Gedanke ist das    Entscheidende. Nur so kann man ein riesenhaftes Netzwerk wie das Internet von der    Sicherheitswarte aus unter Kontrolle behalten

Sie brauchen Hilfe, handfeste, echte Hilfe, sonst triumphiert letztlich doch die Usability und lässt sie einfach weiterklicken. Der Browser leitet einige Schritte in die Wege, um Zertifikate zu prüfen: Zum Beispiel ob der Name des Zertifikats und der URL übereinstimmen. Das reicht jedoch nicht, denn es gibt Fälle, bei denen man dem Browser vorgeben kann, dass der URL übereinstimmt. Die Prüfungen müssen hier noch engmaschiger und akribischer aufgesetzt sein.

Fazit: Schon immer gewusst

Die gegenwärtigen Herausforderungen bringen Dinge zu Tage, die man in der Sicherheitsbranche schon immer gewusst hat. Jetzt aber müssen sich alle Marktteilnehmer aufs Neue damit befassen, weil die Internetwirtschaft beträchtlich wächst. Schon allein deshalb muss die Branche bessere Lösungen finden, um den Problemen zu Leibe zu rücken.

Hakin9 Redaktion

Weiteres zum Thema:

http://krum.rz.uni-mannheim.de/inet/sess-402.html

http://de.wikipedia.org/wiki/Transport_Layer_Security

http://www.ready2host.de/Lexikon/ssl-verschluesselung

DR. TAHER ELGAMAL
Der Autor gilt in der IT-Welt als der „Erfinder“ von SSL und kümmerte sich zum Beispiel um die SSL-Bestrebungen bei Netscape. Zudem schrieb er das SSL-Patent und setzte sich in verschiedenen Gremien der Branche für SSL als Internetsicherheitsstandard ein. Ferner erfand Dr. Elgamal mehrere Branchen- und Regierungsstandards für Datensicherheit und digitale Signaturen – zum Beispiel DSS. Der gebürtige Ägypter ist für zahlreiche Unternehmen als Beirat und für Axway, die Business Interaction Networks Company, als Chief Security Offcer tätig. Seine Promotion erlangte Taher Elgamal an der renommierten Stanford University.

Für Rückfragen wenden Sie sich an:
Susanne Vogler
Axway Deutschland:
Kurfürstendamm 119
D-10711 Berlin
+49 (0) 30 / 89 01 - 01 17
presse@axway.com

Diskussionen

Es gibt noch keine Kommentare.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

Member of The Internet Defense League

Kalender

Kategorien

Archiv

Legal Guide For Bloggers

Bloggers' Rights at EFF

Interessantes

Link Anonymizer

Independent Tests of Antiv-Virus Software

BSD Aktuell

Hacker News

Blog Stats

  • 259,999 hits

Haftungsausschluss

disclaimer

%d Bloggern gefällt das: