Schlagwort-Archive: X.509

Mein TLS/SSL-Kochbuch

7 Antworten

Heutzutage werden immer mehr Kommunikationsverbindungen im Internet mit TLS/SSL-Verbindungen geschützt. Die Verschlüsselung hilft, die Vertraulichkeit der zwischen Sender und Empfänger übertragenen Daten zu schützen und sollte daher standardmäßig aktiviert sein. Doch bereitet der Einsatz von TLS/SSL-Verschlüsselung noch immer vielen Administratoren und Betreibern verschiedenster Anwendungen Kopfschmerzen. Zu undurchsichtig scheint der Dschungel aus Zertifizierungsstellen, Zertifikaten, Zertifikatsanfragen, öffentlichen und privaten Schlüsseln zu sein. Verschiedenste Validierungsverfahren und Dateiformate für Zertifikate tragen nicht gerade dazu bei, den Durchblick zu behalten. Bereits die Erstellung einer Zertifikatsanfrage gerät dabei häufig genug zu einem Problem. Die richtige Konfiguration der zu sichernden Server bzw. Dienste erscheint kompliziert und Fehler in der Konfiguration führen nicht selten zur Nichterreichbarkeit einer Webseite. Die Folge: Immer noch wird viel zu häufig auf den Einsatz von TLS/SSL-Verschlüsselung verzichtet.

Mit meinem TLS-Kochbuch möchte ich dazu beitragen, etwas Licht ins Dunkel zu bringen. Darin finden sich Rezepte mit praktischen Tipps für die Verwendung von TLS/SSL-Verschlüsselung mittels OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP).

Aus dem Inhalt

Nach der Einleitung führt Kapitel 2 in das Thema ein und definiert die wesentlichen Begriffe. Es bildet die Grundlage für das Verständnis der daran anschießenden Kapitel.

In Kapitel 3 geht es um die Implementierung von TLS/SSL. Hier werden verschiedene Methoden zur Generierung von privaten Schlüsseln und Certificate Signing Requests vorgestellt. Darüber hinaus werden einige Zertifizierungsstellen kurz vorgestellt, bei denen Zertifikate beantragt werden können. Im Folgenden wird auf die Implementierung von TLS/SSL-Zertifikaten in verschiedenen Diensten eingegangen. Hier wird insbesondere die Implementierung von Zertifikaten der recht jungen Zertifizierungsstelle „Let’s Encrypt“ erläutert, mit deren Hilfe sich der Prozess der Zertifikatserneuerung automatisieren lässt.

Der Implementierung des HTTP Public Key Pinning (HPKP) widmet sich Kapitel 4. Das Pinning-Verfahren wird am Beispiel des Webservers NGINX erläutert und getestet.

Zum Schluss werden die in den einzelnen Kapiteln vorgestellten Techniken und Methoden nochmals zusammenfassend an einem konkreten Beispiel in Kapitel 5 verdeutlicht.

Hier geht es zum Text

Mir persönlich hat die Arbeit an folgendem Dokument geholfen, mich detailliert mit der Thematik auseinanderzusetzen und mein Wissen zu erweitern und zu vertiefen. Ich freue mich, wenn mein Kochbuch auch euch dabei hilft, ein besseres Verständnis für das Thema zu entwickeln.

Dies ist die erste Ausgabe meines TLS/SSL-Kochbuchs und es gibt sicher noch viel mehr, was man zu diesem Thema schreiben kann. Fehler sowie Wünsche zum Inhalt zukünftiger Ausgaben können gern an die E-Mail-Adresse tls-rezepte(aet)my-it-brain(Punkt)de gemeldet werden.

Downloads zum Text

Passed the CAcert.org Assurer Challenge

Schreibe eine Antwort

Vergangene Woche bin ich auf dem LinuxTag 2014 in Berlin am Stand von CAcert.org hängen geblieben.

Worum geht es bei CAcert.org?

CAcert.org ist eine von einer Gemeinschaft betriebene Zertifizierungsstelle, die kostenfreie Zertifikate für jedermann ausstellt.

Das Ziel von CAcert ist es, das Bewusstsein und die Unterrichtung über Computersicherheit durch die Benutzung von Verschlüsselung zu fördern, insbesondere durch die Herausgabe von Zertifikaten zur Verschlüsselung. Diese Zertifikate können benutzt werden, um E-Mails digital zu unterschreiben und zu verschlüsseln, einen Anwender beim Zugang zu Webseiten zu beglaubigen und zu berechtigen und eine gesicherte Datenübertragung über das Internet zu ermöglichen. Jede Anwendung, die das gesicherte Übertragungsprotokoll mit SSL oder TLS unterstützt, kann von Zertifikaten Gebrauch machen, die von CAcert signiert wurden, ebenso jede Anwendung, die X.509-Zertifikate benutzt, z.B. für Verschlüsselung oder Signierung von Code oder Dokumenten.

Das Prinzip von CAcert.org basiert dabei auf einem Vertrauensnetzwerk, dem sogenannten Web of Trust. Im Gegensatz zu einer hierarchischen Public-Key-Infrastruktur wird die Echtheit von Zertifikaten (digitalen Schlüsseln) nicht von einer einzelnen Organisation, sondern durch gegenseitige Bestätigung (Assurance) der Mitglieder geprüft.

Zur Verdeutlichung hier ein kleines Beispiel aus der Wikipedia:

Alice signiert den Schlüssel von Bob und vertraut Bobs Schlüsselsignaturen
Bob signiert den Schlüssel von Carl
(Bobs Vertrauen in Carls Schlüsselsignaturen ist weder bekannt noch relevant)
Somit betrachtet Alice den Schlüssel von Carl als gültig.

Es ist also eine Frage des Vertrauens. Und die Frage ist berechtigt, wem man mehr Vertrauen schenkt. Einer kommerziellen Zertifizierungsstelle, oder dem Web of Trust und damit der CAcert.org Community. Ich für meinen Teil habe mir diese Frage bereits beantwortet.

Nachdem wir in Folge des Heartbleed Bug alle SSL-Zertifikate in unserem Unternehmen erneuern mussten ist mein Vertrauen in die kommerziellen Zertifizierungsstellen erschüttert. Die durchgeführten „Verification Calls“ ließen mich sehr stark an der Vertrauenswürdigkeit der Identifizierung zweifeln. So hätte auch ein Praktikant oder jeder x-beliebige Mitarbeiter an ein Zertifikat für eine unser Domains gelangen können. Fest steht, der Anbieter kann sich nicht sicher sein, dass er tatsächlich mit der zur Zertifikatsanforderung berechtigten Person gesprochen hat.

Im Vertrauensnetzwerk von CAcert.org wird die Echtheit eines Zertifikats durch eine persönliche Assurance des Besitzers bestätigt. Dabei prüft ein CAcert Assurer mindestens ein offizielles Ausweisdokument, um die Identität des Zertifikatsinhabers zu bestätigen. Es muss also in jedem Fall ein Treffen von Angesicht zu Angesicht stattgefunden haben, bevor einem Zertifikat das Vertrauen ausgesprochen werden kann. Dieser Prozess wird detailliert in der Assurance Policy for CAcert Community Members definiert.

Ich persönlich habe großes Vertrauen in das Prinzip des Web of Trust und entschied mich vergangene Woche selbst CAcert Assurer zu werden, um die Echtheit von Zertifikaten weiterer CAcert.org Member assuren zu können. Dazu ließ ich meine eigene Identität auf dem LinuxTag gleich von vier CAcert Assurern bestätigen, um die nötigen Assurance Punkte zu sammeln, die nötig sind, um selbst Assurer zu werden. Denn nur Personen, denen ein gewisses Mindestmaß an Vertrauen bestätigt wurde und welche die Assurer Challenge bestanden haben, dürfen die Identität anderer Mitglieder bestätigen.

Gestern habe ich die Assurer Challenge im ersten Anlauf bestanden und stehe euch damit als CAcert Assurer zur Verfügung.

Falls ihr noch nicht sicher seid, wie digitale Signaturen und Zertifikate funktionieren, oder Mitglied der Community wird, empfehle ich euch die Seite „CAcert in kurzen Worten“. Dort wird auch der Registrierungsprozess beschrieben, damit ihr euch anmelden und einloggen könnt.

So get Assured
www.cacert.org