Artikelserie Teil 5: Sicher auf dem Server unterwegs

Kryptographie für Anfänger: HTTPS, Zertifikate und Co.
Keine Kommentare

In den vergangenen Teilen dieser Serie haben wir die kryptografischen Grundlagen gelegt, um nun Sicherheit auf Anwendungsebene implementieren zu können: Wie lässt sich ein Webserver absichern?

Das Schöne an der Kryptografie ist, dass sich zahlreiche Anwendungen auf Basis einiger weniger Grundbausteine aufbauen lassen. Diese Grundbausteine wurden in den vergangenen vier Teilen dieser Serie vorgestellt. Zum Verschlüsseln stehen nun die symmetrische und die asymmetrische Verschlüsselung zur Verfügung, außerdem sind Hashfunktionen und Message Authentication Codes (MACs) zum Schutz vor Manipulation bekannt und zu guter Letzt wurden auch die Möglichkeiten zum digitalen Signieren besprochen. Dabei genügt es, einige ausgewählte Algorithmen zu kennen, hauptsächlich AES, RSA und SHA. Natürlich bietet die Kryptografie noch mehr, aber mit diesen Bausteinen kommt man schon erstaunlich weit.

Die vierte Folge hat die asymmetrische Verschlüsselung auf Basis von RSA vorgestellt. Kurz zur Rekapitulation: Im Gegensatz zur symmetrischen Verschlüsselung à la AES gibt es bei der asymmetrischen nicht nur einen, sondern zwei Schlüssel – einen öffentlichen und einen privaten, genannt Public Key und Private Key. Diese beiden Schlüssel stehen dabei in einem besonderen mathematischen Verhältnis zueinander: Was mit dem einen verschlüsselt wurde, kann nur mit dem jeweils anderen wieder entschlüsselt werden. Diese interessante Vorgehensweise lässt zwei grundlegende Szenarien zu:

  • Verschlüsselt man eine Nachricht mit dem öffentlichen Schlüssel des Empfängers, kann nur er die Nachricht wieder entschlüsseln. Nur er kennt schließlich den dafür erforderlichen privaten Schlüssel.

  • Verschlüsselt man eine Nachricht hingegen mit dem privaten Schlüssel des Absenders, lässt sie sich nur mit dem öffentlichen Schlüssel des Absenders wieder entschlüsseln, was – da der Schlüssel ja öffentlich ist – für jeden möglich ist.

Der Vorteil des ersten Vorgehens erschließt sich auf Anhieb, beim zweiten muss man einen Augenblick innehalten und überlegen. Dann jedoch wird klar, dass sich damit eine digitale Signatur implementieren lässt, denn wenn eine Nachricht mit dem öffentlichen Schlüssel von Alice entschlüsselbar ist, muss sie von Alice verschlüsselt worden sein.

Webserver absichern

Der prinzipiell gleiche Ansatz kommt nun auch bei Webservern zum Tragen. Um die Kommunikation mit Webservern abzusichern, wird üblicherweise HTTPS eingesetzt. Tatsächlich handelt es sich bei HTTPS streng genommen gar nicht um ein eigenes Protokoll, vielmehr ist es das klassische (und unverschlüsselte) HTTP-Protokoll, das über eine TLS-Verbindung getunnelt wird. TLS steht dabei für Transport Layer Security (was früher als SSL, Secure Socket Layer, bezeichnet wurde), ein Protokoll, dessen Aufgabe das Absichern von Verbindungen ist. Das Schöne daran ist, dass man an HTTP nichts ändern musste, sondern es einfach um eine weitere Schicht ergänzt hat, die generisch und daher wiederverwendbar ist.

Welcher Art ist nun die Absicherung, die HTTPS (beziehungsweise TLS) übernimmt? Zunächst soll eine HTTPS-Verbindung sicherstellen, dass die Daten zwischen Client und Server nur von den beiden Teilnehmern gelesen werden können. Das ist einfach zu bewerkstelligen und ließe sich sogar auf AES-Basis implementieren. Den dann erforderlichen gemeinsamen Schlüssel könnte man über das Schlüsselaustauschverfahren Diffie-Hellman Key Exchange aushandeln, und alles wäre bereits erledigt. Tatsächlich passiert das so oder zumindest so ähnlich auch unter der Haube.


Allerdings genügt das nicht. Denn wenn man mit einem Webbrowser einen Server anspricht, weiß man nicht, ob man wirklich mit dem gewünschten Server spricht – oder mit jemandem Dritten, der sich nur als der eigentliche Server ausgibt. Man weiß also nur, dass die Kommunikation an sich abhörsicher ist, nicht aber, ob man auch mit dem richtigen Gegenüber kommuniziert. Ein Dritter könnte sich also zwischen den Client und den Server begeben und beiden Parteien jeweils vorspielen, mit dem richtigen Gegenüber zu sprechen: Der Effekt wäre, dass die gesamte Kommunikation verschlüsselt laufen würde, aber trotzdem unsicher wäre, weil eine unerwünschte Partei in der Mitte alles mitlesen kann.

Ein solcher Angriff wird als Man in the Middle (MITM) bezeichnet und ist einfacher durchzuführen als man zunächst vermutet. Die Bandbreite reicht von manipulierten DNS-Einträgen über eine modifizierte /etc/hosts-Datei bis hin zu gezielt aufgesetzten Servern, die sich Unicode-Zeichen in URLs zu Nutze machen. Für eine wirklich sichere Verbindung müsste man sicherstellen, dass nicht nur die Verbindung an sich verschlüsselt wird, sondern dass die Parteien einander auch verlässlich identifizieren können – oder dass zumindest der Client den Server verlässlich identifizieren kann.

Zertifikate dienen der Identifikation

Glücklicherweise lässt sich das (zumindest theoretisch) ganz einfach mit Hilfe einer asymmetrischen Verschlüsselung implementieren, ähnlich einer digitalen Signatur. Dazu werden auf dem Webserver ein privater und ein öffentlicher Schlüssel hinterlegt. Möchte sich nun ein Client verbinden, erfragt er vom Server zunächst dessen öffentlichen Schlüssel. Anschließend kann der Server seine Antworten mit einer digitalen Signatur versehen, was für den Client nachprüfbar ist; damit ist sichergestellt, dass man tatsächlich mit dem Server kommuniziert, zu dem der öffentliche Schlüssel gehört.

Leider greift der Ansatz zu kurz, denn woher weiß der Client, ob der initial zurückgegebene Schlüssel tatsächlich der offiziell zu dem gewünschten Server gehörige ist? Für einen Angreifer wäre es mit diesem System nach wie vor ein Leichtes, sich in die Kommunikation hineinzudrängen. Um das zu verhindern, wird der öffentliche Schlüssel mit Metadaten versehen. Dazu zählt vor allem der Domainname, dem dieser öffentliche Schlüssel zugeordnet werden soll. Da Schlüssel von Haus aus nur mathematische Konstrukte und nicht für die Aufnahme von Metadaten ausgelegt sind, packt man den Schlüssel mitsamt der Metadaten in einen gemeinsamen Container. Dieser Container ist dann ein sogenanntes Zertifikat. Doch auch das genügt noch nicht, denn wer sollte einen Angreifer daran hindern, sich selbst ein Zertifikat beispielsweise für die Domain www.google.de auszustellen?

Deshalb muss ein Zertifikat zunächst noch beglaubigt werden, um gültig zu sein. Diese Aufgabe übernimmt ein vertrauenswürdiger Dritter, der überprüft, ob die Person, die ein Zertifikat beantragt, tatsächlich auch diejenige ist, für die sie sich ausgibt, und ob ihr außerdem auch die Domain gehört, für die das Zertifikat gültig sein soll. Natürlich kann es sich dabei nicht nur um eine natürliche, sondern auch um eine juristische Person handeln, und die Überprüfung kann einfacher oder komplexer ausfallen. Dieser vertrauenswürdige Dritte wird als Certificate Authority (CA) bezeichnet und signiert nach erfolgter Überprüfung das ausgestellte Zertifikat digital mit dem eigenen privaten Schlüssel.

Damit gilt: Ein Zertifikat gilt dann als vertrauenswürdig, wenn die dort eingetragenen Metadaten zum angefragten Server passen und wenn von einer CA per digitaler Signatur bestätigt wurde, dass das Zertifikat tatsächlich zu der Domain des Servers gehört. Damit hat ein Angreifer keine Chance mehr, sich unberechtigt in den Datenverkehrt einzuklinken – oder?

Von CA zu CA zu CA zu …

Leider hat das System einen gravierenden Haken. Denn woher weiß man, ob die digitale Signatur der CA gültig ist? Theoretisch lässt sich das leicht nachprüfen, denn dazu müsste man nur den öffentlichen Schlüssel der CA laden, und könnte dann die Signatur überprüfen. Doch woher weiß man, dass der öffentliche Schlüssel der CA auch tatsächlich zu dieser CA gehört, und nicht beispielsweise von einem Angreifer stammt?

Um dieses Problem zu lösen, könnte man dem öffentlichen Schlüssel der CA Metadaten hinzufügen, beides zusammen in einen Container (d. h. in ein Zertifikat) verpacken, und dieses Zertifikat von einem vertrauenswürdigen Vierten signieren lassen – man braucht also eine weitere CA, die die erste CA beglaubigt. Doch woher weiß man, ob man dieser zweiten CA trauen kann? Dafür bräuchte es wieder eine CA, die wiederum … Am Ende steht die Erkenntnis, dass man sich letztlich nur von CA zu CA hangelt und wirkliche Gewissheit nicht zu erreichen ist. Da diese Kette zudem aus praktischen Gründen nicht unendlich lang werden darf, stößt man über kurz oder lang auf eine sogenannte Root CA, eine Art Super-CA.

Um das Problem auf der Ebene zu lösen, fügen die Hersteller der gängigen Betriebssysteme und Webbrowser die Zertifikate der Root CAs den Betriebssystemen und Webbrowsern direkt zu. Das heißt, dass man sich bei einer Zertifikatsprüfung ganz am Ende also darauf verlässt, dass Apple, Google, Microsoft & Co. ihren Job vernünftig machen. Das kann man nun gut finden oder nicht – Fakt ist, dass die Sicherheit nahezu des gesamten Internets auf diesem Prinzip beruht und letztlich eine Frage des Vertrauens ist.

Ein Zertifikat beantragen

Um ein Zertifikat zu erhalten, muss man es bei einer CA beantragen. Dazu gilt es zunächst, einen privaten Schlüssel zu generieren. Da dieser Schlüssel nur dem Besitzer bekannt sein sollte, ist es äußerst ratsam, diesen selbst zu erzeugen, und das nicht einem externen Anbieter zu überlassen. Auch sollte man für jedes Zertifikat einen eigenen privaten Schlüssel anlegen und ihn niemals wiederverwenden – beispielsweise auch nicht, um ein Zertifikat zu verlängern.

Hat man einen privaten Schlüssel erzeugt, gilt es als Nächstes, daraus den öffentlichen Schlüssel abzuleiten und die für den öffentlichen Schlüssel gewünschten Metadaten zu definieren. Anschließend kann man den öffentlichen Schlüssel mitsamt den Metadaten an eine CA übermitteln. Der öffentliche Schlüssel mit den Metadaten stellt zwar prinzipiell schon den Zertifikatscontainer dar, allerdings fehlt hier noch die digitale Signatur der CA. Deshalb spricht man hier von einem Certificate Signing Request (CSR). Die CA prüft den CSR anschließend und signiert ihn, wenn sie ihn als vertrauenswürdig einstuft. Das Ergebnis ist dann das eigentliche Zertifikat, das man von der CA erhält.

Den privaten Schlüssel muss man natürlich weiterhin sorgsam aufbewahren, den CSR hingegen kann man bedenkenlos löschen: Er war quasi nur die Bestellung, und die ist mit dem Eintreffen des Zertifikats als abgeschlossen anzusehen. Die meisten CAs übernehmen übrigens nicht alle gewünschten Metadaten aus einem CSR, sondern nur einen Teil. Als ein Minimum muss aber der gewünschte Domainname enthalten sein. Gegebenenfalls ergänzt die CA noch weitere Domainnamen, für die das Zertifikat gültig ist, so wird beispielsweise häufig von Seiten der CA bei einem Zertifikat für www.example.com auch noch example.com ergänzt – andernfalls würde das Zertifikat tatsächlich nur in Verbindung mit der Subdomain www funktionieren.

Für lokale Entwicklungszwecke will oder kann man unter Umständen kein Zertifikat beantragen. Gründe dafür gibt es viele, am gängigsten dürfte das Problem sein, dass die Domain gar nicht von außen erreichbar und damit auch nicht überprüfbar ist – oder dass schlicht und ergreifend kein Geld für ein internes Zertifikat ausgegeben werden soll. In beiden Fällen kann man sich mit einem sogenannten selbstsignierten Zertifikat behelfen. In dem Fall erzeugt man das Zertifikat aus dem CSR selbst und signiert es mit dem privaten Schlüssel, der bereits für das Erstellen des CSRs verwendet wurde. Ein solches Zertifikat erfüllt technisch alle Voraussetzungen, um es für die Entwicklung einsetzen zu können, ist aber nicht allgemein als vertrauenswürdig angesehen.

Seriennummer, Ablaufdatum & Co.

Neben den gewünschten Metadaten tragen CAs üblicherweise auch noch weitere Metadaten ein, auf die man keinen Einfluss hat. Dazu zählt zum einen eine Seriennummer: Mit ihrer Hilfe kann eine CA ein Zertifikat als ungültig markieren, wenn beispielsweise der private Schlüssel abhandengekommen ist. Dafür gibt es spezielle Listen, auf denen als ungültig anzusehende Zertifikate geführt werden, sogenannte Certificate Revocation Lists (CRL). Zum anderen zählt dazu auch das Ablaufdatum des Zertifikats: Obwohl ein Zertifikat aus technischer Sicht kein Ablaufdatum besitzen müsste, wird die Gültigkeit in der Praxis beschränkt, üblicherweise auf ein Jahr. Das bewirkt, dass ein Zertifikat regelmäßig ausgetauscht werden muss, und alte Zertifikate, die eventuell nicht mehr den aktuellen Sicherheitsansprüchen genügen, nicht ewig weiterlaufen.

Im Idealfall lässt sich das Beantragen und Einspielen eines Zertifikats natürlich automatisieren, sodass man damit überhaupt keinen zusätzlichen manuellen Aufwand hat. Außerdem hat eine vollständige Automatisierung den großen Vorteil, dass die Zertifikatslaufzeiten noch weitaus kürzer sein können als ein Jahr. Besonders hervorzuheben ist hier die ursprünglich von Mozilla ins Leben gerufene Initiative Let’s Encrypt [1], die als kostenlose CA auf gemeinnütziger Basis agiert. Wer eine eigene CA betreiben will, ist mit Vault [2] von HashiCorp gut beraten.

Wer sich ernsthaft mit dem Thema beschäftigen will, sollte sich außerdem auch mit dem Werkzeug OpenSSL [3] beschäftigen, das die Grundlage für viele der hier genannten Abläufe bildet, und außerdem auch Unterstützung für AES, RSA & Co. enthält.

Fazit

Wie man sieht, sind HTTPS und Zertifikate keine Raketenwissenschaft, sondern einfach erklärbar und gut verständlich, wenn man die grundlegenden kryptografischen Verfahren und Algorithmen kennt. Das gilt noch für viele weitere Anwendungsgebiete, letztlich bauen fast alle von ihnen auf den bislang vorgestellten Ansätzen auf, lediglich ihre Kombination ist jeweils anders.

Theoretisch lässt sich mit Zertifikaten übrigens noch viel mehr anstellen. So könnte man sie beispielsweise auch für die Identifikation des Clients nutzen – Benutzername und Kennwort könnten dann entfallen. Als vertrauenswürdiger Dritter würden sich hier Banken oder der Staat anbieten. Dann könnte der Webbrowser das clientseitige Zertifikat an den Server mit übermitteln, und so könnten beide Seiten sicherstellen, mit dem erwarteten Gegenüber zu kommunizieren. Allerdings hat sich das Vorgehen in den vergangenen Jahrzehnten nicht durchsetzen können, und es ist eher unwahrscheinlich, dass sich daran auf absehbare Zeit etwas ändern wird.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -