{"id":2621,"date":"2019-02-28T12:25:50","date_gmt":"2019-02-28T11:25:50","guid":{"rendered":"https:\/\/www.boc.de\/watchguard-info-portal\/?p=2621"},"modified":"2025-09-11T12:11:55","modified_gmt":"2025-09-11T10:11:55","slug":"verschluesselung-ssl-zertifikate-https-deep-inspection","status":"publish","type":"post","link":"https:\/\/wordpress.boc.de\/watchguard-info-portal\/2019\/02\/verschluesselung-ssl-zertifikate-https-deep-inspection\/","title":{"rendered":"Grundlagen: Verschl\u00fcsselung, SSL, Zertifikate, und HTTPS-Deep-Inspection"},"content":{"rendered":"

In diesem Artikel\u00a0werden\u00a0die Grundlagen von SSL, Zertifikaten und HTTPS-Deep-Inspection betrachtet. Diese Grundlagen sollen dem Verst\u00e4ndnis dienen und sind daher sehr vereinfacht. Auf die mathematischen Grundlagen wird in diesem Artikel nicht eingegangen. M\u00f6glicherweise sind die ein oder andere Betrachtungsweise daher nicht vollst\u00e4ndig korrekt, in diesem Artikel soll der Schwerpunkt jedoch auf dem prinzipiellen Verst\u00e4ndnis liegen.<\/p>\n

<\/p>\n

Grundlagen<\/h3>\n

Symmetrische Verschl\u00fcsselung<\/h4>\n

F\u00fcr die Verschl\u00fcsselung wird ein Schl\u00fcssel verwendet, der dem Sender und dem Empf\u00e4nger bekannt sein muss. Ein triviales Beispiel daf\u00fcr ist beispielsweise eine ZIP-Datei mit Passwort. Das Passwort, das der Sender verwendet hat, muss dem Empf\u00e4nger vorliegen, sonst ist eine Entschl\u00fcsselung nicht m\u00f6glich. Weitere Beispiele w\u00e4ren IPSec-VPNs mit preshared Key oder WLAN-Zug\u00e4nge mit preshared Key. Ein bekanntes symmetrisches Verschl\u00fcsselungsverfahren ist beispielsweise AES.<\/p>\n

Asymmetrische Verschl\u00fcsselung, public- & private-Keys<\/h4>\n

F\u00fcr eine asymmetrische Verschl\u00fcsselung\u00a0wird ein Schl\u00fcssel-Paar verwendet, bestehend aus einem\u00a0privaten Schl\u00fcssel (private Key) und einem \u00f6ffentlichen Schl\u00fcssel (public Key). Diese beiden Schl\u00fcssel h\u00e4ngen \u00fcber mathematische Algorithmen sehr eng zusammen, so dass Daten, die mit dem Public-Key verschl\u00fcsselt\u00a0wurden, nur mit dem Private-Key entschl\u00fcsselt werden k\u00f6nnen, oder Signaturen, die mit dem private Key erstellt wurden, mit dem public Key \u00fcberpr\u00fcft werden k\u00f6nnen. Dieses Verfahren bietet den Vorteil, dass der initiale Schl\u00fcssel f\u00fcr die Verschl\u00fcsselung einfach \u00f6ffentlich \u00fcbertragen werden kann (daher “public Key”).<\/p>\n

Ein bekanntes asymmetrisches Verfahren ist RSA. Asymmetrische Verfahren sind deutlich aufw\u00e4ndiger (=rechenintensiver) als symmetrische Verfahren – bei RSA vs. AES spricht man\u00a0etwa von einem Faktor in der Gr\u00f6\u00dfenordnung von 1000.<\/p>\n

Eine Daten\u00fcbertragung kann wie folgt stattfinden:<\/p>\n

    \n
  1. Der Sender “holt” sich den public Key des Empf\u00e4ngers. Dies kann \u00fcber einen unverschl\u00fcsselten Kanal erfolgen, da es ja der \u00f6ffentliche Schl\u00fcssel ist.<\/li>\n
  2. Der Sender verschl\u00fcsselt seine Botschaft (inkl. seinem public Key) mit dem public Key des Empf\u00e4ngers.<\/li>\n
  3. Die verschl\u00fcsselte Nachricht wird an den Empf\u00e4nger \u00fcbertragen.<\/li>\n
  4. Der Empf\u00e4nger entschl\u00fcsselt die Nachricht mit seinem private Key. Da dieser nur dem Empf\u00e4nger vorliegt, kann die Nachricht von niemandem sonst entschl\u00fcsselt werden.<\/li>\n
  5. Der Empf\u00e4nger ist nun im Besitz des public Key des Senders und kann\u00a0mit diesem die\u00a0Antwort an den Sender verschl\u00fcsseln.<\/li>\n<\/ol>\n

    Anstelle eines bidirektional asynchronen Verfahrens k\u00f6nnte an Punkt 2 auch ein symmetrischer Schl\u00fcssel vom Sender erzeugt werden und dem Empf\u00e4nger mitgeteilt werden, um die anschlie\u00dfenden Nachrichten mit diesem symmetrischen Schl\u00fcssel zu verschl\u00fcsseln und somit Rechenleistung zu sparen.<\/p>\n

    Authentizit\u00e4t<\/h3>\n

    Ein verbleibendes Problem hierbei ist jedoch die Authentizit\u00e4t des public Key. Ist der beim Sender angekommene Key wirklich der public Key des Empf\u00e4ngers oder wurde dieser Schl\u00fcssel m\u00f6glicherweise von jemand abgefangen und durch einen anderen ersetzt (man spricht hier von einer sog. Man-in-the-Middle-Attack, kurz MitM).<\/p>\n

    SSL-Zertifikate, Zertifikatsketten, Zertifikatspr\u00fcfungen<\/h4>\n

    Ein SSL-Zertifikat besteht aus zwei Teilen – einem Private-Key und dem Zertifikat selbst. Ein Zertifikat enth\u00e4lt vereinfacht gesprochen die Informationen \u00fcber den Zertifikats-Inhaber, den Zertifikats-Aussteller, ein Ablaufdatum sowie einen \u00f6ffentlichen Schl\u00fcssel und entsprechende Pr\u00fcfsummen\/Signaturen. Bei SSL geht es normalerweise um \u00dcbertragungen zwischen einem Arbeitsplatz (im folgenden Client genannt) und einem Server.<\/p>\n

    Stufe 1<\/h5>\n

    In unserem Beispiel gibt es genau EIN Stammzertifikat (Z 1). Dieses Zertifikat hat nun einen private Key und enth\u00e4lt einen public Key sowie eine Signatur (Pr\u00fcfsumme) durch sich selbst. Die Signaturen werden kryptographisch durch den private Key erzeugt und k\u00f6nnen mit dem public Key \u00fcberpr\u00fcft werden.<\/p>\n

    Nun sorgen wir daf\u00fcr, dass jeder Client dieses Zertifikat (nicht jedoch den private Key!) als Kopie vorliegen hat und es daher nicht mehr\u00a0\u00fcbertragen werden muss. Das Zertifikat liegt also lokal beim Client im sog. Zertifikats-Speicher vor.<\/p>\n

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

    Stufe 2<\/h5>\n

    Da wir nicht jedes Zertifikat beim Client hinterlegen k\u00f6nnen, geben wir nun dieses Stammzertifikat inkl. private Key einer Zertifizierungsstelle. Diese Zertifizierungsstelle kann ein neues Zertifikat (Z 2) ausstellen und mit dem private Key des Stammzertifikates signieren. Hierzu ben\u00f6tigt 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\u00e4lt. 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.<\/p>\n

    Das Zertifikat (Z 2) ist nur auf dem Server nutzbar, auf dem der zugeh\u00f6rige private Key existiert, also Server S 2.<\/p>\n

    Wenn nun ein Client eine Verbindung mit dem Server S 2 aufbaut, pr\u00e4sentiert dieser sein Zertifikat Z 2. Der Client kann nun das Zertifikat Z 2 \u00fcberpr\u00fcfen, da es mit dem private Key von Z 1 signiert wurde – und diese Signatur l\u00e4sst sich durch den vorliegenden public Key von Z 1 best\u00e4tigen (zur Erinnerung: das Zertifikat Z1 hatten wir an die Clients verteilt, es liegt also im Zertifikatsspeicher vor). Nun wei\u00df der Client, dass die Daten aus dem Zertifikat Z 2 des Servers S 2 g\u00fcltig sind und er kann seine Verbindung aufbauen.<\/p>\n

    Das Ganze steht und f\u00e4llt nat\u00fcrlich 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\u00fcfsumme auf einem Server hinterlegen, die dann von der Zertifizierungsstelle automatisiert abgerufen wird) bis hin zu “organization verified” (bei der tats\u00e4chlich Papiere, Handelsregisterausz\u00fcge etc. gepr\u00fcft werden).<\/p>\n

    Stufe 3<\/h5>\n

    \"\"Aus Sicherheitsgr\u00fcnden werden die Stammzertifikate jedoch nicht selbst zum Signieren der Zertifikate verwendet, sondern nach Erzeugung\/Signieren eines Zwischen-Zertifikates (Intermediate)\u00a0\u00fcblicherweise sicher im Safe verwahrt. Alle\u00a0normalen Server-Zertifikate werden dann von den jeweiligen Intermediate-Zertifikaten signiert. Die Signatur kann dann jeweils mit dem \u00fcbergeordneten Zertifikat \u00fcberpr\u00fcft werden. Dies ist beispielsweise auch beim von www.boc.de verwendeten Zertifikat der Fall, siehe Zertifizierungspfad links (ein Klick auf das Bild vergr\u00f6\u00dfert es).<\/p>\n

    Da es nicht ausreicht, nur eine Zertifizierungsstelle zu haben, gibt es davon mehrere, inzwischen sind weit \u00fcber 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\u00f6nnen bei Mozilla\u00a0eingesehen werden.<\/a><\/p>\n

    Damit das oben genannte Vertrauen in diese Zertifizierungsstellen auch bleibt, gibt es f\u00fcr 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\u00f6\u00dft 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<\/a> verwiesen: Zun\u00e4chst wurden Zertifikaten, die von dieser Zertifizierungsstelle nach einem bestimmten Zeitpunkt ausgestellt wurden, nicht mehr als g\u00fcltig anerkannt; in einem zweiten Schritt wurde allen Zertifikaten das Vertrauen entzogen.<\/p>\n

     <\/p>\n

    Man-in-the-Middle-Attack<\/h3>\n

    Das im Abschnitt “asynchrone Verschl\u00fcsselung” vorgestellte Verfahren des Verbindungsaufbaus wird nun wie folgt abge\u00e4ndert:<\/p>\n

      \n
    1. Der Client\u00a0“holt” sich den public Key + Zertifikat des Empf\u00e4ngers. Dies kann \u00fcber einen unverschl\u00fcsselten Kanal erfolgen, da es ja der \u00f6ffentliche Schl\u00fcssel ist.<\/li>\n
    2. Der Man-in-the-Middle f\u00e4ngt diesen Request ab.<\/li>\n
    3. Der Man-in-the-Middle holt sich den public Key und das Zertifikat des Servers.<\/li>\n
    4. Der Man-in-the-Middle erzeugt ein neues Zertifikat f\u00fcr den Server, signiert dies mit seinem eigenen Zertifikat und sendet dieses anstelle des originalen Server-Zertifikates an den Client.<\/li>\n
    5. Der Client verschl\u00fcsselt seine Botschaft (inkl. dem Verschl\u00fcsselungs-Key) mit dem public Key des Man-in-the-Middle-Zertifikates im Glauben, dieses sei das Server-Zertifikat.<\/li>\n
    6. Die verschl\u00fcsselte Nachricht wird an den Man-in-the-Middle \u00fcbertragen (im Glauben, dies sei der Server).<\/li>\n
    7. Der Man-in-the-Middle entschl\u00fcsselt die Nachricht und verschl\u00fcsselt sie neu mit dem public Key des Servers und schickt sie an den Server.<\/li>\n
    8. Der Server entschl\u00fcsselt die Nachricht mit seinem private Key.<\/li>\n
    9. Der Server ist nun im Besitz eines Verschl\u00fcsselungs-Keys des Man-in-the-Middle (im Glauben, dies sei der Client) und kann\u00a0mit diesem die\u00a0Antwort an den Client (d.h. den Man-in-the-Middle) verschl\u00fcsseln.<\/li>\n
    10. Die Antwort l\u00e4uft also wieder \u00fcber den Man-in-the-Middle, wird entschl\u00fcsselt und erneut verschl\u00fcsselt.<\/li>\n<\/ol>\n

      In diesem Falle haben wir einen klassischen MitM-Angriff – und unsere Daten sind nicht mehr sicher sondern k\u00f6nnen mitgelesen oder sogar manipuliert werden.<\/p>\n

      Schutz vor MitM durch SSL-Zertifikate und CA-Pinning<\/h4>\n

      Durch die Verwendung von SSL-Zertifikaten sch\u00fctzt man sich vor MitM-Angriffen, wenn man die Zertifikate \u00fcberpr\u00fcft. Wenn man das im obigen Beispiel unter Punkt 4 erzeugte MitM-Zertifikat pr\u00fcft, wird man feststellen, da\u00df 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\u00fcfsummen bleibt zwar g\u00fcltig, aber das Fehlen des Zertifikates im lokalen Cerficate-Root-Store f\u00fchrt zu einer Warnung des Clients (Warnseite des Browsers).<\/p>\n

      Mit CA-Pinning wird ein Verfahren bezeichnet, in dem der Client \u00fcber den DNS nachlesen kann, welche CAs denn Zertifikate f\u00fcr diese Domain austellen d\u00fcrfen. Das Verfahren wird auch als Certificate Pinning, SSL Pinning oder offiziell als Certification Authority Authorization (CAA) bezeichnet und wurde in der RFC 6844\u00a0dokumentiert.<\/a><\/p>\n

      Ein weiteres Verfahren ist HPKP (HTTP Public Key Pinning), RFC 7469<\/a>. Hierbei wird eine Liste der g\u00fcltigen Zertifikate inkl. G\u00fcltigkeitszeitraum mittels HTTP-Header an den Client \u00fcbertragen und dort gespeichert – damit dieser bei einer weiteren Nutzung dieser Seite die G\u00fcltigkeit der Zertifikate \u00fcberpr\u00fcfen kann.<\/p>\n

      HTTPS-Deep-Inspection<\/h3>\n

      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\u00fcsselung in diesem Falle explizit von uns so gew\u00fcnscht.<\/p>\n

      Vorteile von HTTPS-Deep-Inspection<\/h4>\n

      Der HTTPS-Traffic kann kontrolliert werden:<\/p>\n