GlobalSign Blog

02 Nov 2017

SSL-Inspection - Überlegungen zu ausstellenden Zertifizierungsstellen und Roots

SSL-Inspection (auch bekannt unter SSL/TLS Entschlüsselung, SSL-Analyse oder Deep Packet Inspection) ist ein zunehmend heißes Thema in IT-Abteilungen. Wir wollen nicht erörtern, ob Sie dies tun sollten oder nicht. Da ich für eine CA arbeite, tue ich mich mit diesem Konzept schwer, da ich an die Grundlagen der Verschlüsselung glaube. Aber immer mehr Unternehmen implementieren Verschlüsselung, obwohl diese nicht unbedingt bedeutet, dass der Inhalt sicher ist. Wenn Sie SSL-Inspection prüfen oder implementieren, sollten Sie Möglichkeiten erwägen, dies sicherer und gut gesteuert zu tun.

Aus diesem Grund möchte ich über einen Aspekt der Implementierung sprechen, von dem viele vielleicht keine Kenntnis haben. Tatsächlich gibt es viele Leute, die sich nicht darüber im Klaren sind: Der Einsatz einer individuellen privaten ausstellenden CA zur Generierung der Entschlüsselungs- und Wiederverschlüsselungszertifikate.

Sie haben richtig gelesen. Statt sich auf selbstsignierte CA-Zertifikate oder die durch Anwendungen für SSL-Inspection bereitgestellte CA-Zertifikate zu verlassen, können Sie eine dedizierte ausstellende CA einer Drittanbieter-Zertifizierungsstelle wie GlobalSign nutzen. Aber bevor wir uns damit befassen, frischen wir noch einmal das Thema im Allgemeinen auf.

Was ist SSL-Inspection und warum wird es verwendet?

Immer mehr öffentliche Websites stellen auf HTTPS um. Dies bedeutet, dass die zwischen Webserver und Client gesendeten Kommunikationen und Daten (d.h. ein Endbenutzer, der im Internet surft) verschlüsselt werden (was nach SonicWall über 60% des gesamten Webverkehrs ausmacht).

Obwohl diese Umstellung auf Verschlüsselung überall offensichtlich eine sehr gute Sache sein kann - Schutz von Kreditkartenzahlungen, Anmeldeinformationen, usw. - haben leider einige mit bösen Absichten damit begonnen, schädlichen oder bösartigen Code in diesem verschlüsselten Verkehr zu verstecken. Dies bedeutet, dass die üblichen Abwehrmechanismen der IT, wie z. B. Intrusion Prevention Systeme oder Data Loss Prevention, umgangen werden und die beängstigenden Sachen direkt auf den Mitarbeiterrechnern landen.  Es ist auch erwähnenswert, dass dieser Trend, Malware in Verschlüsselung zu verstecken, im letzten Jahr um 72% zugenommen hat. Dies liegt zum Teil am Zuwachs von kostenlosen SSL-Anbietern wie Let's Encrypt, die es sehr einfach machen, Domain Validated (DV) Zertifikate mit niedriger Sicherheit zu erhalten. Es wird immer schwerer zu erkennen, ob eine "gesicherte" Website tatsächlich eine "sichere" Website ist.

SSL-Inspection hilft, diese Gefahr zu mindern, indem sie im Wesentlichen zwischen End-Clients (d.h. Ihre Mitarbeiter, die im Internet surfen) und Webservern sitzt und die schlechten Sachen ausfiltert. Es gibt heutzutage eine Reihe von Inspection Appliances auf dem Markt, aber die Prozesse sind grundsätzlich gleich. Wenn HTTPS-Inhalt zwischen einem Client und einem Webserver ausgetauscht wird, geht der gesamte Datenverkehr durch die Inspection Appliance, wo er entschlüsselt und auf bösartige Inhalte überprüft wird.

Wenn die Überprüfung abgeschlossen ist, erstellt die Appliance eine neue SSL-Sitzung, bei der der End-Client den Inhalt entschlüsselt und neu verschlüsselt. Dies ist der Teil, auf den ich mich konzentrieren möchte - diese neuen SSL-Sitzungen und die ausstellende CA, die sie erstellt.

Wie der Entschlüsselungs-/ Wiederverschlüsselungsprozess funktioniert

Damit die SSL-Inspection Appliance den Inhalt entschlüsseln und wiederverschlüsseln kann, bevor er an die Endbenutzer zurückgeschickt wird, muss sie in der Lage sein, SSL-Zertifikate schnell auszustellen. Dies bedeutet, dass ein CA-Zertifikat (manchmal auch Zwischenzertifikat oder Ausstellendes Zertifizierungsstellenzertifikat genannt) auf der Appliance installiert sein muss.

Ein weiterer wichtiger Faktor ist hier, dass, damit den eiligen SSL-Zertifikaten in Browsern vertraut wird (d.h. dass sie nicht bei jedem Besuch Warnmeldungen, wie die unten gezeigten, auslösen), die CA-Kette (oder Hierarchie) im Vertrauensspeicher des Browsers vorhanden sein muss. Da diese Zertifikate nicht von öffentlich vertrauenswürdigen CAs ausgestellt werden, deren Roots und Zwischenzertifikate bereits eingebettet sind, müssen Sie die CA-Hierarchien manuell allen End-Clients bereitstellen.

Warning_message_for_self-signed_or_untrusted_roots_in_Chrome.png

Warnmeldung für selbstsignierte oder nicht vertrauenswürdige Roots in Chrome (Quelle: BadSSL.com)

Für Windows-Rechner ist dieser Prozess möglicherweise nicht so mühsam, da Sie Active Directory- und Gruppenrichtlinienfunktionen nutzen können. Aber was ist, wenn Sie mobile Geräte, Macs oder Linux haben? Alles Nicht-Windows ist in der Regel komplizierter.

Sie müssen auch berücksichtigen, ob Sie bereits andere Roots pflegen und verwalten müssen, einschließlich aller selbstsignierten, Microsoft CA oder OpenSSL-basierten Roots, die Sie evtl. in Ihrem Unternehmen haben. Diese können sich schnell summieren. Wie schützen Sie die privaten Schlüssel? Oder wie stellen Sie sicher, dass keiner davon unerwartet abläuft? Wie stellen Sie sicher, welche Root Sie für jeden Ihrer Anwendungsfälle einsetzen?

Es gibt einen besseren Weg - Verwenden Sie eine private, dedizierte Root von einer Drittanbieter-CA

Wenn der Versuch, mehrere Roots zu verwalten oder sich auf selbstsignierte Zertifikate zu verlassen, nicht Ihr Ding ist, sollten Sie wissen, dass dies nicht Ihre einzigen Optionen sind. Sie können stattdessen mit einer Drittanbieter-CA arbeiten (Hinweis: Nicht alle CAs bieten dies, aber GlobalSign tut es). Jetzt könnten Sie sich fragen: "Moment, ich dachte, man könnte öffentlich vertrauenswürdige Zertifikate für SSL Inspection Appliances nicht verwenden?" Sie haben Recht - in diesem Fall würden die Zertifikate von einer privaten ausstellenden CA ausgestellt, die sich mit einer dedizierten privaten Root-CA verkettet, die für Ihr Unternehmen erstellt wurde und von GlobalSign verwaltet wird.

	Example (simplified) architecture for dedicated customer roots.png

Beispiel (vereinfacht) für die Architektur dedizierter Kunden-Roots

Wie beseitigt also dieses Setup einige der Schwierigkeiten, die ich bereits erwähnt habe? Erst einmal kann es die Anzahl der Roots, die Sie zu verwalten und zu übertragen haben, minimieren. Mit dieser Option brauchen Sie nur eine private Root für alle Ihre internen PKI-Bedürfnisse, mit so vielen Zwischen-CAs wie nötig, die sich damit verketten. Beispielsweise zeigt das obige Diagramm eine mehrstufige Hierarchie, bei der eine der ausstellenden CAs (oder Zwischen-CAs, wie auch immer Sie sie nennen) für SSL Inspection/Entschlüsselungsaktivitäten verwendet wird und die andere ausstellende CA für interne Rechner (Laptops, Server, Desktops, etc.) zuständig ist.

Obwohl der SSL Appliance Anwendungsfall erfordert, dass die spezifische ausstellende CA vom Kunden gehostet werden muss (da sie auf der Appliance selbst vorhanden sein muss), wird die Top-Level-Root-CA von GlobalSign gehostet. Wir erledigen die Sicherung und den Schutz des privaten Schlüssels und haben den Überblick über Ablaufzeiten. Dies bedeutet auch, dass Sie nur diese Top-Level-Root-CA bereitstellen müssen. Allen Zertifikaten, die von einer untergeordneten CA ausgestellt werden, wird dann auch vertraut.

Ein weiterer Vorteil dieses Ansatzes liegt darin, dass Sie bei Bedarf die ausstellende CA der Appliance aus irgendeinem Grund widerrufen können. Wir würden einfach eine neue ausstellende CA für Sie erstellen, die sich wieder in Ihre ursprüngliche private Root einbinden könnte und Sie könnten im Wesentlichen sofort mit dem Einsatz beginnen. Sie müssten sich nicht darum kümmern, irgendwelche Roots bereitzustellen, da sie sich auch mit dieser bereits vertrauenswürdigen Root CA verketten würde.

Lassen Sie uns Ihre internen PKI-Bedürfnisse erledigen

Der SSL Inspection Anwendungsfall ist der neueste in einem wachsenden Trend, das immer mehr Unternehmen sich auf interne oder private PKI verlassen. Andere häufige Anwendungsfälle sind Zertifikate für Benutzer- oder Computerauthentifizierung, SSL für interne Server und Konfigurationen, die in öffentlich vertrauenswürdigen Zertifikaten gemäß CA/Browser Forum Requirements nicht zugelassen sind.

Wenn Sie interne PKI für eine dieser oder andere Anwendungen in Erwägung ziehen oder wenn Sie derzeit Ihre eigene PKI hausintern verwalten, sollten Sie wissen, dass die Auslagerung zu einer Drittanbieter-CA eine Option ist. Die Verwaltung von CAs und Vertrauensankern, sowohl öffentlich als auch privat, ist das, was wir machen - lassen Sie uns dies für Sie erledigen.

von Sid Desai

Artikel teilen

Jetzt Blog abonnieren