Hilfe
Neues Thema
Antworten
Insbesondere soll beleuchtet werden, was das S in "HTTPs" bedeutet. Dabei möge beachtet werden, daß dieses bezeichnete S auch anderswo vorkommt, möglicherweise unter anderem Namen (oder Kürzel), jedoch mit derselben zugrundeliegenden Architektur.
Dies ist insbesondere kein technisches Referendum. Informatcion zur Implementierung gibt es zuhauf; Information zu den Grundlagen glänzen jedoch durch Abwesenheit.
Hier soll daher angesetzt werden in einem hoffentlich allgemeinverständlichen Artikel.
Hinweis: Es werden insbesondere anschauliche Vergleiche verwendet. Dabei entstehen ggf. Namens- oder gar Konzeptkonflikte mit existierenden Implementierungen. Letztere sollen hier außen vor bleiben, können aber natürlich später gern diskutiert werden. Dies soll lediglich ein Einstieg in die komplexe Welt von X.509 sein, seines Zeichens Basis der sogenannten PKI, welche wiederum unter dem Dach von Triple-A zu finden ist (cf. Wikipedia, bei näherem Interesse).
Vertrauen: Was ist das?
Womöglich entgegen aller aus dem Bauch heraus entstehenden Überlegungen, was "Vertrauen" im Kontext der IT bedeuten könnte, ist mit Vertrauen tatsächlich das gemeint, was der Begriff ohne jeden Kontext bereits suggeriert:
- Ich sage etwas und Du glaubst mir, ohne weiter zu hinterfragen.
Du akzeptierst also formal meine noch unbelegte Behauptung als realen Fakt.
- Andersherum kann man Vertrauen also auch als Abwesenheit von Zweifel verstehen.
Was ist ein Tunnel?
HTTPs wird gerne als Tunnel bezeichnet. Aber was ist überhaupt ein Tunnel?
Wie der Name suggeriert, ist ein Tunnel vom Verständnis her eine geschlossene Röhre mit einem Anfangs- und einem Endpunkt. Dabei ist ein Tunnel immer ein Teil einer Gesamtwegstrecke; möglicherweise, aber nicht notwendigerweise, die gesamte Wegstrecke als solche.
Innerhalb des Tunnels ist kein Einblick von außen möglich. Außerhalb des Tunnels schon. Das ist mehr oder weniger offensichtlich. Nicht minder offensichtlich, jedoch ab und zu vergessen: aus dem Inneren des Tunnels sieht man üblicherweise die Außenwelt auch nicht.
Vertraute Tunnel...?
An dieser Stelle können wir eine Brücke schlagen von "Vertrauen" zu "Tunnel"n. Wir gehen also in ein dunkles Loch irgendwo in der Felswand und müssen darauf vertrauen, daß uns der Tunnel dorthin führt, wo wir hinwollten. Sehen, geschweige denn beeinflussen können wir das ja nicht mehr selbst.
Erweiterte Betrachtung: Authentifizierung
Mit einem einzelnen Tunnel kommt man mit HTTPs nicht weit. Stattdessen muß für jedes Ziel ein eigener Tunnel aufgebaut werden. Es entsteht also ein Netzwerk aus Tunneln, die gegeneinander isoliert, jedoch auch miteinander verbunden sein können.
Vereinfacht: Mit meinem Browser bilde ich einen Tunneleingang. Ich kann winfuture.de ansurfen - ein Tunnel. Ich kann Google.de ansurfen - ein zweiter Tunnel. Ich kann außerdem winfuture-forum.de ansurfen; dieser Tunnel ist Teil des winfuture.de-Tunnels. Analog kann ich natürlich auch images.google.de ansurfen: dieser Tunnel ist dann Teil des Google-Tunnelnetzwerks.
Nun hab ich aber das Problem, daß Winfuture nicht Google ist und daß ich nur den einen Eingang hab. Wir brauchen also eine Möglichkeit, zunächst den Weg zum Ziel zu finden (siehe hierzu auch den Post zu den Netzwerk-Grundlagen hier im Forum) und wenn wir dann vor der Türe stehen (am Tunnelendpunkt) diese Türe auch aufsperren zu können.
Hierfür gibt es Schlüssel, die mir von Winfuture (bzw Google) bereitgestellt werden. Diese Schlüssel helfen unter anderem bei der Navigation.
Jedoch gibt es ein kleines Problem: Ich habe einen Schlüssel und der schließt mir etwas auf und ich weiß aber nicht, was. Ich muß darauf vertrauen - siehe oben -- daß der Schlüssel, wo "winfuture.de" dransteht, auch zu winfuture.de gehört. Sonst kann es mir passieren, daß ich mich im Tunnelsystem buchstäblich verlaufe und ich im dunklen Hinterzimmer dunkler Gestalten lande.
Dafür gibt es Zertifizierungsstellen. Nennen wir sie an dieser Stelle einfach Schlüsselvergabestellen.
Diese Vergabestellen haben den unmittelbaren Auftrag, das oben angeführte Vertrauen zu bestätigen bzw. auf sich zu übertragen. Kerngedanke: Wenn ich der Schlüsselvergabestelle vertrauen kann, dann kann ich auch jedem vertrauen, der den Namen dieser Zertifizierungsstelle auf seinen Schlüssel gestempelt hat.
Es sei darauf hingewiesen, daß Schlüsselvergabestellen nicht unbedingt notwendig sind: ich habe als Anwender die Option, "direkt" zu vertrauen (sagen wir, weil ich den Gegenüber persönlich kenne oder überprüfen kann) oder indirekt via der Vergabestelle (weil ich den Gegenüber eben nicht unmittelbar kenne und ihn auch nicht auf Vertrauenswürdigkeit überprüfen kann).
Zertifizierungsstellen obliegt deshalb eine besondere Stellung: wenn ein Anbieter seine Identität nicht nachweisen kann, dann muß das die Vergabestelle für ihn tun.
Das bedeutet unweigerlich, daß die Vergabestelle eben jene Identität für sich selbst nachprüfen muß. Da sie einstehen muß dafür, daß Anwender dem Schlüsselbesitzer vertrauen, ist es die Pflicht einer jeden Schlüsselvergabestelle -- Zertifizierungsstelle oder Certificate Authority = CA genannt -- , dafür zu sorgen, daß sie *selbst* dem Schlüsselbesitzer vertrauen kann.
Oder anders formuliert: Gehe ich zu einem Schlüsseldienst, damit der mir einen Schlüssel für meine Wohnungstür bastelt, muß er - der Schlüsseldienst -- zunächst sicherstellen, daß er mir vertrauen kann, wenn ich behaupte, daß das ein Schlüssel für *meine* Wohnung sei oder daß ich zumindest befugt bin, einen Schlüssel für die Wohnung zu bekommen, die der Schlüssel aufsperren wird. Ansonsten könnte man hingehen und sagen, ich möchte einen Schlüssel für das Büro da in der Lindenstraße in Berlin, "Okay", und nach paar Momenten hat man dann einen Schlüssel... für eine Sache, auf die man eigentlich keinen Zugriff hätte haben sollen.
Erweiterung II: Autorisierung
Wie bereits angesprochen ermöglichen es uns die Schlüssel, Zugriff zu bekommen auf Ziele bei z.B. Winfuture oder Google. Problem: Die Kollegen haben üblicherweise mehr als nur den einen Dienst, auf den zugegriffen werden soll. Möglicherweise gibt es mehrere Dienste, die über winfuture.de zu erreichen sind, und es soll sichergestellt sein, daß auf den einen zugegriffen werden kann und auf den anderen aber nicht.
Unsere Schlüssel - nennen wir sie ab hier Zertifikate, auch wenn wir bei einer stark vereinfachten Form bleiben -- verfügen daher über einen Verwendungszweck. Das ist analog zu einem "richtigen" Schlüsselsystem, welches es ermöglicht, jedem mit "irgendeiner" Zugriffsberechtigung einen Schlüssel auszuhändigen... welcher dann in Abhängigkeit der Position auf bestimmte Schlösser im System paßt oder auch nicht paßt. Insbesondere ist nur dieser eine Schlüssel erforderlich.
Das besorgt der beschriebene Verwendungszweck. Für HTTPs gibt es hauptsächlich zwei: ein Serverschlüssel und ein Clientschlüssel ("TLS Web Server" bzw "TLS Web Client"). Der Clientschlüssel ist optional und wird üblicherweise nicht verwendet. Der Serverschlüssel sagt, daß der konkrete Schlüssel in meiner Hand es mir ermöglicht, auf https://www.winfuture.de zuzugreifen. Ohne diesen Verwendungszweck ginge das nicht und ein Zugriff wäre nicht möglich.
Der Vollständigkeit halber dient der Clientschlüssel zur wechselseitigen Authentifizierung. Verfüge ich über einen Clientschlüssel, so kann ich dem Webserver sagen "ich bin das". Der Webserver kann dann konfiguriert werden in einer Form, daß auf Basis dieses Schlüssels Zugriff gewährt bzw verweigert werden kann. Insbesondere wird mit einem solchen Clientschlüssel kein Benutzername und Paßwort mehr benötigt: Der Schlüssel regelt dann für mich den Zugriff, indem er beispiels als Benutzerschlüssel, Moderatorenschlüssel oder Administratorschlüssel ausgewiesen ist, bekomme ich als Schlüsselinhalber transparent Zugriff auf die für mich relevanten Bereiche (und keinen Zugriff auf die übrigen).
Solche Clientschlüssel befinden sich oft, aber nicht ausschließlich, auf Smartcards. In einem Unternehmen können beispielsweise über GPOs solche Schlüssel automatisch erstellt und an die Benutzer zugewiesen werden: diese bekommen dann auf dieser Grundlage Zugriff auf bestimmte Ressourcen und keinen Zugriff auf bestimmte andere Ressourcen.
Schlüssel weg! Was nun?
Wie jede Sache können Schlüssel geklaut werden. Außerdem kann es passieren, daß Schlüssel geknackt werden. Schlüsselbesitzer können gefeuert werden und sollen dann auch den Schlüssel nicht weiter verwenden können.
Dazu haben Schlüssel zum einen eine designierte Lebensdauer, die auf ein bestimmtes Intervall eingegrenzt ist (Nicht vor... bis Nicht nach...). Das soll dafür sorgen, daß Schlüssel erst dann geknackt werden können, wenn sie bereits ungültig (abgelaufen) sind.
Wenn ich aber auf die Idee komme, einem Schlüsselbesitzer nicht mehr vertrauen zu wollen, und diesem den Zugriff auf ihm bereits genehmigte Ressourcen wieder entziehen will, dann kann ich den Schlüssel an der Vergabestelle sperren lassen - wie eine Geld- oder Kreditkarte auch. Zugriff ist dann binnen kürzester Zeit nicht mehr möglich. Dafür gibt es Sperrlisten. Schlüssel - Zertifikate -- bringen dafür einen Verweis auf solche Sperrlisten mit, die bei Verwendung des Schlüssels abgefragt werden. sollte der verwendete Schlüssel dort eingetragen sein, wird dem Schlüsselbesitzer der Zugriff verweigert.
Schlüsselbund - Zertifikatsspeicher
Irgendwo müssen die verwendeten Schlüssel hingetan werden. Das ist das sprichwörtliche Schlüsselbund. Windows nennt es Zertifikatsspeicher.
Dieser ist aufgeteilt in "Eigene Schlüssel" für die Clientschlüssel und "Vertraute Schlüssel" für die Server- und Schlüsselvergabestellenschlüssel, denen ich vertraue; analog dazu gibt es aber auch "Nicht vertraut" für das Komplement dazu. Jede Schlüsselverwendung wird hierüber geprüft und es wird festgestellt, ob der Benutzer dem verwendeten Schlüssel in irgendeiner Form vertraut.
Aufpassen: Das ist wichtig. Hier geht es tatsächlich um das eigene Vertrauen. Computer können nicht vertrauen; Computer können nur schauen, ob der Benutzer gesagt hat, Ja mach ich, oder, nein mach ich nicht, und weitergehend, ob es dazu keine Information gibt.
Bei negativem Vertrauen - Benutzer hat Nö gesagt -- wird die Verbindung blockiert.
Bei positivem Vertrauen - Benutzer hat Ja gesagt -- wird die Verbindung zugelassen.
Und wenn es keine Möglichkeit gibt, das eine oder das andere festzustellen, gibt es üblicherweise eine Warnmeldung. Aktuelle Umsetzung ist dann "im Zweifel für die Sicherheit" und die Verbindung wird abgewiesen. Dann muß man dem Zertifikatsspeicher selber sagen, was man will. Firefox nennt das "Ausnahme hinzufügen". Mit dem Internet Explorer muß man schauen, wie die Zertfikatskette ausschaut (dazu auf das Schloß oben klicken und "Informationen" auswählen) und dann weiter verfahren. Üblicherweise kann man konkret dieses Zertifikat als "Vertraut" ausweisen, indem man es unter "Vertrauenswürdig" installiert.Man kann das aber auch mit jedem übergeordneten Zertifikat machen - ggf zunächst besorgen, soweit ein Herausgeberzertifikat angegeben, jedoch nicht verfügbar ist -- sich dann fragen, ob man dieser Vergabestelle auch wirklich vertrauen kann und schließlich das bewußte Zertifikat als Vertrauenswürdig deklarieren. Untergeordnete Zertifikate "erben" dann dieses Vertrauen.
Chrome verbuddelt Zertifikateigenschaften tief in den Developer Tools. Aus Sicherheitsgründen ist daher davon erstmal abzuraten.
Mobile Plattformen ermöglichen ggf. unterschiedliche Zugriffsmöglichkeiten.
iOS ermöglicht bis heute nicht diesen Zugriff wegen "nicht genug Interesse". Man muß sich deshalb im Klaren darüber sein, daß mobile Applegeräte NICHT integer sind, da es keine Möglichkeit gibt, das Ziel zu prüfen.
Dasselbe gilt analog für jeden Browser, der dem Benutzer diese Prüfmöglichkeit nimmt.
In jedem Fall muß man sich bewußt sein, daß man hier buchstäblich mit dem Vertrauen spielt. Man kann jedes Zertifikat zu einem "guten" Zertifikat machen, indem man es als "Vertrauenswürdig" einstuft; das gilt auch dann, wenn es ein Malware-Zertifikat war.
Eine Vertrauensprüfung ist deshalb unumgänglich.
Selbstgebastelte Schlüssel
Selbstsignierte Zertifikate sind am ehesten mit selbergebastelten Schlüsseln zu vergleichen. Ich hab mir nen Safe zusammengeschraubt? Ich fühle mich kompetent, meinen eigenen Schlüssel dafür zu verwenden? Insbesondere: ich vertraue eher auf meine eigenen Fähigkeiten als auf Dritte?
Dann kann ich selber meinen Schlüssel basteln, bzw. formal selbst signieren (d.h. den Schlüssel nicht nur erstellen, sondern ihn auch für gültig befinden; das, was normalerweise die Vergabestelle für mich macht).
Dann habe ich also einen Schlüssel, der -sagen wir- auf meinserver.ralphs.de paßt und wo "RalphS" auf dem Herstellerschild steht (und nicht Verisign oder sonstwas).
Der Schlüssel verhält sich dann gänzlich analog zu den "offiziellen" Schlüsseln. Ausnahme: Da keiner ihn kennt außer mir selber, bin ich genötigt, ihn auch selber an die richtige(n) Stelle(n) im Schlüsselbund/Zertfikatsspeicher zu hängen UND, wenn ich ihn weitergeben will, ein Vertrauensverhältnis zwischen "Mir" und meinem "Gegenüber" selbständig aufzubauen. Ist das der Fall, übernimmt mein selbstsigniertes Zertifikat zu 100% dieselben Eigenschaften wie ein "offizielles" Zertifikat das tun würde. Ausnahmen gibt es nur in Abhängigkeit davon, wie "gut" oder wie "schlecht" ich meinen (eigenen) Schlüssel gebastelt habe. Vergesse ich den Eintrag für die Sperrliste, kann ich ihn nicht ungültig machen. Konfiguriere ich den Einsatzzweck zu rigoros (oder zu ungenau) dann kann ggf. zuwenig, ggf. zuviel damit gemacht werden. Und wenn ich eine Lebensdauer von 20 Jahren angebe und der Schlüssel geht vorher zu knacken, dann ist das eine Eigenschaft meiner eigenen Konfiguration... nicht jedoch der Signierungsform.
Für Interessierte ist derzeit die einzig sinnvolle (mir bekannte) Zertifikatsverwaltung, die auch nicht kostet, OpenSSL.
Problem: OpenSSL "kann alles" (fast alles) und ist deshalb umständlich zu konfigurieren.
OpenSSL ist insoweit plattformunabhängig, daß es auf mehr oder wenige jede am Markt verfügbare Betriebsumgebung lauffähig ist - Windows eingeschlossen (Win32OpenSSL/Win64OpenSSL gibt es als Installationsdatei für Win32/64bit unter shininglightpro.com; evtl. wird die non-Light-Variante benötigt).
OpenSSL ist 100% Kommandozeile und (textbasierte) Konfigurationsdatei.
Ein wenig einfacher -wenn man in etwa weiß, was man tut- ist der Zertifizierungsdienst für Windows. Den gibt es allerdings nur auf Windows Serverbetriebssystemen (nicht in der kostenlosen Hyper-V Edition). Hier kann man rumklicken.
Tutorials für OpenSSL finden sich zuhauf im Netz. Diese kratzen üblicherweise nur an der Oberfläche, sind aber aus demselben Grund für den unbedarften Einsteiger die bessere Option.
Für Windows sollte sich unter dem Stichwort TLG = Test Lab Guide Anleitungen finden, unter anderem auch zum Thema PKI. TLGs beschreiben eine virtuelle Infrastruktur, die selbst zu erstellen ist, welche dann für alle möglichen Testszenarien herangezogen werden können.
Dieser Beitrag wurde von RalphS bearbeitet: 03. August 2017 - 06:14
Nach oben
