Kostenlose TLS/SSL-Zertifikate durch eigene CA erstellen (Teil 1: Grundlagen)

Vor einiger Zeit habe ich eine Artikelserie über die Installation von ownCloud auf einem Raspberry PI veröffentlicht. Die für die Absicherung via Transport Layer Security (TLS, vormals SSL) verwendeten Schlüssel wurden damals durch die israelische Firma StartSSL zertifiziert und damit beglaubigt.

Nun sind diese Zertifikate abgelaufen und es ist Zeit für eine Erneuerung. Ein willkommener Anlaß etwas ausführlicher auf die Funktion von Schlüsseln, deren Beglaubigung durch (eigene) Certificate Authorities (CA) und die Installation auf Server und Client einzugehen.

Verschlüsselung und Authentifizierung

Über Sinn und Unsinn von Verschlüsselung muß meines Erachstens nicht diskutiert werden. Das Ziel ist es, Informationen vertraulich aufzubewahren und/oder abhörsicher zu übertragen, so daß sie nur dem Sender und den Empfängern zugänglich sind.

Art und Inhalt der Information sind dabei ohne Belang. Was privat und damit schützenswert und was öffentlich und potentiell einsehbar ist – darüber darf und sollte jeder Bürger eines freien Landes selbst entscheiden. Und wie die jüngsten Skandale rund um NSA, GCHQ, sowie die wiederkehrenden Rufe nach einer Vorratsdatenspeicherung demonstrieren, scheint kein Detail unseres Lebens trivial genug, als daß sich nicht jemand dafür interessieren würde — selbstverständlich nur zu unserer eigenen Sicherheit.

Verschlüsselung

Verschlüsselung macht aus einer Information (einer Datei, einer E-Mail oder dem Inhalt einer Verbindung) ein Geheimnis. Die angewandten, kryptographischen Verfahren lassen sich grob in zwei Kategorien unterteilen:

  1. symmetrische Verschlüsselung (DES, AES, usw.) setzt auf einen einzelnen, dem Sender und den Empfängern bekannten Schlüssel (shared secret bzw. pre-shared-key).
  2. asymmetrische Verschlüsselung (PGP, GnuPG, etc.) verwendet Schlüsselpaare, deren privater Teil (private key) vertraulich bleibt, während der öffentliche Teil (public key) verteilt wird.

Während bei symmetrischer Verschlüsselung der Schlüssel über ein anderes, sicheres Verfahren zwischen Sender und Empfänger ausgetauscht werden muß, benötigt man bei der asymmetrischen Verschlüsselung nur den öffentlichen Schlüsselteil des jeweils anderen Kommunikationspartners. Dieser kann im Vorfeld per E-Mail geschickt, zum Download angeboten oder über eine Public Key Infrastructure (PKI) öffentlich gemacht werden. Für die Verschlüsselung bzw. Entschlüsselung werden der öffentliche Schlüssel und der eigene private Schlüssel kombiniert.

Da die symmetrische Verschlüsselung einfacher und ressourcenschonend ist, kommen beide Verfahren oft in Kombination zur Anwendung:

  • für den initialen Aufbau der Verbindung werden die öffentlichen Schlüssel von Server und Client ausgetauscht
  • über die so mögliche asymmetrische Verschlüsselung wird anschliessend ein gemeinsamer Schlüssel ausgehandelt und auf symmetrische Verschlüsselung umgestellt

Diese Beschreibung ist bewußt einfach gehalten, Interessierten sei an dieser Stelle der entsprechende Eintrag bei Wikipedia oder ein Beratungsgespräch bei meinem Arbeitgeber Cassini Consulting GmbH empfohlen.

Authentifizierung

Die oben beschriebenen Methoden sind bereits ausreichend, um eine verschlüsselte Kommunikation zwischen zwei Endpunkten aufzubauen. Sie sagen aber nichts über die Identität der Schlüsselinhaber aus. Über eine sog. Man-in-the-middle Attacke kann ein Angreifer sich zum Zeitpunkt des Verbindungsaufbaus in den Kommunikationsweg einschalten, die ausgetauschten Schlüssel abfangen und durch eigene ersetzen. Er kann dann den gesamten Datenstrom entschlüsseln und mitzulesen, ohne das dies den eigentlichen Kommunikationspartnern auffällt.

Certificate Authority

Die Bestätigung von Schlüsseln durch Dritte ist daher wesentlicher Bestandteil der Verschlüsselungstopologie. Die Beglaubigung durch eine oder viele, als vertrauenswürdig geltende Instanzen soll einen öffentlichen Schlüssel validieren und seinen Inhaber identifizieren. Die Zertifizierung durch andere, akkreditierte Personen oder Organisationen soll somit die eigene Glaubwürdigkeit bestätigen. Auf diese Art und Weise bildet sich ein Netz aus Vertrauen, das sog. Web of Trust.

Während im Bereich PGP und GnuPG die Authentizität des Kommunikationspartners vornehmlich durch gegenseitige Bestätigung (z.B. auf Crypto-Parties) erreicht wird, übernehmen diese Aufgabe im World Wide Web und bei E-Mail-Verschlüsselung via S/MIME Certificate Authorities (CA).

Kommerzielle CAs

Rund um Zertifikate und Signaturen hat sich darum ein großer, lukrativer Markt entwickelt. Große CAs wie Verisign oder Global Sign versprechen Sicherheit durch gewissenhafte Prüfung und regelmässige Audits — zu entsprechenen Preisen. Günstigere oder gar kostenlose Angebote (wie das von StartSSL) bieten in der Regel lediglich eine Validierung der E-Mail-Adresse und des Domain Records.

Anbieter, deren Stammzertifikate Teil einer Browser- oder System-Installation sind, kommen dabei besonders gut weg, da ihre Kunden keinerlei Warnungen durch den Browser erwarten müssen. Faktisch kein Unternehmen, welches für Glaubwürdigkeit und Sicherheit steht, kann es sich erlauben ohne das Zertifikat einer solchen Root-CA zu arbeiten. Dabei zeigen z.B. der Fall DigiNotar oder die Gewißheit, daß eine Regierung bzw. deren Geheimdienste Unternehmen zur Preisgabe vertraulicher Informationen zwingen kann, daß absolute Sicherheit auch in diesem Bereich nicht existiert.

Die eigene CA

Die Hürde für die Einrichtung einer eigenen Certificate Authority ist äußerst niedrig. Technisch kann die eigene CA Schlüssel signieren und somit Zertifikate erzeugen, welche bzgl. Sicherheit in keinster Weise kommerziellen Varianten nachstehen. Im Gegenteil, sie kann sogar schneller aktuelle Entwicklungen im Bereich Verschlüsselung aufgreifen und anbieten, als es einem kommerziellen Anbieter mit definierten SLAs möglich ist. Außerdem löst die eigene CA die Abhängigkeit von (ausländischen) Unternehmen und deren Rechtsumfeld und spart natürlich Kosten.

Fachlich jedoch wird die eigene Certificate Authority einem akkreditierten Anbieter auf absehbare Zeit nicht das Wasser reichen können. Solange das Stammzertifikat (also der selbst-signierte öffentliche Schlüssel der CA) nicht in allen Clients, wie Computern, Mobiltelefonen, Programmen und Apps installiert ist, werden diese unweigerlich mehr oder weniger dramatische Warnungen beim Verbindungsaufbau aussprechen – oder den Aufbau ganz verweigern.

Aus diesem Grund richtet sich die Anleitung im zweiten Teil der Artikelserie primär an erfahrene Administratoren, welche ausgewählte Dienste in einem kontrollierten Umfeld, für ein definiertes Publikum mit einer sicheren, kostengünstigen Transport-Verschlüsselung anbieten wollen.

Weiter zu Teil 2: Erstellung.

Kommentar hinterlassen