SSL / TLS 101 für Anfänger

Ein detaillierter Blick auf die Verschlüsselung, die unsere Internetverbindungen sichert

Während Netscape SSL ursprünglich Mitte der 90er Jahre erfand, war es nicht für jede Website obligatorisch, ein SSL / TLS-Zertifikat zu installieren, bis Google im Sommer 2018 damit begann, unverschlüsselte Websites zu markieren. “Nicht sicher"

Während Google - mit seiner Suchmaschine, dem Chrome-Browser und dem Android-Betriebssystem - das Internet einseitig neu definieren kann, war es mit diesem Mandat nicht allein. Apple, Microsoft, Mozilla und die anderen wichtigen Akteure der Technologiebranche haben alle eine konzertierte Entscheidung getroffen, SSL / TLS-Zertifikate und HTTPS zu beauftragen.

Der Grund dafür ist einfach: Ohne SSL / TLS und die Möglichkeit, eine sichere Verbindung über HTTPS herzustellen, würde die gesamte Kommunikation zwischen Websites und ihren Besuchern im Klartext ausgetauscht und ist für Dritte leicht lesbar.

Der einzige Nachteil dieses jüngsten Vorstoßes zur universellen Verschlüsselung besteht darin, dass ein Zustrom neuer Kunden in einen unbekannten Markt gezwungen wird, der nur sehr wenig dazu beiträgt, sich für den durchschnittlichen Website- oder Geschäftsinhaber weniger verwirrend zu machen.

Dieser Artikel dient als umfassender Leitfaden für alles, was mit SSL / TLS zu tun hat. Wir legen den Grundstein, indem wir grundlegende Konzepte wie Verschlüsselung, HTTPS und die Art der Internetverbindungen behandeln.

Hoffentlich sind Sie am Ende zuversichtlich, Folgendes auszuwählen: Kaufund implementieren Sie ein TLS-Zertifikat. Denken Sie daran, wenn Sie Fragen haben, können Sie diese in den Kommentaren unten hinterlassen.

Foundational Elements

Beginnen wir mit der Erörterung des Konzepts, das all dem zugrunde liegt: der Verschlüsselung.

Die Verschlüsselung ist in ihrer einfachsten Iteration kaum mehr als das Verwürfeln von Daten - unter Verwendung einer vorgegebenen Chiffre oder eines Schlüssels -, so dass sie von niemandem außer einer anderen Partei mit demselben privaten Schlüssel unlesbar gemacht werden.

Im Laufe der Geschichte war die Verschlüsselung mit privaten Schlüsseln das am häufigsten verwendete Modell. Bei der Verschlüsselung mit privaten Schlüsseln müssen beide Parteien einen privaten Schlüssel besitzen oder zumindest austauschen, mit dem Informationen sowohl verschlüsselt als auch entschlüsselt werden können.

Schon früh waren die meisten Chiffren, die diesen Kryptosystemen zugrunde lagen, primitiv und stützten sich auf einfache Substitutionen oder das Ersetzen gebräuchlicher Wörter durch Zeichen. Aber im Laufe der Zeit wurden die Chiffren mehr von der Mathematik beeinflusst und wurden immer komplexer.

Zum Beispiel schuf der Kryptograf von König Ludwig XIV. Mitte des 1600. Jahrhunderts in Frankreich eine Chiffre, die so gut gestaltet war, dass sie erst 250 Jahre später und nur teilweise gebrochen wurde. Bis heute gibt es in den französischen Archiven Aufzeichnungen im Wert von Hunderten von Jahren, die möglicherweise nie entschlüsselt werden.

Während die Verschlüsselung in der Vergangenheit ein Mittel war, um verdeckt oder geheim zu sein, hat das Aufkommen des Internets das Konzept mehr zum Mainstream gemacht. Das Internet ist allgegenwärtig und erfüllt eine Reihe kritischer Funktionen. Jeden Tag nutzen Milliarden von Menschen es, um auf vertrauliche Informationen zuzugreifen und diese zu senden, ihre Finanzen zu verwalten und Geschäfte mit Unternehmen zu tätigen - wie Sie es nennen.

Das Problem ist, dass das Internet nicht vollständig darauf ausgelegt war, sich an das anzupassen, was es geworden ist. Schon früh, als die Wissenschaft und die US-Regierung erste Netzwerkprotokolle entwickelten, wurde das Internet nur als Mechanismus für den freien Informationsaustausch zwischen der Regierung und akademischen Institutionen gesehen. Zu diesem Zeitpunkt waren kommerzielle Aktivitäten online illegal. eCommerce war noch kein Wort, das erfunden worden war. Und die Website war eher geografisch Vorstellung.

Als HTTP oder das Hypertext Transfer Protocol 1991 erstmals eingeführt wurden, war die Tatsache, dass die Verbindungen, die es bildete, Daten im Klartext austauschten, kein disqualifizierendes Problem.

Die Dinge sind heute ganz anders. Bei den online ausgetauschten Informationen handelt es sich nicht um akademische Forschung oder frei verfügbare Informationen, sondern um persönlich identifizierbare Informationen und sensible Daten, die Menschen Geld oder in einigen Regionen sogar das Leben kosten können. Dies erforderte einen sichereren Ansatz.

Die Antwort war Verschlüsselung.

Ein Problem beim Schlüsselaustausch

Ein Problem, das selbst die besten Kryptosysteme historisch geplagt hat, besteht bis heute fort.

Was wir zuvor besprochen haben und was traditionell der Standard für die Verschlüsselung war, ist die Verschlüsselung mit privaten Schlüsseln. Dies wird auch als symmetrische Verschlüsselung oder bidirektionale Verschlüsselung bezeichnet. Private Schlüssel übernehmen sowohl die für die Kommunikation erforderlichen Verschlüsselungs- als auch Entschlüsselungsfunktionen.

Damit die Verschlüsselung mit privaten Schlüsseln funktioniert, muss der private Schlüssel zwischen Parteien übertragen werden, oder beide Parteien müssen über eine eigene Kopie verfügen. In beiden Fällen war die Sicherheit privater Schlüssel für die Integrität des Kryptosystems von entscheidender Bedeutung, und wie Sie zweifellos vermuten können, ist der Schlüsselaustausch ein Problem, das so alt ist wie die Verschlüsselung selbst.

Dann, in den 1970er Jahren - technisch zwei verschiedene Zeiten, ein ganzer Ozean voneinander entfernt - wurde eine neue Form der Verschlüsselung konzipiert und zum Leben erweckt: die Verschlüsselung mit öffentlichen Schlüsseln.

Während die Verschlüsselung mit privatem Schlüssel eine symmetrische Zwei-Wege-Funktion ist, bei der der private Schlüssel Daten sowohl verschlüsseln als auch entschlüsseln kann, ist die Verschlüsselung mit öffentlichem Schlüssel asymmetrisch. Einweg. Anstelle eines einzelnen privaten Schlüssels gibt es ein öffentlich-privates Schlüsselpaar. Der öffentliche Schlüssel übernimmt die Verschlüsselung und ist, wie der Name schon sagt, öffentlich verfügbar, während der private Schlüssel, der die Entschlüsselung übernimmt, von seinem Besitzer geheim gehalten wird. Mit dem öffentlichen Schlüssel kann man ein Datenelement verschlüsseln und an den Besitzer des Schlüssels senden, wo nur er es entschlüsseln kann.

Großartig, aber wie ist das nützlich?

Die Einwegverschlüsselung ist nicht ideal für die Verschlüsselung von Internetverbindungen. Sie ist schwierig zu kommunizieren, wenn eine Partei nur verschlüsseln und die andere nur entschlüsseln kann. Nein, um eine Internetverbindung zu verschlüsseln, müssten Sie eine symmetrische Verschlüsselung mit privatem Schlüssel verwenden.

Aber wie tauscht man Schlüssel aus? Besonders online?

Verschlüsselung mit öffentlichem Schlüssel.

Und genau darum geht es bei SSL / TLS: um den sicheren Schlüsselaustausch.

Hier verbinden wir all diese Konzepte. Wenn Sie möchten, dass Ihre Kommunikation mit einer Website privat ist, müssen Sie eine sichere Verbindung herstellen. Wenn Sie eine sichere Verbindung zu dieser Website herstellen möchten, müssen Sie symmetrische private Schlüssel austauschen, damit Sie mit ihnen kommunizieren können. SSL / TLS (und PKI im Allgemeinen) ist nur ein ausgefallener Mechanismus zum Erstellen und Austauschen dieses Sitzungsschlüssels.

Mit SSL / TLS können Sie den Server oder die Organisation authentifizieren, mit der Sie eine Verbindung herstellen möchten, und sicherstellen, dass Sie die privaten Schlüssel, mit denen Sie Ihre Kommunikation mit der beabsichtigten Partei verschlüsseln, sicher austauschen.

Leider haben SSL / TLS und PKI eine Menge Terminologie und bewegliche Teile, die Menschen leicht verwirren können, aber diese glauben, dass dies nur eine elegante moderne technologische Lösung für ein Zeitalter ist, wenn man die Mathematik und den Fachjargon entfernt -altes Problem: Schlüsselaustausch.

Lassen Sie uns nun einige Schlüsselbegriffe durchgehen

Bevor wir weiter gehen, gehen wir noch ein paar andere Schlüsselbegriffe durch. Wir haben bereits das HTTP-Hypertext-Übertragungsprotokoll eingeführt, das seit Jahrzehnten das Rückgrat des Internets ist. Aber wie wir bereits besprochen haben, hat sich das Internet zu etwas ganz anderem entwickelt als bei der Erstveröffentlichung von HTTP im Jahr 1991.

Ein sichereres Protokoll wurde benötigt. Also HTTPS.

HTTPS, das manchmal als HTTP über TLS bezeichnet wird, verwendet Verschlüsselung, um die Daten, die während einer Verbindung ausgetauscht werden, für andere als die beabsichtigte Partei unlesbar zu machen. Dies ist besonders wichtig, wenn Sie die Natur einer modernen Internetverbindung berücksichtigen.

Während in den Anfängen des Internets eine Verbindung relativ direkt war, werden Verbindungen jetzt über Dutzende von Geräten auf dem Weg zu ihrem endgültigen Ziel geleitet. Wenn Sie dies jemals in der Praxis demonstrieren wollten, öffnen Sie die Eingabeaufforderung auf Ihrem Betriebssystem und geben Sie den Befehl "tracert geekflare.com" ein.

Was Sie sehen werden, ist der Pfad, den Ihre Verbindung auf dem Weg zum Ziel zurückgelegt hat. Bis zu 30 Sprünge. Das bedeutet, dass Ihre Daten jedes dieser Geräte durchlaufen, bevor sie die Website oder Anwendung erreichen, mit der Sie eine Verbindung herstellen. Und wenn jemand einen Paket-Sniffer oder einen Listener auf einem dieser Geräte installiert hat, kann er alle übertragenen Daten stehlen und in einigen Fällen sogar die Verbindung manipulieren.

Dies wird als MITM-Angriff (Man-in-the-Middle) bezeichnet.

Wenn Sie mehr über MITM-Angriffe erfahren möchten, dann Schauen Sie sich diesen Online-Kurs an.

Mit modernen Internetverbindungen kann viel mehr Fläche abgedeckt werden, als die überwiegende Mehrheit der Menschen erkennt. Deshalb ist es wichtig, dass die Daten während der Übertragung verschlüsselt werden. Sie haben keine Ahnung, wer zuhören könnte oder wie einfach das ist.

Eine HTTP-Verbindung wird über Port 80 hergestellt. Für unsere Zwecke können Sie sich Ports als Konstrukte vorstellen, die einen Netzwerkdienst oder ein Netzwerkprotokoll angeben. Eine Standard-Website, die über HTTP bereitgestellt wird, verwendet Port 80. HTTPS verwendet normalerweise Port 443. Wenn eine Website ein Zertifikat installiert, kann sie ihre HTTP-Seiten auf HTTPS-Seiten umleiten, und die Browser der Benutzer versuchen, bis zur Authentifizierung eine sichere Verbindung über Port 443 herzustellen.

Leider werden die Begriffe SSL / TLS, HTTPS, PKI und Verschlüsselung häufig verwendet, manchmal sogar synonym verwendet. Um die anhaltende Verwirrung zu beseitigen, finden Sie hier eine Kurzanleitung:

• SSL - Secure Sockets Layer, das ursprüngliche Verschlüsselungsprotokoll, das mit HTTPS verwendet wird
• TLS - Transport Layer Security, das neuere Verschlüsselungsprotokoll, das SSL ersetzt hat
• HTTPS - Die sichere Version von HTTP, mit der Verbindungen zu Websites hergestellt werden
• PKI - Öffentliche Schlüsselinfrastruktur bezieht sich auf das gesamte Vertrauensmodell, das die Verschlüsselung mit öffentlichen Schlüsseln erleichtert

SSL / TLS arbeitet zusammen, um HTTPS-Verbindungen zu aktivieren. Und PKI bezieht sich auf das Ganze, wenn Sie herauszoomen.

Verstanden? Mach dir keine Sorgen, du wirst.

Building a Public Key Infrastructure

Nachdem wir den Grundstein gelegt haben, wollen wir die Architektur des Vertrauensmodells im Herzen von SSL / TLS verkleinern.

Wenn Sie auf eine Website gelangen, überprüft Ihr Browser zunächst die Echtheit des SSL / TLS-Zertifikats, mit dem die Website es präsentiert. Wir werden in einigen Abschnitten erfahren, was nach dieser Authentifizierung passiert, aber wir werden zunächst das Vertrauensmodell erörtern, das all dies ermöglicht.

Zunächst stellen wir die Frage: Woher weiß mein Computer, ob er einem bestimmten SSL / TLS-Zertifikat vertrauen soll?

Um dies zu beantworten, müssen wir die PKI und die verschiedenen Elemente, die sie funktionieren lassen, diskutieren. Wir beginnen mit Zertifizierungsstellen und Root-Programmen.

Zertifizierungsstellen

Eine Zertifizierungsstelle ist eine Organisation, die eine Reihe vorgegebener Standards einhält, um vertrauenswürdige digitale Zertifikate ausstellen zu können.

Es gibt Dutzende von Zertifizierungsstellen gratis und kommerziell, die vertrauenswürdige Zertifikate ausstellen können.

Sie alle müssen sich an eine Reihe von Standards halten, die im CA / Browser-Forum, das als Regulierungsbehörde für die TLS-Branche fungiert, diskutiert und gesetzlich geregelt wurden. Diese Standards beschreiben Dinge wie:

• Technische Sicherheitsvorkehrungen, die vorhanden sein müssen
• Best Practices für die Durchführung der Validierung
• Best Practices herausgeben
• Widerrufsverfahren und Fristen
• Anforderungen an die Zertifikatsprotokollierung

Diese Richtlinien wurden von den Browsern in Verbindung mit den Zertifizierungsstellen festgelegt. Die Browser spielen eine einzigartige Rolle im TLS-Ökosystem.

Niemand kann ohne seinen Webbrowser irgendwohin im Internet gelangen. Daher empfängt und validiert der Browser das digitale TLS-Zertifikat und tauscht dann die Schlüssel mit dem Server aus. Aufgrund ihrer überragenden Rolle haben sie also einen erheblichen Einfluss.

Und es ist wichtig zu bedenken, dass Browser so skeptisch wie möglich gestaltet wurden. Nichts vertrauen. Dies ist der beste Weg, um die Sicherheit ihrer Benutzer zu gewährleisten. Wenn ein Browser einem digitalen Zertifikat vertrauen will, das möglicherweise zum Nachteil des Benutzers missbraucht werden kann, muss er sicher sein, dass derjenige, der dieses Zertifikat ausgestellt hat, seine Due Diligence durchgeführt hat.

Dies liegt in der Rolle und Verantwortung der Zertifizierungsstellen. Und die Browser halten auch keine Fehler aus. Es gibt einen wörtlichen Friedhof ehemaliger Zertifizierungsstellen, die den Browsern zuwiderlaufen und auf die Weide gestellt wurden.

Wenn eine Zertifizierungsstelle nachgewiesen hat, dass sie die grundlegenden Anforderungen des CAB-Forums erfüllt, und alle erforderlichen Audits und Überprüfungen bestanden hat, kann sie bei den verschiedenen Root-Programmen einen Antrag auf Hinzufügung ihrer Root-Zertifikate stellen.

Root-Programme

Ein Root-Programm - die wichtigsten werden von Apple, Microsoft, Google und Mozilla ausgeführt - ist der Apparat, der Root-Stores (manchmal auch als Trust Stores bezeichnet) überwacht und erleichtert. Hierbei handelt es sich um Sammlungen von Root-CA-Zertifikaten, die sich auf dem System eines Benutzers befinden. Wieder einmal sind diese Wurzeln unglaublich wertvoll und unglaublich gefährlich - sie können schließlich vertrauenswürdige digitale Zertifikate ausstellen -, daher ist die Sicherheit von größter Bedeutung.

Aus diesem Grund werden Zertifizierungsstellen fast nie direkt von den Stammzertifizierungsstellenzertifikaten selbst ausgestellt. Stattdessen drehen sie Zwischenstammzertifikate hoch und verwenden diese, um Endbenutzer- oder Blattzertifikate auszustellen. Sie können diese Roots auch an Sub-CAs weitergeben, bei denen es sich um Zertifizierungsstellen handelt, die keine dedizierten Roots haben, aber dennoch von ihren Zwischenprodukten signierte Zertifikate ausstellen können.

Lassen Sie uns das alles zusammenfassen. Wenn auf einer Website ein TLS-Zertifikat ausgestellt werden soll, wird auf dem Server, auf dem sie gehostet wird, eine sogenannte Certificate Signing Request (CSR) generiert. In dieser Anfrage sind alle Details enthalten, die die Website in das Zertifikat aufnehmen möchte. Wie Sie gleich sehen werden, kann die Menge an Informationen von vollständigen Geschäftsdetails bis zu einer einfachen Serveridentität variieren. Sobald die CSR abgeschlossen ist, werden sie zur Ausstellung an die Zertifizierungsstelle gesendet.

Vor der Ausstellung des Zertifikats muss die Zertifizierungsstelle ihre vom CA / Browser Forum vorgeschriebene Due Diligence durchführen und überprüfen, ob die in der CSR enthaltenen Informationen korrekt sind. Sobald dies überprüft wurde, signiert es das Zertifikat mit seinem privaten Schlüssel und sendet es zur Installation an den Eigentümer der Website zurück.

Verkettung von Zertifikaten

Nach der Installation des TLS-Zertifikats wird dem Browser des Benutzers jedes Mal, wenn jemand die Site auf dem Server besucht, auf dem es gehostet wird, das Zertifikat angezeigt. Der Browser überprüft die digitale Signatur auf dem Zertifikat, die von der vertrauenswürdigen Zertifizierungsstelle erstellt wurde und die dafür bürgt, dass alle im Zertifikat enthaltenen Informationen korrekt sind.

Hier kommt der Begriff Verkettung von Zertifikaten ins Spiel.

Der Browser liest die digitale Signatur und verschiebt ein Glied in der Kette. Als Nächstes überprüft er die digitale Signatur des Zwischenzertifikats, dessen privater Schlüssel zum Signieren des Blattzertifikats verwendet wurde. Die folgenden Signaturen werden fortgesetzt, bis entweder die Zertifikatkette an einem der vertrauenswürdigen Stammverzeichnisse in ihrem Stammspeicher endet oder bis die Kette ohne Erreichen eines Stammverzeichnisses beendet wird. In diesem Fall wird ein Browserfehler angezeigt und die Verbindung schlägt fehl.

Aus diesem Grund können Sie Ihre Zertifikate nicht ausstellen und selbst signieren.

Die Browser vertrauen nur SSL / TLS-Zertifikaten, die sie an ihren Stammspeicher zurückketten können (was bedeutet, dass sie von einer vertrauenswürdigen Entität ausgestellt wurden). Zertifizierungsstellen müssen sich an bestimmte Standards halten, um ihre Vertrauenswürdigkeit aufrechtzuerhalten, und selbst dann sind die Browser nicht bereit, ihnen zu vertrauen.

Browser haben keine solchen Zusicherungen für selbstsignierte Zertifikate, weshalb sie nur in internen Netzwerken, hinter Firewalls und in Testumgebungen bereitgestellt werden sollten.

SSL/TLS Certificate Types and Functionality

Bevor wir uns mit SSL / TLS in Bewegung befassen, wollen wir uns mit Zertifikaten und den verschiedenen verfügbaren Iterationen befassen. TLS-Zertifikate erleichtern das TLS-Protokoll und bestimmen die Bedingungen der verschlüsselten HTTPS-Verbindungen, die eine Website herstellt.

Wir haben bereits erwähnt, dass Sie durch die Installation eines TLS-Zertifikats Ihre Website so konfigurieren können, dass HTTPS-Verbindungen über Port 443 hergestellt werden. Sie fungiert auch als eine Art Namensschild für die Site oder den Server, mit dem Sie interagieren. Zurück zu der Idee, dass SSL / TLS und PKI im Kern exquisite Formen des sicheren Schlüsselaustauschs sind, hilft das SSL / TLS-Zertifikat dabei, den Browser darüber zu informieren, an wen der Sitzungsschlüssel gesendet wird - an wen die Partei am anderen Ende von Die Verbindung ist.

Wenn Sie die verschiedenen Iterationen von SSL / TLS-Zertifikaten aufschlüsseln, sollten Sie dies berücksichtigen. Zertifikate variieren in Bezug auf Funktionalität und Validierungsstufe. Oder anders ausgedrückt: Sie variieren je nach:

• Wie viele Identitäten müssen behauptet werden?
• Auf welchen Endpunkten soll die Identität behauptet werden?

Wenn Sie diese beiden Fragen beantworten, erhalten Sie einen ziemlich klaren Hinweis darauf, welche Art von Zertifikat Sie benötigen.

Wie viele Identitäten müssen bestätigt werden?

Für SSL / TLS-Zertifikate stehen drei verschiedene Validierungsstufen zur Verfügung, die je nach Anzahl der Identitätsinformationen, die Ihre Website bestätigen möchte, variieren.

• Domänenvalidierung SSL-Zertifikate - Serveridentität bestätigen
• Organisationsvalidierung SSL-Zertifikate - Bestätigen Sie die teilweise Organisationsidentität
• Erweiterte Validierung SSL-Zertifikate - Bestätigen Sie die vollständige Organisationsidentität

Domain Validation SSL-Zertifikate sind aufgrund ihres Preises und der Geschwindigkeit, mit der sie ausgestellt werden können, bei weitem am beliebtesten. Ein DV-SSL / TLS-Zertifikat erfordert eine einfache Überprüfung der Domänensteuerung, die auf verschiedene Arten durchgeführt werden kann. Sobald dies der Fall ist, kann das Zertifikat ausgestellt werden. Sie können auch einige 30-Tage- und 90-Tage-Versionen davon kostenlos erhalten, was zweifellos zu ihrem Marktanteil beigetragen hat.

Der Nachteil ist, dass DV-SSL-Zertifikate eine minimale Identität bestätigen. Und da auf fast der Hälfte aller Phishing-Websites inzwischen ein DV-SSL-Zertifikat installiert ist, kaufen sie Ihnen nicht unbedingt viel Vertrauen.

Organisationsvalidierung SSL-Zertifikate sind der ursprüngliche Typ des SSL / TLS-Zertifikats. Sie sind auch die einzige Art von SSL-Zertifikat, die eine IP-Adresse sichern kann, nachdem das CAB-Forum 2016 beschlossen hat, alle Intranet-SSL-Zertifikate ungültig zu machen. Die Organisationsvalidierung erfordert eine Überprüfung des Geschäftsbetriebs und kann in der Regel innerhalb von ein oder zwei Tagen durchgeführt werden - manchmal schneller. OV-SSL-Zertifikate bestätigen einige organisatorische Informationen, aber ein Internetbenutzer müsste auf das Vorhängeschlosssymbol klicken und danach suchen. Heutzutage werden viele OV-SSL-Zertifikate in großen Unternehmens- und Unternehmensnetzwerken bereitgestellt, beispielsweise für Verbindungen, die hinter Firewalls hergestellt werden.

Da weder DV- noch OV-SSL-Zertifikate eine ausreichende Identität aufweisen, um die meisten Browser zufrieden zu stellen, werden sie neutral behandelt.

Erweiterte Validierung SSL-Zertifikate sind bei weitem am umstrittensten, da einige in der Tech-Community der Ansicht sind, dass mehr getan werden muss, um die Validierung zu stärken, von der sie abhängen. EV SSL behauptet jedoch maximale Identität. Um die erweiterte Validierung abzuschließen, unterzieht die Zertifizierungsstelle die Organisation einem strengen Überprüfungsprozess, der in einigen Fällen mehr als eine Woche dauern kann.

Der Vorteil ist jedoch nicht zu leugnen: Da eine Website mit einem EV-SSL-Zertifikat eine ausreichende Identität aufweist, wird sie eindeutig vom Browser behandelt, einschließlich der Anzeige ihres Namens in der Adressleiste des Browsers.

Es gibt keinen anderen Weg, dies zu erreichen, und Sie können keinen vortäuschen - die EV-Adressleiste ist einer der wirksamsten visuellen Indikatoren, die wir heute haben.

What endpoints to assert Identity on

Die andere Art und Weise, wie SSL / TLS-Zertifikate variieren, betrifft die Funktionalität. Websites haben sich seit den Anfängen des Internets erheblich weiterentwickelt, wobei verschiedene Unternehmen Websites auf unterschiedliche Weise bereitstellen. Einige haben mehrere Domains für verschiedene Unternehmensbereiche. andere verwenden Subdomains für mehrere Funktionen und Webanwendungen. Einige verwenden beide.

Unabhängig vom Kontext gibt es ein SSL / TLS-Zertifikat, mit dessen Hilfe es gesichert werden kann.

Einzel Domain

Die primäre Website und das Standard-SSL-Zertifikat sind nur eine einzige Domain. Die meisten modernen SSL/TLS-Zertifikate sichern sowohl die WWW und Nicht-WWW Versionen dieser Domäne, aber es ist auf eine einzelne Domäne beschränkt. Du kannst Vergleichen Sie hier die SSL-Zertifikate.

Multi-Domain

Multi-Domain-Zertifikate oder Unified Communication-Zertifikate (im Fall von Microsoft Exchange- und Office Communications-Servern) existieren ebenfalls, um Organisationen die Möglichkeit zu geben, mehrere Domänen mit einem einzigen Zertifikat zu verschlüsseln. Das kann ein at seintractive Option, da sie Geld spart und die Verwaltung der Zertifikate (Abläufe/Verlängerungen) erheblich vereinfacht.

Verwendung von Multi-Domain- und UCC-Zertifikaten SAN, das Feld Alternativer Antragstellername in der CSR, um dem Zertifikat zusätzliche Domänen hinzuzufügen. Die meisten Zertifizierungsstellen erlauben bis zu 250 verschiedene SANs auf einem einzigen Zertifikat. Die meisten Multi-Domain-Zertifikate werden mit 2 bis 4 kostenlosen SANs geliefert. Der Rest kann bei Bedarf erworben werden.

Wildcard SSL-Zertifikate

Platzhalter-SSL-Zertifikate sind ein äußerst nützlicher Zertifikatstyp, da sie eine unbegrenzte Anzahl von Subdomains auf derselben Ebene der URL verschlüsseln können. Zum Beispiel, wenn Sie eine Website haben, die Subdomains verwendet wie:

• app.website.com
• portal.website.com
• user.website.com

Sie können sie alle mit demselben Wildcard-Zertifikat verschlüsseln, indem Sie im Feld FQDN Ihrer CSR ein Sternchen verwenden: * .website.com

Jetzt kann jede Subdomain, auch die, die Sie noch nicht hinzugefügt haben, mit diesem Zertifikat gesichert werden.

Wildcard-Zertifikate haben jedoch zwei Nachteile. Das erste ist, dass Sie durch die Verwendung des gleichen öffentlichen Schlüssels auf einigen Endpunkten anfälliger für bestimmte Exploits wie Bleichenbacher-Angriffe sind.

Das andere ist, dass es keine EV-Wildcard-Option gibt. Aufgrund der Offenheit der Wildcard-Funktionalität können die Browser diese Vertrauensstufe nicht delegieren. Wenn Sie die EV-Adressleiste in Ihren Subdomains haben möchten, müssen Sie diese einzeln verschlüsseln oder ein EV-Multi-Domain-Zertifikat verwenden.

Platzhalter für mehrere Domänen

Der Multi-Domain Wildcard ist eine relativ neue Erweiterung des SSL / TLS-Ökosystems und kann bis zu 250 verschiedene Domänen verschlüsseln. In den SANs-Feldern kann jedoch auch ein Sternchen verwendet werden, mit dem Sie 250 verschiedene Domänen UND alle zugehörigen Domänen zuerst verschlüsseln können Subdomains auf Ebene.

Ein weiterer Anwendungsfall für den Multi-Domain-Wildcard ist ein Multi-Level-Wildcard, bei dem Subdomains auf mehreren Ebenen der URL verschlüsselt werden können (ein Standard-Wildcard kann sie nur auf einer Ebene verschlüsseln).

Aufgrund der Wildcard-Funktionalität sind Multi-Domain-Wildcards auch in EV nicht verfügbar.

SSL/TLS in Motion

Nachdem wir alle wichtigen Konzepte für SSL / TLS und PKI behandelt haben, lassen Sie uns alles zusammenfassen und in Bewegung setzen.

Validierung und Ausstellung

Beginnen wir ganz am Anfang mit einer Website, die ein SSL / TLS-Zertifikat von einer Zertifizierungsstelle oder einem Reseller kauft. Nach dem Kauf erstellt der Organisationskontakt, der die Zertifikaterfassung abwickelt, eine Zertifikatsignierungsanforderung auf dem Server, auf dem das Zertifikat installiert wird (dem Server, auf dem die Website gehostet wird).

Zusammen mit der CSR generiert der Server auch ein öffentliches / privates Schlüsselpaar und speichert den privaten Schlüssel lokal. Wenn die Zertifizierungsstelle die CSR und den öffentlichen Schlüssel empfängt, führt sie die erforderlichen Validierungsschritte aus, um sicherzustellen, dass alle im Zertifikat enthaltenen Informationen korrekt sind. Bei Geschäftsauthentifizierungszertifikaten (nicht DV) müssen im Allgemeinen die Registrierungsinformationen und öffentlichen Aufzeichnungen einer Organisation in Regierungsdatenbanken nachgeschlagen werden.

Nach Abschluss der Validierung verwendet die Zertifizierungsstelle einen der privaten Schlüssel eines ihrer ausstellenden Zertifikate, normalerweise eines Zwischenstamms, und signiert das Zertifikat, bevor es an den Websitebesitzer zurückgegeben wird.

Jetzt kann der Websitebesitzer das neu ausgestellte SSL / TLS-Zertifikat nehmen, es auf seinem Server installieren und die Website so konfigurieren, dass HTTPS-Verbindungen über Port 443 hergestellt werden (mithilfe von 301-Weiterleitungen wird Datenverkehr von den bereits vorhandenen HTTP-Seiten an ihre neuen HTTPS-Gegenstücke gesendet). .

Authentifizierung und SSL-Handshake

Nachdem das SSL / TLS-Zertifikat installiert und die Website für HTTPS konfiguriert wurde, schauen wir uns an, wie es verschlüsselte Verbindungen mit den Besuchern der Site erleichtert.

Bei der Ankunft auf der Website präsentiert der Server dem Browser des Benutzers das SSL / TLS-Zertifikat. Der Browser des Benutzers führt dann eine Reihe von Überprüfungen durch.

Zunächst wird das Zertifikat authentifiziert, indem die digitale Signatur angezeigt und die Zertifikatkette befolgt wird. Außerdem wird sichergestellt, dass das Zertifikat nicht abgelaufen ist, und es werden CT-Protokolle (Certificate Transparency) und CRLs (Certificate Revocation Lists) überprüft. Vorausgesetzt, die Kette führt zurück zu einer der Wurzeln im Vertrauensspeicher des Systems und ist gültig, vertraut der Browser dem Zertifikat.

Jetzt ist Handshake-Zeit.

Der SSL / TLS-Handshake besteht aus einer Reihe von Schritten, bei denen der Client (Benutzer) und der Server (Website) die Parameter ihrer sicheren Verbindung aushandeln, symmetrische Sitzungsschlüssel generieren und dann austauschen.

Zuerst werden sie sich für eine Chiffresuite entscheiden. Eine Chiffresuite ist die Gruppe von Algorithmen und Chiffren, die für die Verbindung verwendet werden. Das SSL / TLS-Zertifikat enthält eine Liste der vom Server unterstützten Cipher Suites. Im Allgemeinen enthält eine Verschlüsselungssuite einen Verschlüsselungsalgorithmus mit öffentlichem Schlüssel, einen Schlüsselgenerierungsalgorithmus, einen Nachrichtenauthentifizierungsalgorithmus und einen symmetrischen oder Massenverschlüsselungsalgorithmus - obwohl dies in TLS 1.3 verfeinert wurde.

Nachdem die Liste der unterstützten Chiffren angezeigt wurde, wählt der Client eine akzeptable aus und teilt sie dem Server mit. Von dort generiert der Client einen symmetrischen Sitzungsschlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel und sendet ihn dann an den Server, der über den privaten Schlüssel verfügt, der zum Entschlüsseln des Sitzungsschlüssels erforderlich ist.

Sobald beide Parteien eine Kopie des Sitzungsschlüssels haben, kann die Kommunikation beginnen.

Und das ist SSL / TLS.

Sie können sehen, wie alle Konzepte, die wir zuvor durchlaufen haben, miteinander interagieren, um ein ausgeklügeltes und dennoch elegantes System zur Sicherung von Internetverbindungen zu schaffen. Wir verwenden die Kryptografie mit öffentlichen Schlüsseln, um die Sitzungsschlüssel sicher auszutauschen, mit denen wir kommunizieren werden. Den Zertifikaten, die die Server- oder Organisationsidentität bestätigen, kann aufgrund der Infrastruktur zwischen den verschiedenen Zertifizierungsstellen, Browsern und Stammprogrammen vertraut werden.

Die Kommunikation erfolgt durch symmetrische Verschlüsselung mit privaten Schlüsseln, die von den klassischen Kryptosystemen der Antike abstammt.

Es gibt viele bewegliche Teile, aber wenn Sie langsamer werden und sie alle einzeln verstehen, ist es viel einfacher zu sehen, wie alles zusammenarbeitet.

Bevor Sie loslegen, lassen Sie uns einige SSL / TLS-bezogene Schritte abschließen, die Sie nach der Installation / Konfiguration vornehmen können, um Ihre Investition optimal zu nutzen.

After SSL/TLS – Getting the most out of your implementation

Nur ein Zertifikat installiert und Ihre Website richtig konfiguriert zu haben, bedeutet nicht, dass Ihre Website sicher ist. TLS ist nur eine Komponente einer umfassenderen, ganzheitlichen Cyber-Verteidigungsstrategie. Trotzdem eine wichtige Komponente. Lassen Sie uns einige Dinge behandeln, die Sie tun können, um sicherzustellen, dass Sie die Implementierung optimal nutzen.

Deaktivieren Sie die Serverunterstützung für alte Protokolle

Um auf die Konversation zurückzukommen, die wir zuvor über Cipher Suites geführt haben, müssen Sie bei der Konfiguration Ihres Servers entscheiden, welche Cipher Suites und SSL / TLS-Versionen unterstützt werden sollen. Es ist unbedingt erforderlich, dass Sie die Unterstützung für ältere SSL / TLS-Versionen sowie für bestimmte Algorithmen deaktivieren Verwundbarkeit verhindern zu mehreren bekannten Exploits.

SSL 2.0 und SSL 3.0 sind beide über 20 Jahre alt. Best Practice war es, die Unterstützung für sie vor Jahren abzulehnen, aber bis heute erlauben rund 7% der Alexa-Top-100,000 sie noch. Dies ist gefährlich, da Sie SSL-Stripping- und Downgrade-Angriffen wie POODLE ausgesetzt sind.

TLS 1.0 und TLS 1.1 sind ebenfalls ausgeliehen.

Die großen Technologieunternehmen Apple, Microsoft, Google und Mozilla haben diesen Herbst gemeinsam angekündigt, dass sie die Unterstützung für TLS 1.0 und 1.1 Anfang 2020 ablehnen werden.

Die Protokollversionen sind anfällig für Schwachstellen wie POODLE, FREAK, BEAST und CRIME (dies sind alles Akronyme). TLS 1.2 ist seit zehn Jahren nicht mehr erhältlich und sollte der Standard sein. TLS 1.3 wurde im letzten Sommer abgeschlossen und die Adoption hat sich seitdem stetig weiterentwickelt.

Darüber hinaus gibt es bestimmte Algorithmen, die ebenfalls nicht verwendet werden sollten. DES kann zum Beispiel in wenigen Stunden kaputt gehen. RC4 ist mehr verletzlich als einmal angenommen und wurde bereits durch die Datensicherheitsstandards der Zahlungskartenindustrie verboten. Und schließlich ist es angesichts der jüngsten Exploits nicht mehr ratsam, RSA für den Schlüsselaustausch zu verwenden.

Vorgeschlagene Algorithmen / Chiffren:

• Schlüsselaustausch: Elliptic Curve Diffie-Helman (ECDH)
• Authentifizierung: Elliptic Curve Digital Signature Algorithmus (ECDSA)
• Symmetrische / Massenverschlüsselung: AES 256 im Galois-Zählermodus (AES256-GCM)
• MAC-Algorithmus: SHA-2 (SHA384)

Immer ein SSL

In der Vergangenheit haben Websites manchmal nur die Webseiten migriert, auf denen Informationen zu HTTPS gesammelt werden, während der Rest der Website über HTTP bereitgestellt wird. Dies ist eine schlechte Praxis.

Zusätzlich zu der Tatsache, dass Google diese Seiten als "nicht sicher" markiert, setzen Sie die Besucher Ihrer Website möglicherweise einem Risiko aus, indem ihre Browser zwischen verschlüsselten und HTTP-Seiten hin und her springen.

Sie sollten Ihre gesamte Website für HTTPS konfigurieren. Dies wird als Always-on-SSL bezeichnet. Schließlich ist es nicht so, dass Sie per Seite bezahlen. Ihr SSL / TLS-Zertifikat kann Ihre gesamte Site verschlüsseln. Also mach es so.

Richten Sie einen CAA-Datensatz (Certificate Authority Authorization) ein

Eines der größten Risiken digitaler Zertifikate ist im Allgemeinen die Fehlausstellung. Wenn eine andere Partei als Sie ein SSL / TLS-Zertifikat für IHRE Website erhält, kann sie sich effektiv als Sie ausgeben und alle möglichen Probleme verursachen.

CAA-Aufzeichnungen tragen zur Minderung dieses Risikos bei, indem sie einschränken, welche Zertifizierungsstellen digitale Zertifikate für Ihre Website ausstellen können. Das CA / Browser-Forum verlangt von den Zertifizierungsstellen, dass sie die CAA-Datensätze überprüfen, bevor sie ein Zertifikat ausstellen. Wenn die Zertifizierungsstelle nicht über die Berechtigung zum Ausstellen für diese Site verfügt, kann dies nicht der Fall sein. Dies würde als Fehlausgabe angesehen und den Zorn der Browser-Community auf sich ziehen.

Das Hinzufügen eines CAA-Eintrags ist relativ einfach. Es handelt sich um einen einfachen DNS-Eintrag, der über die Benutzeroberfläche der meisten Hosting-Plattformen hinzugefügt werden kann. Sie können die Zertifizierungsstellen einschränken, die möglicherweise für Ihre Domain ausgestellt werden, sowie festlegen, ob möglicherweise auch Wildcard-Zertifikate für diese Domain ausgestellt werden.

Fügen Sie Ihre Website zur HSTS-Preload-Liste hinzu

HTTP Strict Transport Security (HSTS) ist ein HTTP-Header, der Browser dazu zwingt, nur HTTPS-Verbindungen mit einer bestimmten Site herzustellen. Selbst wenn der Webbenutzer versucht, zur HTTP-Version der Seite zu wechseln, wird auf diese Weise nur die HTTPS-Version aufgerufen. Dies ist wichtig, da dadurch das Fenster für mehrere bekannte Exploits wie Downgrade-Angriffe und Cookie-Hijacking geschlossen wird.

Leider verbleibt bei HSTS ein winziger Angriffsvektor, weshalb Sie Ihre Website zur Preload-Liste hinzufügen sollten. Wenn ein Besucher auf Ihre Website gelangt, lädt sein Browser normalerweise den HTTP-Header herunter und hält ihn dann so lange ein, wie die Richtlinie auf Dauer festgelegt wurde. Aber bei diesem ersten Besuch, bevor der Header empfangen wurde, gibt es noch eine winzige Öffnung für einen Angreifer.

Die HSTS-Vorladeliste des Datensatzes wird von Google ausgeführt und einige Variationen davon werden von allen gängigen Browsern verwendet. Diese Browser können sich nur über HTTPS mit einer Website verbinden, die auf der Liste steht - auch wenn sie dort noch nie zuvor besucht wurde. Es kann ein oder zwei Wochen dauern, bis Ihre Website in der Liste angezeigt wird, da Aktualisierungen der Liste in Verbindung mit den Veröffentlichungsplänen der Browser veröffentlicht werden.

Sie können sich auf das folgende Implementierungshandbuch beziehen.

Wie implementiere ich SSL in Apache Tomcat?

Wie implementiere ich ein ZeroSSL-Zertifikat in Apache und Nginx?

Wie implementiere ich SSL in WordPress auf Shared Hosting, Cloud?

SSL/TLS FAQ

Was ist ein X.509-Zertifikat?

X.509 bezieht sich auf den Typ des digitalen Zertifikats, das mit SSL / TLS und anderen PKI-Typen verwendet wird. X.509 ist ein Verschlüsselungsstandard für öffentliche Schlüssel. Gelegentlich sehen Sie, dass Unternehmen das X.509-Zertifikat anstelle des "digitalen Zertifikats" oder des "PKI-Zertifikats" verwenden.

Warum laufen SSL / TLS-Zertifikate ab?

Dafür gibt es zwei Gründe.

Das erste ist, dass sich das Internet ständig ändert, Websites kommen und Websites gehen. Angesichts der Sensibilität der Browser für das Vertrauen in diese Zertifikate möchten sie zunächst wissen, dass die Websites, auf denen die Zertifikate präsentiert werden, regelmäßig überprüft werden. Es unterscheidet sich nicht wesentlich davon, wie Sie gelegentlich einchecken müssen, um die Informationen auf Ihrem Führerschein zu aktualisieren.

Der andere Grund ist eher technischer Natur. Es ist schwieriger, Aktualisierungen und technische Änderungen zu verbreiten, wenn Zertifikate 3-5 Jahre lang nicht ablaufen. Wenn Zertifikate alle 24 Monate ablaufen, beträgt die längste Zeit, in der ein Zertifikat veraltet sein könnte, zwei Jahre. Im Jahr 2017 wurde die maximale Gültigkeit von drei Jahren auf zwei Jahre reduziert. Es wird wahrscheinlich in Kürze auf 12 Monate verkürzt.

Wie erneuere ich ein SSL / TLS-Zertifikat?

Die Verlängerung kann etwas falsch sein, da Sie das alte Zertifikat durch ein neu ausgestelltes ersetzen. Wenn Sie dies regelmäßig tun, bleiben Sie über neue Fortschritte bei der Verschlüsselungstechnologie auf dem Laufenden und stellen sicher, dass Ihre Validierungsinformationen auf dem neuesten Stand bleiben. Zertifizierungsstellen können die ursprünglich bereitgestellten Validierungsinformationen nur so lange wiederverwenden, bis die Basisanforderungen sie zur erneuten Validierung zwingen.

Bei der Verlängerung können Sie entweder den gleichen Zertifikatstyp wie zuvor beibehalten oder sich für etwas Neues entscheiden. Sie können sogar die Zertifizierungsstellen ändern. Die große Sache ist, wie viel Zeit Sie noch auf dem ablaufenden Zertifikat haben - Sie können bis zu drei Monate übertragen. Solange Sie vor Ablauf des Zertifikats verlängern, können Sie die verbleibende Zeit übertragen und alle Validierungsinformationen wiederverwenden, die seit Ihrer letzten Validierung nicht abgelaufen sind. Wenn Sie es ablaufen lassen, fangen Sie von vorne an.

Was ist HTTPS-Inspektion?

Viele größere Unternehmen mit größeren Netzwerken möchten einen Überblick über ihren Datenverkehr haben. In dieser Hinsicht ist HTTPS ein zweischneidiges Schwert. Es schützt die Privatsphäre der Menschen, kann aber auch dazu beitragen, dass sich Cyberkriminelle verstecken. Viele Unternehmen entschlüsseln ihren HTTPS-Verkehr auf einem Edge-Gerät oder einer Middlebox und senden ihn dann entweder im Klartext hinter ihrer Firewall weiter oder verschlüsseln ihn erneut und senden ihn auf dem Weg. Wenn Sie den Datenverkehr nicht erneut verschlüsseln, wird er als SSL-Beendigung bezeichnet. Wenn Sie erneut verschlüsseln, spricht man von SSL-Bridging.

Was ist SSL-Offloading?

SSL-Offloading ist eine weitere Unternehmenspraxis. In der Größenordnung können Tausende von Handshakes und das anschließende Ver- und Entschlüsseln all dieser Daten die Ressourcen eines Netzwerks belasten. Viele größere Netzwerke verlagern die SSL-Funktionen auf ein anderes Gerät, sodass sich der Anwendungsserver auf seine Kernaufgaben konzentrieren kann. Dies wird manchmal als Lastausgleich bezeichnet.

Warum hat mir meine Zertifizierungsstelle ein Zwischenzertifikat gesendet?

Erinnerst du dich an früher, als wir über Root-Programme gesprochen haben?

Very OS verfügt über einen Root-Speicher, mit dem PKI-Vertrauensurteile gefällt werden. CAs stellen jedoch keine Endbenutzerzertifikate von diesen Wurzeln aus, aus Angst, was passieren würde, wenn eines jemals widerrufen werden müsste. Stattdessen spinnen sie Zwischenwurzeln und geben diese ab. Das Problem ist, dass sich diese Zwischenwurzeln nicht im Vertrauensspeicher eines Systems befinden.

Wenn auf der Website das Zwischenzertifikat nicht zusammen mit dem Blatt-SSL / TLS-Zertifikat angezeigt wird, können viele Browser die Zertifikatkette nicht abschließen und geben eine Warnung aus. Einige Browser speichern Zwischenzertifikate zwischen, aber es wird immer noch als bewährte Methode angesehen, Zwischenprodukte zusammen mit Ihrem Blattzertifikat zu installieren.

Welche Dokumentation benötige ich für ein SSL-Zertifikat mit erweiterter Validierung?

In den meisten Fällen versucht die Zertifizierungsstelle, die die erweiterte Validierung durchführt, zunächst, über öffentlich verfügbare Ressourcen der „Regierungsbehörde“ auf die Informationen zuzugreifen.

An einigen Standorten ist dies jedoch möglicherweise nicht möglich. Es gibt jedoch einige Dinge, die dazu beitragen können, die Validierung zu beschleunigen. Während die Anzahl der Validierungsprüfungen, die ein Professional Opinion Letter erfüllen kann, in letzter Zeit reduziert wurde, kann ein Anwalt oder Buchhalter mit gutem Ruf immer noch erheblich helfen.

Darüber hinaus können Sie einen von der Regierung ausgestellten Geschäftsausweis oder ein „Proof of Right“ -Dokument bereitstellen, mit dem Ihre Organisation das Recht erhält, unter dem aufgeführten Namen Geschäfte zu tätigen. Einige Beispiele für diese Dokumente sind:

• Satzungs
• Ausbildungsbescheinigungen
• Business / Vendor / Merchant-Lizenzen
• Charterdokumente
• Partnerschaftsabkommen
• Registrierung des Handels oder des angenommenen Namens
• Handelsregister

Schlusswort

Ich hoffe, dies gibt Ihnen eine Vorstellung von SSL / TLS. Wenn Sie mehr erfahren möchten, würde ich empfehlen an diesem Online-Kurs teilnehmen.

Dieser Beitrag wurde von Patrick Nohe, Herausgeber von, verfasst Vom SSL Store ausgepeitscht, ein Blog über Cybersicherheitsnachrichten und -trends.