Grundlagen: Verschlüsselung, SSL, Zertifikate, und HTTPS-Deep-Inspection

In diesem Artikel werden die Grundlagen von SSL, Zertifikaten und HTTPS-Deep-Inspection betrachtet. Diese Grundlagen sollen dem Verständnis dienen und sind daher sehr vereinfacht. Auf die mathematischen Grundlagen wird in diesem Artikel nicht eingegangen. Möglicherweise sind die ein oder andere Betrachtungsweise daher nicht vollständig korrekt, in diesem Artikel soll der Schwerpunkt jedoch auf dem prinzipiellen Verständnis liegen.

Grundlagen

Symmetrische Verschlüsselung

für die Verschlüsselung wird ein Schlüssel verwendet, der dem Sender und dem Empfänger bekannt sein muss. Ein triviales Beispiel dafür ist beispielsweise eine ZIP-Datei mit Passwort. Das Passwort, das der Sender verwendet hat, muss dem Empfänger vorliegen, sonst ist eine Entschlüsselung nicht möglich. Weitere Beispiele wären IPSec-VPNs mit preshared Key oder WLAN-Zugänge mit preshared Key. Ein bekanntes symmetrisches Verschlüsselungsverfahren ist beispielsweise AES.

Asymmetrische Verschlüsselung, public- & private-Keys

Für eine asymmetrische Verschlüsselung wird ein Schlüssel-Paar verwendet, bestehend aus einem privaten Schlüssel (private Key) und einem öffentlichen Schlüssel (public Key). Diese beiden Schlüssel hängen über mathematische Algorithmen sehr eng zusammen, so dass Daten, die mit dem Public-Key verschlüsselt wurden, nur mit dem Private-Key entschlüsselt werden können, oder Signaturen, die mit dem private Key erstellt wurden, mit dem public Key überprüft werden können. Dieses Verfahren bietet den Vorteil, dass der initiale Schlüssel für die Verschlüsselung einfach öffentlich übertragen werden kann (daher “public Key”).

Ein bekanntes asymmetrisches Verfahren ist RSA. Asymmetrische Verfahren sind deutlich aufwändiger (=rechenintensiver) als symmetrische Verfahren – bei RSA vs. AES spricht man etwa von einem Faktor in der Größenordnung von 1000.

Eine Datenübertragung kann wie folgt stattfinden:

1. Der Sender “holt” sich den public Key des Empfängers. Dies kann über einen unverschlüsselten Kanal erfolgen, da es ja der öffentliche Schlüssel ist.
2. Der Sender verschlüsselt seine Botschaft (incl. seinem public Key) mit dem public Key des Empfängers.
3. Die verschlüsselte Nachricht wird an den Empfänger übertragen
4. Der Empfänger entschlüsselt die Nachricht mit seinem private Key. Da dieser nur dem Empfänger vorliegt, kann die Nachricht von niemandem sonst entschlüsselt werden.
5. Der Empfänger ist nun im Besitz des public Key des Senders und kann mit diesem die Antwort an den Sender verschlüsseln.

Anstelle eines bidirektional asynchronen Verfahrens könnte an Punkt 2 auch ein symmertrischer Schlüssel vom Sender erzeugt werden und dem Empfänger mitgeteilt werden, um die anschließenden Nachrichten mit diesem symmetrischen Schlüssel zu verschlüsseln und somit Rechenleistung zu sparen.

Authentizität

Ein verbleibendes Problem hierbei ist jedoch die Authentizität des public Key. Ist der beim Sender angekommene Key wirklich der public Key des Empfängers oder wurde dieser Schlüssel möglicherweise von jemand abgefangen und durch einen anderen ersetzt (man spricht hier von einer sog. Man-in-the-Middle-Attack, kurz MitM).

SSL-Zertifikate, Zertifikatsketten, Zertifikatsprüfungen

Ein SSL-Zertifikat besteht aus zwei Teilen – einem Private-Key und dem Zertifikat selbst. Ein Zertifikat enthält vereinfacht gesprochen die Informationen über den Zertifikats-Inhaber, den Zertifikats-Aussteller, ein Ablaufdatum sowie einen öffentlichen Schlüssel und entsprechende Prüfsummen/Signaturen.  Bei SSL geht es normalerweise um Übertragungen zwischen einem Arbeitsplatz (im folgenden Client genannt) und einem Server.

Stufe 1

In unserem Beispiel gebe es genau EIN Stammzertifikat (Z 1). Dieses Zertifikat hat nun einen private Key und enthält einen public Key sowie eine Signatur (Prüfsumme) durch sich selbst. Die Signaturen werden kryptographisch durch den private Key erzeugt und können mit dem public Key überprüft werden.

Nun sorgen wir dafür, dass jeder Client dieses Zertifikat (nicht jedoch den private Key!) als Kopie vorliegen hat und es daher nicht mehr übertragen werden muss. Das Zertifikat liegt also lokal beim Client im sog. Zertifikats-Speicher vor.

Wenn nun der Client eine Verbindung zum Server mit diesem Stammzertifikat aufbauen will, präsentiert der Server beim Verbindungsaufbau sein Zertifikat. Dieses kann mit dem (lokal vorliegenden!) public Key verifiziert werden und damit die Echtheit der Gegenstelle sichergestellt werden.

Stufe 2

Da wir nicht jedes Zertifikat beim Client hinterlegen können, geben wir nun dieses Stammzertifikat incl. private Key einer Zertifizierungsstelle. Diese Zertifizierungsstelle kann ein neues Zertifikat (Z 2) ausstellen und mit dem private Key des Stammzertifikates signieren. Hierzu benötigt die Zertifizierungsstelle einen sog. “Certificate Signing Request” (CSR) eines Servers (S 2). Der Server erzeugt hierzu einen private Key und generiert daraus einen CSR, der u.a. die Server-Daten (DNS-Name, Firma etc.) und den public Key enthält. Dieser CSR wird an die Zertifizierungsstelle gesendet und diese erzeugt aus diesen Daten das Zertifikat Z 2 und signiert es mit dem private Key des Stammzertifikates Z 1.

Das Zertifikat (Z 2) ist nur auf dem Server nutzbar, auf dem der zugehörige private Key existiert, also Server S 2.

Wenn nun ein Client eine Verbindung mit dem Server S 2 aufbaut, präsentiert dieser sein Zertifikat Z 2. Der Client kann nun das Zertifikat Z 2 überprüfen, da es mit dem private Key von Z 1 signiert wurde – und diese Signatur lässt sich durch den vorliegenden public Key von Z 1 bestätigen (zur Erinnerung: das Zertifikat Z1 hatten wir an die Clients verteilt, es liegt also im Zertifikatsspeicher vor). Nun weiß der Client, dass die Daten aus dem Zertifikat Z 2 des Servers S 2 gültig sind und er kann seine Verbindung aufbauen.

Das Ganze steht und fällt natürlich mit dem Vertrauen in die Zertifizierungsstelle, die das Stammzertifikat verwaltet, und in die Verifizierungsmethoden, die die Zertifizierungsstelle anwendet, um die Echtheit des Certificate Signing Request zu verifizieren. Die Verifizierungsmethoden reichen von “domain control validated” (hier muss der Antragsteller eine Art Prüfsumme auf einem Server hinterlegen, die dann von der Zertifizierungsstelle automatisiert abgerufen wird) bis hin zu “organization verified” (bei der tatsächlich Papiere, Handelsregisterauszüge etc. geprüft werden).

Stufe 3

Aus Sicherheitsgründen werden die Stammzertifikate jedoch nicht selbst zum Signieren der Zertifikate verwendet, sondern nach Erzeugung/Signieren eines Zwischen-Zertifikates (Intermediate) üblicherweise sicher im Safe verwahrt. Alle normalen Server-Zertifikate werden dann von den jeweiligen Intermediate-Zertifikaten signiert. Die Signatur kann dann jeweils mit dem übergeordneten Zertifikat überprüft werden. Dies ist beispielsweise auch beim von www.boc.de verwendeten Zertifikat der Fall, siehe Zertifizierungspfad links (ein Klick auf das Bild vergrößert es).

Da es nicht ausreicht, nur eine Zertifizierungsstelle zu haben, gibt es davon mehrere, inzwischen sind weit über 50 Zertifizierungsstellen per Default im Windows-eigenen Zertifikats-Store enthalten. Andere Browser-Hersteller wie beispielsweise Firefox haben sich zu einer eigenen Zertifikatsverwaltung entschieden. Die im Firefox enthaltenen SSL-Stamm-Zertifikate können bei Mozilla eingesehen werden.

Damit das oben genannte Vertrauen in diese Zertifizierungsstellen auch bleibt, gibt es für diese sehr strenge Vorschriften, beispielsweise, wie die Netzwerk-Infrastruktur auszusehen hat und welche Arten von Zertifikaten genau die Zertifizierungsstelle unter welchen Voraussetzungen ausstellen darf. Verstößt eine Zertifizierungsstelle gegen diese Auflagen, kann ihr das Vertrauen entzogen werden, indem Browser nach einem Update beispielsweise explizit dieser Stelle nicht mehr vertrauen. Hier sei auf das Verfahren Google/Chrome + Firefox gegen StartCom verwiesen: Zunächst wurden Zertifikaten, die von dieser Zertifizierungsstelle nach einem bestimmten Zeitpunkt ausgestellt wurden, nicht mehr als gültig anerkannt; in einem zweiten Schritt wurde allen Zertifikaten das Vertrauen entzogen.

 

Man-in-the-Middle-Attack

Das im Abschnitt “asynchrone Verschlüsselung” vorgestellte Verfahren des Verbindungsaufbaus wird nun wie folgt abgeändert:

1. Der Client “holt” sich den public Key + Zertifikat des Empfängers. Dies kann über einen unverschlüsselten Kanal erfolgen, da es ja der öffentliche Schlüssel ist.
2. der Man-in-the-Middle fängt diesen Request ab.
3. der Man-in-the-Middle holt sich den public Key und das Zertifikat des Servers
4. der Man-in-the-Middle erzeugt ein neues Zertifikat für den Server, signiert dies mit seinem eigenen Zertifikat und sendet dieses anstelle des originalen Server-Zertifikates an den Client.
5. Der Client verschlüsselt seine Botschaft (incl. dem Verschlüsselungs-Key) mit dem public Key des Man-in-the-Middle-Zertifikates im Glauben, dieses sei das Server-Zertifikat
6. Die verschlüsselte Nachricht wird an den Man-in-the-Middle übertragen (im Glauben, dies sei der Server)
7. Der Man-in-the-Middle entschlüsselt die Nachricht und verschlüsselt sie neu mit dem public Key des Servers und schickt sie an den Server
8. Der Server entschlüsselt die Nachricht mit seinem private Key.
9. Der Server ist nun im Besitz eines Verschlüsselungs-Keys des Man-in-the-Middle (im Glauben, dies sei der Client) und kann mit diesem die Antwort an den Client (d.h. den Man-in-the-Middle) verschlüsseln.
10. Die Antwort läuft also wieder über den Man-in-the-Middle, wird entschlüsselt und erneut verschlüsselt.

In diesem Falle haben wir einen klassischen MitM-Angriff – und unsere Daten sind nicht mehr sicher sondern können mitgelesen oder sogar manipuliert werden.

Schutz vor MitM durch SSL-Zertifikate und CA-Pinning

Durch die Verwendung von SSL-Zertifikaten schützt man sich vor MitM-Angriffen, wenn man die Zertifikate überprüft. Wenn man das im obigen Beispiel unter Punkt 4 erzeugte MitM-Zertifikat prüft, wird man feststellen, daß dieses von einem Zertifikat signiert wurde, welches nicht im lokalen Zertifikate-Store des Clients vorhanden ist. Hier wurde das MitM-eigene Zertifikat verwendet. Der Check der Prüfsummen bleibt zwar gültig, aber das Fehlen des Zertifikates im lokalen Cerficate-Root-Store führt zu einer Warnung des Clients (Warnseite des Browsers).

Mit CA-Pinning wird ein Verfahren bezeichnet, in dem der Client über den DNS nachlesen kann, welche CAs denn Zertifikate für diese Domain austellen dürfen. Das Verfahren wird auch als Certificate Pinning, SSL Pinning oder offiziell als Certification Authority Authorization (CAA) bezeichnet und wurde in der RFC 6844 dokumentiert.

Ein weiteres Verfahren ist HPKP (HTTP Public Key Pinning), RFC 7469. Hierbei wird eine Liste der gültigen Zertifikate incl Gültigkeitszeitraum mittels HTTP-Header an den Client übertragen und dort gespeichert – damit dieser bei einer weiteren Nutzung dieser Seite die Gültigkeit der Zertifikate überprüfen kann.

 

HTTPS-Deep-Inspection

Der WatchGuard HTTPS-Proxy beherrscht Deep Inspection – und de Facto macht dieser dann genau die oben beschriebene Man-in-the-Middle-Attack. Nur ist das Aufbrechen der Verschlüsselung in diesem Falle explizit von uns so gewünscht.

Vorteile von HTTPS-Deep-Inspection

Der HTTPS-Traffic kann kontrolliert werden:

• ermöglicht den Einsatz des Antivirus-Gateway
• ermöglicht den Einsatz des APT-Blocker
• ermöglicht den Einsatz des Reputation Enabled Defense
• ermöglicht den Einsatz des Webblocker

Voraussetzungen für HTTPS-Deep-Inspection

Damit die HTTPS-Deep-Inspection auf der Firebox aktiviert werden kann, müssen jedoch einige Voraussetzungen erfüllt sein:

1. Vorhandensein des Firebox-Proxy-CA-Zertifikates im lokalen Zertifikats-Store für vertrauenswürdige Zertifikate auf allen Clients
2. die Website darf kein Certificate CA Pinning verwenden
3. die Applikation darf das erhaltene Zertifikate nicht explizit prüfen

Zu 1.

Das Zertifikat kann auf mehrere Arten zum Client gelangen.

• Einerseits besteht die Möglichkeit, das auf der Firebox vorhandene Zertifikat zu exportieren und es auf allen Clients zu importieren. Dies kann manuell passieren oder innerhalb einer Domäne über entsprechende Group Policies.
  das Zertifikat kann man praktischerweise über das eingebaute Certificate Portal per HTTP unter http://<interne.ip.der.firewall>:4126/ herunterladen.
• Die andere Möglichkeit setzt das Vorhandensein einer eigenen Windows-CA voraus. In diesem Falle ist das Windows-CA-Zertifikat bereits bei allen Domänen-PCs vorhanden. Dann würde man von dieser CA ein Intermediate-Zertifikat (incl. Verwendungszweck für Signieren von Zertifikaten) erzeugen und das so erstellte Intermediate auf der Firebox importieren.

Es verbleibt jedoch ein Problem mit allen PCs/Clients, die nicht den Windows-eigenen Zertifikatsspeicher verwenden.

• Firefox oder Opera
• Smartphones & Tabletts
• Nicht-Domänen-Mitglieder (z.B. Laptops im Gäste-WLAN, Arbeitsplätze mit anderen Betriebssystemen wie Mac OS oder Linux)

Zu 2.

Für den Fall, daß die Website ein CA-Pinning wie oben beschrieben verwendet, muss die Site in die Liste der Ausnahmen für HTTPS-Deep-Inspection gesetzt werden, da sonst der Client (Browser) die Kommunikation mit der Seite verweigern wird.

Für den Browser Chrome gilt für Certificate Pinning folgende Ausnahme:

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

An der bewußten Erwähnung von Malware in der Google-Hilfe sieht man sehr deutlich den Zwiespalt, den man hier hat. Einerseits möchte (oder muss man) den HTTPS-Traffic aufbrechen, um Malware erkennen zu können) – andererseits führt ein solches Feature durchaus dazu, daß lokal installierten Zertifikaten auch bei Certificate Pinning vertraut wird. Auch dann, wenn diese beispielsweise durch Malware installiert wurden. Oder wenn lokale Anti-Virus-Programme eigene Zertifikate im Certificate Store installiert haben und ihrerseits die per https-Anfragen erhaltenen Zertifikate nicht (mehr/richtig/vollständig) prüfen.

Für Nicht-Domänen-Mitglieder müssen entsprechende Ausnahme-Policies für HTTPS-Deep-Inspection geschaffen werden. Zumeist reicht es hier, die WLANs gesondert zu betrachten und für die wenigen Nicht-Windows-Arbeitsplätze statische IPs zu vergeben und diese dann über andere Policies getrennt zu behandeln.

Nicht zuletzt muss in diesem Zusammenhang auf den Datenschutz verwiesen werden – durch das Aufbrechen ergeben sich bei eingeschaltetem Logging entsprechende Konsequenzen. Dies ist jedoch außerhalb des technischen Scopes dieses Artikels

Zu 3.

Hier sind es insbesondere Applikationen die zwar Port 443 verwenden, aber das HTTPS-Protokoll geringfügig verändert haben oder Certificate Pinning verwenden. Dies wären mindestens, ohne Anspruch auf Vollständigkeit, folgende:wie SSLVPN-Clients, Skype, Dropbox, Elster uvm.

Hier müssen anhand der Ziel-IP ggf. Ausnahmen von der Deep-Inspection geschaltet werden.