Verschlüsselung und Zertifikate – Ein häufig unterschätztes Thema

Verschlüsselung von Datenverbindungen und Zertifikatverwaltung sind zunehmend die Grundvoraussetzung für den Betrieb moderner Software-Systeme geworden. Dabei geht es einerseits um Schutz von unbefugtem „mithören“, um so den Zugriff auf die Kommunikationsinhalte von E-Mails, Webserver, Zugangsdaten, Zahlungsinformationen beim Online-Banking, personenbezogenen Daten, E-Mail-Verschlüsselungen, digitalen Unterschriften etc. zu verhindern. Und andererseits um Sicherstellen, dass ein Client und ein Server sich über die Identität des anderen im Klaren sind.

Damit alles reibungslos funktioniert ist eine Menge Technik und Know-How erforderlich, sowie eine Reihe von wiederkehrenden Verwaltungsaufgaben. Denn die sicherste Verschlüsselung bringt nichts, wenn die zugrunde liegende Technik nicht optimal konfiguriert und die Verwaltung unvollständig ist. Häufig entstehen Fehler, sei es durch Überforderung oder fehlender Routine des Personals, die sich in Ausfall und Produktivitätsverlust, oder in Form von Sicherheitsmängeln darstellen. Beides kann potentiell hohe Kosten nach sich ziehen.

In jedem Unternehmen, unabhängig von On-Premises oder Cloud, ist dieser Themenkomplex vertreten und er wird insbesondere im Cloud-Bereich immer wichtiger. In meinen Kundenprojekten erlebe ich häufig Situationen in denen Verschlüsselung und Zertifikat-Verwaltung schlecht umgesetzt sind.

In diesem Blogbeitrag erkläre ich einige der technischen Grundlagen und Voraussetzungen auf dem Weg zur optimalen Zertifikatverwaltung.

In den darauf aufbauenden Webinaren gehen wir ins Detail, berichten von Best Practices aus den Kundenprojekten im Umgang mit Verschlüsselungen und Zertifikaten, zeigen die Tricks zur direkten Umsetzung und erklären, wie die unnötigen Fehler vermieden werden: Verschlüsselung und Zertifikate – Best Practices für die Planung und Verwaltung | 20.05.2021 // 10 Uhr.

Nach dem Webinar Wie PKI einige der größten Sicherheitsherausforderungen von heute vereinfacht | 08.07.2021 // 10 Uhr werden Sie eine klare Struktur haben, was eine Public Key Infrastruktur (PKI) ist, welche Technik ihr zugrunde liegt und ob sie auch in Ihrem Betrieb umgesetzt werden soll.

Was hat Verschlüsselung mit Zertifikaten zu tun?

Zunächst erst einmal gar nichts! Bei Zertifikaten geht es in erster Linie um Identität, vergleichbar mit einem Personalausweis. Zusätzlich jedoch ist in jedem Zertifikat ein sogenannter „Public Key“ enthalten. Die meisten Crypto-Implementierungen, insbesondere die für SSL/TLS erfordern, dass sich zumindest der (Web-)Server gegenüber dem Client (Browser, etc.) „ausweist“. Dies erfolgt in der Praxis mit einem digitalen Zertifikat, das neben der Identität des Servers, bestimmte Attribute, und wie erwähnt, den „Public Key“ enthält. Demzufolge benötigt ein SSL/TLS Server immer ein Zertifikat, um überhaupt seine Verschlüsselungsfunktion zu aktivieren. D.h. wenn ich möchte, dass mein Webserver SSL/TLS spricht, muss ich zuerst ein Key-Pair (public und private) erzeugen. Da der public Key im Zertifikat, das der Server vorlegt, enthalten ist, und der Ausstellende Zertifizierungsstelle dem Client bereits vorher bekannt ist, kann der Client die Identität des Servers verifizieren.

Darüber hinaus können über den Mechanismus mit public/private Key im Rahmen von asynchroner Verschlüsselung beide Kommunikationspartner einen symmetrischen Schlüssel berechnen, der später für die eigentliche Verschlüsselung verwendet und niemals über die Leitung übertragen wird.

Symmetrische und Asymmetrische Verschlüsselung

Es gibt zwei fundamental unterschiedliche Formen der Verschlüsselung: Symmetrische Verschlüsselung (z.b. AES) kommt bei der eigentlichen Datenübertragung zur Verwendung. Diese muss sich für große Datenmengen eignen und schnell durchgeführt werden können.

Symmetrische Verschlüsselung setzt aber voraus, dass beide Kommunikationspartner den gleichen Key verwenden – nur wie kommen die Kommunikationspartner zum gleichen Key? Genau hier kommt Asymmetrische Verschlüsselung ins Spiel! Über kryptographische Algorithmen wie RSA, DHE, ECDHE errechnen beide Kommunikationspartner einen „Session Key“ der für die spätere, eigentliche Datenübertragung genutzt wird, und zwar auf eine Weise, dass ein potentieller „Belauscher“ der Kommunikation unmöglich an den Session Key kommen kann. D.h. die asymmetrische Verschlüsselung, basierend auf dem ausgehandelten Session Key, ist sicher.

Public und Private Key

Wie der Name schon sagt, handelt es sich bei beiden um Schlüssel – mit cryptographischen Verfahren berechnete Werte – die zwingend miteinander in Verbindung stehen und die sich doch wesentlich voneinander unterscheiden:

Der Public Key ist nicht viel anders als die Beschriftung der Türklingel eines Hauses, sprich er ist von jedermann einsehbar.

Der Private Key jedoch ist vergleichbar mit dem Hausschlüssel an sich. Diesen teilt man nicht mit Fremden. Beide gehören jedoch zusammen und bilden ein Paar (key-pair). Wenn beispielsweise ein Browser eine SSL/TLS Webseite, z. B. die der Bank, anzeigen möchte, dann wird zunächst über die asymmetrische Verschlüsselung mithilfe von public/private Key ein „Session Key“ ausgehandelt, der von dritten nicht einsehbar ist, und der nachfolgende Datenverkehr damit verschlüsselt.

Wie verläuft ein SSL/TLS Verbindungsaufbau?

Nehmen wir folgenden völlig gewöhnlichen Vorgang an, den jeder Nutzer viele Male am Tag auslöst: Sie wollen auf eine Webseite zugreifen, die TLS1.2 spricht und geben die entsprechende URL im Browser ein.

• Am Anfang von allem steht eine DNS-Abfrage, die zur eingegebenen Adresse eine IP-Adresse ermittelt. Ihr Browser (Client) baut dann eine TCP Verbindung auf Port 80 (http) auf und wird vom Server auf die sichere Variante auf Port 443 (https) umgeleitet. Daraufhin wir eine neue TCP Verbindung aufgebaut, wir erinnern uns, dass jede TCP Verbindung einen 3-way Handshake erfordert und der Faktor Latzenz der Netzwerkverbindung eine Rolle spielt.
• Ist die TCP Verbindung vom Client zum Server aufgebaut, schickt der Client sein „CLIENT-HELLO“ Paket, in dem er dem Server mitteilt, auf welche URL er gerne zugreifen möchte (SNI), welche Verschlüsselungsmethoden der Client kennt (Ciphers) und einige andere Parameter.
• Der Server antwortet darauf mit „SERVER-HELLO“. Wesentlicher Bestandteil dabei ist die Verschlüsselungsmethode (Cipher), die der Server wählt. Es wird die stärkste Variante verwendet, die der Client kennt. Die Auswahl der Methode trifft dabei der Server in Abhängigkeit der konfigurierten Priorität seiner Methoden.
• Es folgt dann das „Server Hello Done“ Paket, in diesem der Server sein Zertifikat mit Public Key und ggf. intermediate Zertifikate, mitsamt weiterer Parameter schickt. Bei beiden Kommunikationspartnern finden nun mathematische Berechnungen statt, die einen gemeinsamen „Session Key“ ermitteln, jedoch ohne diesen jemals zu übertragen.
• Es folgen noch zwei weitere Pakete „Client Key Exchange“ und „Change Cipher Spec“ sowie weitere kryptographische Berechnungen und die TLS Verbindung ist final etabliert

Nun können auf dieser Verbindung Daten ausgetauscht werden, sprich der Client sendet die URL, die er erreichen möchte und der Server antwortet mit den entsprechenden Daten. Dieser Ablauf macht deutlich, dass es für beide Kommunikationspartner „viel zu tun“ gibt, und dass die Netzwerklatenz eine immense Rolle spielt. Das „viel zu tun“ sind die komplexen Mathematischen Berechnungen und spiegelt sich vor allem bei mobilen Geräten in einem hohen Energie-Verbrauch wider. Es gilt also die Einstellungen so zu treffen, dass sie einerseits sicher genug und andererseits effizient genug sind. Die neueste TLS Implementierung TLS1.3 kann dabei durch „0-RTT“ Handshake den Einfluss einer hohen Latenz minimieren in dem schon im ersten Paket Nutzdaten gesendet werden können. Dabei müssen aber beide Kommunikationspartner dieses Verfahren anbieten, oftmals ist zusätzlicher Konfigurationsaufwand notwendig.

Sind alle Zertifikate gleich sicher?

Nicht unbedingt. Es gibt viele Stellen (kommerziell, nicht kommerziell), die Zertifikate ausstellen. Einige der bekanntesten Certificate Authorities (CA`s) sind Thawte, Geotrust, Sectigo oder auch Let`s Encrypt. Es gibt darüber hinaus aber sehr viele mehr!

In der Vergangenheit kam es hin und wieder vor, dass eine CA Zertifikate ausgestellt hat, die sie nicht hätte ausstellen dürfen, z. B. auf einen fremden Namen. Die CA hat also bei der Validierung des Antragsstellers nicht korrekt gearbeitet und verschwanden daher vom Markt. Generell haben die CA`s einen hohen Anspruch an sich selbst, um diese Fehler zu vermeiden. Es gibt jedoch auch verschiedene Validierungsformen, die bei den kommerziellen CA`s auch am Preis ablesbar sind:

• DV (Domain Validation) ist die einfachste Form der Validierung. Hier muss ein Antragssteller normalerweise lediglich nachweisen, dass er für die Domain „company.com“ e-mails empfangen kann, oder DNS-Einträge setzen kann. Die Ausstellung der Zertifikate erfolgt dann automatisiert innerhalb von wenigen Minuten.
• EV (extended Validation) ist hier schon aufwändiger. Der Antragssteller muss der CA nachweisen, dass er tatsächlich der Antragssteller ist und auch berechtigt ist ein Zertifikat für z. B. eine Domain zu beziehen. Dies erfolgt über den Nachweis von Handelsregisterauszügen, und/oder anderen amtlichen Identitätsnachweisen, sowie über den Abgleich von Domain-Registrierungsdaten (RIPE, etc.). Besonders sensitive Anbieter wie Banken usw. verwenden in der Regel EV Zertifikate. Diese waren bis vor kurzem noch über die grüne Einblendung des Antragsstellers in der Adresszeile des Browsers erkennbar, heute muss man bei den Eigenschaften des Zertifikates etwas genauer suchen.
• Darüber hinaus gibt es auch verschiedene Arten von Zertifikaten. Die bekanntesten sind „single Domain“ sprich mail.company.com oder shop.company.com, „Wildcards“, also *.company.com oder SAN sprich www.company.com und zusätzlich beliebige andere Namen wie mail.company.com oder login.company.com.

Insbesondere Wildcard Zertifikate sind problematisch, da diese zwar für die Administratoren sehr bequem sind – sie gelten für alle Namen einer Domain und sind so universell nutzbar – aber eben auch häufig gestreut werden. Oftmals werden diese Zertifikate sowohl von der IT als auch der Marketingabteilung genutzt, welche unterschiedliche Einstellungen/Anforderungen im Bezug auf Security haben können.

Wer garantiert die Vertrauenswürdigkeit von Zertifikaten?

Sobald sich ein Client und ein Server in Verbindung setzen, sind Zertifikate zum Zweck des Identitätsnachweises in der Regel Voraussetzung, damit überhaupt eine verschlüsselte Kommunikation zustande kommt. Wer also garantiert die Identität?

Die Antwort ist einfach: Die ausstellende Identität, sprich die CA. Die Aufgabe einer Certificate Authority ist im Wesentlichen die Identität des Antragsstellers hinreichend zu überprüfen. Dabei muss zumindest die Root-CA dem Client bereits vorher bekannt sein, sprich das Zertifikat der Root-CA muss bereits als „vertrauenswürdige Root CA“ im System hinterlegt sein.

Wie wird ein Zertifikat überprüft?

Normalerweise wird ein Zertifikat akzeptiert, wenn es den formalen Anforderungen genügt. Dazu zählen Anfangs- und Ende Datum, das Subjekt, also der Antragssteller, eine Seriennummer und der geplante Einsatzzweck.

Nun könnte es jedoch vorkommen, dass ein Zertifikat „revoked“ wurde, sprich der Inhaber hat festgelegt, dass dieses spezielle Zertifikat nicht mehr verwendet werden darf. Gründe könnten sein, dass ein unbekannter Dritter in den Besitz des private Keys gelangt ist oder das Zertifikat aus anderen Gründen ausgetauscht wurde.

Jeder Client hat also die Möglichkeit (ob sie denn auch genutzt wird ist eine andere Frage) zu überprüfen, ob das ihm vom Server vorgelegte Zertifikat nicht doch gesperrt wurde. Dazu ist in jedem Zertifikat eine CRL oder OCSP URL hinterlegt, auf die ein korrekt arbeitender Client zugreifen kann und somit ermitteln kann, ob ein Zertifikat mit der entsprechenden Seriennummer revoked wurde oder nicht.